John Dowson

But such controls ARE aircraft specific. I still don't know which aircraft you are using - is it this one: https://flightsim.to/file/50716/cessna-citation-longitude/416279 So, to be clear, the Input Event works on its own (without the offset condition) works to turn on, but not off? Not sure why the offset condition isn't working - try monitoring the offset value to see if that is correct. If you assign two key presses, one for off and the other for on, using input events only, does that work? And if so, do you see the value of the Input Event in the offset change when you do this? If so, it should be possible on one key with an offset condition.

@Pierrot727 I think Edoradar's script is overkill for your needs. If you just want to toggle various freeze states on/off on the press of a button, assign the button to the control Offset Word Togglebits, give the offset as 0x3402, and sum the bit values of the freeze states you want to use for the parameter. So, if you want to freeze attitude (0x20), altitude (0x40) and lat/long (0x80), the value would be 0xE0 (0x20 + 0x40 + 0x80). John

@DaveSCUSA Can you tell me which Longitude you are using and I can see if I can get hold of this and take a look. I thought this was an Asobo aircraft but I only see the Citation CJ4, which has no Input Event as ELECTRICAL_ExternalPower_1. Looking at your log extract, your keypress is turning the external power off and then on, so it looks like it is being triggered twice. Have you tried just using the Input Event (without the preset), and also just using the preset (without the Input Event)? If not, please try this. Usually, but not always, triggering the Input Event should be sufficient.

You do not need MobiFlight. FSUIPC includes the MobiFlight presets in the event file (events.txt), which is from the community-driven effort, led by MpboFlighjt), on the HubHop site (https://hubhop.mobiflight.com/presets/). Please see the Advanced User guide on presets, lvars, hvars etc (in the WASM section). You should read this to get an overview of what presets are and how to update, etc To assign a button/ or key to a preset, you just check the Select for Preset checkbox, and the presets will be available for assignment in the drop-down menu. However, as there are > 16,000 presets (and growing), it is easier to either use the Find Preset.. button to locate a preset, or find the exact name using the search facilities provided by the MF HibHop site.

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

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: John

If that B-var is listed when you list Input Events, then you can try assigning to that. If it is not listed as an Input Event, it is a b-var that is not yet mapped to an external input event and can't be used. I have noticed that some input events don't seem to be logged when used. I am not sure why this is at the moment - it is on my list to investigate and report to Asobo. If its listed as an Input Event (in FSUIPC) but not logged when the button is triggered, you can still try assigning to it. There are two ways to do this: 1. Overload your button/key with two assignments, one to turn off and the other to turn on. Then use an offset condition on an offset that holds the current state of the external power switch. 2. Add the Input Event to a spare/free FSUIPC offset (as an unsigned byte) - see Advanced User guide (page 52), and then use the Offset Byte Togglebits control on that offset with a parameter of x1.

Hmmmm ok I never tried to use it this way. I can give it a try for sure. is there a reference in the manual for how to do that or could you quickly point me towards? Those controls are defined on page 35 of the Advanced User guide, as is control Offset Word Togglebits.

But it toggles only if you write a different value to the offset. So, say freeze position is currently Off, then bit 4 will be 0. Writing 1 to this bit, or toggling it, will send the position freeze control, which in turn will update this bit to 1 (value 0x10). If you write 0 to the offset (when it is already 0), nothing will happen. Now bit 4 is on, if you try and set that bit again, nothing happens. If you set that bit to 0, either by a clear or toggle control, the position freeze will be turned off. Currently bits 0 and 1 of offset 0x3402 use on/off controls (not toggles), but bits 4,5,6 and 7 use toggle controls. I could change these controls to use the equivalent on/off controls (via Set), but this shouldn't be necessary as the offset should always hold the current correct status/value, so toggling performs the same action as a set or clear. So, if the freeze is going on/off repeatedly, then you are repeatedly sending controls to toggle the bits. You should only send the toggle control when needed, once to set the freeze and later to clear the freeze. If you must continually send these controls, then use Offset Word Setbits and Offset Word Clrbits controls instead. But this would make this offset very difficult to use for most users. The standard use case for such controls is user-driven, i.e. the user decides when to freeze (and presses the button or key to trigger this), and when they want to unfreeze they would press the button again. Sorry but I don't have time to go through such a large script in a language I haven't used for over 20 years.

@Edoradar I would like to clarify the issues you are having with this update before I release, so could you please respond to my previous comment.

@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

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..