John Dowson

Ok, thats good. But maybe you can explain how you fixed it, so that any other users that have the same issue and come across this post know what to do... John

You could also try setting the LuaAffinityMask ini parameter to move the lua threads off of core 1. This is not documented, but is basically a mask of the cores that can be used, where core 1 is 2, core 2 is 4, etc (core n is 2^n). So, for example, try using cores 3 & 4, by setting: LuaAffinityMask=x18 (core 3 is 2^3=8 (x8 in hex), core 4 is 2^4=16, or x10 in hex, so add then to get x16). You can add or move to other cores. This may help as core 1 is usually saturated in MSFS (and most flight sims). John

Can you please show me / attach an FSUIPC7.log file from when it is auto-started. Leave it running for several minutes, then exit and attach the log file. If you exit FSUIPC, does MSFS then get to the main menu? If you start FSUIPC7 once you get to the main menu, does it connect and function ok? Can you also please attach your EXE.xml - the location of this file will be logged in your InstallFSUIPC7.log file if you don't know where it is. John

Sounds good - thanks for the update. John

It is connecting but you are still getting quite a few re-connection attempts, as it seems the simconnect open call is taking a long time to respond. You could try the attached version, where I have allowed negative values for the InitialStallTime which will prevent the open call from timing out. Could you try this version please, and set InitialStallTime=-10 which will just log a message every 10 seconds until it connects. I would be interested to know if it does eventually connect, or if it is necessary to time-our and reconnect. Thanks, John FSUIPC7.exe

Ok, that is interesting. This adjustment to the AI traffic handling was done to prevent the issues reported here: I don't understand why this automatic transition of aircraft from ground-to-air is needed though. I will look into this further when time permits... John

How can I go about doing this? Stuff seems to be slowing down so I'd love to try this out, or if you have any links to resources that'd be greatly appreciated. But this change won't do anything. and certainly nothing that would cause "stuff to slow down". You can try this by simply changing the entries in the [JoyNames] section that use id numbers to the ones you want to use. FSUIPC will then attempt to use and reset those, but if that doesn't work it will revert to the ones currently used. And if that doesn't work, you can update the joyIds used in the windows registry, But I wouldn't recommend either action. It really doesn't matter what id numbers are assigned when using letters. That is the whole point of using them! Regards, John

Ok, that is interesting. This fix/change was added as it was causing other issues, when the altitude of ground traffic was changing from the correct altitude to 0, and thus FSUIPC was changing the state from ground to airborne when this was not necessary and was due to an incorrect AI traffic ground level being received. And also FSUIPC should not have to do this - it should receive the ground/airborne flag/status from MSFS, and this is only necessary when this information is incorrect. This is all quire strange and I think this may be due to how the various traffic add-ons are working. Are you using any add-on for AI traffic management, and if so which one? Could also be due to the differences between when using AI and real-time traffic. I need to investigate this further, when time permits, but I don't know when I will have time to do this at the moment.... Ok, thanks. Regards, John

You can also try the attached version. In this version, I have allowed/corrected negative InitialStallTime values. With such values, a successful open call will not time-out (and re-connect), which may help. So try this with the previous values, but set InitialStallTime=-10 John FSUIPC7.exe

Your log files show that FSUIPC7 couldn't connect to MSFS when it was auto-started. How long does it take from when you see the FSUIPC splash screen to when MSFS arrives to the main menu state and is ready? You should time this and set the following parameters in the [General] section of your FSUIPC7.ini file. Lets say it took 90 seconds, then set: DetectToConnectDelayAuto=90 InitialStallTime=45 StartUpTuningDoneVersion=-1 Also, are you using/starting any other add-ons via the EXE.xml? Some starting add-ons seem to cause issues with FSUIPC getting a simconnect connection, for example FS Realistic seems to cause problems. Could you maybe show me / attach your MSFS EXE.xml file - the location of this file will be logged in your InstallFSUIPC7.log file.

This depends on what sort of button you have and what it is assigned to. Can you activate logging for Buttons & keys, generate a short log file showing your issue (i.e. load the aircraft, push the button a few times, slowly, then exit) and attach that, together with your FSUIPC7.ini file.

Looking at your log, only the virtual rotary buttons 0 and 2 are being triggered, so only one button in each direction. This needs to be checked first - but I need to see your Rotaries.lua script. Can you please attach that. The lua log is difficult to interpret (and nearly impossible without the source!) so I will add some extra logging statements to that to log what I need and you can turn off lua debug logging. But it looks like 0 and 2 are the slow buttons, so no two consecutive button presses are being received within the time limit (100ms). Looking at the rotaries log, it seems the poll function is only called every 150ms or more, and if it processes a button press then its over 1000ms! This is extremely slow, and is why there are no fast movements detected. Debug logging will slow things down quite a bit, but it has also been reported that lua is running quite a but slower in FSUIPC7. This is something I need to look into further, when time permits. See One thing I commented there is that this only seems to occur when FSUIPC7 is auto-started by MSFS. So you could try waiting FSUIPC7 once it has been auto-started, and then start FSUIPC7 manually to see if that makes a difference. Please turn off lua plugin debug level logging when doing this, as that certainly slows things down, especially as you have so many scripts running. You can also maybe try tuning/increasing the FastTimeLimit to see if that helps. Also, your assignments are pretty much the same for each in/dec: - you have an inc/dec to the press and release of the slow button for each direction - you have an inc/dec to the press on the fast button in each direction I am not sure how these assignments would give you a fast ind/dec anyway, even if the fast buttons were working, You are sending one in/dec control in fast, and two in slow, so slow is actually quicker! Looking at the presets you have assigned to, e,g, FNX320_FCU_VS_KNOB_DEC : (L:E_FCU_VS) -- (>L:E_FCU_VS) this just substracts 1 from the lvar. For a fast action, you can define your own preset, e,g, FNX320_FCU_VS_KNOB_DEC_FAST as (L:E_FCU_VS) 5 - (>L:E_FCU_VS) which would subtract 5. Or you could parameterize this: (L:E_FCU_VS) $Param - (>L:E_FCU_VS) and specify the dec/inc value on the assignment. But you need to get the fast buttons recognised before thinking about this. John

Yes, it does seem to ne something else that is causing issues with the SimConnect connections. Setting MaxClients may help. The EXE.xml I provided just starts FSUIPC before the other add-ons, but this may not work as the others may still connect first. What you could also try is starting FS Realistic via FSUIPC - see the section Programs: facilities to load and run additional programs in the Advanced User guide. The log looks ok, but I wouldn't recommend a setting of 4 for DetectToConnectDelayAuto, and your log does show some re-connections. I would not recommend any setting below 20, and usually advise 30 as the minimum. John

This depends on whether the new one is assigned the same GUID as the old one or not (and if the names are the same)). If so, no issue, but it will probably be assigned a new GUID, in which case you will need to manually edit the GUID of the existing letter in the [JoyNames] section of your FSUIPC7ini file (for your old throttle), and delete the new letter entries. Also change the name if that has changed. John

I will look into this but I a, rather busy at the moment, so it may take me a few days...probably next week sometime or possibly later... There was one possible change that could cause this - from the changes.txt file (and FSUIPC history document): So you could try that. But before that, please check the build date of your 7.4.18 version, in the 1st line of your FSUIPC7.log file. If this says 1st November, please re-download and re-install. It should say 3rd November. The initial release was accidentally built against the MSFS2024 SDK, and I corrected this the following day. You may need to clear your browser cache to re-download (otherwise the old cached version will be downloaded), John