Pete Dowson

These are the units FS provides. FSUIPC doesn't invent how FS does things. In FSX and P3D it is quite possible for FSUIPC to specify the units required to SimConnect when making the request to be kept up to date with the values. Even if it couldn't, it would be quite possible for FSUIPC to convert it on arrival. After all, the offsets values are housed in FSUIPC memory and placed there upon receipt. However, it wasn't always like that. FSUIPC has provided an interface to the values is provides since FS98. In those days, an interface what just what it was. It provided a window directly onto the values inside the simulator. It couldn't change the way these units were shown. FSUIPC was born out of the idea to make an interface for applications working with FS which stayed consistent across all the versions of FS there were -- FS98, FS2000, CFS1, FS2002, CFS2, FS2004, FSX, FSX-SE and P3D. Other people have also extended the idea to X-Plane, though with less coverage. Across all of those versions, the values which existed in FS98 have been kept in the same units and in the same places. Many others have been added, yes, but the way it has developed has been deliberately designed to maintain compatibility. Hence the "U" in its name, for "Universal". There are much odder values to choose from to demonstrate the apparent oddness of original units. Just take the user aircraft's latitude and longitude, for example. But there were reasons, and good reasons, FS used such units -- mainly internal computational efficiency. As now, FS needs every bit of performance it can muster to meet the needs of simulating the world, and having units which were ready to use in the way those computations were performed was important, and really it still is. The latitude/longitude one, though, has other reasons. The format adopted was designed to squeeze the very maximum precision possible into 64-bit fixed point values. Even floating point doesn't give so much precision (valuable bits are taken for the exponent), and besides which in computers those days floating point was not as fast, relelatively speaking, as today. I'm sorry, but you are misreading it then. As documented, tt's a double floating point value (64-bit "double" in C/C++. known als as a FLT64 in FS terms). Here, on P3D3, on a 737 for example, it reads from about +0.22 full up to -.22 full down. The actual limits are probably given in the Aircraft.CFG file. Here's an extract from my log when I monitored the value to my log (using the Logging monitor facility), and reaching the extreme at the "up" end: 360222 *** EVENT: Cntrl= 65615 (0x0001004f), Param= 0 (0x00000000) ELEV_TRIM_UP 360238 Monitor IPC:2EA0 (FLT64) = 0.22060962 360238 SimRead: 2EA0="ELEVATOR TRIM POSITION" FLT64: 0.220609617452 And here at the other extreme: 382499 *** EVENT: Cntrl= 65607 (0x00010047), Param= 0 (0x00000000) ELEV_TRIM_DN 382515 Monitor IPC:2EA0 (FLT64) = -0.22060962 382515 SimRead: 2EA0="ELEVATOR TRIM POSITION" FLT64: -0.220609617452 Pete

Ah, yes, thank you. I found the details now. That was done through a hack I found in FS2004 which I could not do in FSX. Sorry. All of the facilities which were in FSUIPC3 which I found ways to do were applied in FSUIPC4 for FSX as well, but some were not. There were, n the other hand, more and different facilities possible with FSX. IT's the same with P3D -- some things might be added, others having to be removed because the facility is not accessible. Pete

The lines starting with numbers instead of letters tell FSUIPC how to access the device. The numbers are "joystick IDs" and range from 0-15. The GUIDs and device Names assigned to the letters tell FSUIPC which Number lines to refer to. It matches them up so it can deal with your (now) lettered assignments. The number lines are only generated for attached and detected devices, but your letters remain. The numbered lines can change numbers when you unplug devices and re-plug them. That was your problem before using letters. The Radio Switch is obviously identified by Windows as a game controller, so FSUIPC makes it available. Pete

No, and if it's completely new, and not just an FSX development, I'm not interested. I'm too old to start on a new development. Someone else would no doubt fill the gap, as with X-Plane. Pete

I'll have to see how easy that is to provide. I am too busy at present trying to rewrite the joystick scanning and recognition routines which have become far too complicated over the years. My lists of things to do have grown to an almost unmanageable size. And I am on holiday for two weeks next week. Could you remind me at the end of the month, and I'll look at it then? Thanks. Pete

I don't know anyway of doing that. Where are you reading that? Because I don't recall it at all, nor can I find mention of it. Pete

Both the X55 and X56 have these problems, with two devices associated with each unit (stick & throttle = 4 devices!), one good and one bad. There are many threads on this here, mostly up till recently about the similar X55. That was what the pinned thread at the top of the Forum was about. Currently the work-around is to change the GUID in the INI,, but I have been working full time on this for the last two weeks or more and hope to arrive at a proper solution in due course. I'm hoping I can finish it before i go on holiday next week, but it's tight. Else i'm back on the 25th and will get it finished then. Luckily one kind user has sent me his now disused X-55 to do tests with. Incidentally, the GUID shouldn't need changing again unless you are unplugging the device and/or moving its connection. Pete

