FSUIPC7 7.4.16 hangs restarting LUA script

[Leftos]

I have a pretty simple LUA script I've been using to monitor the PMDG 737 seatbelt switch position and also set it in the MSFS seatbelt offset, so that external apps can detect it, but for some reason, without the script having changed at all, it stopped working as far as reading the Lvar is concerned, and when I use the key binding I've added to restart it, FSUIPC7 hangs completely, and has to be killed through Task Manager.

 

function setSeatbeltSign(varName,varValue)
    print(varName,varValue)
    if varValue ~= 0 then
        ipc.writeUB(0x341D,1)
    else
        ipc.writeUB(0x341D,0)
    end
end
    
event.offset(0x64FB,"UB","setSeatbeltSign")
event.Lvar("switch_104_73X",250,"setSeatbeltSign")

 

(I added the print just for debugging purposes after it started hanging)

Originally I was only listening to the 0x64FB offset, which is the published offset for the seatbelt sign on the PMDG 737, but then I noticed that when using PilotsDeck / Stream Deck, the PMDG 737 profile I was using for it was reading from and writing into the Lvar, so I added that one too. I had a few flights where it all worked great, and whether I was switching the seatbelt sign using the mouse, or using my Stream Deck, I could see the change reflected in the external app that was watching for the 0x341D offset. Today, I couldn't get the Lvar to work (only flipping the switch with the mouse would be reflected in the 0x341D offset, while writing into the Lvar using the Stream Deck would be reflected visually in the plane's cockpit, but 0x341D would remain unchanged), and whenever I try to restart the Lua script using my keybinding (lshift+c), FSUIPC7 hangs entirely. I can't open its UI, Windows says it's "not responding", Mobiflight reports having lots its connection with it, and same with Passenger2.

Let me know whatever information I can provide, and whatever steps you'd like me to try so as to debug this. I've attached my .ini.

Appreciate your help.

FSUIPC7.ini

Edited August 1 by Leftos
attach ini

[John Dowson]

Sorry but I didn't have time to look into this today. I am now on holiday, back in Tuesday 6th (in 4-5 days), and will take a look then.

Sorry for any inconvenience,

John

[Leftos]

No worries, enjoy your vacation!

[John Dowson]

I have taken a look at this and it works just fine here. However, please note that when the lvar value changes, PMDG offset 0x64FB is also updated and vica-versa. So you don't need an event on both the offset and the lvar - an event on the offset should be sufficient.

I do not know why it has stopped working for you, or why FSUIPC hangs when you restart the script - I can restart just fine here. So something else must be going on.
Can you please show me your FSUIPC7.log file from when you have to kill FSUIPC7.

If/when you restart FSUIPC7 after killing it, does it run ok and are all lvars loaded?

[Leftos]

See attached.FSUIPC7.log

[Leftos]

I will say that it hasn't consistently stopped working. Most of the time it works, but then sometimes it doesn't for a whole MSFS session.

[John Dowson]

Your log file indicates that there is a problem with the WASM - FSUIPC establishes a connection to the WASM but no lvars are received. This could indicate a possible crash in the WASM. To verify this, you need to exit MSFS and check the FSUIPC_WASM.log file - if the last line does not show that the WASM exited properly with the following message logged:

Quote

Mon Aug 19 09:46:17 2024  [ALWAYS]: <=============================== END OF PROGRAM ===============================>

then the WASM module has crashed. It has been reported that this occurs only when using complex aircraft AND complex scenery,  and is more 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 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.

If the WASM isn't crashing, then something else is preventing lvar reception. Please enable WAPI Debug level logging (Log->WAPI->Debug) as well as WASM Debug level logging (via the FSUIPC_WASM.ini file) and the next time this occurs please exit MSFS and show me/attach both the FSUIPC7.log and FSUIPC_WASM.log files.

John

[Leftos]

I exited MSFS, and seeing as the date modified of fsuipc_wasm.log is 5 hours ago, I wouldn't be surprised if this pointed to a WASM module crash. I did fly through complex third-party airports with the PMDG B738, so I could see that combo having been fatal for WASM. Interestingly, the last line in the wasm log was:

Wed Aug 28 17:00:12 2024   [DEBUG]: Scanning for new lvars: lvarScanFrequency=-5, last lvarScanTime=1724864407567, timeNow=1724864412622 (difference=5055)

which would indicate an issue with lvar scanning, as you said.

In the wasm prev log, I see it ending with END OF PROGRAM, which reflects the fact that I had no issues with my LUA script or FSUIPC during yesterday's play session.

This is all very useful, thanks John. I'll try the parameters you suggested in the ini in the persistence location and see if that helps.

I can't attach the logs because they're bigger than 3.59kb even zipped, but I can put them in something like pastebin if it helps. Let me know.

[John Dowson]

8 hours ago, Leftos said:

I can't attach the logs because they're bigger than 3.59kb even zipped, but I can put them in something like pastebin if it helps. Let me know.

No need to see the log file as you have determined that the WASM crashed - just try with the updated parameters.

[Leftos]

Just wanted to come back and report everything has been working flawlessly since the adjustments you recommended.