This.
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).
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
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.
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 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 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.
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).
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.
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.
… they forgot to test that… It does not work.
for positiveness!