Pete Dowson

Install any FSUIPC6 add-ons, like Lua plug-ins, macro files AND additional driver DLLs like those for PFC, into the same folder you chose for FSUIPC6. If you had FSUIPC5 before this, in a Modules folder, you just needed to copy all your stuff over then rename the FSUIPC5.INI to FSUIPC6.INI, as I think it suggests in the Installation guide. Pete

Hmm. Interesting. I'll have to look to see how that was done. Tomorrow though, it is late here. I think it probably relates to the fact that the Key Down also generates an event. Might be interesting for you to test those two assignment lines with actions only on the Key Up. If not, I'll try that tomorrow. We should be able to make the Lua events behave in the same way. Currently the "downup" parameters says "either of up or down" whereas the control assignments are distinct. There's no equivakence. So another check is what happens with separate "up" only events. Pete

Excuse me for butting in, but why wait a year before reporting what you think is an FSUIPC error, and only report it just after a new version is released? Such problems have been raised periodically, and are usually traced to other addons. Useful threads to review are these https://forum.simflight.com/topic/83826-shift-e-1234-only-opens-main-doors-in-p3dv3/?tab=comments#comment-506681 Note in that one the replies there are suggestions about the "TimeForSelect" parameter in FSUIPC. If you set that to 0 then FSUIPC will not attempt to provide any assistance against interfering controls from other add-ons. This may allow things to work better on some aircraft, but worse on others. There's also a technique whereby instead of using separate key presses you assign in FSUIPC to Toggle Aircraft Exit and provide the 1,2,3 or 4 as the parameter. Probably more reliable is to assign to Offset Byte Togglebits with offset set as x3367 and the parameter set to 1, 2, 4 or 8 (or additions for more than one door at a time). Other useful references: https://forum.simflight.com/topic/80422-opening-aircraft-doors/?tab=comments#comment-485890 https://forum.simflight.com/topic/86431-cargo-door-issues/?tab=comments#comment-523946 https://forum.simflight.com/topic/80167-doors-failing-to-open/?tab=comments#comment-484347 Pete

Yes, it will do, because both apply. There's really no way around that. You asked for an event to be triggered when A was released. Well it was. At that time, the Ctrl doesn't figure. Pete

Like John, i don't know what that is. There's no point in you repeatedly showing pictures of the software you are using. It is evidently not getting things right. It is the authors of that program you need to address! The only way an FSUIPC application can tell through FSUIPC what version of flight simulator it is handling is through reading offset 3124. I have double checked and this most certainly reads "50" for Prepar3D 5.0, exactly as it should and as documented. I think that the program you are using, has not been updated for P3Dv5 and is not interpreting whatever it is reading from FSUIPC correctly. Most likely it is only reading offset 3308, which does not and never has given the specific version number of FSX or P3D, but only"FSX 32-bit", "P3D 32-bit" or "P3D 64-bit". You need to go to the support forum for that program you are using and ask them for an update. Or just use it and be happy! 😉 Pete

Thanks. Yes, I can repeat this. I'll discuss with John (who's now the FSUIPC developer) about a way of fixing this. We can't promise when a fix will be forthcoming though. Pete

Hmm. This is probably because Windows notifies us of the main key release separately. In which order do you release the two keys? That might make the difference. I can do some experiments here and see if we can handle this either way, but it would be handy to know whether the results are different before we delve into it. Interestingly no one has come up with this before -- the code isn't exactly recent! 😉 BTW the current version of FSUIPC5 is 5.155, and that's really being replaced by FSUIPC6 in terms of development. Pete

We've always striven to retain backward compatibilty of FSUIPC's programming interface, which is what I assume you mean by "codes". FSUIPC version 3 was released as the FS2004-compatible update to Version 2, which was the update for FS2002. Version 1 was for FS2000, but also worked on FS98. Each version update replaced the one before but supported also the extra facilities available with each successive version of FS. The only major change making it incompatible with FS versions FS98 through FS2004 was the introduction of SimConnect in FSX. So FSUIPC4 is not compatible. I cannot verify now that FSUIPC3 remains compatible, but it has undergone no changes which would render it incompatible. That's all I can say. So why not just try it -- it would have been quicker than having this exchange here, and it wouldn't cost you anything. And sorry, I cannot support FS2002 and before. Pete

But you wouldn't be using much of it in any case. if the add-on aircraft needed it, it will just tap into it, all by itself. You'd simply ignore it altogether after you install it. It would be as if it didn't exist for you. But please yourself. I'm not here to twist your arm, only trying to help. Pete

Well, your TQ6 button 2 is assigned to Throttle 2 decrement for your B474 (odd name) profile, but Throttle 1 decrement for your B777 prtofile. That shouldn't matter, jst pointing out that you could easily get mixed up. The only assignments you have to Spoilers are to axes, not buttons. The assignment for your B474 profile is 6=3X,1,D,22,0,0,0 -{ DIRECT: Spoilers }- so it's the X-axis on the TQ6. Could that be the axis associated with button number 2? I don't know the TQ6, but possibly when you press a button associated with an axis, it sends the axis as well? The spoiler setting being seen is 16384, which is fully deployed. Test with the spoiler axis lever at the other end of its travel, which should be spoilers off. See if you get a different result. The other possibility is that before using the reverse thrust button you had spoilers armed, and the add-on aircraft you are using takes that as a signal to deploy spoilers automatically? Not that it should -- it should deploy them on touch-down.. Come to think of it, why are you using reverse thrust if not to slow down after touch-down? Either way, I have to say that it isn't anything in FSUIPC which is doing it. Pete

Thanks Thomas, though it's offset x78ED not x78DE (typo) 😉 Pete

