C:fs9gps variables not working on MSFS2024

Nothing is required of developers in this case. Once the user creates a flight on the world map or files their flightplan with ATC on the EFB, then it will appear in the GET_FLIGHTPLAN call. The 2020 era avionics will continue to load the flightplan with GET_FLIGHTPLAN when the flight loads, as they do today. Additionally, while flight plan updates made on those avionics will not appear on the EFB, they will continue to automatically update ATC as they do in 2020.

Thanks,
Matt

2 Likes

Got it thank you. So it is just the visual plan in the MSFS EFB that will remain out of sync, thatā€™s a good compromise until we full upgrade.

Thanks for the clarifications, very much appreciated.

Best,
Raul

There are presently no APIs in any version of MSFS (going back to when PLN files were added) that read from the PLN file. All simvars as well as the GET_FLIGHTPLAN call read from the fixed format ATC flight plan struct. If ATC updates your flight plan, this changes the data in the struct and will also change the data returned from GET_FLIGHTPLAN and all related simvars. Similarly, if waypoint altitudes are sanitized based on plane type, or waypoints added (such as the basic procedure vectorization that was present in MSFS 2020), that also changes the data in the struct and thus the response of these APIs. There is no access to the PLN file in any version of the sim, aside from the SimConnect event that tells you the PLN filename that happened to be used to construct the fixed ATC flight plan struct.

The operation of the above APIs will not change at all in MSFS 2024. They will continue to read the current flight plan state from the internal sim ATC flight plan struct. The PLN file is not read with these APIs.

What is changing in MSFS 2024:

  • The EFB has a slightly different PLN file format that has been filled out with more standard ICAO flight plan information.
  • This PLN file format does not have any free-form name fields for enroute waypoints, but does support lat/lon waypoints and relative point/bearing/distance waypoints.
  • It is required that the pilot file their plan with ATC before ATC is aware of it.
  • Filing the plan with ATC will engage the ATC flight plan system to read the current EFB route.
  • Subsequent calls to GET_FLIGHTPLAN will return this ATC flight plan as they did in MSFS 2020.

Thanks,
Matt

Thanks, focussing on the data, in summary the EFB will serve new information via each API that may not include the lat, long and names of the waypoints in the original pln, unlike MSFS2020 and FSX, and if we need this weā€™ll need to plan accordingly.

Hopefully the simconnect API simply saying a new PLN has been loaded still works.

It will definitely include this for waypoints defined as lat/lon waypoints. For standard facility waypoints, it would use whatever the FSX and MSFS 2020 behavior is for creating facility waypoints in the ATC flight plan struct, which is, again, where the APIs get their data, so no change there.

I understand the requirements here, but in no version of the simulator did this PLN data remain immutable from input to output, so the fact that this around-the-back method to transfer data via the name field works at all is a testament to the communityā€™s ingenuity and I absolutely applaud them; nonetheless none of these things were designed for this purpose in any of the versions of the simulator. It also targets a very specific PC-centric workflow.

If I might offer a recommendation: a sim EFB app could be fairly easily built that downloads glider tasks in a format more suited to this specific use case and trivially sends them via either the MSFS Avionics Framework event bus to other JS avionics or even WASM avionics via the CommBus API. As an added benefit, this app would be able to run on PC or XBox, and wouldnā€™t require bending this specific serialization format outside of its design contract, which deserializes only into ATC (for the current PLN format) or the EFB (for the new EFB PLN format).

All the best,
Matt

1 Like

Just wanted to reply, so you all donā€™t think weā€™re forgetting about you here! We definitely hear you and are discussing internally.

One thing to keep in mind is that these FS9GPS simvars were purpose-built over twenty years ago just for the ACES GNS530 simulation that came with the sim at the time. As a result, the API is very GNS shaped, along with things like a separate direct-to, enroute, and approach flight plans; these things have no analogue in the rest of the sim (even less so in MSFS 2024) and in fact the whole API even in MSFS 2020 runs in the C++ side of the old MSFS GNS GPS simulation.

