John Dowson

Something like that...I would need to see the logs to confirm (and may even need Trace logging enabled in the WAPI). In theory, the lua threads that are killed should release any locks, and the next lua thread should be able to obtain them. But sometimes lua threads don't seem to die completely and the locks are not released. If FSUIPC is unresponsive, I would think this is due to some sort of race condition in the locking. John

You can use the Pause control (1152 - see page 30 of Advanced User guide) to add a delay, in ms, e.g. to add a 100ms delay try 53=PA,27,CPLDG_LT_R_Down,0 -{Preset Control}-. 54=PA,27,C1152,100 55=PA,27,CPLDG_LT_L_Down,0 -{Preset Control}-. John

👍

Ok - thanks for the update. This SDK lib is very old and does need updating to include the various P3D versions as well as MSFS2020 and MSFS2024, and compiled with VS2022. I will do this at some point when I get a chance, hopefully with the MSFS2024 release,... John

Yes, no WASM crash. Are your rotary encoder buttons assigned to run the lua script? If a button is assigned to run a lua script, when the button is pressed, a thread is created, the script compiled and then ran. The problem with assigning rotaries to such scripts is that button presses are received faster that the previous button press is completed, so a subsequent button press will kill the lua thread from the previous button press, create a new thread and start again. And this is complicated by the lua thread having locks around the lvar access. You can have lua assignments to buttons to perform single actions, but for repeated actions (which include button repeats and assignments to rotary buttons), you should use an auto-running lua that waits for the button press event with no assignment to the button in fsuipc. To check this, can you activate logging for: - Events -(Log -> Events) - Buttons & Switches (Log -> Buttons & Switches) - Extras (Log -> Extras) - WAPI Debug (Log -> WAPI -> Debug) and generate a new FSUIPC7.log file showing your issue, and attach that together with your FSUIPC7.ini file and the lj35_alt+1000.lua file. John

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