Djeez

I think is this fine, as the additional aircraft and scenery in the Community folder are loaded correctly. And this is in agreement with the InstalledPackagesPath and the location when I use the Developer Tools to open the Community folder. Anyway, I'll try reinstalling MSFS and hopefully get my Community folder at a more convenient location. Thanks for all your help thus far, and maybe I'll have to come back to you... Best regards, -Emile.

Yes, you are right about the Community location. That's what I tried when installing MSFS2024 but for some reason a lot of things went wrong and I had to try a few times until I got it installed. At that time the Community folder was at its default location and I left it there because at least I could fly. In my attempts to change the installation folder, I also changed the installation folder setting in the XBox app to C:\MSFS2024, which turned out to be a mistake. This is probably why the fcr-embedded location is so weird. See the screenshot. Maybe it is a good idea to do a full reinstallation of MSFS2024 to get everything setup according to standards. Do you have suggestions how to completely remove MSFS2024? From my initial attempts where I did a few uninstalls and installs it looked like some settings carried over and I could never enter the intended C:\MSFS2024 as installation folder. Anyway, I include the UserCfg.opt files of both MSFS2020 and MSFS2024 and a screenshot of the Community folder contents. If I use the developer tool to open the VFS Community location it opens the right one. UserCfg_MSFS2024.opt UserCfg_MSFS2020.opt

Yes, it is MSFS2024 Windows Store edition, and yes, the folder you describe is present. I will add a screenshot of its contents. I gathered the information you asked for and some more files and screenshots that hopefully can give you some clue. The mystery of the July version of the WASM log is somewhat cleared up because I saw another FSUIPC folder at another location where FSUIPC was previously installed. Those files were dated July 2025 so maybe at that time that version has worked correctly. -Emile. InstallFSUIPC7.log UninstallFSUIPC7.log EXE.xml

In the WASM Debug dialog I can only select fcr-embedded in the Modules dropdown, so I can not select fsuipc-lvar-module to have a look at the Module Section. I changed the FSUIPC_WASM.ini file to set the LogLevel to Debug but that did not change the log file: it is still from July! -Emile. FSUIPC7_with_WAPI_Debug.log FSUIPC_WASM.log

Hi, I tried several starts and FSUIPC restarts, all with the same effect (I am not sure from what session the log file was that I sent you). Here are more log files, copied at different phases during MSFS2024 startup. There is also one with additional logging enabled, from starting MSFS2024 until ready to fly on the runway. -Emile. FSUIPC7_at_first_screen.log FSUIPC7_after_pressing_start.log FSUIPC7_after_loading.log FSUIPC7_after_fly_now.log FSUIPC7_with_additional_debug_info.log

When starting FSUIPC and watching the log, I see that it gets stuck at the "starting everything now" message. When viewing the LVars from the FSUIPC UI, I get 0 LVars and 0 HVars loaded. I checked that the fsuipc-lvar-module folder is present in the community folder. I also tried with different aircraft and removed the fsuipc.ini file to have it recreated from scratch. Nothing helps. Can you help me debug this issue? Attached is one of the typical log files. Thanks! Emile van Gerwen. FSUIPC7.log

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.