It also comes with the baggage that entails, including many assumptions about being manipulated only from the single thread that existed at the time, imperfect or sometimes impossible mappings to and from the sim flight plan, crash potential, no ability to be able to interact with new sim systems due to the unique API shape, and the like. They were not really intended by ACES for generic developer use outside of the GNS and thus were not documented as part of the official SDK or API for more than a decade.

In fact, most of us in the community got our info from the Robbie McElrath FS9GPS guide, who had reverse engineered it to a high degree, since the SDK was almost totally silent on the matter. It is unfortunate that they were documented as a part of the official SDK for MSFS 2020, but certainly we own that. On the plus side, everything that the API used to provide has alternatives either in new APIs or in code available in officially supported libraries.

We will continue to discuss our options internally and watch feedback on this topic, and thank everyone so far who has chimed in.

Thanks,
Matt

2 Likes

Iā€™m joining the conversation late, and I hope you understand that, one month before the launch of MSFS2024, you are leaving all screens based on navsystems.js without functionality, which, among other things, connects with files like MapInstrument.html, flightplanmanager.js, etc. These files have been included in MSFS2024:

Similarly, the new WT screens are included in this same directory:

I think the excuse of reverse engineering and the fact that there has been no documentation for 10-20 years is reasonable (many of us without documentation are exploiting this code for 4 years or more), but we also do not have documentation that allows us to migrate to the WT API. And even less so in just 17 days. As a result, many third-party aircraft, and stock Asoboā€™s F-18 as well, which are based on this API, will not function at the flight plan or MapInstrument level. I have tested this myself in the alpha, and with the F-18, you can no longer enter waypoints by coordinates or display anything on the map (VOR stations, DME, TACAN, airports, etc.) because you have deprecated these FS9 variables without prior notice and without considering the consequences.

All html5/js projects based on BaseAirliners, Navsystem, or baseinstrument or variant systems based on these, that are not the official ones from WT, will also not be able to create flight plans, load departures, arrival, approach procedures, show any map info, etc., or create, edit, or delete waypoints because they are based on FS9, which you have decided to remove without warningā€¦

Even third-party add-ons that are simply FS9-based navigation systems sold on the Marketplace will not work in MSFS2024, causing significant economic harm to those third parties because, without providing any reasonable time to migrate these systems to a new API, they simply become unusable in the new simulator.

I invite you to consider the following: the damage is done indirectly to us, but directly to you Asobo/Microsoft, because if you are removing backward compatibility from third-party add-ons to benefit Working Title systems, then this is like Windows 10 and Windows 11 and why many users remain on Windows 10; they do not find compelling reasons to upgrade to Windows 11.
With what you have done and that we have neither time nor documentation to repair, There are more cons than pros to playing MSFS2024 compared to MSFS2020 if most of their add-ons (which arenā€™t based on WT screens) wonā€™t work.

I basically divide third-party add-ons into two groups: Group 1: those of us who have built our systems based on the FS9 APIs. Group 2: those who simply incorporate the Working Title screens in their planes, saving all the programming that this entails. For example, you find everything from a commercial plane to a military one with a G3000 or GTN450, even though in real life they donā€™t have those screens, but itā€™s the only thing that would now work in MSFS2024.

As far as I know, the F-18 DDIs are still based on navsystems.js and therefore on FS9 variables for the waypointmanager.js. I donā€™t know if youā€™ve tasked WT with updating these systems (allow me to doubt it).

In any case, you are not providing any solution; youā€™re simply apologizing for having deprecated something that worked perfectly (without warning and because this thread was opened half a month before launch) for a new API for which we donā€™t even have documentation or enough time to migrate our systems, let alone in 17 days. I donā€™t think migrating to Working Titleā€™s Garmins, first, will fix the situation and, second, will be accepted by the community.

