MSFS API's frustration

[MSFS 2024] Questions & Community Discussions
1

I understand the MSFS franchise is one great big heap of competing priorities, but I’d like to make a plea for more holistic / less chaotic API’s.

For external apps I think we’re agreed SimConnect is the API of choice.

For html/js gauges I’m assuming the BaseInstrument framework with the SimVars real-time sim data connection should be the way to go.

My example today is trying to communicate the Weather parameters loaded by the user in the sim (i.e. Weather preset name, wind layer parameters, cloud layer parameters).

There’s a good ‘js listener’ API in the html/js framework to get those weather parameters, which are a simple mix of strings and numbers. Actually, an ideal strategy would be the SAME information is available to SimConnect applications, or some modern flavor of that, but currently that’s not the case.

But as I develop in both C# SimConnect and html/js gauges then maybe I can collect the data I need in the html/js code, and communicate that through to my SimConnect code, and lo, my SimConnect logger can log the weather parameters.

The reality is this communicating the data from the gauge code to the C# SimConnect code is extremely clunky (there’s no real API, I’d need to define a whole bunch of shared vars for the numbers, and communicating a string isn’t even possible unless I multiplex that into a whole load more vars).

So not only can the SimConnect app not directly get the low speed ‘static’ info that the html/js gauge can get, but the gauge can’t even package that up and send it to C# SimConnect.

Instead I’ve written a hash function in the html/js gauge that compresses all the weather data into a 7-digit decimal hash, and put that hash in a L: var so the SimConnect can pick that up, and use it to independently detect the preset changing and look up a reference list of weather presets.

With hindsight I could have just added another API to my simconnect exe code so the gauge could send the structured data directly to the logger bypassing the MSFS api’s completely, as I’ve been doing for the past 4 months with the PLN data. But it seems seriously wrong to have my amateur API bridge become an increasingly necessary component to get data from one part of the sim to another.

This looks like a rant, but honestly it isn’t, it’s a frustration that existing API’s are getting more fragmented and if it continues this way it’s going to seriously impact MSFS as a franchise which will be a loss for us all.

2 Likes
2

The JS listener for weather presets existing is a function of the fact that the UI needs it, but it is not really intended to be consumed by external developers. Third party weather reading or adjusting via this method is unsupported (although we are aware of some add-ons using these methods to do so).

In general, the venn diagram that encompasses the overlap between WASM and JS APIs in 2024 is the proper public API surface, and other JS APIs that were created for consumption by the internal UX teams don’t really fall into that category.

Thanks,
Matt

3

Such a general statement looks plausible but ultimately isn’t actionable by any real programmer & I’m not sure why the focus should be narrowed to WASM+JS - there are API’s in model XML, the template system, simconnect & typescript. TBH my view is this highlights exactly the issue: the rapid development of additional apps and features on the FSX/MSFS2020/MSFS2024 platform is leading to the cumulative API surface being very fragile around the edges, i.e. quite a few things that were possible in FSX or MSFS2020 are no longer possible at all in MSFS2024.

The plea is basically add more architectural rigor to the platform, i.e. if there’s a new development (let’s say for example multiplayer support), then consider the access to that information (both static and realtime) in EACH of the programming frameworks. The opposite would be to create a new multiplayer system in Golang and assume that framework as the only 1st-class consumer of that API. Go is awesome, it’s the future, but that’s a terrible architectural strategy.

I can understand anyone preferring to say this is a non-issue, fair enough, but my experience on larger systems suggests otherwise.

(BTW, this thread is intentionally “devs forum/MSFS 2024 Discussion” - I understand there’s a risk moderators might think it’s critical or negative but that’s not my intention. If the thread’s deleted I won’t be offended…)

2 Likes
4

I don’t know that I would agree with this statement. There are some things that have been deprecated intentionally over time, sure, but I’m not coming with examples where this is due to any mode of architectural fragility or API fragmentation, so to speak. Lots of folks using undocumented internal APIs and having those change or not be precisely tailored for external-to-the-sim software doesn’t really count here, as that isn’t really supposed to be a supported API surface.

That’s exactly what we’ve done for 2024 with the new planned route API as well as the new facility data and calls, and indeed even in 2020 the comms bus API was added so even if one API lagged the other temporarily you could always achieve parity by exchanging data.

Sometimes some APIs only make sense for some areas: we’re not going to duplicate the entire XML behaviors system in two other languages, for example. Nor does it make sense to go in the other direction and add the entire API surface of JS/WASM/SimConnect to RPN, as XML/RPN is meant to be “glue” code, not systems modeling code.

-Matt

5

I get the continuous theme of “nothing is broken”, “the new avionics is great”, “you should never have been using that API in the first place”. Those statements seen issued as if from a position of strategic authority for the entire sim but it’s unclear to me whether that’s the case or these are just opinion equally valid with mine (I’m what’s called a “1st-party developer” but TBH I don’t post as if I own the MSFS franchise).

