John Dowson

Yes - you should update these in HubHop, or at least report as erroneous,

No - the script would just run and finish. I can't see how this can do much with the WASM CTD issue... The script is not very efficient as it is poling and thus writing/updating lvars and offsets 4 times a second, regardless of whether the values have changed or not. Would be better to use events on both the offsets and the lvars, and only update the lvars when the offset value changes, and update the offset when the lvar value changes. John

Not sure what that is, but its not an API that I can use. Looks to be an application of some sort, not an SDK, and it seems to use (or look for) an "iFly Plugin".

Sorry - I think I got this wrong... Custom control numbers are those used in assignments when selecting the "<Custom Control>" entry in the FSUIPC assignments drop-downs. Those presets are incorrectly specified, and looks like the description was mistakenly used as the preset name. e,g, the preset Landing_Light_Switch_Left_Up uses "OVHD_LTS_LDG_L_SW_RIGHT_BUTTON_DOWN#90258 (>L:CEVENT)" which is actually the preset definition, not the calc code. I think these have been added incorrectly, and should be: John

Isn't it obvious? 98304 and 98305 are more than the MaxCustomControlNumber set as 96323. Set that parameter the the maximum custom control number that you are using.

When MSFS2024 is released, I will look into updating FSUIPC7 and, more important, the FSUIPC7 installer so it can handle both versions, This will take me a few days, once I have the new version download and running. So, please be patient with MSFS2024. FSUIPC7 should connect and run ok with MSFS2024, but it will use the MSFS2020 folders for many things, which I need to update and discriminate between versions, If you want to use FSUIPC7 with MSFS2024 before I update for this version, you will, at the minimum, need to manually install the FSUIPC WASM into the MSFS2024 Community folder. You will need to manually start FSUIPC7 for use with MSFS2024, or manually update the MSFS2024' EXE.xml if you want it auto-started. I will post details in MSFS2024 compatibility once released and I have taken a look. John

,,,and another thing you could try is to increase the LuaRerunDelay ini parameter to a value that gives the lua script enough time to finish, so that subsequent button presses don't terminate the lua from the previous button press....

Actually, when a thread is killed/terminated, if it has any critical section locks, the state of those locks become undefined. So killing a lua thread that holds locks (i.e. if it accesses lvars) can cause issues. I would have thought this would be timing dependent and quite rare though, so I am not confident that this is the actual issue... John

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