In short, I think you are making a serious mistake by depreciating these systems when I believe they can coexist perfectly. But itā€™s your product, and you decide. Donā€™t be surprised if there are more users on 2020 (where their add-ons, which are many, are guaranteed to work) than on 2024 (where only those with WT systems will work and the rest wonā€™t, because you keep tripping up third-party partners due to, clearly, a whim of yours, making everything we have developed so far useless in MSFS2024).

ā€œBackward compatibility from day oneā€ in my country means exactly that; if you made that promise a year ago, you should stay true to your word. I appreciate that this thread was created because at least now we know what to expect, and so do the users when deciding whether or not to purchase MSFS2024.

Best regards.

2 Likes

Absolutely agree with this. MSFS2024 has pivoted away from an open nav system based around the PLN file and APIā€™s as if only the WT EFP and Garmins need to be considered.

Pretty much the entire nav API has been broken (gps variables no longer exist and the waypoint lat/long/name in JS GET_FLIGHTPLAN is now omits the name).

Given this, a crucial remaining nav API is the simconnect FlightPlanActivated callback which simply passes the filepath of a loaded PLN file and itā€™s unclear whether that has survived. Given the track record so far itā€™s understandable to be concerned this may have silently disappeared.

The PLN file is not stored in memory in any version of MSFS and was also neither open nor extensible in MSFS 2020, FSX, or FS2004. The PLN file is a fixed format in all versions of the simulator in which it appears. Adding XML elements or attributes that are not part of the format will not cause those items to be available in any APIs in MSFS 2020, FSX, or FS2004.

We have made no changes at all to the GET_FLIGHTPLAN JS API (the code is quite literally identical to what exists today in MSFS 2020). It will continue to return your current ATC flight plan struct as it did in MSFS 2020, with whatever data that struct contains. The GET_FLIGHTPLAN JS API did not directly read the PLN file in MSFS 2020, had no knowledge of where any PLN file was or how it was structured, and will continue not to directly read the PLN file in MSFS 2024.

That being said, we will investigate re-adding support in the future for the id attribute of the ATCWaypoint XML element from the previous PLN format to the EFB PLN format, and propagating it to the internal ATC flight plan data struct so it can continue to be returned as name by GET_FLIGHTPLAN.

This API was not touched at all during development and will continue to operate as before.

The instruments using the open source MSFS Avionics Framework go far beyond a couple Garmins, and include CJ4, 4 different Boeing avionics, Honeywell Epic, UNS, many third-party avionics, etc, and is the officially supported JS SDK of the simulator, with all source of the framework available for use. But instead of focus solely on those consumers, weā€™ve instead opted to create platform, stack, and avionics agnostic APIs to interact with the sim flight plan that go beyond what was previously available and move the sim much closer to proper aviation standards.

Weā€™ve opened up an entirely new API that now no longer leaves WASM consumers behind as they were before, putting everyone on the same playing field allowing either platform and either stack to share flight plans both with each other and with the sim itself as well as subscribe to these updates as opposed to having to poll for them, which, is the opposite of catering only to one consumer.

Certainly the suggestion is not to just use WT Garmins (which by the way, donā€™t use any kind of fancy WT-only APIs, just regular documented parts of the sim SDK). Anyone can and should use all the normal exposed parts of the API just as the WT built avionics do.

Perhaps thereā€™s a misunderstanding (and Iā€™m sure some of the fault is indeed mine for not communicating some of this more clearly), as this is not at all accurate. Anything using the MSFS 2020 APIs from JS_LISTENER_FLIGHTPLAN for flight plan management, JS_LISTENER_FACILITY for facility data, and the SimConnect facility request APIs for facility data in WASM will continue to work as they have before. The source is also available for the MSFS Avionics Framework to get high quality examples of the usage of these APIs in Javascript.

Solutions

As promised, we have discussed this topic internally over the past week. We are endeavoring to restore the FS9GPS simvars by launch, with the following technical guidance caveats:

