Pete Dowson

It's up to 4.966c now -- I had to do some fixes for those with any identical devices. Pete

Seems you have some fort of USB problem. FSUIPC has nothing to do with keyboard or mouse. Wait for 4.966c, being uploaded within the next hour. Come back if it still doesn't work. I'll need to see the FSUIPC4.LOG file -- you can paste the contents into a message here. Pete

Well, the need for "" around the parameters (presumably because of the space in the DLL path) must only be because of how it is processed by the dllhost EXE. surely, then, you must use the "" around the parameter when you run IvAp normally? The EXE will get the whole parameter, but if it uses the standard Windows command-line parameter method then the space will split it into 2 parameters, not 1. The quotes make it one. Really most of the problems with this have been simply because of the space in the folder name "IvAp v2". It's a really bad idea to have spaces in folder names. I avoid them when I can. Pete

Sorry, I can't do anything with FS9 versions now. I did carry out diagnostics and make modifications for many years, but now even FSX is very old (12th birthday this coming October!), and changes for that are really because Prepar3D is still in development. See if Captain Sim will fix CS757 for you, because it is obviously a mistake in that -- probably an assumption about a previously unused or undocumented offset. Pete

For all that you use. They are ordinary text files. If you ZIP them they will be very small and should attach easily. But easier still is to paste their contents into a message a message. You can use the <> button above the edit area to insert them, tidily. That's no different from replacing the DLL. That's all the Install really does, apart from documentation updates. And there's no installer for this update yet anyway. Maybe you should show me the logs using the new DLL and with those lines in the INI, so I get the extra diagnostics. This interim update now has several good independent reports of the fix working to deal with multiple instances of the same device. No, not without logs with the diagnostics. But before doing anything, try deleting at least the GUID lines in [JoyNames]. There could still be a problem where they are identical. Pete

If controllers are disabled in the Sim, and not assigned in FSUIPC (as shown in your INI) then what is sending the axis controls you can see moving in FSUIPC calibration? It sounds like you have some other third party software handling the controls. If so it is not surprising that FSUIPC can't see them for assignment. If there is no such third party program doing it then you must be wrong in one of two ways: 1. The controllers are NOT disabled in the sim, or 2. The INI you supplied is not the one actually in use. Maybe you are looking in a different Modules folder? 4.966 was released on the 15th -- maybe at a different time? And in any case purchasing is not downloading. Most folks download it and install it before purchasing. Pete

You must have the axes assigned in the Sim then. Do NOT try assigning in both FSUIPC and the Sim. Use one or the other. If assigning in FSUIPC, disable controllers in the Sim. These are the devices detected by FSUIPC 187 ---------------------- Joystick Device Scan ----------------------- 203 Product= Saitek Pro Flight Combat Rudder Pedals 203 Manufacturer= Saitek 203 Vendor=06A3, Product=0764 (Version 2.1) 203 Assigned joystick id 2 (Registry okay) 218 GUID= {A86269B0-067D-11E7-800D-444553540000} 218 Product= Saitek Pro Flight X-55 Rhino Stick 218 Manufacturer= Madcatz 218 Serial Number= G0011370 218 Vendor=0738, Product=2215 (Version 0.87) 218 Assigned joystick id 1 (Registry okay) 218 GUID= {A8617F50-067D-11E7-8007-444553540000} 218 Product= Saitek Pro Flight X-55 Rhino Throttle 218 Manufacturer= Madcatz 218 Serial Number= G0001644 218 Vendor=0738, Product=A215 (Version 0.119) 218 Assigned joystick id 0 (Registry okay) 218 GUID= {A8613130-067D-11E7-8005-444553540000} 218 ------------------------------------------------------------------- as confirmed in the INI file too: [JoyNames] AutoAssignLetters=No 2=Saitek Pro Flight Combat Rudder Pedals 2.GUID={A86269B0-067D-11E7-800D-444553540000} 0=Saitek Pro Flight X-55 Rhino Throttle 0.GUID={A8613130-067D-11E7-8005-444553540000} 1=Saitek Pro Flight X-55 Rhino Stick 1.GUID={A8617F50-067D-11E7-8007-444553540000} Pete

Please try FSUIPC 4.966b and let me know. Just open the ZIP and copy over the FSUIPC4.DLL into your Modules folder. It is working fine here with multiple Bodnar boards (all i could find here today). You had 4.965, NOT the latest! Pete

