MSFS2024 GET_FLIGHTPLAN waypoints ident / lat / long

B21 · November 23, 2024, 3:32pm

Version: 1.0.7.0

Frequency: Consistently

Severity: Blocker

Marketplace package name: All of the gliders in the sim

Context:

Similar MSFS 2020 issue: MSFS2020 is ok
Bug description:
GET_FLIGHTPLAN data changed in MSFS2024 vs 2020

Repro steps:

UI Load flightplan … Coherent.call(GET_FLIGHTPLAN), only data left from the waypoints in the PLN is the lat/longs.

Background - WT have already been supportive here, which is appreciated:
As discussed on the runup to launch, JS GET_FLIGHTPLAN in MSFS2024 returns a similar JS object to MSFS2020 but the data available for each waypoint after a PLN flightplan load in MSFS2020 was { ident, lat, long } and in MSFS2024 that has shrunk to { lat, long } with a new random ident being generated and the one from the PLN file discarded

We have a lot of glider pilots now with MSFS2024 and need a more concrete confirmation whether/when MSFS2024 might be fixed to provide that “ident” (or another string) that can be passed for each waypoint through from the PLN to the GET_FLIGHTPLAN JS call (or indeed another new call that can be made from JAVASCRIPT)

We can’t migrate 10’s of thousands of lines of JS Nav Panel gauge code to the WT typescript just to read the data from a loaded PLN (I don’t think the idents are the WT info anyway) and our community is already moving quickly to run those html/js gauges OUTSIDE of the sim just so the PLN can be dropped there instead of used in the sim.

Key issue:

We need this either flagged up as “by design” in which case we’ll pivot to providing alternative support for gliding flightplans outside the sim, or have some confirmation the waypoint “ident” or an alternative string can propagated from the PLN to JS gauge as was the case in MSFS2020.

B21 · November 28, 2024, 8:24am

More detail on the EFB app / JS GET_FLIGHTPLAN issues, in summary the EFB app is omitting waypoints in that JS return, nothing to do with our attempt to use the waypoint ident field for gliding.

Step 1. Load this sample PLN file containing departure airport, 5 user waypoints, destination airport (remove the .xml suffix added just to post here)

North Weald Test MSFS2024 icao.pln.xml (2.6 KB)

Step 2. See the waypoints in the EFB app, as screenshot, all 5 intermediate user waypoints are correctly listed. These are custom lat/long “User” waypoints with “ICAO” values each set to 8 letters (Obviously custom lat/long waypoints don’t actually have internationally assigned ICAO codes)

Step 3. Click the “File Plan with ATC button” & close the EFB App. See the flightplan on the world map still showing all 5 user waypoints.

Step 4. Start the flight, use the Coherent console to look at the JS Coherent.call(“GET_FLIGHTPLAN”) return, which only has the first and last user waypoints in the ‘waypoints’ array:

Please note the GET_FLIGHTPLAN API return only contains TWO waypoints, not the original FIVE so it’s currently not a viable source for the flightplan info.

As mentioned above the most important thing for us is to confirm whether this is “By Design” or “Bug Logged” so we can plan accordingly.

B21 · February 17, 2025, 9:47am

Darn - I just posted this in the wrong thread, so deleted/copied here…

Update as of Sim Update 1 Beta currently:

Summary: “User” waypoints loaded from a PLN (EFB format or MSFS2020 format) are being displayed in the EFB app, but some of those waypoints (e.g. 2nd, 3rd and last) are missing in the “GET_FLIGHTPLAN” API call. The wp name/id is being passed ok for those waypoints that make it through to the API.

Test “EFB format” PLN file attached below. Departure/Arrival airports plus mix of 7 “User” waypoints. For the purposes of testing I’ve included “User” waypoints actually matching the departure/arrival airport locations simply because I suspect if the MSFS2024 code wants to delete waypoints for some reason, that would be the likely choice. I would strongly suggest if the waypoint is a “User” waypoint, MSFS should never delete that waypoint, I just can’t see any rationale where the sim code would know better. However, if somehow there is a rationale for MSFS2024 deleting “User” waypoints hopefully that can be documented and consistent.

The PLN (listed below) is essentially:

LIDB        -- Departure Airport, Runway 22
Belluno     -- User waypoint
Start       -- User waypoint
WP1         -- User waypoint
WP2         -- User waypoint
WP3         -- User waypoint
Finish      -- User waypoint
Belluno     -- User waypoint
LIDB        -- Destination airport

The waypoints make it as far as the EFB UI, including the name:

But then seemingly random waypoints from that set are missing from the GET_FLIGHTPLAN waypoints structure, e.g. given the example above the current SU1 waypoints list served by GET_FLIGHTPLAN are:

LIDB
Belluno
WP2
WP3
LIDB

I.e. waypoints “WP1” and “Finish” have disappeared and also (but less critically) the extra User waypoint added for the arrival airports. An example successful output could be:

LIDB
Belluno
Start
WP1
WP2
WP3
Finish
Belluno
LIDB

