John Dowson

If you restart FSUIPC, does it then work, or do you have to restart MSFS? If you need to restart MSFS. you could be experiencing a WASM crash. To prevent this, you need to turn off ;var scanning in the WASM - see the following FAQ entry in how to do this: If its not that, I will need further information. What did you do when this occurred? Your log shows the lua script was killed, and 14 seconds later the WASM SimConnect connection was closed, but the log file wasn't closed: I am wondering what killed the lua script - maybe it hung (when trying to access lvars, as the WASM had crashed) and then you pressed a button to run it again, which would kill the running one?

There is currently no integration of the iFly SDK with FSUIPC7, so this information currently isn't available. How does the SDK make this information available? The PMDG SDK makes the additional data available via client data areas, which FSUIPC reads to populate the offsets. I could possibly do something similar with iFly. Do you have an SDK document available? If this looks feasible, I can contact iFly and go from there. If possible, I am not sure when I will have time to look into this though, as MSFS2024 is in the horizon and I will be busy with this for a while... John

This is because they are using custom control numbers above 84232. which is the maximum that is mapped (and can therefore be used) by default. To allow for higher numbers, you need to set the following ini parameter in the [General] section of your FSUIPC7.ini file: MaxCustomControlNumber=96323 Your FSUIPC7.log file will tell you what numbers are mapped and can therefore be used: John

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

The file you attached is called Simconnect.ini.log whereas it should be called just SimConnect.ini (i.e. remove the .log)- and it should be under C:\Users\xxx\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache. Check your SimConnect.xml file as well (same location), and make sure the MaxClients entries are all set to 128 - if not, update them. What is this entry for in your EXE.xml: ? Also please try the attached EXE.xml - I have moved the FSUIPC entry to be started before the others, John exe.xml

Auto-tuning continually monitors for connection errors/timeouts during start-up, and if any anomalies detected it will flag auto-tuning to be ran on the next FSUIPC7 auto-start. So you must have had a value set that caused some issues, and when auto-start ran the next time it either took a long time to get to the main menu, or possibly you passed the main-menu state before FSUIPC7 connected, and so a large DetectToConnectDelayAuto time was set. You can prevent auto-tuning doing this by setting: StartUpTuningDoneVersion=-1 If you do this, probably also a good idea to increase the initial stall time, i.e. also set InitialStallTime=30 John

I also need to see the Rotaries.lua script, and the Fenix A320.ini - the ini file used with the aircraft you are using, which is "Airbus A320-200 CFM Orbit Airlines D-AOAW". And the slow turns are working but the fast ones not? Was this previously working for the same aircraft? Note that it may work in one aircraft but not another, depending on the controls you are using. Especially with (complex) add-on aircraft as many of the standard FS controls (or FSUIPC offsets) don't work, and you need to use other methods, such as custom controls, presets, input events, etc Presumably you are using the Rotaries.lua to set different virtual buttons for slow/fast in each direction, and have assigned the controls to these virtual flags, no? And it is far easier for you to debug such issues, as you can see what is happening in real time when you turn the rotaries. Are the virtual button flags being set/triggered? Do you have assignments to these virtual buttons, and are they being sent? But I can take a look to see if I can see anything. Please also activate FSUIPC logging for Buttons & Keys and Events, and send me the complete set of files.

This is because you have a very large DetectToConnectDelayAuto set: Auto-tuning is gradually reducing this: but it will only reduce by 10 seconds at a time. This high value was probably set via auto-tuning when MSFS took a long time to load (for some reason). Try manually setting that value to 30 in the [General] section of your FSUIPC7.ini file. If that is too low, auto-tuning should increase this to the correct value, which will take effect on the next restart of MSFS. See the Advanced User guide section Auto-tuning of initial start-up ini parameters on how this works, or the following FAQ entry: John

For help with presets, please use the MobiFlight Discord server on the MSFS2020 channel.

Can you please re-download 7.4.18 and re-install and try again please. The build date should read 3rd November, not the 1st. Please check this. You may need to clear your browser cache to download the version again. The initial release of 7.4.18 was accidentally built against the MSFS2024 SDK, but I correct this a day later and re-uploaded but didn't change the version number. Sorry about this. John

Please show me this file as well: C:\Users\marty\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\EXE.xml Yes, but it connected and was working when you did this, although it took far longer to connect than it should. I do not know or understand why simconnect is either not responding or taking a very long time to respond, I can only think that this is due to other simconnect clients, which is why I would like to see a simconnect log file (as this shows all simconnect activity. Not sure why you attached that log file - just shows that you exited FSUIPC after 14 seconds, and there is no additional logging. For the time being, please run with the logging console open (Log -> Open console) and monitor the messages, and only exit FSUIPC if you see that it cannot connect after a minute or so. Also please set the following options in the [General] section of your FSUIPC7.ini file: InitialStallTime=45 DetectToConnectDelayAuto=20 StartUpTuningDoneVersion=-1 TestOptions=x800 This will reset those parameters and prevent auto-tuning changing them (as well as setting the additional logging), This issue seems very different from your original issue. Did this connection problem start recently?