Please try FSUIPC 4.966b and let me know. Just open the ZIP and copy over the FSUIPC4.DLL into your Modules folder. It is working fine here with multiple Bodnar boards (all i could find here today). Pete

Please try FSUIPC 4.966b and let me know. Just open the ZIP and copy over the FSUIPC4.DLL into your Modules folder. It is working fine here with multiple Bodnar boards (all i could find here today). I think the update will fix it, but if you want full details of what it is doing,both in the Registry and with DirectX (both are involved), add these two lines to the [General] section of the FSUIPC4.INI file. The log will be full of stuff including registry places. Pete

Please try FSUIPC 4.966b and let me know. Just open the ZIP and copy over the FSUIPC4.DLL into your Modules folder. It is working fine here with multiple Bodnar boards (all i could find here today). Pete

Please try FSUIPC 4.966b and let me know. Just open the ZIP and copy over the FSUIPC4.DLL into your Modules folder. It is working fine here with multiple Bodnar boards (all i could find here today). Pete

Oh, good. Because I am up to my eyes with FSUIPC and joysticks at present! Pete

Sorry, I know! The change to joystick handling, to deal with the numerous cases of missing joystick IDs and FSUIPC not seeing many joysticks, was first implemented in 4.964. It worked beautifully in Windows 7, using some Windows functions just made for the job! But then it was found that these functions crashed FS in Windows 10. They are broken. I don't know when MS will fix them, but I cannot wait. So I looked for an alternative and worked out one which was implemented in 4.965 a couple of weeks ago (and some pre-releases before that). It all appeared to be working and I received few if any problems with it. Now, just one day after releasing 4.966, with NO CHANGES in this, I get 4 reports of these problems all on the same day! Weird, and not a little frustrating! I am working hard to try to fix it. At least I can now reproduce it, having found two spare Bodnar boards and connected them (with no switch or stick connections) to the test PC. Pete

