John Dowson

Looks to be a general issue since the SU5 update. You could try deleting your rolling cache (if you use one) as it seems to improve loading times for some folk. See https://forums.flightsimulator.com/t/extreme-long-loading-times-since-su5-solved/428994 John

The increased loading time sounds like it is due to the latest MSFS update, not the FSUIPC update - especially as you have the same loading times with FSUIPC7 not installed. FSUIPC7 does not change anything in MSFS (expect the EXE.xml if the FSUIPC7 auto-start component is installed) and so can not be the cause of the increased loading times without it being installed.

I'm surprised at this if you are only polling every 500ms, which is slow. I would have thought that there would be plenty of time to receive the updated values back from the FS, even at a 6Hz update frequency. You could try setting the update frequency to VisualFrame (or Frame), to see if that helps.

Hmm, strange. How are you reading them? Reading an offset should be the same whatever the offset holds - an lvar, a simvar or anything else, as the code is the same. Its only the way the offset is populated that is different. Or are you talking about when monitoring them? If so, the monitoring logging will only be performed when the lvar value changes, which depends on the defined update frequency. The lvar update frequency can be controlled by the WASM ini parameter LvarUpdateFrequency, which is set to 6Hz by default, i/e/ 6 times per second. This can be changed to one of the following values: Off, Second, 6Hz, VisualFrame, Frame (with Frame being the fastest). Alternatively, if you turn off lvar updates in the WASM, you can set the update frequency in the client (FSUIPC7) by setting the same ini parameter in the [WAPI] section of your FSUIPC7.ini. Please see the WASM Module section in the Advanced User Guide, P 43. Ok, good. Thanks for letting me know.

From the log menu, and the statements will go to youy FSUIPC7.log file (if you don't opt to log luas to a separate log file, which you shouldm't). Please see the User Guide.

@Ircghost Did you try just leaving it running to see if it eventually loads? Just done some tests (in my development system) on loading times with and without the FSUIPC WASM module installed. In both cases, FSUIPC7 is started around 4min 10-15seconds after MSFS started. Without the WASM installed, I get to the MSFS main menu after around 11min 45seconds. With the FSUIPC WASM module installed, this increases but only by around 15 seconds, to 12min or so. So I really don't know what could be causing your issue....

I've increased this locally and now get 1903 lvars for the CRJ700. I will release this update in the next WASM/FSUIPC7 full release. I can post and advanced copy here if you need access to any of the lvars not currently discovered.

The current build/release of the FSUIPC WASM module is limited to 1752 lvars per aircraft - any with an index of 1752 or higher will not be discovered by FSUIPC7. This is due to the number of CDAs used to transmit the lvar values, currently fixed to 12 (and allowing 146 lvars per CDA). It seems there are more than 1752 lvars for the CRJ, which is why some are missing. I could increase the number of CDAs to 14, to allow for up to 2044 lvars to be discovered, if that helps. Let me know. John

There is an issue using the SD size specifier. That should really be used for an int (or signed int), not a 32-bit floating point value. I've updated to use signed int for SD in the attached version, and also added a new size specifier F, which can be used to convert the lvar value (double) to a 32-bit floating point number before being stored in the offset (4-bytes). FSUIPC7.exeFSUIPC7.zip

What exactly isn't working? The script log shows that the lua is running ok. Maybe you can try listing the lvar values and checking the value of the lvar L:A32NX_PARK_BRAKE_LEVER_POS Does it change value when you apply/release the parking brake?

I'm not sure. Are your scripts running and not working, or are the scripts not running? How are you starting them - from your ipcReady.lua? Your log shows one of the luas being killed (twice!): 251266 LUA: "announcement.lua": killed 1139453 LUA: "announcement.lua": killed Fist, check the scripts are running. Try activating debug logging for lua scripts, which would tell you if they are running or not. If they are not running, try adding them to the [Auto] section of your FSIOC7.ini (see Advanced User Guide for details) and remove them from your ipcReady.lua, if they are started from there. If they are running but not working as before, then please show me your 3 lua files (ipcReady.lua, announcement.lua, anouncement2.lua).