MSFS 2020

  • Use of FS9GPS simvars is strongly discouraged. Their exact behavior is not fully documented and non-deterministic in some cases, and can result in incorrect facility data, flight plan data corruption, and potential crashes. Proceed with great care.
  • Due to the threading model of MSFS compared to when FS9GPS was implemented, this can cause changes in cycle wait times from one query to the next. Take great care in leaving enough wait time in the consuming code to account for this possibility.
  • The flight plan of FS9GPS does not always fully interact with the rest of the flight plan related systems in the simulator (ATC, World Map, etc). When reading or writing the flight plan using these variables, you may find unexpected data or behavior regarding those systems.
  • Do not, under any circumstances, write to the flight plan from JS using these simvars, as it is guaranteed to result in eventual data corruption and/or crashes.

We strongly recommend users of this API switch to equivalent APIs from elsewhere in the MSFS 2020 API area:

  • Facility Data: In Javascript, we strongly recommend the MSFS Avionics Frameworkā€™s FacilityLoader, or the JS_LISTENER_FACILITY Coherent listener and associated API calls. In WASM, we recommend the SimConnect facility request API.
  • Flight Plan: In Javascript, we recommend the JS_LISTENER_FLIGHTPLAN Coherent listener and associated API calls. In WASM, there is no API for the flight plan at this time.
  • Geographical and Navigational Math: In Javascript, we recommend the MSFS Avionics Frameworkā€™s geographical mathematics classes (GeoPoint, GeoCircle, NavMath). In WASM, there are a number of libraries of this type of math available, but we donā€™t have a specific recommendation amongst them.

MSFS 2024

  • FS9GPS simvars are now deprecated. The simvars should work as they did in MSFS 2020 but support is discontinued. As WASM modules now run on their own thread, you may encounter data consistency issues or crashes using these from WASM that you did not previously while using them under MSFS 2020.

We strongly recommend users of this API switch as soon as possible to these equivalent APIs:

  • Facility Data: In Javascript, we strongly recommend the MSFS Avionics Frameworkā€™s FacilityLoader, or the JS_LISTENER_FACILITY Coherent listener and associated API calls. In WASM, we recommend the SimConnect facility request API.
  • Flight Plan: In Javascript, we strongly recommend the MSFS Avionics Frameworkā€™s FlightPlanRouteManager, or the JS_LISTENER_PLANNEDROUTE Coherent listener and associated API calls. In WASM, we recommend the fsPlannedRoute API.
  • Geographical and Navigational Math: In Javascript, we recommend the MSFS Avionics Frameworkā€™s geographical mathematics classes (GeoPoint, GeoCircle, NavMath). In WASM, there are a number of libraries of this type of math available, but we donā€™t have a specific recommendation amongst them.

As always, we really do appreciate the lively and passionate feedback from everyone in the community!

Thanks,
Matt

2 Likes

Thank you very much Matt for this feedback and decision.
I really appreciate how you are considering the needs of your users and partners.
Keeping this API and marking it deprecated is the way to go.

2 Likes

Iā€™d like to point out thereā€™s a third group using the FS2020 JS APIs provided by Coherent bindings to build avionics from scratch, some before the WT instruments even existed, and a fourth group building their own avionics using the WT MSFS SDK (the KLN 90B is a fine example). There are multiple different levels you can choose to build at.

4 Likes

My apologies in this case since I did not intend to offend any of those two groups or any other (surely there are even more that neither you nor I know), so I will rectify in any case to ā€œtwo majority or main groups.ā€

In any case, what I have come to claim here is something that does not affect me individually, but rather a fairly large group that incorporates the modules that I have mentioned into their projects:

image

Within MapInstrument.html all other elements are already incorporated to be able to display content on the map.

and in any of them you will find functions based on FS9, for example:

This example would have nothing to do with the map, since the map is for displaying elements, but not for manipulating the flight plan like the function I have pasted, but even so, some of us create subpages to be able to create, edit, delete waypoints, or activate procedures, among many other things. And if you take this away, we wouldnā€™t have time to migrate to something else, we would have to throw everything to trash and start from zero.

