Pete Dowson

Well, yes, and I'll be doing some tests along those lines when I can (still tied up here). But the theory is incomplete, because I still cannot understand why restarting the scan doesn't work. SimConnect should first give me the AI current positions, even if they haven't really changed. I'll look at my code too, to see if I've somewhere imposed a minimum level of traffic before I bother! It's a possibility I suppose, though unlikely, and if so it dates back a very long time, maybe to FS9 in 2003/4. Pete

Is the G1000 a standard FSX (or is it P3D?) gauge, or is this an add-on gauge, part of the Flight1 aircraft? If it isn't a standard part of the sim it won't have any FSUIPC / SimConnect controls built in. The only G1000-dedicated FS controls are those listed starting with 'G1000'. I don't know the G1000 and don't know what they all do -- there aren't any specifically labelled for radio displays. They all see to be concerned only with the PFD and MFD aspects. So I assume the radios are really standard FS radios as in any other FS aircraft, but with only one displays for both 1 & 2. I've just looked at the Mooney Acclaim in P3D, with G1000. It has displays for NAV1/NAV2, COM1/COM2, both active and standby and you change the selectopn between 1 & 2 by clicking with the mouse just below the frequency knob. By logging I see there's no controls for that, but by logging L_Vars using the supplied Log LVars lua plug-in I see that there are L:Vars for this, as follows: L:SelectedCom2=0 for COM1 L:SelectedCom2=1 for COM2 L:SelectedNav2=0 for NAV1 L:SelectedNav2=1 for NAV2 So, if you ARE talking about the G1000 supplied with FSX/P3D then I think you will just need macros to send those LVars with parameter 0 or 1. Pete

No,, not really, not without lots of programming. But isn't that the shared cockpit facility built into FSX and, I presume, P3D? I seem to remember such a thing demonstrated by Microsoft at one of the conferences launching FSX way back in 2005/6. Or was I dreaming? I really had little interest in it so never followed it up. It might be a good idea to ask in the FSX forum over on AVSIM, re-phrased of course. Maybe it wasn't even carried over into FSX-SE, because Steam have a different idea of muliplayer etc, so ask about FSX first. Or maybe you need to move to P3D. Pete

I'm not sure why that can happen -- though the 2 with identical GUIDs could explain that I suppose (it is supposed to be impossible), but it certainly sounds like the two button boxes are indistinguishable to Windows, and when you make other changes it re-scans and re-assigns GUIDs. That really wrecks the steps FSUIPC takes to check against this. Bodnar boards used to have that problem -- they were identical -- but now they have serial numbers and are not a problem. Best to set up a configuration, get it working, and leave it be. But, then, if you keep track of the assignments (keep the previous INI when making a change to the devices connected), it would be easy enough to edit the letters assigned in the INI to put things right again. Pete

I'm afriad you'll need to go into more detail that that. See below. GUIDs are supposed to be absolutely unique. It's the guarantee for those from Microsfot for the Windows GUID assignments. The fact that you get two the same amazes me and really does sohw something is rather corrupted in your Registry. In software there is absolutely no way I can distinguish between two devices with exactly the sme names and same GUIDs! It is supposed to be impossible! I suggest that you go remove the button box(es) and go into Windows Device Manager and uninstall them completely, driver included. Then check that there are no references anywhere to them in the Registry, using Registry Editor. Then install them again. Interesting. I've never seen an "odt" file before. I double clicked it and it opened as a table in Word. How do you make one of those files? Oddly, the two with the same GUID don't seem to have the problem. I certainly don't know why the two with the different GUIDs (8013 and 8015) got mixed up -- unless perhaps they are indistinguishable (same serial numbers etc -- use HidScanner to check that) and were unplugged/disconnected/powered off, so that when Windows saw them again it assigned the wrong GUIDs. Also, i don't really understand what the second 8007 was assigned to MIP Switches, but then labelled as New, No Assignments Yet! What's that about? I'd certainly expect some problems with absolutely identical devices being detached or moved about. Windows cannot tell, just as FSUIPC cannot. But assigning two devices the same GUID is absolutely wrong and ruins the whole idea. It suggests something else, deeper, is wrong. Pete

Probably. I'd need to try it to be sure. But C won't be called till B has finished and exited in any case. I don't know off-hand whether the flag to tell it to execute the new event is carried forward till then, but I think it is very likely. It should be easy enough to check. Just use ipc.log to give a message on entry to each. Pete

It isn't really the restart that is the problem. That wouldn't occur if SimConnect was still providing traffic updates. The restart of the traffic scanning is just doing EXACTLY what FSUIPC does initially in order to get the traffic data in the first place. Even if you stopped the restart occurring there'd be no traffic updates in any case -- the restart is just an attempt to recover. I've no idea why it seems to be affecting only FSUIPC (and of course its clients). That is really a puzzle. I've no time ot investigate further today in any case. But I tend to have lots of traffic. I'm wondering if it is related to the fact that you seem to only ever have a few. Maybe I'll test with 12 or less and see what happens, though I can't think what could be causing the non-receipt of data no matter how many there are. Pete