Yes. Her. for clarity with all the "FALSE" conditions and spurious entries removed along with the unprogrammed "KEYUP"s, and with the active lines emboldened: Case 1: Conditional Buttons, first click 173255 Button changed: bRef=0, Joy=0 (T), Btn=0, Pressed 173255 [Buttons] 16=W3367>3 PT,0,K69,9 173255 .... Offset check: x3367/2 > 3? (7), Result = TRUE 173255 SendKeyToFS(00040045=[shft+E], KEYDOWN) ctr=0 173255 [Buttons] 17=W3367>3 PT,0,K49,8 173255 .... Offset check: x3367/2 > 3? (7), Result = TRUE 173255 SendKeyToFS(00000031=[1], KEYDOWN) ctr=4 173255 [Buttons] 18=W3367>3 PT,0,K50,8 173255 .... Offset check: x3367/2 > 3? (7), Result = TRUE 173255 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=5 173255 SendKeyToFS(00000032=[2], KEYDOWN) ctr=6 173255 [Buttons] 27=W3367>3 PT,0,K51,8 173255 .... Offset check: x3367/2 > 3? (7), Result = TRUE 173255 SendKeyToFS(00000033=[3], KEYDOWN) ctr=7 173255 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 173270 Sending WM_KEYDOWN, Key=69 (Scan code 18), Ctr=8 173270 KEYDOWN: VK=69, Waiting=0, Repeat=N, Shifts=1 173270 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 173317 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=5 173317 KEYDOWN: VK=49, Waiting=0, Repeat=N, Shifts=0 173317 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 173317 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 173348 Sending WM_KEYDOWN, Key=50 (Scan code 3), Ctr=3 173348 KEYDOWN: VK=50, Waiting=0, Repeat=N, Shifts=0 173348 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 173348 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 173348 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 173380 Sending WM_KEYDOWN, Key=51 (Scan code 4), Ctr=2 173395 KEYDOWN: VK=51, Waiting=0, Repeat=N, Shifts=0 173395 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 173395 *** EVENT: Cntrl= 65538 (0x00010002), Param= 0 (0x00000000) SELECT_1 173395 *** EVENT: Cntrl= 65539 (0x00010003), Param= 0 (0x00000000) SELECT_2 173395 *** EVENT: Cntrl= 65540 (0x00010004), Param= 0 (0x00000000) SELECT_3 173458 [Buttons] 16=W3367>3 PT,0,K69,9 173458 .... Offset check: x3367/2 > 3? (7), Result = TRUE 173458 [Buttons] 17=W3367>3 PT,0,K49,8 173458 .... Offset check: x3367/2 > 3? (7), Result = TRUE 173458 [Buttons] 18=W3367>3 PT,0,K50,8 173458 .... Offset check: x3367/2 > 3? (7), Result = TRUE 173458 .... Offset check: x3367/2 > 3? (7), Result = TRUE 174425 Monitor IPC:3367 (S8) = 6 174425 SimRead: 3367="EXIT OPEN:0" FLT32: 99.2338027954 174425 Monitor IPC:3367 (S8) = 4 174425 SimRead: 3367="EXIT OPEN:1" FLT32: 99.2338027954 174425 Monitor IPC:3367 (S8) = 0 174425 SimRead: 3367="EXIT OPEN:2" FLT32: 99.2338027954 All 4 doors opens Two of the doors are operated together as 0 1 or 2 above? You see from the above how cumbersome using keypresses are, when you could use the FS controls directly. Why on Earth use the keypresses? Case 3: Button with TOGGLE_AIRCRAFT_EXIT assigned 772642 Button changed: bRef=0, Joy=0 (T), Btn=6, Pressed 772642 [Buttons] 26=PT,6,C66389,0 772642 FS Control Sent: Ctrl=66389, Param=0 772642 *** EVENT: Cntrl= 66389 (0x00010355), Param= 0 (0x00000000) TOGGLE_AIRCRAFT_EXIT 772907 Button changed: bRef=0, Joy=0 (T), Btn=6, Released 773671 Monitor IPC:3367 (S8) = 1 773671 SimRead: 3367="EXIT OPEN:0" FLT32: 0.666926264763 One door (left front) opens Yes, of course! You were simply supposed to replace the KeyPresses with the Toggle Aircraft Exit control, conditional on 3367 still, with parameters 1 then 2 then 3 -- instead of Shift+E then '1' then '2' then '3'! Sending just one Toggle aircraft Exit with parameter 0 or 1 is the same as just doing "Shift E" once,, on its own!!! Case 4: Button with "offset togglebits" assigned 1093146 Button changed: bRef=0, Joy=0 (T), Btn=6, Pressed 1093146 [Buttons] 26=PT,6,Cx0D003367,x0F 1093146 IPC Offsets Control: Ctrl=x0D00, Length=1, Offset=3367, Param=xF 1093146 *** EVENT: Cntrl= 66389 (0x00010355), Param= 1 (0x00000001) TOGGLE_AIRCRAFT_EXIT 1093146 *** EVENT: Cntrl= 66389 (0x00010355), Param= 2 (0x00000002) TOGGLE_AIRCRAFT_EXIT 1093146 *** EVENT: Cntrl= 66389 (0x00010355), Param= 3 (0x00000003) TOGGLE_AIRCRAFT_EXIT 1093146 *** EVENT: Cntrl= 66389 (0x00010355), Param= 4 (0x00000004) TOGGLE_AIRCRAFT_EXIT 1093146 Monitor IPC:3367 (S8) = 15 1093302 Button changed: bRef=0, Joy=0 (T), Btn=6, Released One door (left front) opens Hmm. It's doing exactly the right thing though. Something is wrong or different with your setup someehow, then, which I don't understand. Because EXACTLY the same sequences here opens or closes the doors correctly, including on the default Beaver. Try with a parameter 7. You seem to only have 3 door controls even with 4 doors, according to the earlier logs. Also see what assigning a button or key to Toggle Aircraft Exit with parameters 1, 2, 3, or 4 does, respectively. Because those controls seem broken. I'm wondering if that was working correctly in FSX/SP2. It always worked in FSX/ACC, and now in FSX-SE and P3D. Pete

No fix yet. I just said to remove the error results in the INI file manaually before each test. I am thinking of posting a link to a version to test soon. I don't have two identical devices to test with here. Pete

What additional log files? Pete

You'll need to delete the bad entries in the [JoyNames] section when I provide an updated FSUIPC for you to try. i.e with this, as it is at present: [JoyNames] AutoAssignLetters=No 0=Pokey #1 0.GUID={B527DB20-EDC0-11E5-8001-444553540000} 1=Pokey #1 1.GUID={B527DB20-EDC0-11E5-8001-444553540000} delete the GUID line for the device for which the assignments are not currently working. Pete

