John Dowson

Yes. its strange that that happens... Thanks for the feedback! Cheers, John

Yes, I don't know what is setting that for some folks, but I presume its anti-virus software. Do you use any anti-virus software on top of Windows Defender?

Please use the specific sub-forum for all issues with FSUIPC7, not the main support forum. I have moved your post. There is nothing wrong with the installer, and you don't need to run it with Admin rights. Check that anti-virus software is not blocking it from running. Also check that you have the latest VC++ redistributables installed.. Do you see anything at all when you run the installer? If not, check the installer properties (right-click, select Properties). Sometimes it is blocked there from running. Note that you have to run MSFS at least once after installation before you can run the FSUIPC7 installer.

I know what APL2 is, but I do not know how it uses FSUIPC. If there are issues with APL2, then report to them. If there is an issue with APL2 using this beta, then they should contact me to explain what this issue is. As I say, I can only support FSUIPC, not 3rd party programs that use FSUIPC.

Your FSUIPC7 version is fine. You need to check your network. Please review the section Configure your Network in the WideFS User guide, and maybe add the ServerName and Protocol WideClient ini parameters. Also try with firewalls disabled (client, server and router) to see if a firewall is blocking the connection.

I don't know and do not support 'A Pilot's Life'. You should contact them first - maybe that needs an update for MSFS2024? Otherwise, I would need to know what this app uses to determine the 'flight stage'. The image you attached also shows FLIGHT SIMULATOR DISCONNECTED, so its not surprising that the flight stage is not started.

I need to see your FSUIPC7.log and FSUIPC7.ini files as well, and not your InstallFSUIPC7.log file. However, if this started after a windows update, you need to check your network set-up, especially the WorkGroup. Please see the provided WideFS documentation, and follow the set-up and trouble-shooting guides there. Also, if using FSUIPC7 version 7.4.18, check the build date (1st line of FSUIPC7.log file). If that says 1st November, please update - it should say 3rd November. You may need to clear your browser cache to download again.

Presume you mean 7.4.18, no? If not, please update. If using 7.4.18, please check the first line of your FSUIPC7.log file. If it has a build date of 1st November, i.e.: then please download and re-install. it should say 3rd November: The initial release was accidentally built using the SDK from MSFS2024, and I corrected this the following day, If that is not the issue, please show me / attach your FSUIPC7.log file. Ah...just seen your updates... Yes, that is definitely the issue - please update. John

You did not set this: That will always log the value it is using on start-up. You either set it in the wrong ini file, added/changed it while FSUIPC7 was still running, or maybe added it again and there is another entry.

That was the log from the H145. You then set LvarScanFrequency=0 and said the WASM still crashed when loading the H160. It therefor seems like it crashed on the first lvar scan for this aircraft- but I need to see the mew/updated log to confirm. This delay will always be long passed when the WASM crashes. This is just the delay between aircraft load and the first scan for lvars. You only need to increase this if the first scan does not return lvars that you are using directly by name or id (not in calc. code or presets), i.e. by adding to offsets, in lua or in macros. Ok. But this is also a known issue with the WASM, and is not related to the MSFS2024 release. John

So the WASM crashed on the initial lvar scan? That is very strange, and worrying - I haven't seen this before. Could you show we the FSUIPC_WASM.log file for this please. That will delay when the first scan will be performed, but if its crashing when initially scanning for lvars, it may not help. Unless its some sort of timing issue, and crashes if the lvar scan is done at certain stages of aircraft load / operation. I have checked this now - it doesn't pick-up hvar files added to the Community WASM folder' modules folder any more, as you noticed. It probably needs to be added to the layout.json file, as you say. I will ask Asobo about this and update the documentation accordingly. You can try adding them to the persistent storage area work folder instead - they should load from there (and that is the preferred place to add them anyway!). John

It should process all hvar files in the Community\fsuipc-lvar-module\modules folder. Your log shows that there was no match of the hvar file names to the aircraft you were using ("Airbus H145 ADAC NoHMD"): So this is expected. What do you mean by "the 2 not listed therein"? Did you add these files to the correct folder? The log shows only the 7 hvar files installed by the installer were found. When you execute calc. code, and with Debug logging set in the WASM, you should see the calc code execution in the log, like this: When it stops working, do you see anything logged? If not, then the WASM has crashed and you need to disable lvar scanning (see FAQ section). As the last entry in your log is this: It does look like the WASM has crashed when scanning for lvars. Are you also using add-on scenery by any chance? How did you install the H145 - manually or via the MSFS2024 market place?

I have checked this and it is correct, i.e. it contains the 1.0.6 WASM. Your issue is that you have the 1.0.5 WASM installed. If using FSUIPC7, you should download and install the latest release (and maybe also try/install the 7.5.0-beta available in the Announcements sub-forum), If not using FSUIPC7, then install the WASM from the FSUIPC WASM module zip file that you downloaded.

If you do this, make sure that you update the EXE.xml for MSFS2020 to point to the copied folder, otherwise the main folder (where you installed using the installer) will be used.

That log is not using the version posted above, it is using 7.4.18 (the current released version). Also, you haven't set InitialStallTime=-10 : or maybe you set this but it was reverted as you were using the wrong version.

@LeoSchoonbroodt Yes, that is preferred over using hvars directly. It is not related, but I will check this. Presets and calculator code are basically the same thing - a preset is just a name associated to a calc. code string. And no, you shouldn't need to do that. They are only in that location if you add them there. I don't know - as I said, I will look into this. If it stops working, I can only think that the WASM has crashed. When it stops working, do you see anything logged in the WASM log when you send the calc code? If you exit MSFS, foes the WASM exit correctly, i.e. is the last line: If not, then the WASM has crashed. If it hasn't crashed, I need to know if the request is reaching the WASM or not.

If there is a difference in the aircraft names, you could use separate profiles. Otherwise its up to you - you can have a separate installation or have two ini files and copy/rename them before starting the sim.

Did you also extract/install the WASM folder (fsuipc-lvar-module) from that zip file to your Community folder? if not, please do that and try again. That message indicates that the dll is the correct one for 1.0.6, but you have the 1.0.5 WASM module installed. If you have already done that, then I will check the version.... John

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. Try an included aircraft. I don't want to complicate things too much at this stage...

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