Enhanced API to access all aircraft state and trigger all cockpit functions

Les over at SPAD kindly explained to me that the reason a switch or other control didn’t move in the virtual cockpit (even though the data is being used) is because they were B-events. But I have no idea why there are so many different types of events and VARs, and what they are. I’d like to learn.

And I definitely want access to those, and all the other events and VARs through SPAD. Flipping a switch and seeing the lights come on but the switch not move is very annoying. I know there are much deeper issues here, but Microsobo really needs to pay attention to the 1106 votes (including mine) and expose everything in the API. I have a very modest cockpit (Alpha/Bravo, basic TM rudder, Stream Deck +, iPad) and seem to be constantly frustrated by not being able to see events happening in the cockpit.

I don’t fully understand how API’s work for 3rd Party developers, though. If Asobo exposes everything, will developers be able to write their code to allow SimConnect to access everything?

Maybe this will happen in MSFS 2024. It sure isn’t heppening in MSFS (2020).


Meanwhile, I patch xml files, as suggested by this post: “Adding workarounds to MSFS2020 for MobiFlight – Bad Casserole”, although I am not a mobiflight user


In the “August 10th, 2023 Development Update”, in the “SDK UPDATE/SimConnect” section, MS mention new API functions, such as “SimConnect_SetInputEvent”. Hopefully, this will give access to the Bvar’s

1 Like

So it’s now regressed from planned back to under Investigation. What is going on here. No mention of this at all. There was a dev stream question about another item that had 600 votes yet this one has over 1100 and has been around for ages and still nothing. Please give us a proper update on this specific item.


Just watched the latest Q&A stream *VOD

Best part the the question about Water Physics to support all these new float planes.

Amazing and amusing the answer to the question was, by saying nothing and just looking at each other with seemingly embarrassed silence.

Are water physic going to be updated for 2024 - I think we all know the answer now …

Not the first time we have seen similar “Deer caught in the car’s Headlight” moments.


The API I look forward to seeing is the one to read any parameter obtained from a .cfg file, and the ability to write back a new value for it, different to the static default value in the .cfg file


I’m not sure what’s up with their roadmap (ha!), but with SU13 they did update SimConnect with new features regarding “Input Events” (basically “B” vars). I’ve been playing with them (for the TP plugin I maintain). It’s a… nice, or at least interesting, start, for sure.

The good news is that I’ve been able to successfully set/activate an input event with a value. This is equivalent to, for example, using Dev Mode Tools → Behaviors → Input Events → Pinned → Execute with a Parameter on a “_Set” event. Eg:

(from https://devsupport.flightsimulator.com/t/behaviourdebug-inputevents-currently-tracked-values-extra-set-event-showing-after-simconnect-setinputevent-call/6580)

The unfortunate part is that it’s not ready for prime-time at all yet. Besides the implementation itself being kinda strange (awkward to use and not really following established SimConnect precedents), it’s also just plain buggy. For examples:

I can also get/read the current input event values, but it’s extremely volatile in terms of crashing the sim.

But yea, it’s some kinda progress! :clap:



Also try to send the Events when your NOT in Dev mode :slight_smile: … they forgot to test that… It does not work.

Looks like they punted today to 2024+

I managed to get/set Bvars through SimConnect and the new API, but I confirm this process is far from perfect.
Actually, it works only in developper mode.
I do not always receive the callback relevant to SimConnect_EnumerateInputEvents().
I do not always receive the callbacks relevant to SubscribeInputEvent() calls when the Bvar values change; particularly, I noticed that this process may be disturbed when another application calls UnubscribeInputEvent(0). Not 100 % sure, but possibly, the callbacks relevant to GetInputEvent() calls may also be disturbed. Currently, my workaround is to avoid to acquire Bvar values and rather acquire Lvars through the usual SimConnect API, and only use SimConnect_SetInputEvent() to set Bvars; so far, I have always found an appropriate read-only Lvar reacting to a Bvar change, this makes toggles possible.
It’s an odd situation: henceforth, we can (sometimes) set a Bvar through SimConnect with a single Bvar name, but when using execute_calculator_code() through a WASM module, none of the Bvar variants such as (>B:xxx) or (>B:xxx_inc) work.
Anyway, let’s be positive: hopefuly, soon, no more need to patch model xml files.

1 Like

One scenario right now is that it doesn’t respond while a model is loading. This corresponds to the time in the Dev mode behaviors inspector when the inputs list has been cleared and hasn’t repopulated yet (as with most other tabs relying on the model’s XML files to be loaded).

Or rather SimConnect responds with an ERROR exception. I have a bug logged about it here (only took them 1.5 months to get it to “reviewing” stage).

I had to resort to using a delay timer to keep trying to resubmit the Enumerate() call when I know it is pending and SimConnect keeps sending ERROR. Silly.

Yea this seems like another indication of a funky implementation on their side. I know B vars can be used from within an actual gauge module, just not a standalone one. The irony is that they managed to shoehorn this into SC somehow but not the C API, nor the JS API as far as I know. :person_shrugging:

:+1: for positiveness! :slight_smile:


Sounds familiar, although I do not receive the ERROR exception. So far, I haven’t found a reliable way to determine that a flight is actually loaded in all scenarios, including the standard case after a click on READY TO FLY. I monitored the various system events to try to find a ‘universal’ sequence, but failed. Currently, I have a loop with several seconds waits and new setup attempts until everything gets fine; tedious.

1 Like

Yes, this needs to happen in order to make Spad work properly. Spad even says after you buy it “will not work with MSFS” before you install.