MSFS show correct names ("B738_Beacon_Light_Dn", "B738_Logo_Left") but WASM don't: some names are truncated and end with one or two non printable characters ("rectangles").
This now occur with old FSUIPC version (restored from a backup) and with various ProSim versions (beta 3.32bxx and 3.31 release). What could be the reason? Attached file contains FSUIPC7.log and FSUIPC.ini 🙂 Not sure at the moment. Could you set Debug level logging in the WAPI (Log->WAPI->Debug) and show me/attach another log file. As it seems to happen straight away, you could even set Trace level logging in the WAPI. Can you also set Debug level logging in the WASM (via the FSUIPC_WASM.ini - see Advanced User manual for details on where this is) and also include/attach your FSUIPC_WASM.log file. Your log files are very interesting...
They show the lvar names correctly in the initial scan, when 134 lvars are detected, but (97 seconds) later 137 lvars are detected and two of the lvar names have been corrupted.
This corruption looks to be in the WASM, so I am surprised when you say that ' MSFS Disconnect / MSFS Reconnect from FSUIPC menu often solves the issue'. However, to confirm this, I would need to see an FSUIPC_WASM.log with Trace logging activated. It is strange that the following 3 lvars are created such a long time after aircraft load: 77391  [TRACE]: LVAR Data: name=' FSDT_VAR_Frozen '
77391  [TRACE]: LVAR Data: name=' B738_EmergencyDoors '
77391  [TRACE]: LVAR Data: name=' Prosim738_Steering '
It looks like you are getting a similar issue, but rather than a WASM crash you are getting a memory corruption somewhere.
To prevent this, try tuning your WASM ini parameters. You currently have these set: Wed Oct 30 08:17:25 2024  [ALWAYS]: lvarScanDelay = 5
Wed Oct 30 08:17:25 2024  [ALWAYS]: lvarScanFrequency = -5
Wed Oct 30 08:17:25 2024  [ALWAYS]: lvarScanPeriod = 120 If you still get issues, and if not using those 3 additional lvars (mentioned above) directly (you can still use them via presets/calculator code), you could disable continual lvar scanning by setting:
LvarScanFrequency=0 There seems to be something un MSFS that is corrupting the lvar name space, which I reported to MSFS a while ago but have yet to receive a response. I have ran the FSUIPC WASM in a debugger for days at a time and have not seen any corruption in the WASM itself, so this seems to be an MSFS issue... Hello John,
This need to be confirmed... I think you gave me the right clue to solve our issue.
In FSUIPC_WASM.ini, I've changed the values of LvarScanFrequency and LvarScanDelay :

;LvarScanFrequency=-5
LvarScanFrequency=0

;LvarScanDelay=5
LvarScanDelay=35

Perhaps editing solely LvarScanDelay could be enough? Later, I'll try to restore LvarScanFrequency value... Here are the new log files I gathered this morning : Subfolder "FAILS" with trace, you'll notice those LVar's names (line 252874 in FSUIPC_WASM.log)

Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: B738_Landing_L=0.000000
Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: t 31 09:15:00 2024=0.000000

Subfolder "FAILS" with trace, you'll notice those LVar's names (line 252874 in FSUIPC_WASM.log)

Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: B738_Landing_L=0.000000
Thu Oct 31 09:15:00 2024   [TRACE]: updateLvars: lvar updated: t 31 09:15:00 2024=0.000000

Hello John 🙂
The issue seems to have vanished since I've added an entry in ipcReady.lua 🤔
I added "ProSim-Lvars.lua" to instantiate some LVars useful to the new vmsACARS version.
Previously I had a "sort" of empty ipcReady.lua (old LUA got commented as new ProSim versions did not need them anymore):

-- ipc.macro("Lua:ProSim-60knots")
-- ipc.macro("Lua:ProSim-positive-rate")
-- ipc.macro("Lua:ProSim-Lights")
-- ipc.log("Ready: GearUpGearDown")
-- ipc.macro("Lua:GearUpGearDown")
-- ipc.runlua("ProSim-Rain")

Could having an "empty" ipcReady have caused the issue I observed??? Or could creating LVars (my new LUA) have add some nice effect??
Kind regards,
Didier ProSim-Lvars.lua 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.