C:fs9gps variables not working on MSFS2024

[MSFS 2024] Questions & Community Discussions HTML/JS
1

The C:fs9gps:IcaoSearch variables for waypoint search are not working anymore on MSFS2024.
Is it a bug or intended?
How could we replace that?
This is a blocking feature for us.

1 Like
2

Any advice on this?
The C vars are part of the 2024 documentation but are not working (ex search session) in the dev alpha.

2024-10-25 18_21_38-Simvar.js
2024-10-25 18_21_38-Simvar.js1320×666 134 KB

3

Hello,

The legacy C:FS9GPS simvars have been deprecated and removed from the simulator. For getting facility data, we recommend using the SimConnect Facilities API (if an external app or a WASM module) or the MSFS Avionics Framework Facilities API (if a Javascript/Typescript module).

Hope that helps!

Thanks,
Matt

1 Like
4

Hi Matt,

Just to clarify: Deprecation refers to APIs that are still in use but are likely to be removed in the next major release. What you’re describing is actually obsoletion, not deprecation, where the API is removed altogether.

Also, note that the documentation lacks any warning about either of these, suggesting that the team has made an undocumented breaking change. Moving forward, the team should improve processes to prevent undocumented breaking changes like this if it is going to make good on its compatibility forward promises.

1 Like
5

Hello,

You are correct, this API has been fully removed. Our deepest apologies on mistakenly leaving this documentation unaltered; unfortunately with a product this large sometimes some of the deeper annals of legacy APIs can get lost in the shuffle. We will definitely add (and had intended to add) some notes to point folks to the much more current APIs.

While of course we would always like to maintain strict 100% backwards compatibility, these systems were brought forward mostly unaltered from legacy FSX era code and as such were not ever well integrated into the simulator and could cause data corruption as well as crashes. In making this decision we reviewed the various published addons using this feature compared to all addons as a whole, and although we always regret having to force developers to make any changes, we found that it was in the best platform interest to move fully to the new APIs, which are more functional, robust, and integrated into the sim.

Thanks,
Matt

5 Likes
6

Thanks Matt for your answer.
I think we could be able to replace fs9gps variables by some framework or coherent calls.
The only ones for which we could get issues are about the airspace data.
The GTN750 has a nearest airspace page that gets information from the fs9gps variables. Unfortunately, we can get the same information from a coherent call nor from the framework (or I missed something).
We miss the status (C:fs9gps:NearestAirspaceCurrentStatus), the near distance (C:fs9gps:NearestAirspaceNearDistance) and the ahead time (C:fs9gps:NearestAirspaceAheadTime).

7

Hello,

There is not a single call for just that specific information pre-computed, but you can use the nearest facility search listed in the MSFS Avionics Framework documentation to get airspace boundaries (FacilitySearchType.Boundary), which will give you a collection of boundaries, their type, and the boundary geometry from which you can compute this information.

Thanks,
Matt

8

Sure thing but not so easy to program the distance to the airspace boundary.

9

We could do with clearing up exactly what SDK features related to Nav in MSFS 2020 are no longer working in MSFS2024, and whether that’s somewhat belatedly going to be called ‘as intended’ or fixed as a bug,

