Pete Dowson

If anyone in this thread wants to help solve these problems, please see the pinned thread at the top of the Forum and send me an email. I've only got one kind volunteer so far, but also an update to FSUIPC for testing. but I am not posting links here as I want to retain control for now. Pete

If this occurred after an update to a recent FSUIPC version, then it will be because a bug in the GUID checking has been corrected. In this, your JoyNames section: [JoyNames] AutoAssignLetters=No R=Mad Catz Pro Flight Rudder Pedals R.GUID={68A93020-D4E0-11E6-8002-444553540000} S=Saitek Pro Flight X-55 Rhino Stick S.GUID={68B56520-D4E0-11E6-800A-444553540000} T=Saitek Pro Flight X-55 Rhino Throttle T.GUID={68B2A600-D4E0-11E6-8008-444553540000} T=Saitek Pro Flight X-55 Rhino Throttle T.GUID={68B60160-D4E0-11E6-800D-444553540000} 0=Mad Catz Pro Flight Rudder Pedals 0.GUID={68A93020-D4E0-11E6-8002-444553540000} 1=Saitek Pro Flight X-55 Rhino Stick 1.GUID={68B56520-D4E0-11E6-800A-444553540000} 3=Saitek Pro Flight X-55 Rhino Throttle 3.GUID={68B2A600-D4E0-11E6-8008-444553540000} 4=Saitek Pro Flight X-55 Rhino Throttle 4.GUID={68B60160-D4E0-11E6-800D-444553540000} I don't know how you got two throttles registered with different GUIDs -- update to Windows perhaps? Before I corrected the GUID checking you were just lucky that the right device was selected. Try changing the second "T" pair to be "U" instead of T. Then see whether you get T or U showing in the Axis assignments tab. If T then delete the U and 4 lines. If U then delete the T and 3 lines and change the two U's to T's. Pete

If it is asking you whether to run it or not then it isn't the same problem. You need to let it run. It's a timing problem in SimConnect "trust" code which has been there in all versions of FSX and FSX-SE. There's a thread about it in the FAQ subforum above. Once it goes through once without a problem reported then it works forever after. Most folks never get this problem at all, but in the worst cases it seems to occur on every new FSUIPC update. Pete

Yes, this is occurring AFTER FSUIPC has closed normally hence: Please see the pinned thread at the top of the forum. I cannot reproduce the problem here and neither can my colleague Thomas, so we need volunteer testers to try things. STOP PRESS: I just realised: you are using FSX. This is the very first report of this error with FSX! Up to now it looked specifically P3D version 3, so we've only been looking in areas which are different for P3D! This makes it of wider scope! Not sure to be pleased or horrified at this. Pete

Just enter "Event Viewer" into the Windows Start / Run edit box and press return. Pete

Ah, you never said that before. You have a direct assignment to FSUIPC's tiller somewhere! Find it in the INI file and delete it. Pete

Yes, a lot of folks has said that mouse clicks on some more sophisticated add-on aircraft appear to be rather slow in activation. By reports I've seen I think it is with P3D this is so rather than FSX, though it probably applies to both. Sending what are effectively mouse clicks you are emulating the user with a real mouse, so you need to insert delays to bring it down to human times. Have you tried using the facility to hold the button down for a time? You'd either have to measure the time for a certain larger increment, or read back the value and rorrect overshoots afterwards. Or measure the overshoot and correct with a shorter time. Since PMDG have not provided any way off writing values directly, as you could with default aircraft, I don't know of any other ways really. Not holding the button down? Have you tried using the mousewheel? I thought I saw a Mouse code for that. The Lua plug-in Mouse library provides for wheel turning, but you'd probably need to move the mouse to the right position first, rather than just end the PMDG control with a mouse code. You could try posting on the PMDG forum too -- they'll all be PMDG users there! Pete

You misunderstood. It's the check INSIDE FSUIPC which was corrected. The FSUIPC settings won't need to have changed! Well it doesn't seem to deter others! You can use the <> button above to place the text into a frame with scroll bars where applicable. In the INI file you attached, the [JoyNames] section contains this: [JoyNames] AutoAssignLetters=Yes A=Logitech Extreme 3D 0=Logitech Extreme 3D 0.GUID={8CB99BC0-67B3-11E6-8001-444553540000} Is that your only device? No yoke or throttle or anything? That device does it all? Anyway, I think the problem is that the GUID for device A is missing. You need the section to read: [JoyNames] AutoAssignLetters=Yes A=Logitech Extreme 3D A.GUID={8CB99BC0-67B3-11E6-8001-444553540000} 0=Logitech Extreme 3D 0.GUID={8CB99BC0-67B3-11E6-8001-444553540000} Try that and let me know. There are NO other chanes in FSUIPC which would affect your device's actions, only the GUID check. Pete

It may be that the GUIDs associated with your devices are wrong. I recently fixed an error in FSUIPC whereby the GUIDs were not being correctly used to identify devices, as they should always have been. If there are some old incorrect entries in the [JoyNames] section of your settings, the FSUIPC4.INI file, then it may be that the current correct GUIDs are now associated with old joystick letters or numbers, so your assignments are ineffective because they are expective a non-existent device. I'm not sure what changes the GUIDs -- probably a Windows update -- a change of Windows version -- or of PC. And that could have been any time since you had those devices and started using FSUIPC for assignments. It should be easy to fix, and I'll show you if you show me your FSUIPC4.INI file. Pete

