John Dowson

These are the WASM permanent storage areas created by MSFS2024. @LeoSchoonbroodt Please don't embed your questions into quoted text, you are just making things difficult for me...I am not going to respond to that, sorry. But please check that you are not suffering from a WASM crash if you have issues where calc. code updates stop working. I have already posted enough information on this. Otherwise, please post any quertions unquoted... That is it definitely it for tonight now - no more responses from me until late tomorrow or even later. Please review before posting. John One more piece of advise: if you are manually copying aircraft from MSFS2020 to MSFS2024 and have issues, please DO NOT post here. Doing this just complicates things, and I will not look into any issues if you have done this.

Neither. You copy the fsuipc-lvar-module folder to the MSFS2024 Community folder, as described in the initial post. If you then want to add an FSUIPC_WASM.ini file to the WASM persistence storage area, you need to first run MSFS2024 with the WASM installed, then the WASM storage area folder will be created under the ...\WASM\MSFS2020 folder. Then add your ini to the ...\WASM\MSFS2020\fsuipc-lvar-module\work folder. I don't understand why this is so difficult. This works in exactly the same way as with MSFS2020, it is just the folder names that have changed. I will update the documentation for this, once I have updated the installer...

@LeoSchoonbroodt Are you actually using the hvar files? These are only needed if using in lua or macro scripts (or via offsets). It is far easier to use presets, where these files are not needed., I am going to remove these as they are continually causing issues and are really not needed anymore. They are a hangover from the early days of MSFS2020. If using hvars directly, switch to using presets instead. If using presets for hvars, stop going on about hvars and just talk about presets. Of course not. They are only there if you add them. I do install some hvar files, but they are installed with the FSUIPC WASM folder under your Community folder. As with the FSUIPC_WASM.ini, there is an order to how these are loaded, but please see the Advanced User guide - I am not going to explain this again when this has nothing to do with MSFS2024... It all works in exactly the same way with MSFS2024 as with MSFS2020, only the locations have changed. I will update the documentation with the new locations for MSFS2024 before I release officially. @SMN204 Looks like you are suffering from a WASM crash. See the FAQ entry on how to resolve this - but take care to use the MSFS2024 locations. If you had this in MSFS2020, you probably added an FSUIPC_WASM.ini with updated ini parameters to resolve this in your MSFS2020 WASM persistence storage area. You need to copy this across to the MSFS2024 WASM persistence storage area. @kr283 Your issue also sounds like a WASM crash (IF you have the WASM installed). Please check the FAQ entry on what to do. But it is A:WAYS helpful if you can attach a log if/when you have issues. If I need further info or additional logging, I will ask. But attaching a log when you experience am issue is always helpful, and I would encourage everyone to do this - it can save a lot of time... @jabloomf1230 The clear function in FSUIPC only clears the FSUIPC assignments. not the ones in MSFS. It is up to you to either create an empty profile in MSFS, or delete any assignments to a button/Switch/key/Axis in MSFS of assigning in FSUIPC. Other than that, I am not sure what your issue is. Your log file looks ok, but shows you are using 7.5.0a. Please download and update to 7.5.0b. Thats it from me for tonight.... John

Because that is the folder MSFS2024 has designated for this WASM. Presumably because MSFS2024 detects that the WASM has been compiled against the MSFS2020 SDK. I wouldn't worry about this - I certainly aren't! Then please try and restrain this instinct...at the moment its difficult to get anything done when I am continually answering support questions....

👍

WASM modules compiled for MSFS2020 are treated as such, so I don't think this is an issue. MSFS2024 knows when its using an MSFS2020 WASM. Presume you mean in the MSFS2024 WASM modules folder? Nothing has changed here - except maybe the aircraft name in MSFS2024. Does your hvar file name match the aircraft name? Can you activate logging in the WASM and show me the FSUIPC_WASM.log file. Do this with WASM Debug level logging set. Or maybe you had the hvar files in the persistent storage area for MSFS2020? If so, you will need to copy these to the persistent storage area of the FSUIPC WASM for MSFS2024.

For such events that are constantly logged, you should ignore these by setting the DontLogThese ini parameter. See the Advanced User guide for details. In the assignments panel. check the Select for Preset checkbox. Then the Find Preset... button to see the tree-preset selection box. I do supply user manuals...read them! John

Then please use the specific support forum for FSUIPC7 / MSFS. I will move your post. Have you tried the available presets - FNX320_LIGHT_RWY_TURNOFF_ON, FNX320_LIGHT_RWY_TURNOFF_OFF or FNX320_LIGHT_RWY_TURNOFF_TOGGLE?