Note the ‘duplicate’ waypoints for the Departure/Arrival in MSFS2020 are always “Airport” waypoints so it’s possible to differentiate there if needed. However my example PLN in ‘EFB format’ (I cut and paste from the SDK docs and added my best guess at “User” waypoints) so I suspect any waypoints being deleted is not as intended.

I’ve tried to keep the PLN structure as simple as possible, a constraint is the documentation for the new EFB PLN format is not updated since the typos were acknowledged. I’ve tried the EFB format with or without ‘User’ waypoints matching the start/end airport which is convenient for our use case, but that makes no difference to intermediate “User” waypoints missing in the GET_FLIGHTPLAN “waypoints” array API return.

It would be really helpful to have an example PLN file (EFB or otherwise) that should load correctly via the EFB including User waypoints, as it’s always possible I’ve guessed the EFB format wrong.

I’ve done a lot of tests and they’re all showing the same issue, but the PLN matching the comments above is :

<SimBase.Document>
    <FlightPlan.FlightPlan>
        <DepartureID>LIDB</DepartureID>
        <DestinationID>LIDB</DestinationID>
        <Title>LIDB - LIDB</Title>
        <Descr>Flight from LIDB to LIDB</Descr>
        <FPType>VFR</FPType>
        <CruisingAlt>8000</CruisingAlt>
        <AppVersion>
            <AppVersionMajor>12</AppVersionMajor>
        </AppVersion>
        <DepartureDetails>
            <RunwayNumberFP>22</RunwayNumberFP>
        </DepartureDetails>
        <ATCWaypoint id="Belluno">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 10' 2.00",E12° 14' 52.00",+001240.00</WorldPosition>
        </ATCWaypoint>
        <ATCWaypoint id="Start">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 9' 47.48",E12° 9' 35.92",+001965.00</WorldPosition>
        </ATCWaypoint>
        <ATCWaypoint id="WP 1">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 1' 42.37",E11° 19' 9.65",+003668.00</WorldPosition>
        </ATCWaypoint>
        <ATCWaypoint id="WP 2">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 33' 53.14",E12° 12' 9.18",+007119.00</WorldPosition>
        </ATCWaypoint>
        <ATCWaypoint id="WP 3">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 15' 11.65",E13° 32' 17.69",+001758.53</WorldPosition>
        </ATCWaypoint>
        <ATCWaypoint id="Finish">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 10' 7.97",E12° 15' 34.57",+001158.14</WorldPosition>
        </ATCWaypoint>
        <ATCWaypoint id="Belluno">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 10' 2.00",E12° 14' 52.00",+001240.00</WorldPosition>
        </ATCWaypoint>
    </FlightPlan.FlightPlan>
</SimBase.Document>

MattNischan · February 18, 2025, 4:20pm

@B21

I can’t really see a reason at the moment why this would occur, the full list of waypoints is passed into the ATC flightplan creation code properly. Does MSFS 2020 also have this same issue with an equivalent PLN?

Thanks,
Matt

B21 · February 18, 2025, 5:42pm

MSFS2020 populates the ‘waypoints’ array of the GET_FLIGHTPLAN return with all the ATCWaypoints from the PLN. It doesn’t seem fussy about whether they’re Airport waypoints or User, and as the User waypoint is more convenient for our requirement we exclusively use those. I guess that’s as would be expected - certainly we’ve relied upon it routinely to load our complete tasks into a variety of nav panels. GET_FLIGHTPLAN has always been a bit of a hybrid between what was in the PLN and the ‘value add’ that the sim code was putting in there (like WP journey time, or estimated altitudes), but FWIW our gauges ignore everything except the original waypoints data. At some point MSFS2020 injected additional new waypoints called TIMECRUIS, TIMEDSCNT, TIMEVERT into that waypoints array but at least that was without deleting any existing waypoints.

It may be that FSX/MSFS2020 PLN/GET_FLIGHTPLAN code is no longer fit for purpose. If there were an alternative in MSFS2024 serving the PLN waypoints info we could pivot to that, the main complexity is working out out which sim you’re in to know which API to call.

bm98 · February 18, 2025, 7:08pm

Just as second opinion…
Imported the latest provided PLN file, then used the WASM PlannedRoute Interface and got the following items reported.
However I did not file with ATC or entered a flight…

Sorry for the strange format, but my WASM is reporting CSV strings I’ve put into a table with the headers used for the lines for reading
BTW queried the sim about 5 times and reporting was the same.

Could not see immediately an error.

The exported PLN file is close but not exactly representing the input but this might be intentional?

MattNischan · February 18, 2025, 7:18pm

@B21 I think I might see what is going on here.

Per the SDK docs for the EFB PLN, the ICAO element is a required element in AtcWaypoint. Because no ICAO element is provided, one is being autogenerated to fulfill that requirement for each user waypoint, based on the lat/lon of the waypoint. For example, the autogenerated identifier of both the Belluno and Start waypoints is 46N012E. As the list of waypoints is sent into the ATC flightplan, that ATC flightplan generation does some deduplication of successive waypoints with the same identifiers.

So, adding something like this to each waypoint corrects that issue:

<ICAO>
  <ICAOIdent>BELLU</ICAOIdent>
