Pete Dowson

Really? But DLL's are just collections of functions which can be called from anywhere and call functions anywhere else. They are just collections of functions which can be separately loaded instead of bound in like LIBs. So I don't see how you can separate them off to run in a different core, Also, FSUIPC doesn't do anything for long. I mean it has no functions which would occupy a core for long enough to be worth any selection or switching process. It isn't as if it is continuously doing anything. It isn't in a loop polling values anywhere. The joystick scanning is on a timer call, and all the offsets are populated from SimConnect callbacks when the data changes sufficiently. What would you hope to gain? Pete

In VB the prefix &H means the number is in hexadecimal. In C/C++ the prefix 0X is used instead. All offsets listed in the FSUIPC documentation are in hexadecimal. Really, for basic questions about VB you should use a beginners guide to programming in VB. Oh, and the name is "Dowson" by the way, with an 'o' not an 'a'. Pete

Delete the DLL first or the Installer won't work. And if you go back you get no support. so make sure you update to a current version before you return here. I need information from users with problems to move forward. None of these problems are generally reproducible, neither for me or my colleagues. Pete

Ah, I didn't notice you'd set it for profiles in files. Sorry. Too busy sorting out the rest. 3. 958? That's was FS2004! ;-) I'm afraid the GUID checks are there to stay because they were always intended, and the only sure way to track otherwise identical devices if you move them around or update Windows. The fact that it didn't work correctly before has cause many more problems than yours, and those only arose for you because there's such a lot of rubbish in the INI file, with out of date and incorrect GUID assigned to currently assigned letters and vice versa. Anyway, I did do most of the work for you. After replacing your JoyNames section, You just need to make sure with identical devices that the letters are the right way around in the JoyNames section I made for you. Pete

The "host" process being FSX or P3D, you mean? What's wrong with the CFG file parameter for it? Why try to change it after it is running, if you even can? Prior to run time? So it has no effect until you restart the simulator. I suppose it just edits the Prepar3D or FSX CFG file for you. Or do you mean the VOXATC process? Don't forget FSUIPC is just a little DLL running inside the sim, it isn't a separate process. Pete

That sounds lke one of the so far inexplicable results of P3D crashing on exit instead of closing down properly. Please see the other threads on this to see things to try. There is a lot being done to identify the cause, but still more information is needed. You need to use the Windows Event viewer to get the P3D crash details. Yes, the typical symptom of the restart problem is that SimConnect is trying to enter FSUIPC appearently before it has loaded it. FSUIPC never gets a chance to run, so it cannot crash. You misunderstand,. I was NOT referring to a "windows crash" but Windows "crash data". Windows detects crshes and records them in logs which can be seen in the Event viewer. Pete

In that case it cannot be anything to do with FSUIPC. Your aircraft is receiving the data it needs and is visibly responding but the model isn't working. I see you are using the new PMDG 747. You'll need to go to PMDG support. Maybe they've not tested it with older versions of P3D. Pete

The log shows a perfect session till it was closed normally. no crash. You supplied no information about any crash at all I'm afraid., and no Wideows crash data either. Pete

The log is fine and shows FSUIPC is working okay. Sorry, I've never heard of a bug where SimConnect doesn't pass on the menu selection. It isn't a function of FSUIPC, and most definitely not calling simconnect end when you close the system cannot in any way affect anything before you close the session. I can only think that the window is coming up behind. try using Windowed mode. If that works then it's a video driver problem. What else have you changed? Something, evidently. Pete

The CallSimconnectEnd option is only relevant to the close down of the sesion, so that's nothing to do with iyt. something else has changed on your system. If there's no FSUIPC menu then either FSUIPC isn't loading (renamed incorrectly?) or Simconnect has stalled. If there's a log that will show. If there isn't then it isn't being loaded! Of course, FSUIPC won't work if it isn't actually loaded or if SimConnect has stalled. It cannot work magic! ;-) Pete

And what's "this"? (sorry, I don't have time or patience to watch videos. you need to describe any problems). Why on Earth are you sticking to such old P3D versions? The current version is 3.4.22! The log seems good. There's no problems shown except one temporary SimConnect stall, here: 533087 Sim stopped: average frame rate for last 26 secs = 11.1 fps 533087 Max AI traffic was 0 aircraft 580792 Advanced Weather Interface Enabled 632865 **** No SimConnect events or states being received! Re-connecting now ... **** 632958 SimConnect_Open succeeded: waiting to check version okay which was recovered okay and the session continued fine. That error occurred during some loading operations. For some reason, P3D's SimConnect tells FSUIPC that it is all ready to fly when in fact it's still displaying the progress bar for loading. I'm looking to do something about that. It has become worse as P3D develops. But after that, when the system got going, no FSUIPC problems occurred at all. Pete

