plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

Please take a moment to read the platform’s guidelines before you get started!


For HUDs issues management, please read the article here !

question

Coren avatar image
Coren asked neile commented

B input events and the SimConnect and Gauge APIs for hardware developers

This discussion moved here from the general FS2020 forums (thread: https://forums.flightsimulator.com/t/state-of-affairs-when-using-external-controllers-not-good-imho/438814)

I'll paraphrase the expressed voices: the current state of Input Event is problematic for those of us who interface external simulation hardware with Flight Simulator: the state of things before SU5 was that much arcane gauge calculator code was needed to activate many of the cockpit controls, but we mostly managed. Since SU5, because of the overhaul of the Input Events (specifically, moving controls to the new B "variables"), much of our interface work has been broken with few ways to fix them.

It would appear that the Input Events (invoked either through >B: or F:InputEvent) exactly match our use case (have an in-cockpit control be activated by external hardware and reflect the appropriate state) but for some reason it is not possible to invoke input events from execute_calculator_code() requiring snippets of XML added to the planes in order to track local variables or similar.

The solution appears simple to us hardware developers (and users): allow invocation of B: input events so that we can flip controls from external inputs. In practice: this could be easily done in at least two ways:

A) The simple and sufficient way: simply allow execute_calculator_code() to use "(>B:Foo_Bar_Set)" and friends either directly or via "(>F:InputEvent)". At this time, attempts to do so fail with "Unknown Variable" errors.

B) The better long-term way which would obviate the need for standalone WASM modules whose sole purpose is to relay Gauge calculator code from external sources: allow invoking Input Events directly from SimConnect. Obviously this is more complicated since it requires extension of the current SimConnect api (and, presumably, wire protocol).


defaultsimconnectwasm
9 comments
10 |10000 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Hello @ll,

as the originator of the other thread I have been asked to post here too, so I will do just that.

I would like to voice my modest wishes about the methods to use external controls here. There are many people who like to use external controls instead of the mouse, who enjoy StreamDecks, MIDI devices, Saitek Panels, Knobsters etc.etc. It seems to me, that their use cases and requirements are not really important in MSFS development.

This has been a problem from the start, what with the LVars and HVars etc. that can only be accessed with additional programmatic assets instead of just SimConnect. The current implementation of the B: variables is just the latest nail in the coffin. The B: input events just showed up in SU5 and they don't offer any proper migration path for the existing logic that was accessing LVars and HVars. This leaves us developers and our customers stranded and, let's say, "unhappy". I say this on behalf of hundreds, possibly thousands of people who rely on AxisAndOs, FSUIPC, SPADNext, Mobiflight, Logitech etc.etc.

So my wishes are:

1. Asobo, please give us access to all variable types, regardless of scope, especially B:, O:, I:, in the gauges API, so we can read from/write to them with a stand alone WASM module. The icing on the cake would be an equivalent of "execute calculator code" for SimConnect. But I am pretty sure that both options are needed (considering devs have to resort to pure WASM on the XBox)

2. Asobo: please don't change core functionality of the default aircraft just like that, not after they have been around for over a year. If there is new logic that makes life easy for aircraft developers, please consider just making new planes that use it - not necessarily change the old ones. Current customers who had their StreamDecks and X-Touch devices set up just right are left in the cold at the moment - all the hours that they put into their profiles and scripts invalidated.

3. Aircraft developers, please consider publishing information about what is required to operate VC knobs and switches from the outside (LVars, HVars).

4. To both: It would be really nice to have a separate XML file that would describe/handle external controller input. For example by listing the necessary variables, or linking the B: variables to LVars . That could be a short term solution as well. For example something like this would probably do the trick:

 <!-- AAO BVar link ################################# -->
  <Component ID="LVAR_TO_BVAR">
  <UseTemplate Name="ASOBO_GT_Update">
  <UPDATE_CODE>
  (L:AAO_TBM_FUEL_Selection_Auto, Bool) (B:FUEL_Selection, Bool) != if{ (&gt;B:FUEL_Selection_Toggle) }
  (L:AAO_TBM_InertSep, Bool) (B:DEICE_Engine_1, Bool) != if{ (&gt;B:DEICE_Engine_1_Toggle) }
  </UPDATE_CODE>
  <FREQUENCY>1</FREQUENCY>
  </UseTemplate>
  </Component>


3 Likes 3 ·

Great example @neile, there are plenty of other stuff that needs multiple lines of script but could be handled with only one B variable. Also after SU5 those scripts/events/variables are much harder to find than before.