But I’m necessarily a broad-based MSFS developer and I think if you focus mainly on a particular subsystem it’s important to understand the limitations that can place on a systems-wide view. E.g. one might need to ask for examples of what’s breaking because everything looks rosy inside some framework.

So for example: The SimConnect FlightPlanActivated event no longer works. This has implications that someone who has never programmed a C# simconnect application (e.g. a logger or a flight planning app) will be familiar with, and can lead to erroneous assumptions.

IMHO there is no good reason the FlightPlanActivated event should have broken in MSFS2024, it was just a piece of the sim outside the framework some developer not using that API was updating, and it broke. There was no announcement or documentation deprecating that API, there was no announcement the API had ceased working, it was just left to other developers to discover that.

All this can be answered with another round of “everything is fine”, “the avionics is great”, “you should never have been using that API in the first place” but that is the trajectory that is eventually going to sink the MSFS franchise.

3 Likes
6

Asobo and Working Title are the developers responsible for the SDK; at this time we (Working Title) are responsible for the flight planning, JS avionics, and navigational data facing portions of the API, and we share collaboratively with Asobo the direction setting regarding the SDK (with of course more collaboration happening in areas of overlap, like these areas, and other areas with relatively little overlap, like art and scenery).

Indeed, I can say from a position of authority that internal JS listeners created solely for the use of the sim UX teams were not intended to be a public API surface for the sim and although we can’t explicitly prevent folks from using them, as internal APIs intended to allow the sim’s UX JS to communicate with the sim only they are not intended to be carried to other languages or API platforms, most especially for the weather panel, which was not built for the purpose of being end-developer addressable at this time.

If you’re referring to us, we didn’t update any of the underlying code regarding this event; however, we do have an issue logged for investigation to see if it is getting confused by something upstream, as many things changed in flight plan generation and order of operations outside of our area in order to support the career system as well. That being said, we haven’t been swamped by reports of this from developers so the total impact of the issue does not seem wide-ranging.

Unfortunately, it isn’t exactly clear what this event would mean semantically today; in old sim versions there was a clear delineation because there was just the single limited flight plan for the player and a very clear point when that plan would become the active plan; today the plans are more appropriately local to the systems that use them.

I’m assuming SimConnect users wouldn’t want a FlightPlanActivated event every time someone modified the plan in the EFB. So, would it only be when the plan is filed with ATC? There is no longer a single “player plan”: there’s the plan you have in the EFB, there’s the plan you have in your avionics, there’s the plan you’ve filed with ATC, etc.

This splitting was a very conscious choice as that represents how the real world works and although I’m sure one could argue it’s “easier” for everything to just have one plan that is magically known and forced to be used by all systems, we have had numerous developers large and small over the years ask for these to more easily be separated so that there’s more of a first-class support for multiple plans.

I think probably the closest and most appropriate thing to do in this case is keep this tied to ATC as it was in the past; in any case we can investigate why this event is not giving usable information right now.

-Matt

7

We’re also affected by the disappearance of the Weather listener in many ways. We’ve been asking for some of that data to be exposed a long time ago but nothing got implemented. One (of many) example of that is the fact that we can’t get the relative humidity via a sim var despite the fact that the sim has that data already calculated.

While I understand this listener and many others were initially created for the UI team, including it in the SDK and then locking us out of this data post-release and not giving us an alternative really sucks for developers and ultimately, users of the platform.

I really hope this can be reconsidered. The last thing we want to do is write a long blog post explaining why most of the products we sell today won’t be coming to 2024.

4 Likes
8

We’re also affected. We’re one of several add-ons/developers that have already established FS2024 compatibility using the weather listener that apparently now is suddenly blocked for SU2. Including it in the SDK, having it be adopted over several years (and well after FS2024 release), accepting it, referring to it publicly as something positive that some devs are doing, and then suddenly locking us out post-release is, well, terrible for everyone.

On behalf of the many developers and thousands of MSFS2024 customers directly affected by this, I hope this can be reconsidered.

9

I’m not totally clear where it was stated that JS_LISTENER_WEATHER was going away, so I apologize if I’m a bit lost here.

My understanding of the topic of the thread was a lament that there wasn’t also weather theme access in the other languages and/or APIs supported by MSFS. I’m not aware of anything that would be preventing anyone from continuing to use JS_WEATHER_LISTENER as it exists today, which, to me, looks the same as it did pre-SU2.

The message I was attempting to convey was that the API, as an internal facing one, would likely not be getting additionally covered in SimConnect and/or WASM, for the reasons aforementioned. It just was never built with the flexibility of third-party access in mind and as such may offer challenges in compatibility as the features of the sim evolve, but there’s no barrier to using it.

Are folks having sudden difficulty accessing the listener?

-Matt

10

Maybe I misunderstood the thread, I don’t want to hijack it but yes, it’s an issue: Legacy HTML/JS access of UI View Listeners