John Dowson

The parameter is the bit (in the byte) to toggle. x1 is but 0 (2^0). If it was bit 1 you wanted to toggle, you would use x2 (2^1=2), bit 2 would be x4, etc. And you toggle multiple bits by summing. So x3 would toggle bits 0 and 1. Basically its the mask of bits to toggle. A byte cannot hold a decimal value - you would need 4-bytes for that (a float). FSUIPC does the conversion of the original decimal value of the Input Event using the modifier you specify in the line where you add the input event to an offset. No, you didn't try this - that was SET EXTERNAL POWER, which requires two parameters. The toggle control only needs one. You add it to an offset and toggle that offset, as Al showed in the previous post. As its a toggle control, you don't need to gave a condition on this. If you did, you would just add an offset condition as explained in the Advanced User guide. John

If it helps the investigation here, I tried both of the above (assigned a different key to each one) and they both work to toggle the Longitude's external power on and off Thanks Al - I don't know why the OP just doesn't use those instead of messing around with input events and lvars. The easiest way is usually the better way...maybe @DaveSCUSA could explain why he can't use either of those, as he just seems to want to toggle on a keypress.

Trial key sent via PM.

Note also that some devices send a press on the first button press, and a release on the second button press, acting like 'sticky' buttons. For such devices, you need to assign on the press and release. You seem to be using some sort of button-box that sends key presses, no? If so, check it is sending the same key presses each time you press, and if the second press is a release, you need to assign to that as well. Otherwise, follow my previous posts and respond to them. And show me your assignments and log files so that I can see what is happening - these are needed as otherwise I cannot understand what you are trying to tell me. Finishing now for the day. I will review again tomorrow - and see if I can get access to the Longitude to take a look. John

You also said: I asked to see these assignments that work. Please show me them and we can go from there. If they are using Input Events, please log the offset holding the input event and see if that changes. If so, you can use one button and an offset condition on your two assignments. Otherwise, if an lvar changes, add that to an offset and use that for your offset condition. If the input event works on its own, you can also just write to the offset to change the value of the Input Event,

Sorry, what does this mean? But you need to check fist if the input event is sufficient. Normally, a properly implemented input event will do several things, such as triggering events (k-vars) and updating lvars, so you shouldn't need to do anything else but trigger the input event. But, as I keep saying, this depends on how things are implemented. You need to test. This doesn't make sense...of course you can change an offset with/on a button or keypress, using the provided offset controls. You can also do that in a profile - whatever you can do in general assignments, you can do in a profile. What is a 'mom button'?. If you mean a standard (momentary button), then I just call that a button (i.e. a standard button) - the other types are sticky buttons (i.e. stay in when pressed, and release when pressed again). If thats the case, I have already shown you - use overloaded assignments and an offset condition. BUT, you need to test the offset that you a are using, which is why I have asked you to monitor the offset that holds the Input Event. Did you try this? And input events have values, not off/on, although some may have a value of 1 for on and 0 for off. But input events seem to be like lvars - they are just a different type of variable that holds a value. To set/change this value, you just assign to the input event and specify the value as the parameter.

If it works with two buttons, foes the offset holding the Input Event change value? If so, you can use offset conditions. No, I didn't know this and find this confusing. I thought you were using the Input Event only, not lvars. Can you please show me the assignments that work, and/or explain what you mean. Not sure what you mean here, please explain. I am confused about your assignments and what is working. Why are you talking about offsets when the assignment is using input events (or so I thought)? If the input event works, you can try just using the input event offset and write to that. There are differences - compound functionality relates to the state of one button (or button flag) when another is pressed. For key presses, this just doesn't make sense. For key presses, you use modifier keys, not other conditional keys, hence the difference. Offset conditions are the same for keys as buttons.

Looking in the MSFS debug window, it looks like the longitude is registered but not mounted, but the 6 livery folders are refistered AND mounted. I did have the Test Pilot livery installed and that was registered but not mounted as well - I removed that and no change. Anyway, this is an issue on mu side that I will look into. For your issue, please try what I suggested, i.e. monitor the offset holding the input event value, initial use two keys assigned to the input event (only) to switch on/off, and see if that works and the offset value changes. If it does, then you should be able to use one key with the assignments overloaded and with an offset condition. Also maybe try just one key assigned to the MF preset LONGITUDE_TOGGLE_EXTERNAL_POWER_SWITCH, or to the FS control TOGGLE_EXTERNAL_POWER with a parameter of 1 (which is what that preset uses).

Yes, I can see it in my MSFS official folder, with 9 additional livery folders. It just doesn't appear in the MSFS aircraft selection. I did have the WT mod installed, so uninstalled that, and that other N75RA mod I linked to above. Maybe its the xbox liveries I have installed - will try removing those...

The Lonfitude should be in the premium deluxe version, which I have, but I don't see this in my aircraft selection - and I even have the WT enhancement for this aircraft installed...strange...

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.