To me biggest concern about B variables are that if aircraft developer decides not to add input events to XML, then there is no way to interact anything from outside of the sim. We already have switches and knobs in default aircraft that cannot be done like before.

One example would be CJ4’s floodlight knobs, they can only be turned via B:LIGHTNING_Cabin_1_SET.

2 Likes 2 ·

Here's another example, this time for an output. I want to know if the Gear unsafe LEDs are on. The sim uses the following code to figure that out:

1628603229889.png

I don't have access to B:LANDING_GEAR_Light_Test, which relies on a value stored in an O: var that's also inaccessible via SimConnect/WASM. So I can't make my gear unsafe light properly match the sim lights.

With access to Bvars I would be able to replicate that output logic, even though it's pretty involved, to make my lights perfectly match the sim.

2 Likes 2 ·
1628603229889.png (247.0 KiB)

B variables/events could be a great tool for all the people connecting hardware to the sim, once they are available to 3rd party software. Right now in the post-SU5 state, their introduction is more of a hinderance since a lot of things that worked previously (although in a somewhat clunky fashion) are now impossible to do without getting into modifying XML files of individual aircraft.

They could be _the_ way to go for making any aircraft-specific functions accessible to hardware, once they are actually accessible. They're the missing layer to decouple control inputs from aircraft-specific logic related to those inputs.

2 Likes 2 ·

Thanks for starting this thread @Coren!

The Bvars are absolutely fascinating and incredibly exciting for home cockpit builders. I wanted to share just one concrete example of how helpful it would be to have access to them as Coren describes above.

The TBM930 has a three position switch that enables AP and Trim. Today in order to map that to my physical switch I have to use three different blocks of code depending on what position my switch is in:

AP and TRIM: 0 (>L:XMLVAR_APTrim) (A:AUTOPILOT DISENGAGED, Bool) if{ (>K:AUTOPILOT_DISENGAGE_TOGGLE) }

TRIM only: 1 (>L:XMLVAR_APTrim) (A:AUTOPILOT DISENGAGED, Bool) ! if{ (>K:AUTOPILOT_DISENGAGE_TOGGLE) } (A:RUDDER TRIM DISABLED, Bool) if{ 0 (>K:RUDDER_TRIM_DISABLED_SET) } (A:AILERON TRIM DISABLED, Bool) if{ 0 (>K:AILERON_TRIM_DISABLED_SET) }

OFF: 2 (>L:XMLVAR_APTrim) (A:AUTOPILOT DISENGAGED, Bool) ! if{ (>K:AUTOPILOT_DISENGAGE_TOGGLE) } (A:RUDDER TRIM DISABLED, Bool) ! if{ 1 (>K:RUDDER_TRIM_DISABLED_SET) } (A:AILERON TRIM DISABLED, Bool) ! if{ 1 (>K:AILERON_TRIM_DISABLED_SET) }

This is really way more complicated than it should be and extremely brittle. I don't care at all about the inner workings of the model. I only care about sending an event that says "hey, the switch moved to this position".

The new Bvars do exactly that: they decouple the underlying model logic from the input event that triggers them. If Bvars were accessible via SimConnect or WASM all the above would go away and become these three simple statements:

AP and TRIM: 0 (>B:HANDLING_AP_Trim_Set)
TRIM only: 1 (>B:HANDLING_AP_Trim_Set)
OFF: 2 (>B:HANDLING_AP_TRIM_Set)

There are plenty of other examples of this with the TBM930: Engine starter, engine ignition, AP vertical speed, ELT beacon, etc. are all plane controls that do more than simply set a value.

Asobo please make the Bvars accessible via SimConnect/WASM. The home cockpit community is tantalizingly close to having exactly the input ability to a sim we've dreamed of for years. The hard work of creating the InputEvent system is done in SU5 and amazing. Now just take that tiny extra step and give us a way to send those events to the sim!

1 Like 1 ·

Please also make B Events available through JS,


Currently K Events can be Intercepted in JS by Coherent.call('INTERCEPT_KEY_EVENT', -----)

With the introduction of B_EVENTS will here be equivalent


Coherent.call('INTERCEPT_B_EVENT', -----) ??


ie

const listener = RegisterViewListener('JS_LISTENER_BEVENT")

listener.on('BIntercepted',BEventName)

coherent.call('INTERCEPT_B_EVENT', B event name, 1)





0 Likes 0 ·
Show more comments

0 Answers

· Write an Answer

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.