You should be using 4.964 minimum now. Then I would advise replacing the DLL with 4.964f. Both are available in the Download Links subforum. These updates work much better with joystick scanning and assignment. Assuming you are not using "UseProfiles=Files", then once all mention of H assignments are deleted, and the entries in [JoyNames] for the device are removed, then it will be gone. best to unplug it first, though, or FSUIPC will again add it to JoyNames. If you are using files for your Profile assignments then you would also need to remove assignments in each of the individual files in the [Profiles] subfolder. FSUIPC's scanning will always recognise and assign letters to any USB devices which classify themselves as "Joysticks", which Bodnar boards certainly do, but that doesn't matter if you don't make assignments to them (though most Bodnar users do, of course). And, yes, please do update to 4.964 then 4.964f. Pete

PLEASE always post support questions here, the Support Forum. I've moved your post from FAQ. You are in the wrong Forum. There is no such message in any of my programs. Maybe you are using Active Sky with the option set to automatically load the current flight plan? Pete

Yes, that's really odd. The re-scan occurs when FSUIPC has not received any AI updates for 4 x the SimConnectStallTime parameter. That cannot be disabled at present. You could try setting it to 20 which would mean it wouldn't restart until there were no updates for 80 seconds. Note that it doesn't count time when the sim in paused or in a menu, nor if there are no AI in its list. I am wondering whether all you <12 AI are parked or stopped somewhere, and so not moving? Maybe SimConnect doesn't send anything then? If this is the reason for the restart, then I should probably first check whether they all have GS = 0 and if so don't restart. Whati s more the problem is why FSUIPC is getting no new data for AI after the restart. It only repeats what it did during initialisation, as if it were a new client, like Traffic Board. It does suggest something else, more serious, going on which somewhere stops SimConnect sending FSUIPC the data. Here, when I'm developing and testing, there are often stops for debugging which FSUIPC doesn't recognise as pausing or menu action, and these always cause a restart of the Traffic section and it has never failed to reload all the traffic again very quickly. I wonder if the closed Client is failing to re-open for some reason. Do you check the loags? If it fails FSUIPC logs "Failed on SimConnect_Open for AI Traffic Client" with an error number added. One change you can make, just as a test, is to set "UseAIClient=No". This will make FSUIPC use the main FSUIPC client for the AI Traffic instead of a separate client. This was the old way of doing it, which I changed because it appeared that the sheer amount of FSUIPC data requested could overload once a lot of AI data was also included. No. That's purely concerned with whatever traffic there is, not an empty table. Pete

The "8-byte record" is, of course, two 32-bit (byte) values, the parameter in 3114 and the command (1070) in 3110. It is the writing of the command which triggers the action, so either write both as one 8-byte structure, or write the parameter first, then the command (in one Process call). The keycode is the standard Windows keycode, all of which are listed in the Advanced Users guide (which is also where the 1070 description above comes from). -- see page 22, where you will see that K has keycode 75. On the following page you find the shift codes, where you see Shift is 1 -- but normally you'd also add the 8 (for "normal"), though I don't think this is strictly necessary. So the end result for the parameter has 9 in the 2nd byte (256 x 9) and 75 in the 1st, or low byte. i.e. in the 32-bits: 0x0000094B = 2379 decimal. Please do use the documentation provided. It is all in your FSUIPC Documents subfolder. Pete

FSUIPC reads the original data, 737NGX data, within the main FSUIPC SimConnect Client. It creates separate clients for 737CDU data, 747 data, 747CDU data and 777 data. Separate clients are, as far as SimConnect is concerned, separate programs. I make them separate to avoid clogging up the main channels. If, for instance, the main problem was with the 737NGX then maybe I should separate that to its own client too. It's only part of the main part because of the historical development -- the 737NGX implementation goes back quite a while. Incidentally, but possibly related, there have been reports of AI Traffic data from SimConnect ceasing, and sometimes not even restarting when FSUIPC detects this and restarts its traffic client. And this seems to be with PMDG aircraft, so far. Pete

The way from VBA, if you can access offsets as you seem to confirm by your first message, is using the 0D70 offset, as I thought I clearly stated! I did not say you should use Lua, I said you could NOT use Lua from VBA. Please read my replies more carefully! You have to make two separate purchases, one for WideFS6 for FS9 and the other for WideFS7 for FSX. You don't need to purchase the "package" with FSUIPCs included. Pete

You have something wrong, then, as that is certainly what FSUIPC reads and writes with no problems. The FSUIPC offsets, since FS98 days, are intended to maintain compatibility over all versions of FS since then. That's why there is a "U" in the name "FSUIPC". It stands for Universal. Values from SimConnect are converted to the same units as those originally provided in FS98, FS2000, FS2002 and FS2004 (also CFS1 and CFS2 for a subset). Added offsets since FS98 days carry extra information -- those can be added without causing application program incompatibility. Look in offset 3AE8 for the original value, in floating point 'double' (64=bit) format, which is what FSUIPC receives from SimConnect when specifying "percent" as the unit. The 16-bit fixed point value is derived from that. Pete