4.957c!? Well,, yes, I'm definitely thinking I'm not going to fix this by FSUIPC changes only. This is with P3D 3.4.xx? Because so far that's the only (other) common factor. Please see my pinned post at the top of the Forum. Pete

Understood, and please see email. Pete

Check with default aircraft. And check your FSUIPC version number. Pete

Hmm. You say it might be FSDT others say it's PMDG 747, I expect others will say they have neither. The only common factor is P3D 3.4 -- and, mostly, Win 10, though that's only from what i've seen reported. Oh, and FSUIPC. Pete

This gets weirder and weirder. The ONLY change was moving the memory check to its own thread. What if you disable the memory checker again? Can you always check the event viewer to see if P3D crashed on exit from the previous session, and also if FSUIPC's log shows a proper close? Pete

This is EXACTLY the same problem with recent versions of P3D 3.4 that is reported as discussed in this and other threads. Please go and read the pinned thread at the top of the Forum. Pete

You are using an out of date reference. The current document for offsets is in your FSUIPC Documents folder, inside the FSX Modules folder, along with the other FSUIPC Documentation. Offset 3308 is a 2-byte value, not 4-bye as you are reading. The "FADE" part is another documented value, if you go look. 2 byte values are probably not called "Integers" in VB. You need to learn VB before you write a VB program! Pete

Just to clarify something about the P3D startup crash which is the main thing which folks are concerned with. Some folks are saying it was all okay in version 4.959 and want to go back o that. but if you refer to the thread referenced at the end of this message (and others) you'll see, especially if you skip the first few messages which were different, that it was 4.959 which had the strt-up problems with P3D. It's a long thread with a long list of test releases going from 4.959a to 4.959m. The "m" version seemed to fix it for folks then, and it wasn't long ago. A couple of fixes to prevent LINDA crashing (due to a bug in LINDA now fixed i understand, to version 4.959p, it was relabelled 4.960 and released. The change between 4.960 and 4.961 was a minor one, to put the OOMcheck into its own thread to prevent a small stutter every 10 seconds when Windows was asked to tot up the memory blocks. It was also announced to support P3D3.4.22 which was released the same day, though in fact 4.960 already was 3.4.22 ready. So, i cannot revert back to 4.959 level as it will re-introduce the problems which have been fixed with a lot of blood sweat and toil. Well, maybe not blood. The only conclusion we can reach is that there's more than one cause for the P3D startup problems. I am pretty sure it only occurs if the preceding otherwise good session crashed on exit, or even hung as some have reported, Identifying what might cause that is the focus of my work on this. it isn't easy because it isn't crashing or hanging withing FSUIPC. As the log shows, FSUIPC is long finished and gone -- unloaded even. So if FSUIPC is causing it, it must be something it did whllst it was still there, even though nothing went wrong during that time. With the original problems it seemed mostly relating to the way Lua plug-ins were terminating or being killed, so most attention was focussed on that area and I now believe that's a good as it's going to get. So it's somewhere else. Since I can't reproduce the problem, and nor can Thomas, I'd like volunteer user testers please, to try experiments and gather information on the resluts. Those willing and able to help and who can definitely reproduce the problem (crash or hand on exit, mainly. There's no way for us, outside L-M, to debug the crash on start). please drop me an email: petedowson@btconnect.com. Pete

Just to clarify something about the P3D startup crash which is the main thing which folks are concerned with. Some folks are saying it was all okay in version 4.959 and want to go back o that. but if you refer to this thread http://forum.simflight.com/topic/82599-crash-loading-p3dvhttpforumsimflightcomtopic82599-crash-loading-p3dv34-reporte-fsuipc4dll34-reporte-fsuipc4dll/ you'll see, especially if you skip the first few messages which were different, that it was 4.959 which had the strt-up problems with P3D. It's a long thread with a long list of test releases going from 4.959a to 4.959m. The "m" version seemed to fix it for folks then, and it wasn't long ago. A couple of fixes to prevent LINDA crashing (due to a bug in LINDA now fixed i understand, to version 4.959p, it was relabelled 4.960 and released. The change between 4.960 and 4.961 was a minor one, to put the OOMcheck into its own thread to prevent a small stutter every 10 seconds when Windows was asked to tot up the memory blocks. It was also announced to support P3D3.4.22 which was released the same day, though in fact 4.960 already was 3.4.22 ready. So, i cannot revert back to 4.959 level as it will re-introduce the problems which have been fixed with a lot of blood sweat and toil. Well, maybe not blood. The only conclusion we can reach is that there's more than one cause for the P3D startup problems. I am pretty sure it only occurs if the preceding otherwise good session crashed on exit, or even hung as some have reported, Identifying what might cause that is the focus of my work on this. it isn't easy because it isn't crashing or hanging withing FSUIPC. As the log shows, FSUIPC is long finished and gone -- unloaded even. So if FSUIPC is causing it, it must be something it did whllst it was still there, even though nothing went wrong during that time. With the original problems it seemed mostly relating to the way Lua plug-ins were terminating or being killed, so most attention was focussed on that area and I now believe that's a good as it's going to get. So it's somewhere else. Since I can't reproduce the problem, and nor can Thomas, I'd like volunteer user testers please, to try experiments and gather information on the resluts. Those willing and able to help and who can definitely reproduce the problem (crash or hand on exit, mainly. There's no way for us, outside L-M, to debug the crash on start). please drop me an email: petedowson@btconnect.com. I'll post this as new new pinned thread too. Pete

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