John Dowson

Ah, ok.

I don't think you can open that file in MSFS2024....if you succeed, let me know!

The path is available at offset 0x3C00. FSUIPC gets this from the AircraftLoaded event.

FSUIPC tries to read the icao_type_designator, icao_manufacturer, icao_model & icao_airline from the reported location of the aircraft.cfg file. However, it can only do this if the file is readable and not encrypted. Are you sure FSUIPC is reading this? Check offsets 0x0618, 0x09D2 and 0x0B26 and you will probably see that they are empty, which means that the aircraft.cfg can't be read.

Some devices do report multiple GUIDs - I wouldn't worry about this. Yes you should, and you should not have to reconfigure anything. It would be a lot easier to fix your current issue if you had done this, but probably not a good idea to do this at the moment - we can do this later. Can you do the following please: - run the windows registry editor and take a back-up of your registry - disconnect the following devices: MJ162, MJOY32, VKB-Sim Space Gunfighter L, Flight Throttle Quadrant - download and run (i.e. double-click it) the attached .reg file: removeDevices.reg - reboot your system - reconnect the devices you disconnected - run P3D/FSUIPC, and once loaded just exit - show me / attach those 3 files again (ini. log and JoyScan.csv). Do NOT change anything or assign/re-assign until we have corrected this. - if you can, let me know which device ids have changed from those used for your assignments, i.e. if you previously assigned to the device when it had a different id, let me know the current id and the id that was previously used for assignments on this device Note also that your ini file is a bit of a mess. The '//' characters are NOT the comment string for ini files, although such lines will be ignored. Best to remove these or replace with the comment character ';' (a semi-colon). You should also consider using substrings for your profile aircraft names, e.g. for the FSL320 profile, change to You should do similar changes (i.e. use substrings to match all variants) to all your profiles. Please also update to the latest and only supported version of FSUIPC6, v6,2,1. John

I have now released 7.5.0a-beta. Please see Please use that topic for all questions/issues/feedback - I will lock/close this topic now. John

I have now released 7.5.0a-beta. Please see If you downloaded this version from this topic (previously available above) then please download this new version as there have been some changes. The version number is the same (7.5.0a), but the build date for this official beta release is now 21st November (previous version was 20th December). I am closing/locking this topic now. Please use that Announcements topic for all issues and feedback with this version. John

...and one thing I don't understand is that 3 of your devices have been assigned the same GUID: GUIDs should be unique....I don't understand why these aren't. Please reboot before providing me the files.

There is no point doing this...the entries associated to a JoyId number will be completely re-written by FSUIPC. You should also use/enable JoyLetters to prevent issues when the JoyIds changer. Its also not a good idea to disconnect and reconnect devices when P3D/FSUIPC is running, especially if you have issues and are not using JoyLetters. Do you still have your original FSUIPC6.ini? If so, please use that, otherwise use the latest one which has all your assignments. Start P3D/FSUIPC, let it load and then exit. Then show me / attach the files FSUIPC6.log, FSUIPC6.ini and FSUIPC6.JoyScan.csv files - I need to see all 3 from the same session. The JoyScan file you attached shows that your registry is a bit of a mess and will need cleaning. I can provide a script to do this once I have seem those files. From that file, it looks like you have the following devices: 1 vJoy devoce 1 TCA Q-Eng 1&2 2 MJ162 2 MJOY32 1 Logitech G27 Racing Wheel 1 VKB-Sim Space Gunfighter 1 Flight Throttle Quadrant Is that correct?

That is just returning the value of the simvar FUELSYSTEM PUMP SWITCH at index 2. In FSUIPC, that value can be found in offset 0x0B05, but only when you have set the ini parameter NumberOfPumps to a value > 1. In general, it will depend on the output preset definition on how you would read the value in FSUIPC (and FSUIPC clients). For simvars (or A-type variables), you can check to see if it is already in an offset and use that if so, otherwise you can add any simvar to a spare/free FSUIPC offset for both read/write. See the Advanced User guide on how to do this. Yes, that is all that calc code does. John

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

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,