John Dowson

The FSUIPC WASM crash is a known and ongoing issue and has been reported many times, and also seems to be more common in MSFS2024. This is related to the scanning for the new lvars which must be disabled - see the following FAQ entry: I have previously looked into this in detail and there are no memory issues in the WASM itself and I am at a loss as to what is causing this. I have also reported to Asobo but have received no response. However, I haven't checked this for quite a while now, and will look into it again at some point (when time permits). If the current crash you are reporting is not related to the scanning for lvars, I will need to see your FSUIPC_WASM.log file, with Debug level logging enabled in the WASM. For all WASM crash reports you should attach this file. Note that, as a new forum member, your attachment limit will be very low. You should compress/zip the file, but if it is too large to attach you can deliver it via one of the free file transfer websites (e.g. https://filetransfer.io/) John

I'm not sure why its using 3 hex digits instead of 6, but try this: https://borderleft.com/toolbox/hex/ John

Ah, I see the documentation says 3 hexadecimal digits (not bytes). I will check this...

This has previously been reported see here: I have reported this to Asobo. https://devsupport.flightsimulator.com/t/cannot-receive-function-keys-f13-f22/13023 There isn't anything I can do about this I'm afraid - it needs to be fixed by Asobo. John

They should be standard hex colour codes.N.B. 3 byes are 6 hex digits.

Do you mean Hvars? And if so why is the title of this topic 'Lvars'? K-type variables are events, B-type Input Events, etc. You can use both H (HTML) and L (local) type vars in FSUIPC7, either directly or using presets / calculator code. The easiest way to use hvars is via calculator code really. There is no actual way to discover the available hvars for the loaded aircraft, as there is with lvars, so the way this works in FSUIPC7 is that you have to let FSUIPC7 know which hvars you want to use by providing a *.hvar file (some are included as an example). This is documented in the Advanced User guide, under the WASM section. Once a hvar is known to FSUIPC7, you can use it either in a macro or a lua script. But these days almost everybody uses hvars via presets (calculator code). You can define your own preset to trigger a hvar: in the myevents.txt file, e.g. Trigger_My_Hvar#(>H:hvarName) Then assigning to the preset 'Trigger My Hvar' would trigger/set the hvar ' H:hvarName'. See the documentation for further information. Also take a look at the available presets in the events.txt file as many of these will use hvars. You can find available presets by pressing the Find Preset button in the assignments windows once Select for Preset is selected/checked. John

@DaveSCUSA Also, to get an event notification on a restart, you can use the event.sim function - you will get a FLIGHTLOAD event notification followed by an AIRCRAFTCHANGE event notification on a restart, the same as when you initially start a flight.

You do this by using 'compound conditions'. See the Advanced User guide, page 22. John

Why don't you just keep the lua running until you go back to the main menu? Do you really need to stop/exit this and then restart? As I said, you can also use offset 0x026D to determine the camera state, with values: If the lua has terminated, it needs to be restarted. You can also just start/restart it on a button press (or from another lua) and if its currently running it will be killed. How is this lua started? Maybe you can also attach this lua script so I can take a look.

Maybe - could be due to the initial button state scan... Then I think this is because of the change I made to allow repeated LuaValue calls with the same parameter - but I'm not sure how this change could cause this error! I have disabled Button actions before everything is initialized in the attached version. John FSUIPC7.exe

This looks to be because you are pressing a button that starts a lua thread far too early - well before the aircraft is loaded and before FSUIPC is fully initialized. This looks to be confusing SimConnect and interfering with the initialization. You should really not be doing anything until AFTER you have pressed the Ready-to-Fly button. I also don't think this is related to any of the recent changes. FSUIPC should really ignore such early button presses. Not sure why it is actioning those button presses when they should be ignored. I will take a look to see if I can prevent this. But you should wait until the aircraft is fully loaded and after you have pressed the ready-to-fly button before doing anything, and really it is better to wait until all lvars have loaded, which will be several seconds after you the cockpit view is loaded. John

The camera state is not just the views, it is what is displayed in the MSFS main window, so can be Menu, World Map, Hanger, Waiting, etc As I said, 32 is undocumented (internal only) so just wondered why it hit that state when you were (probably) in a cockpit view (state 2). Its not important - just wondered if you had noticed anything in MSFS, apart from FSUIPC becoming unresponsive (as it was killing the luas).

Just wondered what you saw when the camera state when to 32. Anyway, I have removed this now in that last exe. There is another camera state of 36 that will also cause luas to be killed which might also need removing. As I said, I will do some testing later today - I haven't looked at this since the latest SU update and these things tend to change on each release... John

Check you are looking in the correct place - use the File->Open Installation Folder in FSUIPC. Also check that you have not set windows Explorer to 'Hide extensions of known file types'. If you don't know what this means, see the Addendum in the Installation and Registration guide (last page). John

The aircraft name logged was "Dirty 30 Short Configuration" which seems very strange... What actually happened in MSFS at this time? Your log indicates that FSUIPC killed the lua scripts as the camera state changed to 32 (which is an undocumented/internal camera state). In MSFS2020, the 'plane in parking state' variab1e is used to determine when a flight is ended and luas need to be killed (as well as performing other tasks needed when an flight is ended). But this is not reliable in MSFS2024, and so an additional check on the camera state was added specifically for MSFS2024, and when certain camera states are received, FSUIPC thinks the flight is ended and will stop the luas. The camera state values were determined by trial and error, and 32 was one of these (even though the exact meaning of this state is unknown). I will do some more tests on this, but I will remove 32 from the list that determine a flight has ended. I have done this in the attached version. John FSUIPC7.exe