Bug description: The flight plan files saved by MSFS 2024 have changed compared to the legacy format. The cruise altitude is wrong (for example, 1.3 million feet when flying from Munich to Rome), the departure and destination airports are not in the Waypoint List and all Waypoints are missing the geographical location data (WorldPosition). This makes it impossible to use these files in apps that want to do GIS related processing.
Repro steps: Generate a flight plan on the EFB and save it to disk
That definitely sounds like either a PLN serializer bug or a bug with the EFB planner app itself.
They are now in their own elements, to separate them from the enroute segment of the plan, as in a proper ICAO standards flight plan.
Waypoints that are navigational data facilities will not include positions any longer in the new format. The issue with including positions is that these locations can shift over time, and thus create a problem in which the data can therefore be bad or in conflict with itself (the file indicates a fixed facility but in a different location than it currently is in the navdata), and it isn’t clear the intention of the PLN file.
As such, only custom lat/lon waypoints will include this WorldPosition element. If you need the locations of navigational facilities, you should look them up with the JS or SimConnect facility API (or otherwise reconcile them with your own nav database if that’s how the program works) to get their current positions.
as far as I know, the facilities and waypoint IDs themselves can change over time, as do the procedures. A .pln file can always only be a snapshot of a certain point in time. I don’t see the point why they shouldn’t have geo coordinates. If MSFS expects trouble with the coordinates, it could just ignore them when a PLN file is imported.
Traditionally, PLN files were used (by me at least) as a medium of transferring routes between the sim and other apps. These other apps (like flight planners or ATC) don’t necessarily have access to SimConnect and the scenery API. Now the pln files are nothing more than a MSFS internal asset and can only be used for this one purpose - from my point of view that is a real loss of inter-app functionality.
They don’t need access to either of those, as long as they have access to some nav data (which pretty much any ATC or flight planning system must have). The sim ICAO identifiers are the same structurally as the identifiers in standard ARINC data, in that they identify the type of the facility, the region the facility is in (matching the ARINC region codes), any associated airport, and the alphanumeric ID.
There’s nothing proprietary or modified about those identifiers that make them unique to MSFS; in fact, given any standard nav data you can quite trivially use these identifiers to look up those facilities and get their locations.
Doing it the way we’ve done it now improves transferability between applications, because each application can easily look up the location of the facility in its native navigational database as opposed to having to rely on the provided location.
But that was actually the benefit - because one could rely on the data being exactly the same as in the sim. Imagine for example an app that wants to display your current flight in Google Earth. In the old days, you just exported the flight plan, parsed the geo data out of it and built a KMZ from that. Now this same app effectively has to export the flight plan, then parse the procedures and the waypoints, query all that from the scenery API, and only when all these queries and subqueries from queries are complete, it can think about building the target format.
I’m sorry, but I find it really hard to see this as an improvement. Not that this should concern you, I just wanted to voice my feelings about this new logic. I can work with it of course, but it has made a very simple task massively complicated. Which as a programmer I can’t really appreciate, sorry.
I won’t pretend to be an expert on this, but isn’t a flight plan only valid inside the AIRAC cycle that it was made for? And that the waypoints are static inside the same cycle? It feels like this should be the case, so all associated actors (flight planning to FMC) are on the same page?
I’ve taken a look at the SU3 format of the PLN file for an IFR flight plan. The cruising altitude has been fixed, it reads the correct number of feet.
The rest is the same as before, the waypoint list no longer includes the airports, and none of the waypoints has lat/lon/alt information. From my point of view, this should at least contain the AIRAC cycle number that the plan was made for. Or the entire route with all waypoints, with lat/lon/alt and no procedures or anything.
The way the file is now, it is unusable in any other app than a SimConnect client that is directly connected to the sim. I still can’t see where this is an improvement over the format that we’ve become used to over at least 25(?) years.
There are three things you can do (we do them all):
(1) You can extract nav information from the sim - easiest is have Little NavMap do the heavy lifting (credit our hero Alex). For our purposes we need all the airports & runways (but not the navaids) and that can end up as a modest ~7MB data structure in javascript indexed for very fast access both by lat/long and icao. Not ideal but it’s a game changer if you’ve got it.
(2) Create a PLN creation app (i.e. flight planner) that everyone is going to use so you can control what goes into the PLN file, and store everything in the file as “User” waypoints. I understand this is more than you’d expect to have to do to get the info you need into the PLN but given the EFB format your options are limited. We have a well coordinated community of glider pilots that makes that workable.
(3) - this doesn’t directly address the EFB format lack of latl/ong issues, but it makes life a lot easier if you do - create a Windows exe you can drop the PLN onto (which can then support both 2020 and EFB-format PLN files) and serve that data (as XML or JSON) directly to your html.js or WASM package over a http API. That exe can also be a simconnect app which adds a lot of options. Drastic though this sounds, our multiplayer gliding would be dead in the water without it.
The sim is designed to be moddable - for that we generally need reliable file formats and API’s but that’s been tricky with regard to nav since the MSFS2024 launch. I guess all the options above seem drastic, but that’s what we needed to do.