</ICAO>

However, most unfortunately, after addressing that, I have found there is an additional bug within the sim that triggers during conversion to the ATC flightplan that is overwriting these identifiers anyway for user waypoints, so we will need to address that on the sim end, as that still leads to the deduplication.

-Matt

B21 · February 18, 2025, 8:32pm

thanks for the clarification- the docs could do with a bit of an update as there’s no “User” waypoint example given so the use-case for a user-generated ICAO isn’t entirely clear (e.g. how long can they be). We do actually use unique custom ICAO codes on the user waypoints but I removed those in case that would be a cause of trouble. So small detail but those ICAO codes should be passed through ok ?

MattNischan · February 19, 2025, 1:19am

Per the docs, up to 5 characters:

This is a required sub-element of <ICAO> and is the 5 character ICAO identifier for the navigation aid or waypoint.

Yes, they are intended to be (barring the aforementioned bug).

-Matt

B21 · March 7, 2025, 2:04pm

Is there a timescale for a fix? SU1 ? SU2 ?

I’d really recommend the EFB PLN docs get updated coincident with the bugfix - there’s still the major glitches in the docs (like WorldLocation) which also prevent working “per docs” PLN files.

MattNischan · March 7, 2025, 7:59pm

SU1 released yesterday, so probably not that one . We have been looking into it and hope to have a fix for SU2.

Thanks,
Matt

B21 · March 10, 2025, 8:21pm

When you do the work on the PLN load to GET_FLIGHTPLAN API, FYI I think we’ve come across a MSFS2024 meters-to-feet conversion bug in the elevation for User waypoints. It’s a little bit tricky to tell with the current sim because of the mixup of User waypoints in the API.

Loading the MSFS2024 PLN below (I exported a LSZW-to-LSZW plan from the EFB, and added what hopefully is the acceptable 2024 User waypoint format) some WP’s are lost (as expected from the bugs reported) but WP1 is served in the MSFS2024 GET_FLIGHTPLAN API at +10173 feet (i.e. 3101 meters) rather than the +3000 feet in the PLN file. I appreciate this could be due to any reason, not necessarily a units conversion issue.

Note from MSFS2020:

the elevations in the PLN file are in FEET.
the GET_FLIGHTPLAN API has the elevations in METERS.
and there’s a possibility these have got mixed up somehow.

<?xml version="1.0" encoding="UTF-8"?>

<SimBase.Document>
    <FlightPlan.FlightPlan>
        <DepartureID>LSZW</DepartureID>
        <DestinationID>LSZW</DestinationID>
        <Title>LSZW - LSZW</Title>
        <Descr>Flight from LSZW to LSZW</Descr>
        <FPType>IFR</FPType>
        <CruisingAlt>1500.000</CruisingAlt>
        <AppVersion>
            <AppVersionMajor>12</AppVersionMajor>
            <AppVersionMinor>1</AppVersionMinor>
            <AppVersionBuild>282174</AppVersionBuild>
        </AppVersion>
        <DepartureDetails>
            <RunwayNumberFP>14</RunwayNumberFP>
        </DepartureDetails>
        <ATCWaypoint id="WP1">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 39' 31.06",E7° 34' 39.53",+003000.00</WorldPosition>
            <ICAO>
                <ICAOIdent>AAWP1</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ATCWaypoint id="Thun APT User WP">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 45' 12.32",E7° 36' 14.21",+001840.00</WorldPosition>
            <ICAO>
                <ICAOIdent>LSZW</ICAOIdent>
            </ICAO>
        </ATCWaypoint>

        <ATCWaypoint id="WP3">
            <ATCWaypointType>User</ATCWaypointType>
            <WorldPosition>N46° 58' 45.64",E8° 15' 19.32",+005000.00</WorldPosition>
            <ICAO>
                <ICAOIdent>CCWP3</ICAOIdent>
            </ICAO>
        </ATCWaypoint>
        <ArrivalDetails>
            <RunwayNumberFP>14</RunwayNumberFP>
        </ArrivalDetails>
    </FlightPlan.FlightPlan>
</SimBase.Document>

MattNischan · March 19, 2025, 11:27am

Hello,

A fix for this issue and the aforementioned user ident overwriting should be available in the first SU2 beta build, when that lands.

Thanks!
-Matt

B21 · March 20, 2025, 10:16am

Thanks -

FYI I see the EFB PLN docs have been changed to now allow up to 8 chars:

Couple of other issues/queries regarding that EFB PLN spec:

As above the same EFB PLN docs still refer to “WorldLocation” rather than the “WorldPosition” used in MSFS2020 PLN files an MSFS2024 Mission PLN files. Can we confirm if that’s a remaining docs glitch that has slipped through the cracks or a correct requirement for a “per the docs” EFB PLN file?

Also the EFB PLN docs page refers to 5-8 chars for the ICAO but is the minimum-of-5 limit intended? It seems unlikely to be practicable with Heathrow conventionally being “EGLL” or Blairstown USA being “1N7”. The docs have “MEDAN” as the example ICAO code, but AFAIK that’s not an airport code.