question

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>

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

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.

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!