Djeez

This was in MSFS2024. It all worked fine in MSFS2020. I just installed the new version and tried some of my home cockpit functions for the Cessna. -Emile.

I installed 7.5.0c over 7.4.18 with the MSFS2024 MS Store version and copied over the fsuipc-lvar-module folder from the 2020 Community to the 2024 community folder. Installation was without problem. My first tests in the C172 G1000 version do show some breaking changes, probably related to the sim than to FSUIPC: Virtual keys such as F19, F20, .. are not picked up by FSUIPC. They are detected when assigning them in the Assignments -> Key Presses dialog and can be configured, but they are not detected during flight The Avionics master switch control (ipc offset 0x3103) does not work The fuel selector (ipc.control 65955 and above) does not work The fuel pump (ipc offset 0x3104) does not work The last 3 items probably have to do with the new electronics / fuel system I remember being mentioned in one of the development blogs. Anyway it is good to know. (EDIT: I know see that there is a new installer available. I installed using the "original" 7.5.0c, without specific MS2024 selection)

Never mind. After restarting MSFS yet another time the issue resolved itself.

Suddenly (?) my Lua scripts cannot access Lvars anymore. Checking the Add-ons->WASM menu I see that WASM is enabled but all other entries (such as list Lvars) are grayed out. Disabling and re-enabling WASM has no effect. I updated to version 7.4.11 that also installed the WASM module dated March 31 in the Community folder, but to no avail. Any idea what could be wrong? Thanks! Emile.

It works great. I see Lvars discovered in the log window but my event handlers on subscribed Lvars are not called, so no flickering anymore. Thanks for the fix! -Emile.

Hi John. Thanks for the reply. I installed the version as you indicated (showing 7.3.18b in the About box). Unfortunately, the problem is still there. Just before the "Lvars received: ..." line appears in the log, I see that the Lvars I subscribed to get a callback with parameter 0 and soon thereafter a callback with parameter 1, effectively making the LED's flicker for a moment. It is not critical, just annoying (every time it happens I have this little fear that my custom hardware fails...) so I can wait for a final version that fixes this. If you would like me to test a beta release I am very happy to do so. -Emile.

In my Lua scripts I use event.Lvar() calls to subscribe to Lvar changes to activate/deactive a corresponding LED. It seems as if an automatic Lvar rescan triggers the events: For every Lvar that was 1, I see two events: the Lvar being 0 and immediately thereafter the Lvar being 1 again. As a consequence, I see all LED's that are ON in my cockpit flicker whenever the number of Lvars changes. From the log file I can see this coincides with the change in number of LVars. 10220203 Lvars received: 4494 L:vars & 0 H:vars now available This flickering did not happen before 7.3.17.

For your information: I use the AXIS_STEERING_SET event (67466) for the nose steering (tiller). It takes 1 parameter in the range [-16383..16383]. Emile.

I can confirm that. Thanks to both of you. -Emile.

Sorry about not being clear. The Rotor brake controls do work. My intention is to light up LEDs when the A/P, A/T, or FMC button light up and for that I need to either inspect the offsets, or the LVars. What I see (as Hermann posted) is that the value is always 0, regardless of the state in the virtual cockpit on screen. This is for both the offset as well as the LVar, for all three (A/P, A/T, FMC). -Emile.

Indeed, these offsets do not work as expected, and neither do the corresponding LVar's, such as L:switch_3391_73X. It seems something is wrong at the PMDG side when exposing these states. -Emile.

This works great and is a very nice feature to have. I assume the myOffsets.txt is read during the FSUIPC startup? For development it would be convenient to have a reload myOffsets menu item in the FSUIPC7 interface just as there is one for the WASM reload. -Emile.

What you could do is provide an offset in which I can write in how many batteries I am interested. Since I know which plane is loaded, I set the number of batteries accordingly and it would be my responsibility to set the correct number. The default being 0 so that the bitwise offset is not populated when not requested. This is quite a hack and I can understand you are not fond of such a solution but honestly I don't think we can expect a solution from the SDK team at Asobo in short term. -Emile.

Thanks John. Getting errors on non-existent batteries and no way of knowing the number of batteries seems like a bad interface design on MSFS part. I appreciate you looking into this. Did you report this to the SDK team and would it help if I (also) report this? -Emile.

These is an offset for the Master Battery (0x3102) but MSFS2020 supports multiple batteries, such as in the default C172 (standby battery) or SR22 (master battery 2). When inspecting the log when toggling the switches I see (0x000102c1), Param= 2 (0x00000002) TOGGLE_MASTER_BATTERY (note the parameter 2) I could use the ipc.control with parameter 2 in my Lua script but I also need to know the state of the switch. The MSFS2020 SDK documentation shows that the SimVar needs an index so presumably this means that read and write access to all batteries is possible. My request is to make these settings available as offsets, or one offset with multiple independent bits set for every battery. Thanks! -Emile van Gerwen.