Yes, most certainly. Windows assigns them different IDs. If yuo want FSUIPC to keep track of them if you do that you must use Joy Letters.. That's what the facility is for. Just enable it in the INI file to "AutoAssignLetters" if you don't understand the User Guide. But on this: Unless the file is corrupted, FSUIPC never ever deletes such settings in your INI file! You have to do it manually or via the Options. BTW you posted this in the FAQ subfoum, which is for REFERENCE. For support ALWAYS post here, into the Support Forum! Pete

Yes, AUTO_THROTTLE_ARM. It's a toggle action. You only disconnect it by disarming it. Once I've fixed other problems, notably with the Saitek X55 and 56 attachments, I'll be releasing a proper update. The builds after 4.966c are currently test versions, for feedback to see if they work. Thanks for yours. I hope to make a new release by the weekend or if not very soon after. Pete

So it is all okay now? The registry fix given above is actually now built into the FSUIPC Installer (and for quite a few past releases), so it would have been okay after re-running that. Without knowing what you changed to make it work okay there's really nothing further I can investigate. Pete

If it "suddenly" started occurring, it would be due to something you changed or added. Can you recall what that was? Did you update anything? Quite often things get added to the DLL.XML file at the end and some of these interact with FSUIPC adversely. This is why the FSUIPC installer places its entry at the end -- except for the Active Sky module, the only one which definitely needs to go after (and its installer ensures that too). So first of all try just re-running the FSUIPC installer. No need to reregister or anything ("not now" is the answer there). If that doesn't help I need to see any crash reports for FSX in the Windows Event Viewer, please, and also the FSUIPC4.LOG file from the FSX modules folder. You can paste them here. It would also help to see your FSUIPC4.INI file, from the same folder, and a list of add-ons you are using. Pete

That was true until recent versions of FSUIPC4. Now that fuss is built into the FSUIPC code. Can you tell me how those are described in the Windows settings/control panel? Axis name, button numbers? As well as what Thomas says, please run my "HidScanner" program and attach the log file it produces. You'll find this program in the "Useful Additional Programs" thread of the Download Links subforum. Also export these relevant registry parts: HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties Do this by running RegEdit from the Windows start menu, going down the Explorer style layers to those and with that layer selected do File-Export give them each a name (it’ll save as a .reg file).Don't change the fileype at all, just leave it off. Then rename them from .reg to .txt so the mail system or my anti-virus doesn’t reject them (.reg files, when run, change the registry), and show those to me. I suspect this may be a similar Registry problem caused by Saitek installation which occurs on other devies, notably the X55 and X56. If so then I am working hard at finding an automatic resoluition, but meanwhile it is probably possible to find out from the REgistry what to change in the FSUIPC4.INI file. Pete

More than that, it isn't even read for TCAs applications. It does not cull in any case if the FPS is above a non-zero target. You say that, but every single symptom points that way. the only thing determining whether than message occurs at the end is that flag. nothing else. We didn't expect anything to change in the j version. Please write to me at petedowson@btconnect.com and I'll send you the k version, which is only changed in that there is logging when that flag changes. If it doesn't I'd be surprised, but much more puzzled. If it does get set non-zero, the log with show the actual value, which would normally only be 0 (normal) or 1 (no AI). The value written to it could be a useful clue too. Pete

No, the Vendor and Product ID are the same in both cases. The call into Windows to enumerate the devices gives only the first one in the Registry, so that's the one I use. Multiple identical devices have the same structure in the Registry, but they are separately enumerated. I can't tell the first one is no good. I tried actually seeing if it gives a valid response when asked for its joystick and button values, but it does, albeit null (default) values-- but then so does, say, a Bodnar board before it has any connections. I'm still looking for a way. If i was to avoid using DirectInput, go direct to the USB port and read it directly instead, I could make it work but that's a lot of work, a lot of error-prone changes. I notice that P3D now has links into the Xinput API, the newer one MS added originally for Xbox-connected devices. Perhaps that's something I could use, but again, a biggish rewrite. Thanks, Pete

So effectively it is EXACTLY the same problem I am trying too resolve with the X55. Currently what you did is the work-around, but I'm trying to find a way to do that automatically. I will persevere, but currently it's on hold whilst I await the arrival of a donated X55 ... trouble is, I'm on holiday for two weeks in 8 days time, so it may not be fixed properly till the end of the month or so. Currently you have to see the registry to do the work around, and that's not on for the average user. Pete

