John Dowson

Are you just using presets, or are you using lvars directly and their values? If not using lvar values (such as for reading, increment or decrement or on events), you could disable the update of lvar values (where this crash is occurring) which may prevent this crash. To do this, set the WASM ini parameter LvarUpdateFrequency to Off. You can also set the LvarScanFrequency WASM ini parameter to 0 to prevent further scans for lvars after the initial scan. Probably better to try this after the next FSUIPC7 release, as I think there is a minor issue when setting LvarUpdateFrequency to Off in the version you are using (this issue is now corrected). Or I can provide you with an update WASM if you want to try this now. John

Ok, that is interesting, and I am very surprised that this is a scenery issue (I don't have much add-on scenery, only a few airports). I will add this information when I report to Asobo, later today or tomorrow. I will release the updated WASM with a new version of FSUIPC7 in the next few days. Thanks for your extensive testing for this issue. Regards, John

There do not seem to be any MF presets available for these functions, and as I don't have this aircraft, I cannot really advise. You need to use logging to determine what is being used. Activate logging for Events and Input Events, open the logging console window (Log->Open Console) and activate the buttons in the VC and see if anything is logged. If so, try using that. If not, you will need to list the available lvars to see if any look applicable, and if so try those first to see if they work (using the Add-ons->WASM->Set Lvar menu item) and if so, use those. Otherwise, its the MobiFlight HubHop site that manages the community-driven effort to discover presets. Try posting for help on the MobiFlight MSFS2020 Discord channel.

Your ini file shows that you do not have a profile-specific calibration section for the 737, and so the default calibration section is used where you have flaps calibrated. Create a profile-specific calibration section for the PMDG 737 (i.e. with the aircraft loaded, got to the calibration tab of the axis assignment panel and check the profile-specific checkbox) and then remove the flaps calibration (i.e. go to the flaps calibration page and click Reset).

In the FSUIPC7 Offset Status document. There has been no change/update in PM functionality in FSUIPC7 from FSUIPC6 (and earlier versions).

License sent.

What do you mean by this? Doesn't toggling a bit activate/deactivate the defined mode change? I don't think this functionality is generally suitable for this offset - I would think most use would be to manually trigger these on and off/ and noy on a timer. You can always implement such timer functionality in a lua script if needed..

No problem - your wife is certainly more important! It was a simple updated and I have tested writing to all (writable) bits, so need really, but I always like to get the user who requested an update to test to make sure. I will hopefully release this tomorrow (with a few other minor updates)...unless the wife has other plans! Cheers, John

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

Did you manage to test this? I have tested here (of course) and it seems ok, so I will probably release a new version of FSUIPC6 this weekend. Thanks! John

You should be ok with all aircraft and scenery add-ons (although you can test with all these installed first to confirm) I would think, it is the other add-on types I would concentrate on, and add those back one at a time. It is interesting that MSFS console error of file-not-found is caused by Flow/SimFX - I wonder why this is, but I doubt very much that this is anything to worry about. Ok, that's good. Ok, sounds good - thanks. It would be very useful to know which add-on or combination of add-ons provoke this issue. I don't think its worth me continuing to try and reproduce this issue here at the moment. I am also going to post on the Asobo support forums about this issue. I will also release a new version of FSUIPC7 with the latest WASM updates in the next few days. Regards, John

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

In your installation folder, along with your FSUIPC7.log and FSUIPC7.ini files (other files I ask for when you get issues). Please read the documentation - this explains such things. Which was?

Why would you do this? Nothing to do with microsoft... This normally happens if you have the document already open that you are trying to replace. Anyway, you should be able to continue with the installation. - this error should not stop installation. Also, if you have any installation issues, always a good idea to show me / attach your InstallFSUIPC7.log file. John

Ok... What add-ons are you actually using (apart from scenery and aircraft)? Maybe best to just start with FSUIPC installed, test that, and then add each add-on back one by one until you get the crash, Then go back and change the order to confirm its one add-on (could be a combination of add-ons....). You can also try the Simstaller program, which I think I mentioned earlier, to see if there are any conflicts. I have not used this yet myself although its been on my list to try for quite a while...

Those logs are interesting, and show that the WASM is most probably crashing when calling an MSFS Gauge API function get_name_of_named_variable. Although it could be crashing when I am logging the name returned by this function, but that was a recent addition so I doubt it. I have added additional code in the attached WASM to correct for this, so please switch to this version. Not sure what, if anything, I can do if its crashing in that function, except report to Asobo. I don't this error is actually anything to do with FSUIPC but something else causing a memory issue in MSFS that is causing the WASM to crash.... Anyway, last update doe today. I will continue investigating over the weekend, when I have time. John layout.json FSUIPC7_WASM.wasm

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

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

Ok, but this doesn't really help as the log shows the WASM crashing after the same line is logged. This is not relevant to this issue. It is a heap or stack corruption, which is (or should be) only available to the WASM. Ah, GSX....this has caused issues before. If you can first try with the latest WASM and show me the log (after a crash) from that, hopefully that will be more useful. Once you have done that, maybe try without GSX for a while to see if it still crashes without that... John

The WASM is used only for lvar/hvar controls and presets/calculator code. Standard controls are not affected. That is strange - I always have this open in an editor when running MSFS, and update when I need to, without issue. 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

This is very confusing...are you also installing/replacing the layout.json file that I provide with each WASM update (in the folder one-up from the WASM itself)? The attached WASM has extra debugging, and will log each lvar found in the scan. The log file may get quite large, depending on how long t takes to crash... John layout.json FSUIPC7_WASM.wasm

Well, I can't even reproduce when NOT debugging! Yes, looks to be crashing on the same place. I will add extra logging in this area and provide you a new WASM shortly. This is very strange - I have not seen that error here. Could you let me know what add-ons you are using, and if using GSX maybe try without that, John

Ok, thanks. That is interesting and also very confusing, as it seems to be crashing in a block where there is no possibility of a memory issue, except if it is in the Gauge API function get_name_of_named_variable. Unless maybe there is a buffering issue with the log messages. Very strange... Ok, thanks, although I doubt the log files will reveal anything. Really I need to get this error here and trap it in a debugger, but after many hours of trying I still cannot reproduce....

Yes! My log file was > 64GB after an extended run. There is no way to open such large files - you need to split it into smaller files (when you get a crash) and send me the last 500mb or so. To split the files, see https://stackoverflow.com/questions/31786287/how-to-split-large-text-file-in-windows. It is definitely a memory issue, but I cannot find any memory issues, and I have ran MSFS.FSUIPC7 for over 24 hours with the WASM attached to a debugger, switching aircraft many times and sending many presets and lvar updates without issues. So this is very strange. It could be that another add-on is trashing an lvar name string that I am referencing, and when I try to reference this it causes the error. I have changed some code in the attached WASM version to correct for this if you could try it. I have removed the extra logging in this version, so the log files shouldn't be too large and it shouldn't effect the performance that much, so please switch to this version and let me know how you get on. Thanks for your assistance with this issue. John FSUIPC7_WASM.wasm layout.json

Could you please try with the attached WASM module and let me know how it goes. Thanks, John layout.json FSUIPC7_WASM.wasm