So the FSUIPC entry is still in the Add-Ons menu? The surfaces and graphic control levers moving means that the controls must be working. Nothing else would do that. if the flight of the aircraft doesn't reflect those changes then there's something wrong with the installed aircraft. There's no way FSUIPC has of moving control surfaces and cockpit control graphics without sending controls to P3D. If P3D is then not responding correctly you need to look at the installed aircraft, not FSUIPC. Try with a default aircraft. Do NOT load one of those very complex aircraft by default. Test with a default aircraft and load the more advanced one after. Surely you cannot have started a flight within 10 seconds of starting the sim. Even on my 5GHz cockpit system it takes minutes, not seconds, and you seem to have a lot of add-ons. The Log shows nothing wrong, but then you didn't actually do anything by the look of it: 47219 Starting everything now ... 47281 ASN active function link set 47281 Ready for ASN WX radar 82031 Sim stopped: average frame rate for last 49 secs = 19.9 fps 82031 Max AI traffic was 0 aircraft So, the system would have been ready to fly some time after 47 seconds from starting P3D. I've found here that the FSUIPC "Starting everything now" occurs whilst P3D is still actually loading stuff, with its progress bar on screen. To actually see when it does occur on your system, could you run P3D in Windowed mode (ALT+ENTER) and enablre FSUIPC's Console Log (in the Logging tab in Options). You'd need to restart P3D after setting these changes. Then you would see the log being created at the same time as the progress of the P3D loading etc. The log you supplied shows you terminated the session pretty much when it was ready to fly (i.e. when it could accept the terminate request) -- just 35 seconds after FSUIPC itself was ready. So, there's absolutely no useful information in the log. It is just a successful load and termination of P3D and FSUIPC. You are looking in the wrong place. From the symptoms you describe it has to be one of the internal add-ons, the complex aircraft. I suspect one or more of those is clogging up the SimConnect communications. If they have DLLs being loaded then you might need to try disabling those too. Pete

Further to my last reply, to help me work out what is wrong could you please add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=x200000 then run the Sim (only till ready to fly, then close) and show me the FSUIPC4.LOG. You can remove those two lines afterwards. Pete

Further to my last reply, to help me work out what is wrong could you please add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=x200000 then run the Sim (only till ready to fly, then close) and show me the FSUIPC4.LOG. You can remove those two lines afterwards. Pete

Further to my last reply, to help me work out what is wrong could you please add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=x200000 then run the Sim (only till ready to fly, then close) and show me the FSUIPC4.LOG. You can remove those two lines afterwards. Pete

I'm currently investigating two other cases with multiple devices of exactly the same types. The odd thing is that since 4.966 was released only yesterday I've already had three similar reports, although this code has not changed at all in 4.966 -- it was like this in 4.965 two weeks ago! How come no one used that? Pete

That's fine. The registry definitely has different GUIDs for each device, so it must be something daft my code is doing. I'm trying to emulate having two quadrants here by fiddling the registry but it won't work. It has to see them too. I'll let you know as soon as I've got to the bottom of it. The odd thing is that since 4.966 was released only yesterday I've already had two similar reports, although this code has not changed at all in 4.966 -- it was like this in 4.965 two weeks ago! Pete

A lot! There were more than 9 major releases and uncounted interim ones. If you want a complete history refer to the History document in your FSUIPC Documents folder along with the more recent changes listed in the Changes document in the download zips. As Thomas says, we need to see the INI and LOG files. It would also help me to double check what FSUIPC is doing if I could see the Registry entries for your devices. (I'm a bit worried about setups with two devices of the same type and I'd like to improve this if I can). To do this: Run Regedit (from the place Win10 allows you to type in program names to look for them). You will see it comes up with an Explorer type Window. Navigate right down to HKEY_CURRENT_USER\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput then, in the File Menu select Export ... and choose a place to save the data -- save it as a Txt file, NOT a Reg or you won't be able to upload it here. then, before leaving Regedit, do the same (but with a different name of course) with HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput (Don't worry if you can't find one of the above. As long as one of them is there. But there are both normally). Then please show me both files. Pete