LVars stop updating

[airforce2]

I'm running FSUIPC 7.4.15 and the TFDi MD-11F in MSFS.

I've had a number of similar failures where Lvars apparently stop being updated.  I use Lua scripts for a number of controls, and those that read Lvars stop working...sometimes they fail at session start, sometimes after a while, sometimes they work OK for an entire flight.  I can still send controls that work, but any script that bases an action on an Lvar value stops working.  To troubleshoot I copied the Lvar value to an offset to monitor it, and when this problem occurs, the Lvars are all reading zero (0.0000).

After the last occurrence, I shut down FSUIPC immediately and grabbed the logs.  I've attached the FSUIPC.log, and .ini, and the FSUIPC_WASM.ini (persistent) and log as well.  I don't see anything telling in there.  I also attached one of the lua scripts that works at first and then doesn't after this happens.

I also tried with the WASM module you had posted in the other thread that uses tagged vars--had the same thing happen.

Regards

Bob Scott

temp.zip

[John Dowson]

Sounds like you are also experiencing a WASM crash.

8 hours ago, airforce2 said:

I also tried with the WASM module you had posted in the other thread that uses tagged vars--had the same thing happen.

Yes, that is the thread where this was originally reported.

Was the FSUIPC_WASM.log file you attached uploaded after MSFS was shut-down? If so, it was definitely a WASM crash. If not, the next time this occurs can you exit MSFS and take a look at the end of the FSUIPC_WASM.log file. If the log file ends with the WASM closing down like this:

Quote

<=============================== END OF PROGRAM ===============================>

then there was no crash, but if it didn't log that message then it looks like the WASM crashed. You can also open the MSFS logging console (only available once devmode is activated) and search for 'messages with 'fsuipc' in them - if the FSUIPC WASM crashed there should be a message to this effect.

I have been investigating this issue for over a week now and cannot reproduce this here. I will keep investigating this and get back to you.

[John Dowson]

Could you please try with the attached WASM module and let me know how it goes. Thanks,

John

layout.json

FSUIPC7_WASM.wasm

[airforce2]

7 hours ago, John Dowson said:

Sounds like you are also experiencing a WASM crash.

Was the FSUIPC_WASM.log file you attached uploaded after MSFS was shut-down? If so, it was definitely a WASM crash. If not, the next time this occurs can you exit MSFS and take a look at the end of the FSUIPC_WASM.log file. If the log file ends with the WASM closing down like this:

Yes, in fact I couldn't open the log file until after I closed MSFS.  Oddly, though, controls sent via FSUIPC still work after the problem appears--don't they also use the WASM interface?

Am I good to use the existing manifest file with the new WASM module?

[John Dowson]

49 minutes ago, airforce2 said:

Oddly, though, controls sent via FSUIPC still work after the problem appears--don't they also use the WASM interface?

The WASM is used only for lvar/hvar controls and presets/calculator code. Standard controls are not affected.

49 minutes ago, airforce2 said:

Yes, in fact I couldn't open the log file until after I closed MSFS. 

That is strange - I always have this open in an editor when running MSFS, and update when I need to, without issue.

49 minutes ago, airforce2 said:

Am I good to use the existing manifest file with the new WASM module?

Yes, shouldn't be an issue - its the layout.json that matters. The manifest just contains text information associated with the build, although you can also use the attached, which just updates the version number and build date.

John

manifest.json

[John Dowson]

Are you using GSX by any chance? Or any other add-ons running with FSUIPC, apart from the aircraft (if thats an add-on)?

[airforce2]

1 hour ago, John Dowson said:

Are you using GSX by any chance? Or any other add-ons running with FSUIPC, apart from the aircraft (if thats an add-on)?

Yes--Pilot2ATC via WideFS, ActiveSky FS, Navigraph Simlink, PSXT (static traffic only), and GSX.

I just flew the TFDi MD-11F from KIND to KMKE...had FSUIPC stop responding on me during the landing rollout.  It appeared to happen right after activating a switch to turn off the autobrakes, which runs a Lua script that writes to an Lvar in the MD11 panel.  FSUIPC stopped responding--could not bring up the menu from the taskbar, P2ATC no longer showed updates to position, speed etc, and all the Lua scripts stopped working.  I had to terminate FSUIPC7 via the task manager.

