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

This discussion moved here from the general FS2020 forums (thread:
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).

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:


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!

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.

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

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.

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:

  (L:AAO_TBM_FUEL_Selection_Auto, Bool) (B:FUEL_Selection, Bool) != if{ (>B:FUEL_Selection_Toggle) }
  (L:AAO_TBM_InertSep, Bool) (B:DEICE_Engine_1, Bool) != if{ (>B:DEICE_Engine_1_Toggle) }

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

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

I think a lot more people are using additional hardware controls these days.

There are affordable MIDI controllers like the Behringer X-Touch Mini (~60
dollars) that lets you have rotary 8 encoders and 32 buttons with indicator
leds hooked to MSFS functions. People are also using StreamDeck devices to
program the switches and annunciators that are part of the cockpit workflow
into their panels.

This is a new era of pilots too, compared to the past in MSFS. A lot of us are
grown ups, and have real world aviation experience, and see the huge potential
in personal refresher training and learning with Flight Simulator. And expect
better quality add-on hardware and controls.

Even though everyone can’t build their own “home cockpit”, there is still a
lot of readily available generic input devices that can be used as desktop
avionics controls.

It would be really useful to have a proper API to access all of the cockpit
controls via Simconnect. B-vars seem to fill that role from our point of view,
though we understand it might be programmatically difficult to do that due to
legacy code.

But could it be possible that SimConnect would be extended so, that all custom
controls would be added to the SimConnect API by the SDK builder? The level of
detail we are trying to achieve is WAY beyond the otherwise excellent
HoneyComb yoke/throttle switches and buttons, as you can see below. With
MobiFlight it is possible to create true to life panels with functional
controls. But it depends on access to way more things than what SimConnect
standard events and variables support.

Actually, would it be possible that the SDK would scan through the B vars, and
create matching K-events that are accessible from SimConnect. Like prefix them
with Plane Specitic or something similar? The compiler could build a matching
XML file for the plane automatically that wraps all B-vars into simconnect

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_ BEVEN T ") listener.on(’
BIntercepted ‘, BEventName ) coherent.call(’ INTERCEPT_B_EVENT ',
B event name, 1)

An official wishlist post for this is now up in the Flight Simulator forums.
Please take a moment to swing by, comment, and upvote!