This are the (new) Support Forums for FSUIPC and related products.
These forums replace the old support forums which have been running for 20+ years. The old forums contain a wealth of information on all FSUIPC products, and are still available (until the end of the year) for read-only here.
At the moment these new forums are quite empty – I will be updating the FAQ section and copying across the User Contributions from the old forums in the next few months.
Please note that you will need to Register and Login to post for support, and also to download attachments. You can view these forums without registering.
Support is also available via Discord. Please use the following invite link to join the FSUIPC Discord server:
https://discord.gg/zjwUTrxmmE
[Solved] Creating and writing to Lvars FS2024 SU4
Hi,
I am in the process to migrate my PMDG 737 instruments from FS2020 to FS2024. For that I use the “Offset Mapping for PMDG 737” provided with FSUIPC7 documentation. I need to react on value changes in some of those offsets and write to an Lvar that I create in the FSUIPC lua script. That has worked without a hitch in FS2020 and the PMDG 737-700.
I use FSUIPC7 version 7.5.5 (9th November 2025) with MSFS 2024 System update 4. I use Lorby Axis and Ohs, and Sim Innovations Airmanager to read Lvars.
I see that FSUIPC7 has correct values in those PMDG 737 offsets. But if I create Lvars per ipc.createLvar() call, I can in some cases see that the Lvar is being created, in others not. And if I write to my Lvar using ipc.writeLvar() calls the Lvar does not change. It stays value 0, which is the initial value.
I wonder, if somebody is creating Lvars successfully and writing to them with FSUIPC7 and FS2024 since SU4. And reading the Lvar outside FSUIPC.
I am just starting with FS2024, so I don’t know if this behavior would be the same in earlier FS2024 versions.
Any advice is appreciated.
Thank you,
Detlef
Posted by: @det737But if I create Lvars per ipc.createLvar() call, I can in some cases see that the Lvar is being created, in others not. And if I write to my Lvar using ipc.writeLvar() calls the Lvar does not change. It stays value 0, which is the initial value.
This could indicate that the WASM module has crashed. Creating lvars using the ipc.createLvar function will also perform a reload in the WASM (so that the lvar becomes available to FSUIPC7), and it is the reload that can cause the WASM to crash.
Posted by: @det737I wonder, if somebody is creating Lvars successfully and writing to them with FSUIPC7 and FS2024 since SU4. And reading the Lvar outside FSUIPC.
There should be no issues here – as I said, the problem is most likely that the WASM has crashed. There is a FAQ entry on this issue.
To prevent the WASM crashing when creating lvars, especially when creating multiple (more than one) lvars, then rather than using ipc.createLvar, use ipc.execCalcCode to create an initialise all the lvars that you want to use. You can also do this in an ipcInit.lua or an ipcReady.lua script (the init script probably better) with a single line, e.g.:
ipc.execCalcCode(“0 (>L:myFirstLvar) 0 (>L:mySecondLvar) 0 (L:anothLvar)”)
If you do that in an ipcInit.lua, they will be create when FSUIPC7 starts and will be passed to FSUIPC7 with the other aircraft lvars after it has been loaded.
Also, if using the MDG 737 in MSFS2024, you should update to the latest beta (7.5.6b) available in the News section, which has some improvements for PMDG aircraft in MSFS2024.
John
Hello John,
thank you for your support. I got it working now using ipc.execCalcCode() calls as you suggested.
Posted by: @fsuipcTo prevent the WASM crashing when creating lvars, especially when creating multiple (more than one) lvars, then rather than using ipc.createLvar, use ipc.execCalcCode to create an initialise all the lvars that you want to use. You can also do this in an ipcInit.lua or an ipcReady.lua script (the init script probably better) with a single line, e.g.:
ipc.execCalcCode(“0 (>L:myFirstLvar) 0 (>L:mySecondLvar) 0 (L:anothLvar)”)
If you do that in an ipcInit.lua, they will be create when FSUIPC7 starts and will be passed to FSUIPC7 with the other aircraft lvars after it has been loaded.Also, if using the MDG 737 in MSFS2024, you should update to the latest beta (7.5.6b) available in the News section, which has some improvements for PMDG aircraft in MSFS2024.
ipcInit.lua did not work. I think because WASM is not yet running by the time ipcInit.lua starts. ipcReady.lua did work, but I use my own .lua now which is also ok as long as I do an ipc.reloadWASM() in it.
Detlef
Hello again John,
I still have some difficulties to get my Lvars working reliably. So I put my Lua code in ipcReady.lua as you suggested some days ago. After starting FS2024 and a Free Flight with the PMDG 737-800, the Lvars e.g. IPCPMDG_AIR_DisplayFltAlt have not been created. I could not list them with FSUIPC7 menu command List Lvars.
Then I changed the aircraft to a Cessna, and restarted everything. And then with the FS2024 session open I changed to the PMDG 737-800 and started a Free Flight. Now all my Lvars (20 in total I think) have been created and do work. In the ipcReady.lua file I create the Lvars and start event watching for some PMDG offsets.
What can I do to reliably create the Lvars and have the event watching for the PMDG offsets working?
Sorry if the Lua code is somewhat complex. I can shrink it down to something simpler if needed. See attachments. The Lvars are created in multiple ipc.execCalcCode() calls, not just one.
An additional question: In the log file there is a line:
118484 PMDG 737 Simconnect connection closed.
I guess, the Simconnect connection must remain open?
Thank you,
Detlef
(see log file)
Posted by: @det737So I put my Lua code in ipcReady.lua as you suggested some days ago. After starting FS2024 and a Free Flight with the PMDG 737-800, the Lvars e.g. IPCPMDG_AIR_DisplayFltAlt have not been created. I could not list them with FSUIPC7 menu command List Lvars.
Depending on how you create the lvars, you may also need to issue a WASM reload command to get them recognised.
Posted by: @det737Then I changed the aircraft to a Cessna, and restarted everything. And then with the FS2024 session open I changed to the PMDG 737-800 and started a Free Flight. Now all my Lvars (20 in total I think) have been created and do work. In the ipcReady.lua file I create the Lvars and start event watching for some PMDG offsets.
This would indicate that the lvars have been reloaded. Be aware that lvars are persistent between aircraft changes and reloads – once an lvar is created, then it is available until MSFS exits.
However, there are now ‘scoped lvars’ (MSFS2024 only) that are only scoped to the currently loaded aircraft…but forget these for the moment, they are a bit of a pain at the moment….
Posted by: @det737What can I do to reliably create the Lvars and have the event watching for the PMDG offsets working?
After you have created all the lvars using ipc.execCalcCode, make one call to ipc.reloadWASM(). That will then force a rescan and make all the newly created lvars available to FSUIPC.
Posted by: @det737An additional question: In the log file there is a line:
118484 PMDG 737 Simconnect connection closed.
I guess, the Simconnect connection must remain open?
No – here is the log:
34375 Aircraft="737-800 PAX BW HD"
34375 System time = 04/01/2026 17:51:51, Simulator time = 16:51:51 (16:51Z)
110921 PMDG 737 offsets enabled
118421 * PMDG737Thread finished **
118484 PMDG 737 Simconnect connection closed.
118500 Aircraft="C172SP G1000 Cargo"Initially the PMDG threads were enabled as the PMDG 737-800 was detected, but then you switched to the Cessna 172, and so the PMDG threads were stopped as these offsets are not used with this aircraft. This is perfectly normal.
John
Posted by: @det737ipcInit.lua did not work. I think because WASM is not yet running by the time ipcInit.lua starts.
Ah yes…it is running, but FSUIPC7 doesn’t connect to the WASM until an aircraft is loaded.
Posted by: @det737ipcReady.lua did work
Yes, better to use that…
Posted by: @det737but I use my own .lua now which is also ok as long as I do an ipc.reloadWASM() in it.
Thats ok too, but be aware it is the WASM reloads that can cause the WASM crash, so you don’t want to be doing that too often.
Thanks for the update.
John