The logs are attached--FSUIPC7.log in particular has a lot of warnings about a WASM-WAPI version mismatch.  The WASM log shows that it terminated normally when the sim was shut down.

Regards

Bob

edit: this was run with the test WASM module you posted up-thread

crash2.zip

[John Dowson]

40 minutes ago, airforce2 said:

The logs are attached--FSUIPC7.log in particular has a lot of warnings about a WASM-WAPI version mismatch.  The WASM log shows that it terminated normally when the sim was shut down.

The WASM version mismatch message is nothing to worry about. As the WASM didn't crash, this is a completely different issue than previously reported.
I will take a look at your files and see what they reveal, but over the weekend now.

John

[airforce2]

OK, thanks John.  I think I might have figured out what triggered this last lockup...the Thrustmaster TCA quadrant speed brake knob is a rotary switch where all but one of the positions of the knob are mapped to a separate switch on the joystick.  When turning the knob a couple clicks, it was triggering the same Lua script rapidly with each press and release sent as the knob passed through the different switch positions.  The script had a sleep delay in it, too, so I think it was trying to run 4-6 rapidly-triggered instances of the script concurrently.

I swapped it for an autorun script that polls the autobrake switch array a couple times a second and sets the AB only if the knob position changes...have made two flights now without it falling over.  No WASM issues so far since installing the modded module.

Regards

Bob

[John Dowson]

10 hours ago, airforce2 said:

OK, thanks John.  I think I might have figured out what triggered this last lockup...the Thrustmaster TCA quadrant speed brake knob is a rotary switch where all but one of the positions of the knob are mapped to a separate switch on the joystick.  When turning the knob a couple clicks, it was triggering the same Lua script rapidly with each press and release sent as the knob passed through the different switch positions.  The script had a sleep delay in it, too, so I think it was trying to run 4-6 rapidly-triggered instances of the script concurrently.

Ah, ok. There is an ini parameter that you can set to increase the delay between re-running luas:

Quote

LuaRerunDelay=66: This parameter sets the time, in milliseconds, which is imposed between re-runs of the same Lua plug-in. It is a safety precaution against repetitive execution causing an FS crash by stack overflow. For plug-ins which take more than that amount of time to load and execute this effectively restricts the repeat rate from dials to 15 times per second. The rate from buttons or keypresses being held down was already restricted as for those the repeat is not effective until the current plug-in execution finishes.

But it is generally better to re-write such luas touse events...

10 hours ago, airforce2 said:

I swapped it for an autorun script that polls the autobrake switch array a couple times a second and sets the AB only if the knob position changes...have made two flights now without it falling over.  No WASM issues so far since installing the modded module.

Ok, but rather than polling, you could assign your rotaries to LuaValue, with a different parameter for each position, and in your auto-ran lua wait for the position change using an event.param call and handling function.

Regards,

John

[John Dowson]

4 hours ago, John Dowson said:

Ok, but rather than polling, you could assign your rotaries to LuaValue, with a different parameter for each position, and in your auto-ran lua wait for the position change using an event.param call and handling function.

You can also, of course, just do everything in lua, using the event.button function.  Attached is a script that does this for the PMDG 737/777 autobrake, as an example.

John

PMDGAutoBrake.lua

[John Dowson]

@airforce2 I don't know if you have been following the other thread on the WASM crash, but the OP there has reported that this occurs only when using complex aircraft AND complex scenery,  and ismore likely to happen after an aircraft change. The crash seems to be an MSFS issue that I will report. If you find that the WASM is crashing (and presets stop working) then you can try tuning the WASM via ini parameters to prevent this. You need to disable continual lvar scans by setting
      LvarScanFrequency=0
and if setting this it is also a good idea to tune the delay of the initial scan, by increasing the value of the LvarScanDelay ini parameter (the default is 5 seconds). Suggest, for complex aircraft, you use:
     LvarScanDelay=10

Please see the Advanced User guide on setting WASM ini parameters. You should set these in the FSUIPC_WASM.ini file in your WASM persistence area, not the one in your Community folder. If this doesn't yet exist, copy the one from your Community folder to the WASM persistence are location (details in the Advanced User guide) and then edit/modify.

John

[airforce2]

On 7/20/2024 at 2:25 AM, John Dowson said:

Ah, ok. There is an ini parameter that you can set to increase the delay between re-running luas:

But it is generally better to re-write such luas touse events...

Ok, but rather than polling, you could assign your rotaries to LuaValue, with a different parameter for each position, and in your auto-ran lua wait for the position change using an event.param call and handling function.

Regards,

John

John;

  Thanks for all the helpful hints.  Where can I find the documentation for the LuaValue control?  I have searched the manual, advanced user's guide, Lua library, and Lua plugins guides to no avail--there are a couple references to using it in the events section of the Lua library docs, but it's not at all clear to me how.

  So far I've managed four medium-length (1-2 hr) flights in the TFDi MD-11 since installing the test WASM module and re-writing my scripts to avoid rapid-fire spawning of duplicate scripts.

Cheers

Bob

[John Dowson]

1 minute ago, airforce2 said:

Where can I find the documentation for the LuaValue control?  I have searched the manual, advanced user's guide, Lua library, and Lua plugins guides to no avail

There is not much documentation on that control as its very straightforward - it just updates the ipcParam lua variable in the script referenced, which will trigger an event,param function, and it can also be passed to a script as a parameter when it is started (to set the initial value of ipcParam). The documentation is in the Lua Plugins document:

Quote

On top of these facilities, when a Lua plug-in is run because of an FS control (Lua <name> or Lua Debug <name>), any parameter passed with that control is available to the Lua program as a variable called ipcPARAM. This might be particularly useful if the control is assigned to an Axis or POV, where the axis or POV value is thereby passed to the program. The added FSUIPC control "LuaValue ..." also passes values via ipcPARAM, and changes to it can trigger Lua plug-in code via a special event.

Note that the ipcPARAM value is set internally to the Lua plug-in before each function entry from an event, and also after every use of the ipc.sleep function. It is not a variable which can be used internally to the plug-in to retain its own value unless both events and sleeps are completely avoided.

John

[C.Schaffhausen]

I think I just had the same problem here, the Fenix stopped responding to my preset assignment, it usually worked when I restart it but this time it does not work at all. I'm suspecting this related to a WASM crash as well. I tried to List LVAR but the option was greyed out when I'm using the Fenix. No problems with PMDG for me yet.

[John Dowson]

1 minute ago, C.Schaffhausen said:

I'm suspecting this related to a WASM crash as well.

There are two ways to determine if its a WASM crash:
1. Look in the MSFS debug console window (only available when devmode is activated) and see if there is a crash message/exception (search for fsuipc).
2. Exit MSFS and look at your FSUIPC_WASM.log file. The last message should indicate the WASM has closed - if thats not there, then the WASM crashed before MSFS exited.

4 minutes ago, C.Schaffhausen said:

I tried to List LVAR but the option was greyed out when I'm using the Fenix.

You can list lvars even after a WASM crash as they are held internally by FSUIPC. If the option is grayed-out, this implies the WASM / WAPI is either not enabled or the initial lvar list has not  been received (from the WASM) by FSUIPC. This could be due to a WASM crash, if this was on a change of aircraft, but could also be due to other things. If the WASM didn't crash, I will need to see your FSUIPC7.log file (with WAPI Debug level logging enabled: Log -> WAPI -> Debug) to see what is happening.

John

[C.Schaffhausen]

33 minutes ago, John Dowson said:

There are two ways to determine if its a WASM crash:
1. Look in the MSFS debug console window (only available when devmode is activated) and see if there is a crash message/exception (search for fsuipc).
2. Exit MSFS and look at your FSUIPC_WASM.log file. The last message should indicate the WASM has closed - if thats not there, then the WASM crashed before MSFS exited.

You can list lvars even after a WASM crash as they are held internally by FSUIPC. If the option is grayed-out, this implies the WASM / WAPI is either not enabled or the initial lvar list has not  been received (from the WASM) by FSUIPC. This could be due to a WASM crash, if this was on a change of aircraft, but could also be due to other things. If the WASM didn't crash, I will need to see your FSUIPC7.log file (with WAPI Debug level logging enabled: Log -> WAPI -> Debug) to see what is happening.

John

Thanks John, I'll test a bit after my flight

[C.Schaffhausen]

Hello John,

It seems to work now after following steps from this post. Not sure why it suddenly stopped working before though. I'll attach my FSUIPC.ini here regardless.

 

FSUIPC7.ini