Yes and yes (21H1). Here are the exe details: size: 625 KB (640,000 bytes) size on disk: 628 KB (643,072 bytes) created: 17 ‎August ‎2021, ‏‎19:27:50 modified: ‎17 ‎August ‎2021, ‏‎19:26:31 Check the file properties are the same. I occasionally get support requests saying that the installer contains a trojan or virus (again, false positives, and usually due to the installer using NSIS) but this is the first time someone has complained about the standalone exe. zip attached. FSUIPC7.zip

I can download that and run it without windows defender causing any issues. If I rebuild, its exactly the same. I don't know why you are getting a false positive. If you don't want to try it, thats up to you, but there is nothing more i can do. John

No, just ignore.

Its not an issue as as you don't have any assignments in FSUIPC. All text display facilities are broken since SU5, so that will be your issue.

Did you not read my last comment: ? Corrected in the attached version - please try this: FSUIPC7.exe

No idea. Please show me your FSUIPC7.log and FSUIPC7.ini files. If using a new PC, did you check and update your device GUIDs in your FSUIPC7.ini? You need to change these if moving to a new PC, as the GUIDs (and also joy ids) can change. Also, what do you mean by 'announcements'? Note that all standard FSUIPC text display facilities are broken in MSFS since the latest update, as the SimConnect_Text API function is no longer working at all (it was partially working in previous releases).

Found an issue when adding lvars to offsets when the lvar id > 1023. I've corrected this and will post an update shortly. There also seems to be an issue when using the SD size specifier for lvar offsets. The lvar has the correct value but the monitoring if the lvar doesn't show the correct value or value change. I am looking into it. John

There doesn't seem to be any logging available. Can you try just leaving it running to see if it eventually loads - with just the FSUIPC7 WASM in your Community folder, nothing else.

Just taken a look and I can now see those lvars. For ASCRJ_VAR_AP_SELHDG, you need to treat it as an 8-byte double, so use and monitor as a FLT64.

I was starting on a runway with engine running, and I still couldn't see those lvars. Did you try issuing a Reload command to rescan for lvars (from add-ons->WASM menu)? The scanning of lvars is done shortly after the aircraft is loaded, but the full set of lvars may not yey be available, especially in more complex aircraft. There is a WASM parameter that you can adjust (via the FSUIPC_WASM.ini) called LvarScanDelay, which adds a delay before the scanning of the lvars is performed. I suggest that you increase this. You can also manually issue a Reload to check if more lvars are available. FSUIPC only scans in aircraft load. As I said, issue a Reload to see if you get more. Could you please show me your full log file, together with your .ini. Also, please also list the lvars again if/when the monitor log shows 0. I'll take another look at the CRJ700 later to see if I can get that lvar...

The SimConnect_Text API function is broken completely in the latest SDK update, which is what FSUIPC relies on for the message display facilities. Currently the only way to display messages is using the lua wnd library.

@Maniek45Please do not hijack an unrelated topic. There are similar topics to your issue - either post in one of those or create a new topic. Note, however, that the menu items are grayed out until the initial list of lvars is received from the WASM module, which occurs when you have loaded an aircraft and are ready-to-fly. The installation log looks fine, so I have no idea why the WASM module isn't loading and is preventing MSFS from starting correctly. Maybe there is some sort of logging in MSFS (possibly in the dev mode). I'll take a look and get back to you.

Please re-install again, this time with the WASM selected for install, and try again. If it doesn't work, show me your new install log, and manually move the WASM folder out of your Community folder of it doesn't work (rather than uninstall/reinstall). Also, show me your FSUIPC_WASM.log file, if there is one - it will be under your AppData\Roaming\Microsoft Flight Simulator\Packages\fsuipc-lvar-module folder. I am not sure why it is running with the WASM installed, very strange. This was reported before, but a re-installation solved the issue last time. John

So its not getting as far as loading FSUIPC7 no? If its stuck in the loading screen, its usually due to something in your MSFS Community folder. Did you install the FSUIPC7 WASM module? Maybe try without that - no need to reinstall, just move the fsuipc-lvar-module folder outside of the Community folder. Do you have anything else in there? If moving the WASM module out of the Community folder solves your issue, please show me your InstallFSUIPC7.log file.