Not hard to do, but how urgently do you need it? I'm pretty well completely tied up till next week. Are you getting the problem with all three PMDG aircraft, or one in particular? Are you reading CDU data too? The CDU data for the 747 involves 3 more clients, and the 737 has 2 more. The 777 has no CDU data clients (at least, none in the SDK file I was sent). Pete

It is "GENERAL ENG THROTTLE LEVER POSITION:1" (the 1 being for Engine 1). It works both ways, reading and writing. Pete

No, Lua is interpreted by FSUIPC in loaded plug-ins. Those functions are added into the Lua interpreter in FSUIPC, they are not general functions of Lua and certainly not VBA. However, from an FSUIPC application you can read and write LVars via offset 0D70, as described in the FSUIPC4 Offsets Status document installed in your FSUIPC Documents folder. Pete

It means that, although there are known AI aircraft in the air, no updates have been received for their positions for too long a time, indicating possibly that, due to overloading, SimConnect has stopped supplying them. It is a better, more efficient way, than re-initialising the entire SimConnect connection which can cause slight pausing due to the sheer number of Sim Variables being re-requested. From what you say it seems that even restarting the traffic scan doesn't help get it going again. Are you perhaps using a PMDG or FSL aircraft? They are known to be very substantial SimConnect users. RC4 uses FSUIPC to get AI traffic data, so it is going to suffer if FSUIPC does. I think PF3 probably does too. To see if SimConnect itself is failing to provide it altogether you'd need some other, non-FSUIPC program which reads AI, like Super Traffic Board, FS-FlightControl, or ProATC/X. Oh, or maybe just the free AI Traffic Limiter utility (AirTrafficManager? Or AirTrafficControl?). Pete

I should think that this would be a possibility. It might be better to monitor the vertical speed or acceleration if you need such information. You might need to experiment. Pete

That cannot happen. Whilst the thread created for your plug-in is running, no events will be checked for your plug-in. The event, when it occurs, is simply flagged in an event list for your plug-in, and those flags are checked in-line, within your plug-in's thread, when it exits the function. Also events are not queued, you only get one call no matter how many times the offset changes whilst your plug-in is executing the function. Pete

The first one will be called and when that exits, the second may or may not also be called, depending on the state of the offset by then. You never get more than one thread per plug-in (unless you use so rather esoteric external Lua libraries, not supplied with FSUIPC). Really it is not logical to have two for the same event. However, taking your question literally, the swecond function doesn't need to terminate the first because the second one cannot run whilst the first is still running, so when it does run the first is already terminated. But taking the question the way you might have meant, you stop an event function being called by using the event.cancel function. But best, and more logical, you should declare only one function for the event, and then, when you want to change which function to call for the next such event, before exiting, use event.cancel then event.offset within the code in the first function. It won't be called until the next time the event is signalled. Pete

Yes, that's the certain symptom of a video driver problem.. Pete

Well, that sounds strange. If PF3 uses FSUIPC how could it not be compatible with it? That's rather self-contradictory. Make sure there is no FSUIPC.DLL also in the main FS folder, or FS may load it there. It must only be in the Modules folder. Otherwise this normally only ever occurs if you have FS still running, as a process, from a previous session -- i.e. it has hung, after closing its Windows etc. Use Task Manager to find it and end it so you can start another session. Something you are running is causing FS to hang on closing instead of closing properly. FSUIPC3 is no longer being changed and has been the same, stable and working program now for many years. Your problems are somewhere else I'm afraid. Pete

That's a video driver problem. Try running FS9 in Windowed mode and you'll see. See if you can update your video drivers. Usually what happens is that the dialogue gets drawn BEHIND the full screen FS9 window, so you don't see it. That sounds like a VERY serious driver problem, then. You should be able to just press escape to exit the dialogue. All FSUIPC does when you select it is open a standard Windows dialogue -- using all standard Windows functions. There is no fancy code, it is very basic Windows calls only. If PF3 is supposed to work with FS9, then, yes, of course. Does PF3 use FSUIPC at all? If it does and if it is okay with FS9 then it is certainly okay. If it doesn't use FSUIPC then the question isn't relevant. Pete

As you can see from the .h document and others in the PMDG SDK folder, the data is mapped in SimConnect as "Client Data". FSUIPC simply asks SimConnect to be told of any changes to the data for the three PMDG aircraft. Client Data is identified by a uniquely registered name. Once registered to receive such notifications, the whole data area is accessible. FSUIPC just copies whatever has changed into the FSUIPC assigned offsets. Data isn't polled or requested separately. It just arrives when it is there because FSUIPC asked for it, once, during initialisation.. I don't have any PMDG aircraft so I've never used it. The facilities and mapping for all three aircraft have been checked for me by users. Pete