Then best show me the "Runways.txt" file, which will show what has happened with a little more detail than you are giving us. That file is the log of what MakeRunways did. Pete

Sorry, I see you've attached a picture of some table or other, but it is completely unreadable even if I magnify it. If you can operate the functions you want through offsets documented by FMGS then you need to state what offsets they are and what values the aircraft expects. Then we can help you enter the correct assignments in FSUIPC. Pete

Topics of more permanent importance or announcing changes or new versions are now all located in the ANNOUNCEMENTS subforum -- except for the one here which should be read concerning posting problem reports. This is in order to make it more obvious that this, the main Support Forum, is the place for interactive support and help. The subforums above are for reference -- excepting the FSUIPC7 sub-forum, which should be used for all issues with FSUIPC7 / MSFS2020, and the specialist one supporting users of Paul Henty's .NET DLL. .

Verified! P3Dv5 doesn't send the SystemEvents for SimConnect Texts or Menus. I've posted to L-M in the Beta (Developer's) forum. [LATER] The problem has gained L-M attention, both in the SDK forum and in the Developer's forum, so I expect we'll see results in due course! Pete Pete

The problem has gained L-M attention, both in the SDK forum and in the Developer's forum, so I expect we'll see results in due course! Pete

There's no way FSUIPC loses any settings. They are stored in your FSUIPCV INI file and reloaded each time. How are you actually detecting the the slope settings are lost? And how do you "recalibrate" if there correct values are already displayed? What do you change? Please tell us the actual things you see and do. Without some actual information we can't really help much. We don't know even what simulator you are using, let alone the version of FSUIPC. And we'd need to see your FSUIPC settings anyway (the FSUIPC INI file). Pete

Well, apart from the Log showing continuous "85637" custom controls -- presumably one of the PMDG ones -- indicating a constantly and rapidly repeating button, It also shows that you have an axis control being sent for SPOILERS_SET. There's nothing else useful there, and it is even less useful than it should be because of this: [Continuation log requested by user] This shows you specifically closed the clog and started a new one, by pressing the NEW LOG button in the Logging tab. Please don't do that! It's only these for breaking up a long test into manageable files. We can't really help further without a proper log, from the beginning, AND, even more importantly, tyour FSUIPC settings -- the FSUIPC5.INI file. Pete

Sorry you found it so. Just surprised by your post, and also probably slightly annoyed by having to move your post which was incorrectly placed. No offence was intended. BTW Just for information. I'm actually retired now at long last (I am 77 this year), and just helping out here because John is so busy. There's still a lot to do in the P3D world and MSFS looms! A poor excuse i know, but it is one! 😉 Pete

I don't use any PMDG aorcraft, but as far as I know, and according to the supplied PMDG information (the controls list in their SDK "h" file), all of the custom controls provided operate like the mouse operation they replace, and use one of the listed mouse codes accordingly. If you've had them working with plain numbers I think you may have just been lucky, or the number has a correct matching bit in it when compared to the mouse codes. The complicated looking decimal numbers you quote are actually simple in binary. The hex representations are: -2147483648 = 0x80000000 (so just one bit set) 536870912 = 0x20000000 (ditto) Check in that PMDG file to see what they mean it terms of mouse operations. FSUIPC isn't really doing much here, only sending whatever action you assign on to the Sim, to be picked up by the aircraft code. Pete

Please always post support questions to the Support Forum -- you posted in the Download Links subforum! No it doesn't! Where do you read it saying that? WideFS 7 keys will work. They are the same across FSUIPC4, FSUIPC5 and FSUIPC6. But not an FSUIPC5 key in FSUIPC6. Pete

Sorry, then I'm misunderstanding you. I took this "stub" you mentioned to be something else. You are simply talking about P3D not terminating, which we knew about. Obviously if it isn't terminating there's still the process in memory. Yes, that is strange though. Once a file is closed it can have anything done to it. Ah, that makes more sense. So the "less than a second" manual close is just the external LINDA application? Not really relevant to what's going on with P3D and FSUIPC. Thanks for the clarifications. Pete

FS2002 was before FSUIPC needed purchasing (it was free from FS98 to FS2002 inclusive), and before most of its User Facilities were added. So it sounds like your add-on aircraft only used the programming interface into FSUIPc which was free. So you don't need a registered version. Pete

Ah, in the Software Development Kit (SDK) Questions area. I didn't think of looking there. I checked the main forums and the SimConnect specific one. Let's hope for a HotFix soon with L-M taking note of these things. Pete

This is what seems at odds. FSUIPC closes the log when it says it does, with the three extra lines added simultaneously. I'm really puzzled at why it isn't "released" till later. What is this "hanging P3D background task". Is this related to something LINDA has got running and which doesn't get closed when the LINDA task is killed? So you don't use VRI driver linked via virtual ports? It's only just dawned on me. The other 7 ports are USB joystick connections, your Saitek and other controls! Duh! I've been puzzling about that for ages! I didn't expect it to work! It was merely an attempt to get more information so i could understand what was going on, as i said earlier. That's because it appears to be crashing or hanging during the closure of the first COM port, when the first thread is closed -- or possibly in the second thread when it is seeing that it needs to close (a note on this just below). That might be an error in my new logging loop. i'll check. By "manually closed" is this a tidy metthod you've implemented, or an assignment to an FSUIPC Kill control? If you can do a tidy close like that, do you use "event.terminate" to close down your Lua functions? I think that only gives a short time extension to tidy up. Perhaps you need more? Maybe that should be configurable in the Lua code. e.g event.terminate("function name", timeout) where the timeout parameter is optional. Pete