Nor I, and the INI is no help -- it is fine, quite normal. It must be something corrupting that flag. I'm working out how to log it when it happens so we can see if there's anything specific going on at that time. Pete

Oh, sorry. yes, that's expected really. It takes control and FSUIPC can't see it. You might just be able to fiddle it by changing the GUIDs used, but more later about that ... That's the normal way of using all Saitek devices successfully, actually. (Same applies to CH devices and their CH Manager). Really? No reason why that should be the case, unless their presence as buttons 32-35 is "fiddled" by the Saikek software, but there should be no reason why they should do that. I'll just check the HidScanner log you sent ... was that with the Saitek stuff installed too? For the X56 Stick is shows: Buttons range 1 -> 17 at indices 4 -> 20 Value Y at index 0, range 0 -> 65535, using 16 bits Value X at index 1, range 0 -> 65535, using 16 bits Value R/RZ at index 2, range 0 -> 4095, using 12 bits Value POV at index 3, range 1 -> 8, using 4 bits Value V/RY at index 21, range 0 -> 255, using 8 bits Value U/RX at index 22, range 0 -> 255, using 8 bits So only 17 buttons 1-17 on the stick. (FSUIPC would number those 0-16, as windows does itself, internally). For the X56 Throttle it shows: Buttons range 1 -> 36 at indices 2 -> 37 Value Y at index 0, range 0 -> 1023, using 10 bits Value X at index 1, range 0 -> 1023, using 10 bits Value Dial at index 38, range 0 -> 255, using 8 bits Value Sldr at index 39, range 0 -> 255, using 8 bits Value V/RY at index 40, range 0 -> 255, using 8 bits Value R/RZ at index 41, range 0 -> 255, using 8 bits Value U/RX at index 42, range 0 -> 255, using 8 bits Value Z at index 43, range 0 -> 255, using 8 bits Now that's all read direct form the USB device itself, at the serial port level. So any program should be able to read the stuff (1-36 on the Throttle), with or without the Saitek drivers. FSUIPC is just limited to 32. To see if FSUIPC can pick up the devices with the Saitek software running, could you just try changing the GUIDs listed in the [JoyNames] section of the INI file (save your current one first). Part of them at present will either be Stick: 8002 or 8003 Throttle: 8001 or 8004 Just try with those changed to the alternative possibility please, and let me know. Pete

I received your email. Thank you. Here's my reply. Right. That explains why FSUIPC doesn’t see it. It only handles 32 buttons per device (the original Windows limit), and always has done. It would be a very big conversion job to change this. Sorry. Ah, same problem then. Does this device really have 32 other buttons? Sounds like the same problem as with the X55, notified by Saitek on their support site. Apart from those two buttons/switches, does everything else work in FSUIPC? If so you probably do not have the same problems as the X55 sufferers. I'd still be interested in whether the X56 does the same odd things in the Registry though, so, to that end, could you do the following please? Export these relevant registry parts: HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties Do this by running RegEdit from the Windows start menu, going down the Explorer style layers to those and with that layer selected do File-Export give them each a name (it’ll save as a .reg file).Don't change the fileype at all, just leave it off. Then rename them from .reg to .txt so the mail system or my anti-virus doesn’t reject them (.reg files, when run, change the registry), and send those to me. Thanks, Pete

I suspect the X56 is just as problematic as the X55. Please see both the thread about this (clearly headlined with X55 mentioned), and the pinned thread at the top of the Forum. I have been actively pursuing this nasty problem now for nearly three weeks, but I am currently awaiting a donated X55 so I can work out what is going on at first hand. Meanwhile please write to me at petedowson@btconnect.com so I can provide you with a special test version of FSUIPC, and instructions on obtaining log files and registry extracts which will help me delve further, and maybe even advise on a workaround. I think Mode Switches can only be programmed in the special software provided for the device. Not sure what a "slider button" is. Do you mean an actual slider? For both these controls, can you tell me how they show in Windows Game Controllers (or the Win10 equivalent)? Also, please could you run my "HidScanner" program and show me or send me the log file it produces. You'll find this program in the "Useful Additional Programs" thread of the Download Links subforum. Thank you, Pete