E.g.

  • Loading a PLN before loading the plane (in 2020 it’s at the World Map) is not working in the Dev Alpha, this means it’s not possible for the plane to get the flightplan data (via Coherent.call(“GET_FLIGHTPLAN”) on plane load as currently is the method in MSFS2020. Note in MSFS 2020 there is no option to load a PLN after the plane is loaded, and the EFB seems to be intended to add that, but that will be a new code path for html/js gauges not considered in 2020.

  • In the Dev Alpha the Coherent.Call(“GET_FLIGHTPLAN”) is not compatible with MSFS2020 as it returns only the lat/longs of the waypoints, no other information from the PLN. Presumably this is all WT needed for their Garmin gauges. MSFS 2020 returns at least also the names of each of those waypoints exactly as recorded in the PLN file.

Ultimately it seems the EFB has only really been programmed to interact successfully with the WT Garmin gauges, the exchangeable PLN file representing the flightplan has been forgotten. FWIW the PLN is the crucial component of an open software ecosystem of alternative flight planning software - if we’re going to collapse from that to a closed system based on the EFB then we ought to spell that out clearly now.

Our multiplayer gliding relies entirely on the ability to share a common flightplan, with up to 40 players flying multiple ‘tasks’ together every week. This isn’t a use-case the EFB helps with at all (not a lot of fuel calculations in glider flying), but it’ll be difficult if the core MSFS2020 nav support (PLN files and ‘GET_FLIGHTPLAN’) we need for our gliding nav gauges and flightplans is broken (or ‘deprecated’) in MSFS2024


10

Hello,

The PLN format used by the EFB has actually been expanded quite a bit as opposed to reduced, with the ability to define a number of things not previously possible to define, potentially required for an ICAO standard compatible flight plan route:

  • Defined departure procedure name and departure transition name (as opposed to just an incorrect flat set of legs for those)
  • Arrival procedure and arrival transition name
  • Selected approach procedure
  • Selected visual departure and visual approach procedures
  • User ICAO identifiers for waypoints
  • Relative point/bearing/distance waypoints

As opposed to being designed only for WT usage, this format (and the similar interchange formats for the EFB sync APIs) is designed to be as avionics and application agnostic as possible, so that any avionics system or app can consume and transmit standardized flight plan routes without the baggage of formatting that would be specific to one type of avionics or use case.

Indeed, the intention here is to make a much less “FSX” specific plan route interchange format (which has never been well documented and contains many features with various levels of compatibility or incompatibility) that can be easily consumed by anyone. The existing format continues to be used for mission, bushtrip, activity definition, etc.

However, you are correct in finding that this does not include arbitrary length waypoint names at this time. That being said, waypoints can be named still using the waypoint ICAO identifier using a type of U and a name of up to 8 characters in the Ident. We are looking into supporting arbitrary length waypoint names post-launch, but have some technical challenges to clear, namely that this interchange format is also necessarily part of the API: unlike previously, routes will be sharable across both JS and WASM, and arbitrary length data exchange becomes more difficult in the WASM domain. We feel it is crucially important to have the ability for WASM planes to synchronize with the sim route, as this was a feature missing in 2020 that was highly requested.

This is the incorrect method even in MSFS 2020. The GET_FLIGHTPLAN call should only be made after the GameState becomes GameState.ingame. If GET_FLIGHTPLAN is only called exactly when the plane loads, then any plan changes made after the user selects their plane on the world map are totally ignored.

By waiting until GameState becomes GameState.ingame, then you can ensure the plan is loaded once the player has started the flight, after which it is guaranteed they have finalized their planning on the world map. You can get the current GameState by calling getGameState() on your instrument class that extends BaseInstrument.

If you are using the MSFS Avionics Framework (which we highly recommend), then an easy convenience class GameStateProvider is provided that converts the GameState into a simple to consume Subscribable using GameStateProvider.get(): msfs-avionics-mirror/src/sdk/data/GameStateProvider.ts at main · microsoft/msfs-avionics-mirror · GitHub

Finally, the planned route APIs in the dev alpha are not the final planned route APIs and as a result we will have further documentation on them in the coming weeks.

Thanks!
-Matt

2 Likes
11

You misunderstood me here although your advice about Gamestate may be useful for others. My point is in MSFS the PLN is selected before the plane spawns into the sim, and there is no option to select a PLN after the plan has spawned into the sim. So the logic to load the flightplan in MSFS2020 does not need to arbitrarily wake up at any point during the flight to load an unexpected new flightplan and the flightplan in MSFS2020 can be reliably loaded (when the sim is ready) at the start of the flight. The EFB can be used in the cockpit, so in MSFS2024 gauges using the flightplan need to be able to detect the arrival of a NEW flightplan at any point during the flight. Please correct me if I’m wrong there.

Assuming your ‘PLN format’ means an actual file it will be good to see documentation of the actual format, and clarification of what data then gets passed to the JS in the GET_FLIGHTPLAN call.

In MSFS2020 essentially just the waypoint names and lat/longs appear in GET_FLIGHTPLAN which is why the names are so crucial. If you’re designing a new format please include a flexible new property for each waypoint (<Comment>?) that is available from the GET_FLIGHTPLAN call. That’s what the ‘name’ currently is and you’re killing that. There’s absolutely no way you guys can think of everything that could go into a flightplan and trying to hardcode every possibility is never going to work.

12

I think I’m understanding now; to this end there is an entirely new API that will exist in both JS and WASM that will do the following:

  • Allow to ask for the sim EFB route
  • Subscribe to route sync broadcast from the EFB
  • Subscribe to requests from the EFB to get the avionics route
  • Respond to route requests from the EFB

The legacy GET_FLIGHTPLAN call will continue to exist for backwards compatibility but MSFS 2024 addons should be upgraded to use the new route API. Because adding any additional data would be a breaking change for backwards compatibility, the data structure returned by GET_FLIGHTPLAN will remain the same with none of the additional data (i.e. it will continue to just be a flat list of legs with limited procedure support, etc).

Yes, we will be updating the documentation with the EFB PLN file format in the coming weeks. It looks mostly like the previous format.

The name (id attribute) property was always intended to just be a slightly longer human readable identifier for a waypoint. It was never intended or indeed designed to hold data or commentary, so should not be used for this purpose even in MSFS 2020. Even if that is technically functional now, that is definitely not guaranteed by the contract of that data structure.

Maybe a more thorough description of what kind of data needs to be held in the plan for this glider tasks use case would spur some more ideas on our end as to how this could be supported in a more first-class way.

Thanks,
Matt

2 Likes
14

thanks - the key point is it’s unrealistic to hardcode into a file specification every data field that might be needed for every aviation use-case. For gliding:

The flightplan can have these attributes

  1. title
  2. (optional) HH:MM minimum duration

Each waypoint can have these attributes (assume the departure, destination airports as 1st and last wp’s):

  1. lat/long
  2. elevation (of the ground at the waypoint)
  3. name (e.g. “Six Mile Bottom” or “Mifflin Start A”
  4. (optional) ICAO if it’s an airport
  5. (optional) radius
  6. a flag to say this wp is the ‘start’ or ‘finish’ of the task
  7. a flag to say if it’s an Assigned Area Task waypoint
  8. (optional for departure, arrival airports) a runway identifier

We have TWO issues with the current flightplan system:

(1) The XML file format assumes only some fixed fields with no flexibility for optional additional data

(2) The MSFS ‘flightplan load’ is only very loosely connected to any available API call inside the sim, e.g. the elevation of the waypoint (essential for gliding) inside the PLN ‘WorldPosition’ field is discarded, and the API’s provide a completely different altitude figure instead. The ONLY data reliably communicated from the PLN file through to the in-game API’s are

  • user waypoint lat/long
  • user waypoint name

Although clunky, this MSFS2020 support has enabled us to create very successful multiplayer gliding tasks with up to 40 pilots flying together. We’ve accumulated over 500 of these ‘tasks’ since MSFS2020 went live. Hack though it is, the fact MSFS2020 does NOT try and mangle the name before passing it to the API’s is the saving feature of this fairly awful support for the XML files and we can encode information into the name e.g. in “*Mifflin Start A+825” the asterisk indicates this WP is a ‘start’ or ‘finish’, and the “+825” is the elevation of the ground at Mifflin.

The ‘Plan B’ we’re considering if MSFS2024 simply doesn’t have the support we need for gliding tasks is to continue the use of PLN files but load them directly into the html/js of the nav gauges bypassing MSFS completely. TBH the html/js is perfectly capable of reading/parsing the XML files. Getting that information before it gets totally mangled by MSFS would make life infinitely easier.

1 Like
15

Just for you guys to know
 we are currently using the c:fs9gps variables in a number of cases, mostly on our IndiaFoxtEcho F-35 and F-14 projects, through XML scripts.
I guess this means those scripts will not work on MSFS2024
 and systems may need to be rewritten.

In F-14 Tomcat:
The F-14 features a completely custom navigation system which mimics (quite closely) the real one. C:fs9gps variables are used for three things:

  • load MSFS waypoints, if a flight plan exists, into the custom variables (in case the player has created a flight plan via the game interface)
  • generate radar track and navaids via Geocalc to plot them on the TDI
  • simulate INS error accumulation (by reading data from flight plan, adding error and plot on the TDI, and add error on top of Geocalc above)

In the F-35, the c:fs9gps variables are used to

  • generate location of items (such as Link16 and radar tracks) for the TDI, via Geocalc variables
  • generate simple direct-to flightplans and edit/remove waypoints

Removal of c:fs9gps variables implies that both the MSFS2020 F-14 and F-35 will not be compatible with MSFS2024.

16

I’d like to suggest an additional point, noting Matt’s reference to ‘routes from the EFP’ in the API and no mention of ‘data from the flightplan’, ultimately in the hope that the EFP adds value rather than constrains flightplan use to a particular use case.

EFP routes are meaningless for gliding, that’s fine if the original flightplan info is still available. But it’s an issue if the ‘EFP route’ becomes the only info served in the sim.

17

To return to the original subject, I don’t think an API should be removed without first warning users.
The correct solution would be to keep the API, mark it as “deprecated” in the documentation (with necessary warnings about stability or other drawbacks), and propose a replacement solution that covers the entirety of this API.
Backward compatibility should be systematically ensured where possible.

2 Likes
18

I agree.

These changes (in this thread) are nav-related. Here’s a couple of MSFS2020 Nav API items in case either of those require ‘warnings’:

Underneath all this the baseline concept is there’s a PLN file, and simconnect has OnRecvEventFilename with SIMEVENT_ID.FlightPlanActivated. Those represent the ultimate backstop keeping the data in the FlightPlan relatively open and accessible so it’s definitely in the nav “API” category that shouldn’t be removed without first warning users.

We need to include the Coherent.call(“GET_FLIGHTPLAN”) in this category as it’s referred to in this thread as “legacy” which sounds ominous but I’m not sure that’s a warning.

1 Like
19

I think this may be where some misunderstanding lies. In every version of Flight Simulator, going back decades, the PLN file itself is not something that is loaded into memory at all. The fact that it is XML is merely to provide an easy to generate (for third parties) serialization format for the fixed flight plan data structure in the sim and does not by the fact that it is XML imply anything about its extensibility.

As such the simulator (and we’re talking going back to I think FS2004 or even earlier) has always completely discarded the content of the PLN file immediately after deserializing it into the internal fixed flight plan data structure. The PLN file is not really the backbone of the system, the fixed flight plan data structure is, and a PLN file is merely a serialization of that that happens to be XML.

This is why, in all those versions of FS, data that you put into the PLN file can end up different if you save it again: the pilot flight plan is shared by ATC and other internal systems and any sanitization (or logic otherwise) of altitudes, waypoints, etc done by internal systems alters this fixed flight plan data structure. When the pilot asks to save the PLN, they are not getting the PLN file they put in, they’re getting the flight plan struct serialized into XML again, and all of this is and always has been definitely by design. It’s just a serialization format.

In the same vein, the new EFB PLN XML is also just a convenient serialization format for a slightly more comprehensive and ICAO standards compliant flight plan route structure used by the EFB. The PLN file itself is not retained after it is deserialized into the route, in the same way that it is not for the non-EFB format.

Also in the same vein, GET_FLIGHTPLAN does not (in MSFS 2020 or MSFS 2024) read the PLN file. It simply serializes the pilot assigned ATC fixed flight plan structure that is used and shared by all the internal sim systems into a Javascript object. That is why you may get different data exactly than you put into the PLN file, for the same reasons outlined above.

In MSFS 2024, we have separated the pilot flight plan layer from the ATC flight plan layer. In all previous versions of FS the pilot flight plan was identical to the ATC flight plan; there was just one “flight plan” for all systems. To add a much more realistic flow, the player flight plan must be filed with ATC (via the EFB, like you might do in Foreflight) in order for ATC to receive it. ATC will no longer magically receive updates as they did in the past from MSFS 2024 avionics.

However, to maintain backwards compatibility with the MSFS 2020 JS API, the GET_FLIGHTPLAN call will continue to return the pilot/ATC flight plan as it has before, and using the other calls from JS_LISTENER_FLIGHTPLAN to update the plan will also operate as before (directly into the pilot/ATC flight plan). These legacy APIs should be considered deprecated and will not interact with the pilot’s EFB route in any way.

Hope that helps,
-Matt

2 Likes
20

Obviously the PLN file is a common data exchange between the various flight planning apps and ultimately with the sim. Up until now we’ve been able to programmatically get access to that file (via simconnect) and access to each waypoint lat, long and name via simvars and more recently the GET_FLIGHTPLAN call. If your long explanation above means any of that is going to change in MSFS2024 it would be good to have those changes spelled out.

21

Hi Matt,

Thanks for the insight, so to ensure compatibility with our MSFS 2020 airplanes until we can fully convert to MSFS 2024 standards (which will take months for each product) what is the advice? tell the users to load the FP from main menu so it goes to both the MSFS default EFB and the aircraft avionics V1?

I see an issue for my FSR500 here, where I was supporting SimBrieft flight plans imports via my own EFB or NaviGraph plugins and sending this FP to the G1000 (in this case a V1 in MSFS 2024). My current code inside MSFS 2020 sends this FP also to ATC so the user can do all it requires from the tarmac. (Teste in MSFS 2024, all works except of course communicating with the EFB)

As I understand so far, Market Place will only receive 2020 compiled projects and push these towards MSFS 2020 MP and MSFS 2024 as backward compatible simultaneously, however we cannot say please take this 2020 compiled aircraft project with this small modification and only send it towards MSFS 2024 but NOT MSFS 2020. This presents a problem in a way because we cannot update our custom avionics, panels, etc. to work with the MSFS EFB 2024 and the ATC as you explain) unless we proceed to fully convert.

So the upshot is, we are unable to send custom patches for a backwards compatible aircraft via market place to make it compatible with the MS EFB / ATC, so the question is what we do in the meantime so customers that receive our MSFS 2020 backward compatible mode products can use them inside MSFS 2024 and be able to use the ATC, etc.

Thanks for your insight on these matters as it will help us to communicate with our customers in relation to what to do, etc.

All the best,
Raul