What FS are you using, and what version of FSUIPC? Have you tried activating logging for Events, open the logging console and see what is logged when you turn on/off the runway lights in the VC?

I have updated the version number for this now, available from first post in this topic. A few logging changes also. John

Ok, thanks for the update.

No, that is not the WASM module, it is the persistent storage area for the WASM, which in MSFS2020 was under C:\Users\[USERNAME]\AppData\Roaming\Microsoft Flight Simulator\Packages\fsuipc-lvar-module If using FSUIPC7 with MSFS2024. please use the latest beta, available here: All questions / comments / requests on using FSUIPC7 with MSFS2024 should be posted in that topic for the time being. I am closing / locking this topic now. John

If things are working, then you can just leave everything as it is. However, please update to use JoyLetters - just set AutoAssignLetters=Yes in the [JoyNames] section of your ini. If you want to try cleaning the registry, follow the instructions previously posted. But switched to JoyLetters first, and run P3D/FSUIPC at least once after doing this, to get your files updated to use the letters.

By the way, you are now getting two devices reported with the same GUID (previously was 3): Maybe make sure those two devices (vJoy Device and Flight Throttle Quadrant) are connected to ports on different USB hubs. GUIDs should be unique for each device - I don't understand why these are being reported as the same. You should really be getting unique GUIDs from HID scanning. Cleaning the registry won't correct this.

That is surprising as your log shows two devices assigned the same id and have the same GUID: Are these two devices working ok? I would do this as your registry is still a mess. Maybe also check that you have USB3 devices plugged into USB3 ports, and USB2 devices connected to USB2 ports.

What do you mean by 'lost many of my device'? You should not try and do anything with any device yet. As O said, just run and exit and show me the files. Restore what from backup? Restoring the registry dump from back-up should put your system/registry in exactly the same state as it was before you ran the .reg script, This is the whole point of taking a back-up... That script only removes the registry entries for 4 devices and in no way should affect your USB ports/hubs, Sorry but I have no idea what you did or why this is happening. You obviously have not followed my instructions, or I would have expected to see your files after you had ran P3D/FSUIPC for the first time after cleaning the registry and reconnecting, and before doing anything else. Sorry, but I cannot help if you are now having issues with USB controllers - this is nothing to do with FSUIPC.

And maybe not. If I ever see separate downloads of this file for MSFS2024 and MSFS2020 on the HubHop server, then I will update FSUIPC7 to handle this, and load the specific events.txt file for the FS being used. But I doubt this will happen. As you can now access B-vars in calc. code in MSFS2024, there will be some presets that are MSFS2024 specific. There are some discussions on how to handle this over on the MobiFlight Discord server. I will update FSUIPC to handle this once it has been decided what to do. But I wouldn't expect anything to change for some time yet.

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.

And maybe not. If I ever see separate downloads of this file for MSFS2024 and MSFS2020 on the HubHop server, then I will update FSUIPC7 to handle this, and load the specific events.txt file for the FS being used. But I doubt this will happen.

Why are you sure about this? If its the same aircraft, I would have thought the same settings would apply. This is the case with P3D, where I use one installation of FSUIPC6 for both P3Fv5 and P3Dv6 (and sometimes also with P3Dv4). No, just one FSUIPC7.ini file per installation. It is really up to you - you can use the same installation for both MSFS2020 and MSFS2024, or you can have a separate installation for each FS. Personally, I will be using one installation for the time being. If I find any issues with this, I will switch to using separate installations - or see of I need to update FSUIPC7 to handle things differently in some way for each FS. If you need to do different things in lua for MSFS2020 and MSFS2024, then you can just test for this in the script itself, by reading offset 0x3124 or 0x3304, You could even have one lua script that checks the version, and then starts the lua scripts needed for that version. Its up to you how you want to handle this. If you prefer separate installations, then just do this.

I would like to release this ASAP, by Tuesday or Wednesday next week at the latest. No - FSUIPC7 is for both MSFS2020 and MSFS2024.

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.

Yes. I think you must be mistaken. FSUIPC does not appear anywhere in MSFS2020. What you are probably seeing is a profile (that you created) called FSUIPC. MSFS2020 (and 2024) automatically creates profiles for many controllers, but if you assign your controllers in FSUIPC we recommend first creating an empty profile in MSFS. As with MSFS2020, you should create empty profiles in MSFS2024 for your controllers / devices if assigning in FSUIPC. If you are using the same FSUIPC installation for 2024 as with 2020, then your current assignments should be preserved.