The limit isn't applied unlessthe frame rate descreases below your chosen value. Have you set that in the INI file? If it is defaulted to zero then the limit applies always, irrespective of frame rate, Perhasp I need to see your INI file, or at least the limiter section. I always have my desired frame rate set. Maybe that's the difference? Okay, then it must be to do with the parameters in the INI as it works fine here in FSX-SE (and P3D). Let me see those and I'll try the same here. As am I. There's been no substantial change in TrafficLook for years. The only recent change was to add the distance to the nearest aircraft(even if not in TCAS range) to the title bar. I've no idea why that doesn't run on your system. Does it even create an INI file? Is their any error entry for it in the Windows Event Viewer? I looked at the log. Something strange is evident: 715545 Sim stopped: average frame rate for last 134 secs = 7.8 fps 716747 === Closing session: waiting for DLLStop to be called ... whereas unless the AI traffic gathering is explicity stopped by an INI file parameter, it should have a summary line for traffic at every "Sim stopped" entry, so:: 229243 Sim stopped: average frame rate for last 118 secs = 20.2 fps 229243 Max AI traffic was 251 aircraft (Deleted 375) 236372 === Closing session: waiting for DLLStop to be called ... also, similar information also appears in the final summary. Yours shows: 725389 *** FSUIPC log file being closed Minimum frame rate was 6.9 fps, Maximum was 8.9 fps Minimum available memory recorded was 32768Mb Average frame rate for running time of 134 secs = 7.8 fps G3D fix: Passes 29189, Null pointers 0, Bad pointers 0, Separate instances 0 Memory managed: 8 Allocs, 8 Freed ********* FSUIPC Log file closed *********** whereas unless traffic data was turned off it would show: 179324 *** FSUIPC log file being closed Minimum frame rate was 13.1 fps, Maximum was 17.0 fps Minimum available memory recorded was 2379Mb Average frame rate for running time of 17 secs = 11.5 fps Maximum AI traffic for session was 596 aircraft Memory managed: 86 Allocs, 85 Freed ********* FSUIPC Log file closed *********** again, with the "Maximum AI traffic line. So, somehow the flag in FSUIPC's memory telling it to not collect AI Trafic data is getting set. There's no other way. I definitely need to see your INI file, please! So, I can only think this flag somehow being set (corrupted in fact, as it is only set once, during initialisation). This would also explain why the FSUIPC count stops, and the traffic limiter stops. That must happen at the EXACT moment the flag is cleared. I have to nail that moment somehow and see what event is related to it. As a start I'll log it if it changes -- expect a revised test version. But I'd like to see your INI file first, please. Pete

Okay .. the DeleteVehicles action is making no difference! I'm using MyTraffic6 with the traffic sliders near max but my limit to to 250. And at Heathrow, a very busy aircraft, that's what it stays at -- agreed by Traffic Explorer (+1) and my own VAS display lua, which also shows the current Traffic count (this little display Lua is available in two versions, one for the FS PC and one for WideFS, in the Lua plug-in examples in your FSUIPC Documents subfolder). So, sorry. Apart from the fix in the 'j' version to allow traffic scanning with the New DeleteVehiclesForAES parameters active (a silly error which must have been there a while!), I can see nothing wrong. How it counts 7 below the Explorer makes no sense. The lack of effect of the limiter is different though. Maybe the deletion isn't working. That relies on a function in the sim. In order to find out if that is going wrong, please add these lines to the [General] section of your FSUIPC4.INI file: Debug=Please LogExtras=x100 and set the Traffic Limit please, so it logs it when loading. See if the limit isn't working, then shut down and show me the log. Also please tell me what traffic add-on you are using. Or is it default? Pete

I'm making a test version here with the "delete Vehicles" option forced on, despite no AES and using FSX-SE / P3D, so I can test just that change (which you said was all that messed it up). Will be back afterwards ... Pete

Always ZIP files. Text files compress very well. Ok, I'll take a look, but I must say that all the things you say makes me very suspicious of your system. [LATER] All the log shows is lots of Lua files being loaded and run, and the session being closed down just 46 seconds after FSUIPC was ready to do anything. Not sure what you expected me to make of it. Pete

So the Installer you were using pre-dated the version (4.939 -- which is very VERY old itself!) you were actually using! Sounds like you have your filing system in a bit of a mess! And how long ago did you download that? If just, where on Earth did you get it from, because that is very old and unsupported too, and not available from any official source! The Installer NEVER EVER deletes anything! You must have done that yourself! You'll want to get those files (FSUIPC.KEY, not REG, and FSUIPC4.INI) from your backup if you deleted them by mistake! Well of course there isn't one to check! You deleted it! You have to enter the details again if you can't find a backup copy of FSUIPC4.KEY. Pete

Interesting resolution, and well tracked down! Thanks for posting this! Pete