and my surprise is that something that works perfectly in 2020, suddenly, I have to find out through a thread that they have eliminated the API that makes this to work:

And you will forgive me but this does not cause me crashes at any time.

But thatā€™s not the point. The thing is that you send me an alpha when there is a month or less of a launch month left. It is one thing to deprecate, and another is to remove something without warning and ā€œaffecting whoever it affects and without the ability to react.ā€ 17 days is not enough time for us to start migrating the database to something that we do not know or that we do not have references, and assuming that we were able to do it, how many partners would upload their solution and how long would it take to process.

In any case, I am glad to know that its use has been reconsidered. And with time, we can start migrating to something more compatible.

I thank you very much and I will act under my responsibility, since it is my responsibility to debug my product. By destroying the core files, many of us would simply have no product to debug or maintain.

MapInstrument itself is not part of the official SDK but instead something internally implemented on the SDK in MSFS 2020 specifically for the purpose of needing to implement various avionics systems for first party aircraft and was not built with library usage in mind; its support for proper vectorization of procedures is a extremely limited and has a number of outstanding issues. As such it is not documented nor supported.

We strongly recommend developers use the officially supported MSFS Avionics Framework, which is listed in the documentation, and has available source and examples in source of usage of MapSystem and MapSystemBuilder.

Usage of the facility system in the officially supported MSFS Avionics Framework is available here, and has been for a few years now: Querying Navdata | MSFS Avionics Frameworks and Instruments

Just to offer some background on how this decision came to be made, we did do some research on the percentage of Marketplace add-ons using these FS2004 APIs in their submitted packages vs the total pool of add-ons, and the usage of these was seen to be quite limited and mostly in usage of already unsupported components at the time. Obviously, as developers ourselves we realize the difficulty and potential frustration when APIs between major software revisions change, but as platform holders we also have a duty and responsibility that we take incredibly seriously to offer only APIs that are stable and without footguns. Unfortunately FS9GPS simvars very much betray these platform standards.

However, this is part of why we love the community aspect of this process, as it offers us a chance to have another source of data for these decisions other than strict usage percentages and statistics, and opens us up to alternative usages that may not have come up in our original research, and weā€™re always happy to pivot if need be. And weā€™re pleased to have been able to come to a compromise in this case to expand that backwards compatibility support just a little bit more.

Again, we thank everyone here for all the helpful feedback!

-Matt

2 Likes

What will FlightPlanRouteManager return? Is this the same or similar to the current FlightPlan from the Avionics Framework or an entirely different type?
Iā€™m thinking about the path forward for my KLN-90B. I currently use a custom flight plan system, because it is so simple. But if I would need to work with the FlightPlan from the Avionics Framework anyway, then it would make sense for me to switch to this type instead.

For me building custom nav instruments, I donā€™t need the output from the EFB, all I need is its ā€˜load flightplanā€™ button and access to that data. the fs9gps simvars and JS GET_FLIGHTPLAN met this purpose, but it wasnā€™t setting the bar very high. Counter-intuitively it will feel a bit odd launching the EFB just to load a flightplan for a paraglider or sailplane but thatā€™s ok if it works.

It would be great if the APIā€™s were a bit more layered, i.e. an html/js callback that serves the actual XML from the original PLN would work best for me. Others (presumably) just need simvars giving e.g. current bearings and distances to waypoints, and Iā€™m assuming thereā€™s a dev constituency that will benefit from the complex route plans for specific aircraft the EFB is capable of generating.

What comes out of the new API is not a series of legs, itā€™s more like a generic plan route like if someone handed you a standard FAA or ICAO flight plan form with your filed flight plan on it. So, it doesnā€™t have ARINC data at all, unlike FlightPlan, which is more geared towards a structured and vectorizable set of legs and segments for use in avionics systems.