I need to see the details, the FSUIPC4.LOG file if any and the Windows crash details. Pete

Yes. The installer only replaces it and checks the DLL.XML and replaces all the documents. It does nothing else at all. I tend to just rerun the installer. You don't need to re-register in any case, and I just find it faster. Pete

Okay. even more mysterious then, because the main changes 4.959 to 4.961 were to Lua terminations, to solve problems mainly with LINDA, but possibly with other scripts. Pete

4.961

Following on from my previous reply, I just located the mouse actions list in the PMDG .h file. Here it is: /* Mouse flags for mouse click simulation #define MOUSE_FLAG_RIGHTSINGLE 0x80000000 #define MOUSE_FLAG_MIDDLESINGLE 0x40000000 #define MOUSE_FLAG_LEFTSINGLE 0x20000000 #define MOUSE_FLAG_RIGHTDOUBLE 0x10000000 #define MOUSE_FLAG_MIDDLEDOUBLE 0x08000000 #define MOUSE_FLAG_LEFTDOUBLE 0x04000000 #define MOUSE_FLAG_RIGHTDRAG 0x02000000 #define MOUSE_FLAG_MIDDLEDRAG 0x01000000 #define MOUSE_FLAG_LEFTDRAG 0x00800000 #define MOUSE_FLAG_MOVE 0x00400000 #define MOUSE_FLAG_DOWN_REPEAT 0x00200000 #define MOUSE_FLAG_RIGHTRELEASE 0x00080000 #define MOUSE_FLAG_MIDDLERELEASE 0x00040000 #define MOUSE_FLAG_LEFTRELEASE 0x00020000 #define MOUSE_FLAG_WHEEL_FLIP 0x00010000 // invert direction of mouse wheel #define MOUSE_FLAG_WHEEL_SKIP 0x00008000 // look at next 2 rect for mouse wheel commands #define MOUSE_FLAG_WHEEL_UP 0x00004000 #define MOUSE_FLAG_WHEEL_DOWN 0x00002000 You'll see that the x20000000 value means "Left Single Click, and the x00020000 one means "Left release". The latter is a bit puzzling though. Pete

Another question (please also see the previous message). Can you try setting this parameter in the FSUIPC4.INI [General], please, and let me know: CallSimconnectEnd=No Earlier versions of P3D had a problem with crashes or hangs when closing which occurred when FSUIPC closed its connection. That seemed to have been fixed in 3.4 so I then defaulted it to "Yes", but mayby the more recent version(s) of P3D have re-introduced this bug. 9L-M have never admitted to a bug even though the crash was always deep into P3D code). I still think making P3D close cleanly at the end of the session is the only way to fix the restart crashes, which are still a complete mystery as none of the software involved is running at the time of those crashes, and there's really nothing changed by reinstalling FSUIPC. Pete

Any Lua plug-ins at all? Can you try setting this parameter in the FSUIPC4.INI [General], please, and let me know: CallSimconnectEnd=No Earlier versions of P3D had a problem with crashes or hangs when closing which occurred when FSUIPC closed its connection. That seemed to have been fixed in 3.4 so I then defaulted it to "Yes", but mayby the more recent version(s) of P3D have re-introduced this bug. 9L-M have never admitted to a bug even though the crash was always deep into P3D code). I still think making P3D close cleanly at the end of the session is the only way to fix the restart crashes, which are still a complete mystery as none of the software involved is running at the time of those crashes, and there's really nothing changed by reinstalling FSUIPC. Pete

Yes. The details shown in the offsets list show the way to convert the other way, for READING the Lat/Lon, which is the more usual application. All of the unit conversions sohwn in the whole documwent are that way around. The strange units were designed (way back in SubLogic days I think, presumably when floating point was slow or maybe not even universal), to accommodate the most precision in a fixed point integer. Pete

Yes, "steering set" is an FS control, not an FSUIPC direct control, which uses the rudder still for direct compatibility across all versions of FS. Steering Set was new to FSX. It works fine here, at least in P3D with FSUIPC 4.961. Are you sure your tiller input axis is working correctly? Do the numbers change in the assignment tab? Check with a default aircraft loaded in case something is preventing it. (I see Thomas already got in and asked the last question). Pete

If I do some experimental backward updates, a section at a time, to the few things which changed between 4.959 and 4.961, would you be willing to test them for me? It's impossible for us as we cannot reproduce the problems. Just one question first, though. Do you run ANY Lua plug-ins at all? (Including LINDA for instance)? If so, which ones? If you don't then it's an area I can ignore in this backward check. Pete

The previous session of P3D hung, instead of crashing. I'd be interested to see the FSUIPC log file from such an incident, to see whether it closed properly as it seems to do in the other cases, even though P3D did obviously crash, possibly unnoticed, on exit. Pete

PMDG in their wisdom designed their custom control interface to use mouse type flags, giving the same mouse action for the switch as you would use for direct mouse use on the switch. The parameters look odd by they are just simple flags: 131072 is x00020000 and 536870912 is x20000000 Those are rather easier numbers, and have just one flag bit set which is meaningful. The mouse values SHOULD be documented in the SDK's .h document where the controls are listed. are they not? (Otherwise you can certainly find them on Microsoft programming reference sites for the WM_MOUSE message group). FSUIPC will accept hexadecimal values like this, just precede them with an x. Pete

It shows assignments by joystick letters to 4 Saitek Quadrants (B, D, T and U), one rudder and 2 yokes, plus a load of "pads". Is that right? THe 4 quadrants and 2 yokes aren't all recognised when FSUIPC scans the devices. Just one of each there. I really can't believe this INI would work properly on ANY version of FUIPC, there are so many things to mess your sim up. Just to pick out some examples, in the axes assignments you have both a rudder AND a throttle assigned to the rudder (device A). On one quadrant (device D) you have two generic all engine throttles assigned, no separate throttles. On the yoke (device C) you have aileno and elevator ok, but also rudder, again! You only appear to have buttons assigned to the non-Saitek "pad" devices. You have 5 profiles defined but have not made use of any of them for any assignments or calibrations. Quite honestly, this looks a complete mess. I wouldn't know where to start to sort it out. How did it get like this? These are the only "real" devices listed, and even then it sees two quadrants. 0=Saitek Pro Flight Rudder Pedals 0.GUID={28EBBAA0-829A-11E5-800C-444553540000} 1=usb pad 1.GUID={28EBBAA0-829A-11E5-8002-444553540000} 2=usb pad 2.GUID={28EBBAA0-829A-11E5-8003-444553540000} 3=usb pad 3.GUID={28EBBAA0-829A-11E5-8004-444553540000} 4=usb pad 4.GUID={28EBBAA0-829A-11E5-8001-444553540000} 5=Saitek Pro Flight Yoke 5.GUID={28EBBAA0-829A-11E5-800D-444553540000} 6=Saitek Pro Flight Quadrant 6.GUID={28EBBAA0-829A-11E5-800E-444553540000} 7=Saitek Pro Flight Quadrant 7.GUID={28EBBAA0-829A-11E5-800F-444553540000} 8=Pro Flight Cessna Trim Wheel 8.GUID={4F45C0A0-7B6A-11E6-8001-444553540000} You need to find out which of devices 6 and 7 is the "real" quadrant. I'll cover that later on ... The above devices correspond to letters M N P Q R S T U and L, respectively, though there's no GUID assigned to L. Here's a corrected joyNames section which shows how your system looks now: [JoyNames] AutoAssignLetters=Yes 0=Saitek Pro Flight Rudder Pedals 0.GUID={28EBBAA0-829A-11E5-800C-444553540000} M=Saitek Pro Flight Rudder Pedals M.GUID={28EBBAA0-829A-11E5-800C-444553540000} 1=usb pad 1.GUID={28EBBAA0-829A-11E5-8002-444553540000} N=usb pad N.GUID={28EBBAA0-829A-11E5-8002-444553540000} 2=usb pad 2.GUID={28EBBAA0-829A-11E5-8003-444553540000} P=usb pad P.GUID={28EBBAA0-829A-11E5-8003-444553540000} 3=usb pad 3.GUID={28EBBAA0-829A-11E5-8004-444553540000} Q=usb pad Q.GUID={28EBBAA0-829A-11E5-8004-444553540000} 4=usb pad 4.GUID={28EBBAA0-829A-11E5-8001-444553540000} R=usb pad R.GUID={28EBBAA0-829A-11E5-8001-444553540000} 5=Saitek Pro Flight Yoke 5.GUID={28EBBAA0-829A-11E5-800D-444553540000} S=Saitek Pro Flight Yoke S.GUID={28EBBAA0-829A-11E5-800D-444553540000} 6=Saitek Pro Flight Quadrant 6.GUID={28EBBAA0-829A-11E5-800E-444553540000} T=Saitek Pro Flight Quadrant T.GUID={28EBBAA0-829A-11E5-800E-444553540000} 7=Saitek Pro Flight Quadrant 7.GUID={28EBBAA0-829A-11E5-800F-444553540000} U=Saitek Pro Flight Quadrant U.GUID={28EBBAA0-829A-11E5-800F-444553540000} 8=Pro Flight Cessna Trim Wheel 8.GUID={4F45C0A0-7B6A-11E6-8001-444553540000} L=Pro Flight Cessna Trim Wheel L.GUID={4F45C0A0-7B6A-11E6-8001-444553540000} The problem is that all of the button assignments are to devices B C D E F G and H, and the axes to devices A B C D E F G (even though there are some crazy assignments in there, as already mentioned). So, somehow, all the GUIDs have changed and the devices therefore re-mapped. I have no idea how that has occurred, but the difference between 4.958 and 4.961 is that there was a bug before 4.960 which made the GUIDs irrelevant -- they weren't being used to distinguish between otherwise identical devices such as all your "usb pads". That's now fixed, so the future is better, but unfortunayely it has caught you out because of the mess in the INI file. So, I've spent a lot of time trying to sort it out for you. but you need to do something too now, as I'll explain. It will be worth it to stop such messes happening in future. Try this,, to start with. Replace the complete [JoyNames] section with this (you can use to <> button above to allow you to copy it for pasting): [JoyNames] AutoAssignLetters=No 0=Saitek Pro Flight Rudder Pedals 0.GUID={28EBBAA0-829A-11E5-800C-444553540000} A=Saitek Pro Flight Rudder Pedals A.GUID={28EBBAA0-829A-11E5-800C-444553540000} 1=usb pad 1.GUID={28EBBAA0-829A-11E5-8002-444553540000} E=usb pad E.GUID={28EBBAA0-829A-11E5-8002-444553540000} 2=usb pad 2.GUID={28EBBAA0-829A-11E5-8003-444553540000} F=usb pad F.GUID={28EBBAA0-829A-11E5-8003-444553540000} 3=usb pad 3.GUID={28EBBAA0-829A-11E5-8004-444553540000} G=usb pad G.GUID={28EBBAA0-829A-11E5-8004-444553540000} 4=usb pad 4.GUID={28EBBAA0-829A-11E5-8001-444553540000} H=usb pad H.GUID={28EBBAA0-829A-11E5-8001-444553540000} 5=Saitek Pro Flight Yoke 5.GUID={28EBBAA0-829A-11E5-800D-444553540000} C=Saitek Pro Flight Yoke C.GUID={28EBBAA0-829A-11E5-800D-444553540000} 6=Saitek Pro Flight Quadrant 6.GUID={28EBBAA0-829A-11E5-800E-444553540000} D=Saitek Pro Flight Quadrant D.GUID={28EBBAA0-829A-11E5-800E-444553540000} 7=Saitek Pro Flight Quadrant 7.GUID={28EBBAA0-829A-11E5-800F-444553540000} U=Saitek Pro Flight Quadrant U.GUID={28EBBAA0-829A-11E5-800F-444553540000} 8=Pro Flight Cessna Trim Wheel 8.GUID={4F45C0A0-7B6A-11E6-8001-444553540000} L=Pro Flight Cessna Trim Wheel L.GUID={4F45C0A0-7B6A-11E6-8001-444553540000} Note that I've changed AutoAssignLetters to "No". You really need to take control with this number of devices. In the above I've had to just assign the "usb pad" devices in order, E, F, G, and G. When you try a button on each you can see if those are correct, else change the letters around. I've had to leave the second quadrant because I don't know which one is the real one. Find out by seeing what letter comes up in axis assignments when you move a lever. If it is D then just delete the lines beginning 7 and U above. If it vcomes up as U, delete the lines starting 6 and D and change the U entries to D. Finally, I've no idea about the Cessna Trim wheel as you have no assignments to it in any case. So i've left it as L. Oh, also delete all of the [Profile ...] sections completely. You are not using them in any case and they are only going to confuse matters. Try all this and then come back with the results. Pete

I really need to get to the bottom of this, as I know of n significant difference which would account for this. It would be good if myself or my colleague Thomas could reproduce any such problems ourselves. Pete