I’ve recently transitioned to MSFS2024 and started working on connecting my Saitek Multipanel and three StreamDecks to the Longitude’s cockpit functions. However, I’ve run into a number of issues. Many SimConnect variables and L:Vars seem to have changed since MSFS2020, which has broken most of my existing SPAD.neXt profile for the Longitude.
While looking for other ways to bind the right buttons to the right events, I found that nearly all buttons and switches in the Longitude are now tied to B-Events. Sometimes also changing simconnect events, but sometimes not. That’s a great step towards more straight forward button-control, as it allows us to link physical hardware directly to in-game cockpit controls instead of manipulating aircraft systems indirectly! So I was up and running with a new SPAD.next profile in no time.
However, the B:-data doesn’t seem to function properly in practice. According to SPAD.neXt technical support, this appears to be caused by the way the B:-event system is currently functioning in MSFS2024. Unfortunately, there’s no workaround from within SPAD.neXt or any other external hardware control software.
This poses a issue for many Asobo aircraft, especially because numerous variables and data elements used in MSFS2020 have either changed or been removed. In my case, only about a third of the physical buttons are functioning as intended. The issues I encounter include:
After launching both SPAD.neXt and MSFS2024, B:-variables don’t update StreamDeck button images or light up the Multipanel buttons. Only after re-saving or editing the events in SPAD.neXt do they start responding again.
Some B:-events fail to trigger their corresponding in-game cockpit controls entirely (e.g., the Longitude’s APU Generator switch).
Some switches toggle a function (e.g., turning on landing lights), but then won’t toggle it back off again.
I’m currently exploring workarounds, but many cockpit functions simply can’t be reliably controlled with the current B:-event behavior. So I can’t bind all buttons, which means I can’t use my hardware seperately.
I’d really appreciate it if the MSFS development team could take a look at this and consider improving B:-event support and overall variable access. That would go a long way in making things easier for home cockpit builders and peripheral users like myself.
Also, are there any workarounds known to other users which I’m missing? I’m not a pro, just a enthousiastic home-cockpitbuilder with some experience in using SPAD.
Please keep in mind this is not a SPAD.neXt support platform so there are some issues I cannot provide any feedback on, not knowing their implementation.
First important thing to know is that an issue was uncovered on the InputEvents API regarding how parameters can be enumerated and processed when sent through SimConnect_SetInputEvent: Trouble with InputEvents since Beta - [MSFS 2024] Bug Reports / SimConnect - MSFS DevSupport
This was addressed in SU3 beta and is likely to be part of the reason why SPAD.neXt is not supporting some events.
Then I made sure the InputEvents API allowed me to trigger the events you mentioned on the Longitude
This does work when using SimConnect directly. The event is named LNG_ELECTRICAL_APU_GENERATOR and expects a double with 3 possible values 0=OFF/1=ON/2=RESET
LNG_LIGHTING_LANDING_1/2 are not toggle events. You are expected to provide the value 0 to switch it off, and 1 to switch it on. If the button is being pushed but it stays in the ON state, it is likely that the event is triggered while always providing 1 as a value
I don’t understand what “B:-variables” refers to.
I assume this refers to value returned by SimConnect when an InputEvent is subscribed to?
If so, I will also have a look.
I’m not familiar with SPAD, but I imagine that “B: variables” refers to the Bindings of the InputEvents. It is possible to read from/write to B: type assets (=same name as the input event, but added the binding “do-word” like _Set or _Toggle) using the execute_calculator_code method, and I assume that SPAD does that (I do it too, sometimes this works better/at all than using Input Events directly).
Have you yourself witnessed an issue about the values returned this way?
B vars in RPN are used quite a lot so that would be surprising if we had a long standing issue on this.
However, I might have found an issue in the case of doubles returned through SIMCONNECT_RECV_SUBSCRIBE_INPUT_EVENT where 0 is returned instead of the correct value.
I will have this looked at.
Edit: nevermind, I just wasn’t processing the value correctly. It is working as expected.
no problem on my side (=in AxisAndOhs). I can utilize BVars just fine, both reading from them and actuating their actions.
As I wrote, I know nothing about how SPAD handles this, but I suspect that @Steefiee6963 may be confused about how BVars operate in actual practice. In any case, IMHO, the first step should always be to utilize the Input Events themselves, and only resort to their bindings/BVars when absolutely necessary (BVars are quite handy though).
I ran a quick test in the Longitude, using AxisAndOhs for MSFS 2024 (Beta, 1.5.10) with LNG_ENGINE_Run_Switch_1:
(B:LNG_ENGINE_Run_Switch_1) returns the actual state of the switch (0/1)
1 (>B:LNG_ENGINE_Run_Switch_1_Toggle) operates the switch as expected
So again - no problem with them BVars that I can see.
BVars are the “Bindings” of InputEvents. IEs can be operated directly through SimConnect, without any detour, and I would expect them to be present in SPAD too (I don’t really know that though, for obvious reasons…).
BVars don’t have a fixed name - it is adjusted as per your use case:
To read from a BVar you just use the name of the Input Event:
Example: (B:LNG_ENGINE_Run_Switch_1)
To trigger an action, you have to add a “do-word” to the BVars’ name:
Examples:
1 (>B:LNG_ENGINE_Run_Switch_1_Toggle)
0 (>B:LNG_ENGINE_Run_Switch_1_Set)
1 (>B:LNG_ENGINE_Run_Switch_1_Set)
Which ones of the potential suffixes are available can be seen in the behavior debug dialog in the sim itself. They can also be _Inc, _Dec, _Up, _Down, _Open, _Close - etc. The sky is not the limit
It is important to note that reading a BVar (or IE) value only returns the state of the switch/knob/lever. This does not necessarily tell you the state of the aircraft system that this asset controls. OK? Just because the landing light switch is down does not mean that the light is actually on. A momentary button may set the BVar to 1 when pressed and 0 when released. That doen’t tell you if the system that it controls is on or not, that would probably be in some other variable (A: or L: or whatever). So what assets you apply in your StreamDeck Actions depends on you actual use case.
Crucially, IEs and their BVars are aircraft specific assets, not simulator/SDK things. So if and how they work is between the aircraft (s developer) and your controller software. Your question should ideally be directed at SPAD support.
I was interested to read this… MSFS ‘event’ support is a bit of a mystery to me, where in most programming languages triggering and subscribing to events is pretty clear cut.
Can you ‘subscribe’ to a B event? i.e. have some code in your model XML or html/js or typescript or simconnect or wasm that gets called when a B event occurs?
And can the B event be triggered from anywhere (e.g. simconnect) and it will still be detected somewhere else (e.g. html/js) ?
BVars are properties of the behavior code (bindings of InputEvents). They don’t just float around in the simulator code to be used as you please, they are purpose bound. With SimConnect you are supposed to use the InputEvents directly, it has separate methods for doing that. BVars cannot be triggered (or accessed in any way) with SimConnect, but InputEvents can. And you can subscribe to IEs too. SimConnect API Reference
Look for the section “Input Events”.
And here is the spec of the behavior code, how Input Events come to be and what “bindings” are. Model Behaviors
I’m not technically as far as you are, and I’m certainly not a pro at this. But I found a workaround which allows me to use SPAD and B-events to operate the switches directly. I understand that using Input Events is the standard, but I find it very convenient this ways. Especially for switches that operate multiple input events which are triggered when using a B-event.
When I open SPAD I have to activate another profile and then activate the correct profile. This way (and again, I don’t know what’s going on between SPAD and SimConnect) SPAD updates the button states. Also, this way all B-events are triggered correctly.
It’s not perfect, but a fair workaround to make it work. I don’t have a lot of time to spend on gaming, so I rather spend it on another flight then changing the entire profile to Input Events