That being said, it isnā€™t terribly difficult to look that information up using the facility system. The route API will give you BLOKR6 as the departure name, for example, and then you can look up the departure and get the list of ARINC legs for that from the airport facility.

Hopefully that makes sense!

I donā€™t know that we would consider such an API. As mentioned, the XML is just used to deserialize the fixed flight plan structure in the sim and the actual XML is not retained in any version of MSFS. Itā€™s not designed to be a generic data transfer mechanism.

The WASM work folder and file APIs were expressly designed with these type of use cases in mind where specialized, avionics or use case specific data file formats are required. I would recommend exploring those options in the SDK.

Thanks!
Matt

1 Like

Sorry are you assuming the EFB is the only application that ever creates a PLN or loads it into the sim ?

My comments are wholly unrelated to the EFB and apply equally in all versions of the sim from FS2004 up through MSFS 2024. Long before the EFB existed I would have given the same guidance.

The sim (when I say ā€œsimā€ here I mean all of them since FS2004) has a very limited understanding of the PLN file. The PLN file itself is never used at all, except once at PLN file load time to be deserialized into the internal fixed flight plan structure inside the simulator. During load time, only specific XML elements and attributes are read and mapped directly to specific fixed fields inside the userā€™s ATC flight plan structure. Once this process is complete, the XML is completely discarded, never to be used again during the lifetime of the flight.

No code in the sim, other than mentioned above, reads or has access to the PLN file. This applies to all versions of flight simulator in which PLN files appear. As such, it was never designed as a generic data container or transfer mechanism.

However, thankfully, there are a large number of tools within the SDK that can help with file reading and data communications to help solve specialized use cases like custom data files and interchange.

Thanks,
Matt

Thanks for your help.

The disconnect Iā€™m struggling with is for 25+ years retrieving the original flightplan waypoints names has been trivially simple.

Now itā€™s not possible in MSFS2024 and weā€™re expending pages and pages of text why that makes sense or why itā€™s necessary. I categorically do not agree the PLN is some kind of ā€œjust serializesā€ afterthought, itā€™s been the core information sharing in our multiplayer for decades.

Iā€™ll implement a way of us loading common PLNā€™s so our nav gauges work in multiplayer as intended, itā€™s not that difficult, but Iā€™d rather just pick up the waypoint names (& lat/longs) from the loaded PLN using a built-in API.

Thanks again for your help - I appreciate this is a niche use-case and you have a much broader range of challenges you want to address bringing the flight-planning ā€˜in-houseā€™ and Iā€™m sure a lot of people will appreciate those.

Thatā€™s because the internal fixed ATC flight plan structure happened to have a field for that name. For a standard FAA or ICAO flight plan, this type of information is not really relevant nor suppliable, so the new internal route structure does not have this field.

That being said, as I mentioned far back in the convo, we are looking into adding such an optional field to the new internal structure so it can be propagated to other downstream consumers (like GET_FLIGHTPLAN). I canā€™t say it would for sure be for launch, but it does seem potentially possible we could hit that target.

Nonetheless, even in the current format, this name field is being overloaded with custom data for these glider tasks that is not actually the name of a waypoint but instead a ā€œformat within a formatā€, which, even in MSFS 2020, can be truncated as the PLN loading will only load a fixed number of characters. Thatā€™s why I continue to recommend something fit for purpose, as opposed to hacked into fields not meant for structured data.

To be clear here, weā€™re not talking about St James Cathedral in the name field, which would be expected, but things like *Start+7470|10000x5000;AAT01:45;, which isnā€™t exactly application agnostic. I completely understand why losing this route of transmission is not ideal for this highly specific use case and is absolutely a bummer; I completely sympathize, truly! That being said, I hope you can also appreciate just how outside the PLN specification and design intent putting this data into this field lies, though.

Hopefully this conversation ends up being academic for you by launch or shortly after, but I would still strongly discourage this ā€œformat within a formatā€ practice.

Thanks,
Matt

1 Like