Marketplace package name: all gliders in the sim are directly affected, but any custom nav instrument would be affected also. TBH gliding is probably the only aspect of MSFS flying where we rely on fully custom nav support.
Context:
None of these MSFS2020/24 nav API’s are functional in MSFS2024:
Simconnect FlightPlanActivated
Model XML FS9GPS simvars
HTML/JS Coherent.call(“GET_FLIGHTPLAN”)
HTML/JS Coherent.call(“GET_EFB_ROUTE”)
Similar MSFS 2020 issue: the first 3 of those API’s are working as expected, the last API is new for 2024 but seriously buggy so unusable. GET_FLIGHTPLAN was limited in MS2020 but in 2024 it got much worse by dropping the idents and re-writing the ICAO’s.
That’s 100% of the nav API’s in MSFS2024 broken so custom nav panels are impossible unless the only user waypoint information you want from the PLN is just the lat/longs. Any truly custom nav support is going to need all the information from the PLN.
Bug description:
The only remaining API that consistently returns all the waypoints from the flightplan is Coherent.call(“GET_FLIGHTPLAN”) but in 2024 that ONLY returns the lat/longs of each user waypoint, discarding the ident and ICAO, and creating new random ICAO’s.
GET_EFB_ROUTE should work in MSFS2024 but that often only returns the 1st and last waypoint, depending on user. At a guess it’s an asynchronous data race error. Maybe MS/Asobo/WT will only care about this API but that’s unclear. FWIW a planned route for a power plane is of limited use for a glider as it omits important information and includes a lot of irrelevant information so if that’s the only way forward it’ll be useful to know.
Repro steps:
Do some actual testing of those API’s after you’ve loaded a PLN.
Note The big issue here is we’re trapped in a miasma of very non-specific “look at the Avionics Framework” and “typescript is a great language” which doesn’t actually help at all. There’s either a nav API or there isn’t, and currently there isn’t except for the specific EFB → Garmins use case.
If MS/Asobo/WT isn’t going to make any improvements to the nav API’s for 3rd party nav instrument development, please make that clear. E.g. if PLN files are no longer an agreed data format for flightplans, please state that clearly without obfuscation of justification.
If some improvement is going to be made to those nav API’s, can that be spelled out clearly?
It is unclear what fully custom nav support here means. Does that refer only to the overloaded Id attributes that contain data for glider tasks or something else?
Each system in the sim (WT21, Epic 2, UNS-1, Garmin GNS430W/530W, G1000, G3000, G3X Touch, Boeing 747-8, Boeing 787, Boeing 737-Max) is totally a completely custom navigational system, using the new APIs, so it isn’t clear to me what would not be possible to build or what fully custom nav support means.
There’s no intentional change to the behavior of this event, and the flight plan loading goes through the same code as before. However, there may be some unrelated bug preventing this event from being sent, so we can investigate.
There are quite a few FS9GPS simvars. Do you have examples of bug in these that we can look into?
This is actually not an issue with the GET_FLIGHTPLAN API, which doesn’t have any code changes from 2020. However, we do believe that the EFB planner app may be seeing custom user waypoints and then reformatting the identifiers according to its own conventions. It’s something we are looking into as it doesn’t always reproduce.
Do you have a PLN file that reliably reproduces this issue? This is not something we have seen so far during development or testing.
Do you have examples of this glider information that had fields for it supported by the previous APIs that is omitted now? I cannot locate any glider specific fields in the previous PLN spec, nor can I see fields which should not make it to the current APIs.
There is no change in the position of PLN files in the MSFS ecosystem. PLN files are still intended to be used to share aircraft agnostic flight plans between users and software.
Hard to answer this general question without writing an essay
it refers to the gameplay style that someone uses a custom flight planner , perhaps share the PLN with others, loads it into the sim, loads a custom aircraft containing custom gauges. Microsoft can’t predict what custom gauges will use what information from the PLN file. As an example, waypoints have lat, long and elevation in the PLN file. Gliding needs all three of those values, so an API that silently substitutes a different value for the elevation, replacing it with an autopilot suggested height is problematic. Gliding can also uses the ICAO code value on User waypoints to hold the nationally specified turnpoint identifier (the spec allows ICAO codes on User waypoints, but hte sim currenly doesn’t care what they are) but having that substituted is similarly problematic.
It isn’t my intention to argue the value or otherwise of gliding as an aviation sector trying to use the PLN file as a means of distributing gliding tasks to the that sim community. That could be perceived as ‘using it wrong’ and we just need to know when to give up. The ‘ideal’ nav api’s would ADD value to the nav data stream on that PLN → gauges data journey, while leaving the original data still available.
Re FlightPlanActivated - that’s ultimately the canonical callback that does give you 100% of the original data in the PLN. It should fire as soon as the player hits a ‘Load PLN’ button, passing the filepath. That call is crucial to simconnect flight loggers that record the loaded ‘flightplan’ which most of them do, but equally they can typically survive ok if that api doesn’t get fired because they simply miss the flightplan.
Re GET_EFB_ROUTE I’m sorry we don’t have any PLN that reliably reproduces that error but it’s been seen by me and others and it’s intermittent for different people loading the same PLN. From a usage standpoint this is all fairly new and it’s conceivable some other issue is causing that behaviour (which is much better that what initially looks like a really-difficult-to-track-down intermittent issue).
Here’s a possibility, but I’m really not sure: Recently we’ve discovered that the ‘Load PLN File’ ‘Send to ATC’ sequence loads the correct airport into the World Map ‘departure’ but the ‘departure runway’ doesn’t seem to be initialised correctly - it may be the runways list element on the EFB app has some default sort, and the app is defaulting to accept the one at the top of that select list rather than the runway given in the PLN (this causes issues with the rather wind-sensitive aerotow feature in MSFS). Changing the runway on the World Map (i.e. correcting it to the into-wind one) seems to have the effect of resettting the flightplan in some way but that is not visible to the user. When they click Fly, and the nav API is served to the instruments then, the flightplan will be the reset one, not the original.
I really don’t know if the above suggestion is related / causes what appeared to be the ‘intermittent’ flightplan serving isssue, but this runway-reset is quite a recent discovery.