John Dowson

I haven't got time now to do a proper beta release, will do this tomorrow. but for now can you try the attached version, which is 7.5.0a. This is for both MSFS2020 and MSFS2024. I wo; release this in the Announcements sub-forum tomorrow. John FSUIPC7.exe

Hi Umberto, Yes - this will be updated and the version number for MSFS2024 will be 14. However, it will now only be populated once connected to the FS. Note you can also use offset 0x3124 which holds 110 for MSFS2020 and 120 for MSFS2024. I will be releasing a beta version of FSUIPC7 for MSFS2024 compatibility shortly. John

For the POV buttons. you have to assign to the relevant keypresses or assign in MSFS as the POV controls don't work in MSFS - as it says in the README.txt: Not sure about the "other" buttons, but note that many standard controls do not work for many aircraft (especially add-on aircraft), and you need to use presets (or lvars/hvars/Input Events). I will be very bust for the next few days (or weeks!) updating FSUIPC7 for MSFS2024 compatibility. So please: - ALWAYS check the documentation and support forum before asking questions - do not ask about anything for MSFS2024 at the moment, until I have updated and released a beta version that is compatible. And then, please post in the beta release topic (once available) until this is officially released.

No - works ok here. But I am using a slightly modified version of FSUIPC7. For any issues with FSUIPC7 and MSFS2024, can you please wait until I have released an updated beta version, hopefully in a few hours. I will post/release this in the Announcements sub-forum. There is no point in posting any issues with MSFS2024 prior to this beta release of v7.5.0 John.

Thanks for the feedback! You had a better experience than me... Managed to install and ran it for the first time to download the remaining files. I then quit to install the FSUIPC WASM module, but after that I couldn't use it due, I think, to server issues. On the first restart it got stuck at 97% loading, the 2nd time at 0% loading, and then i was permanently in a log-in queue...I gave up after several hours... Seems to load ok today though. To use lvars/hvars/presets/etc, you can copy the FSUIPC WASM module (folder fsuipc-lvar-module) from your MSFS2020 Community folder to your MSFS2024 Community folder. I will be releasing a beta version of FSUIPC7 later today (hopefully!) with better compatibility with MSFS2024, and will also update and release the installer in the coming days. John

You can use the current 7.4.18 release of FSUIPC7 with MSFS2024. However, there will be a few issues, such as: - MSFS2020 folders will be used for various things, such as - saved flights (including auto-save) - flight plans - detection of WASM I will correct these and hopefully release a beta version of FSUIPC7 later today. I guess you could, but probably better to just use the current / latest version. For the time being, just copy/duplicate your current installation folder. I will be updating the installer to allow either one installation for both MSFS2020 and MSFS2024, or to have separate installations for each FS (as I do with FSUIPC6 which supports P3D versions 4, 5 and 6). This will tale me a couple of days. I will post details later, but if you want FSUIPC7 auto-started, you can create an EXE.xml (or add an entry to it if already created) file for MSFS2024, and for access to lvars/hvars/presets/calc. code, you can copy the FSUIPC WASM module (folder fsuipc-lvar-module) from your MSFS2020 Community folder to the MSFS2024 Community folder.

This is because you are using a preset name already defined in the events.txt file: Please give your presets a unique name. As most presets are aircraft dependent, its a good idea to prefix the preset name with the aircraft name, e.g. TFDi_MD11_Master_Caution_Press#86110 (>L:CEVENT) TFDi_MD11_Master_Caution_Depress#86111 (>L:CEVENT) I should maybe add a check to make sure the name is unique when loading the presets... John

Ok, thanks for the update. I could not understand your issue as each button repeat should be independent, i.e. repeats on one button should not affect repeats (or not) on other buttons.

Its the state of a key he wants to read, not a button.

The SDK_Defines,h is interesting, and shows the aircraft doe supply additional information but through a shared memory block. I could possibly look into accessing this and adding this to FSUIPC offsets. I will add it to my list to look into when I have more time, but I will also need to contact iFly for additional information on the SDK and for a license to implement this. Not sure when I will have time for this at the moment though - maybe next year at some point... John

That is interesting - I will add this info to the Advanced user guide. I would like to look into thus further, when time permits, to see if I can discriminate between the different traffic types and come up with a solution that works for both. Thanks for looking unto this further. John

Well, no switch position is ever permanent...otherwise why have a switch! Your use of the word temporary is just confusing for me...all repats, button and key, are temporary in that sense... And none of this is related to the TFDi MD11, it is your assignments. But I do not understand your issue, which is why I need to see a log file. This will tell me what is happening, then maybe I can make sense of your description...

Please activate logging for Buttons & Switches, and show me / attach the FSUIPC7.log file showing this, together with your FSUIPC7.ini file. Repeats on one button should not affect the assignments for another button. What do you mean by "temporary" here - there is no such thing. Assignments are either repeated or not, nothing temporary about them...

No. Then just duplicate/overload the assignment, or use a macro. You can add a paise control (1152) in between the controls if you need a delay. Or use lua for any more detailed control. Not sure what you mean by this.... "Repeat while held" just does as it says - it repeatedly sends the control while the button is held (i.e. from the press to the release event). It should not affect any command send "afterwards", from another assignment.

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

👍