John Dowson

It is also strange that some basic start-up parameters seem to be missing from your ini file. When you start MSFS, wait for FSUIPC7 start and then wait for MSFS to get to the main menu. Once this is done, the start-up ini parameters will be written to your ini file. Then exit MSFS and start it again and your FSUIPC start=up parameters will be tuned.

The FSUIPC7.log file shows that you started FSUIPC7 manually, it didn't detect MSFS, and you exited 4 minutes later. Was MSFS running when you started FSUIPC7, or did you start MSFS after FSUIPC7 was running? If MSFS was running at some stage, then this was not detected by FSUIPC7. If this is the case, please try adding DisableMSFSMonitor=Enum to the [General] section of your FSUIPC7.ini file. This is usually only needed with Windows 11, but maybe there has been a windows 10 update which now requires this for Windows 10 (I will check this later). Otherwise, please show me/attach a log showing your issue. John

Some MSFS events now take two parameters, such as Set External Power. You cannot directly assign to such events via the FSUIPC UI as this only supports one parameter for each event. To use such events, you need to define a preset as explained by @ark1320. Otherwise, also as mentioned by @ark1320, if a toggle control is sufficient you can also use that, maybe with an offset condition on the current state of the external power (if available). II need to update the FSUIPC7 UI to either be able to handle events with two parameters (preferred), or to at least make it known to the user somehow which events take two parameters so that they can consider defining a preset for such events. John

First, just try logging one type of events at at a time - start with Events, then try Input Events. Don't have any other logging set. If you still see lots of events logged when you are sitting on the runway doing nothing, then these are events that the aircraft continually emit. Many aircraft in MSFS continually emit certain events. You need to tell FSUIPC to ignore such events by using the DontLogThese ini parameter. This can go in the [General] section of your FSUIPC7.ini file, but it is better to put this in the [Profile.xxx] section (where xxx is the profile name), as such events are usually aircraft specific. You can ignore Input Events in a similar way using the DontLogTheseIE ini parameter. The use of both of these ini parameters is documented in the Advanced User guide. You can also do this, but it is generally easier to see the events in real-time. You can also try listing the available lvars (Add-ons -> WASM -> List Lvars) to see if anything looks applicable. If so, you can try setting these to see if they have any effect using the Add-ons -> WASM -> Set Lvar menu item. If the lvar works, you can then use that for your assignment, either via a macro, a preset or by adding it to an FSUIPC offset.

For assignments, as explained above: If you want to send multiple controls, add the parameters. So to freeze attitude, altitude and lat/long, you would use a parameter of 0xE (0x20 + 0x40 + 0x80 = 0xE0) If using lua, you would use the function: ipc.togglebitsUW(offset, mask) using offset 0x3402 and the mask is the same as the parameter as defined above.

This shouldn't affect any add-ons - unless they are using FSUIPC to access lvars and the lvar needed was not picked up in the first scan. The first scan usually detects all lvars for simpler aircraft (using the default delay of 5 seconds), but for complex aircraft quite a few lvars are detected in subsequent scans. If setting LvarScanFrequency=0 - and you are using complex aircraft, you can adjust the delay before the initial lvar scan is performed by increasing the value of the LvarScanDelay ini parameter. The default is 5 (seconds) - maybe try 8 or 10.

I have no idea how to freeze speed or fuel burned. If you are freezing position (or latitude/longitude), then wouldn't the speed also freeze (or be zero)? I do not know how this affects the fuel burned though. You would normally hold the airspeed via the Autopilot. Again, I don't think you can freeze the speed. Note also that with position freeze in offset 0x3402, I have linked this to the FS control POSITION FREEZE USER. This is different from the FSUIPC controls for position freeze, that freeze the latitude/longitude. John

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)?