New incompatible PLN file format for EFB?

[MSFS 2020] Questions & Community Discussions
1

I’ve just discovered the EFB webapp has invented a new, similar, but incompatible file format but used the SAME suffix as the existing MSFS PLN file. EFB Flight Plan XML (PLN File) Properties

Is it too late to rename that new file format ‘.EFB’ ?

That file even has outer XML objects common to the existing PLN format but with different internal contents, so it’s pretty much a random set of changes to an existing format, given the same name as the old format.

Obviously naming two different file formats with the same suffix is a compatibility mess, with MSFS2024 still using the previous format in some parts of the sim and the EFB format in other parts.

2

They only need to change the extension if there is a breaking change to the XML schema. And there isn’t. It’s an extension.

The changes in what data is populated on saving an PLN file is a different issue and that is very annoying. I’ve not checked to see if it’s any better since last patch. Once I got a good FS24 sample file it only took about 20 minutes to change my exporter and importer code to work with both formats though I don’t use much of the new stuff.

3

I think you need to look at almost any XML element in the PLN file, e.g. ATCWaypoint is probably the most canonical for a flightplan. Write out a waypoint using the MSFS2020 spec, do the same thing using the EFB spec. In some places the same Element name is used but the contents are different. Sometimes required content in the MSFS2020 PLN is missing from the MSFS2024 content. WorldPosition has disappeared in the EFB PLN format so how would you even know the lat/long of waypoints? A new element WorldLocation has appeared in the the EFB format which looks identical to the 2020 WorldPosition - what’s that all about, is that a typo? The Id attribute of “User” waypoints is on the ATCWaypoint element in the MSFS2020 format but it’s on the ATCWaypointType element inside the same ATCWaypoint element in the EFB format. That’s not an ‘extension’, no MSFS2020 program or 2024 mission could pick up any data from that file at all, even though it mostly has the same data that was in the original PLN format.

So in a nutshell you could throw a dart into the EFB PLN format and find “a breaking change” from the 2024 mission/2020 PLN format.

4

Well I’d say the two are distinct versions
EFB_ContentModel.pdf (296.0 KB)
ATC_ContentModel.pdf (237.8 KB)

I created the xsd for both from SDK DOC
https://docs.flightsimulator.com/msfs2024/html/5_Content_Configuration/Mission_XML_Files/Flight_Plan_XML_Properties.htm

In the attached docs you may see the very different exposure of a Flightplan and in the SDK DOC the mentioned purposes of each

While doing it I found some inconsistencies in the ‘old’ ATC format vs. Spec and many in the new EFB format vs. spec, actually the EFB does not import a Plan according the SDK doc (hence I patched the EFB Waypoint with WorldPosition which does not exist in the spec) but it will not validate any exported plan.

I.e. right now the xsd is unusable due to the many EFB import and export issues (BUGs… they are :slight_smile: ) Would be nice to a) have the XSD from Asobo but b) at least a word what the future holds - change of spec or change of code or both??

If someone wants the XSDs just let me know.

5

The ‘EFB’ format is absolutely obviously just a file someone started creating after making random edits to the previous PLN format so the new content matches some idea of how the EFB webapp might like to read it.

There’s not a huge excuse for it as almost all the actual data content is the same in the two formats, just tag names and structural positions of some items have been moved around.

Where it went seriously off-piste was to re-use fundamental identifiers, like the ‘PLN’ for the suffix and <FlightPlan.FlightPlan> for the outermost XML element. That introduces a fundamental issue to all software processing PLN files needing to somehow work out which version they’ve been given (e.g. 3rd-party planning apps, simconnect flight loggers, mission utilities). Of course all this software could be re-programmed to spot when they’ve been given the EFB-format file but common sense would have been to plan for that.

Hence the practical suggestion at this stage to adopt an ‘EFB’ extension for the new file.

6

Only if you take a very restrictive view of what a flight plan is (i.e. just a set of ATCWaypoint elements for glider tasks). The rest of the existing format was not really suitable to an ICAO standards-based flight plan, which needs more concrete information about procedures, proper and guaranteed facilities, what type of waypoints each leg is, etc.

It really has nothing to do with any dependency to the EFB application. In fact, the dependency is in the reverse: the PLN file was revised to more match a proper standards-based flight plan that could be filed in the real world, and thus be much more agnostic to the purpose (instead of looking like just a serialized version of some random internal data structure, which it was) therefore making it more suitable for more consumers (other planners like SimBrief, Navigraph, LNM, and the like); it was the EFB planner application that was built to support such a featureset.

Having a much better ability to read and write selected procedures as well as have some guarantees about waypoint type and facility existence is a huge benefit towards eliminating the hacks (which often varied from app to app) necessary in the previous format to convey the same information, and brings the whole ecosystem much closer together. We’ve seen consumers like SimBrief and Navigraph rapidly bring their customers the ability to read and write this new format with limited issue.

It would be good to have a more concrete list of the issues encountered so we can check if they are bugs in the code or bugs in the documentation. One that we also spotted recently and will be updating in the documentation is the typo of WorldLocation, which should be WorldPosition, as in the previous spec.

PLN files under the 2020 spec (which was, incidental to this conversation, different from the FSX spec) should load just fine into the EFB, as the ATCWaypoint element is compatible. I’m not sure where you’re seeing Id under ATCWaypointType, but that is not the spec, either in the 2020 spec or in the 2024 EFB spec.

The sim version is provided in all PLN files.

Thanks,
Matt

7

The Id on the WaypointType is in the EFB PLN docs:

image
image941×760 52.4 KB

If the WaypointLocation is a typo for WaypointPosition then that fixes that issue.

With those fixes maybe we end up with compatible PLN’s, I haven’t done that diligence based on this update.

The Working Title model “we have exclusive access to the PLN load button, and exclusive access to the data that was contained in the PLN, you tell us what you want to use the information for, and what data you’d prefer us not to change before we give it to you, and we’ll think about programming that” is just too much to rely on. Meanwhile our 2000-member multiplayer gliding community is keen to fly in MSFS2024 and that was held up waiting to see whether our ‘requirement’ (access to unaltered PLN data) was ever going to be addressed.

We’ve implemented an API to load/serve the PLN data (gauges or apps can request it as XML, JSON or the FAI IGC format), notify of a new flightplan, and that data is exchanged by the gauges and an ecosystem of external applications. So it’s not ideal, but at least we’ve started our multiplayer flying in MSFS2024.

8

Yeah, that seems like a typo that crept in there at some point in the docs transfer process. The Id attribute is in the same location as it has always been, and should not be indicated here on ATCWaypointType.

I don’t understand what you mean by exclusive access, was there some non-exclusive access that was available in MSFS 2020? In 2020 no third party developer had any access to the PLN load button any more than they do now, so I’m not following or understanding this. We’re not holding this effort hostage, we’re simply trying to understand the requirements, just like any other piece of software.

It’s hard to keep repeating the same facts over and over, which is that even previously in 2020 the PLN file was not directly read by any of the APIs about which you are complaining. They all parsed the file, read it into a structure in memory, discard the file entirely, made decisions about that data, and re-serialized using totally different set of code for each API.

It seems that your mental model of this is that each API reads right from the PLN XML, and that the only thing “loading” a PLN does is tell the sim where the file is. But that’s just completely incorrect. There have always been 5-10 layers of code that transform the data at each step from loading to sending out via a different API. And the primary complaint is that we’ve broken this direct PLN file reading which never existed at all in the first place.

Instead of blocking you all, we took special time during crunch to try to address your concerns with the Id and other fields so that we could try to continue to allow the custom formatted data hacks survive from end to end through all these 5-10 processing layers into that field that are used by this glider tasks process.

Now, it sounds like perhaps there are still some issues preventing this from working end to end for some users, to which we are happy to help identify but it is also difficult to break through what feels like an excessively antagonistic and unhelpful tone in each of these topics.

Thanks,
Matt

1 Like
9

Simconnect FlightPlanActivated gave access to the original PLN data -that no longer fires. GET_FLIGHTPLAN was a reasonably transparent conversion of the XML to JSON, as you know stripping ident out of that and re-writing the ICAO codes removed the only string we had access to leaving only the lat/long of each waypoint which is not enough for any use other than those that only need the lat long. The EFB routeplan api is hit-and-miss whether it serves all the waypoints or only the first and last. The EFB webapp is choosing the wrong departure runway when you load a PLN - if you change that runway on the World Map the internal flightplan seems to get thown away and you’re left with only the start airport in the api’s - this alone is a blocker on gliding tasks where the aerotow won’t work if you’re on the wrong runway.

This isn’t intended as antagonistic, hopefully it’s straightforwardly factual. I understand you want clarity on ‘just tell me the issues’ (that’s why I drafted the para above, I hope that’s not mistaken for antagonistic) but trying to work out what is “by design” vs. a “typo” vs. “we’ll fix that” take a huge amount of time that feels like free beta-testing issues that are pretty fundamental.

10

Here you are:

An EFB using Cruiselevel FL exports as 100* FL*100 (spec is ft not ft/100)

An EFB using Cruiselevel FT exports as FT*100 (spec is ft not ft/100)

An EFB using Cruiselevel FT export and import will revert to FL not FT

An EFB using a GPS approach does not export GPS for GPS approach

An EFB using a VFR Pattern approach does export not complete and mostly wrong
Wrong FPType - should be VFR
Same wrong type is true for the WASM retrieved type

ApproachVisualPattern does not represent the selected approach
ApproachVisualPatternType is wrong
ApproachDetails is missing element

An EFB using a generic VOR e.g. VOR A approach does not export runway selected by the user

An EFB using a Bearing Distance Waypoint does not export this waypoint

An EFB Approach to a runway using a visual pattern does not export the specifically selected pattern
Details are missing in the ApproachVisualPattern element
Same for the Departure.

An EFB Approach to a runway using a visual pattern does not export the landing runway in ApproachDetails element
where other procedure exports include the Runway

An EFB does not import a PLN at all if using the ICAO WorldLocation element

An EFB does not maintain the imported Id Attribute of Waypoint Type anywhere

for some I have screeshots taken but not attached.

BTW I did not specifially test the EFB, the only intent was to get a variety of examples…

Would it be an idea for a test case to ask for:

  • enter a flight plan A)
  • export the plan as V1, verify the data against the GUI
  • import the plan and verify the GUI agains the prev. GUI
  • export the plan as V2 and compare V1 and V2 - must be identical else it’s a failed test case

Automated testcase: from repository import PLN, export PLN(V2), import PLN(V2), export PLN(V3) compare (all 3 must match else = failed)

Have a repository of plans covering seldom used scenarios (usually the often used ones have been checked by the dev and mostly work…)
And well - have a spec that is formal i.e. an XSD for XML everything else is considered as a rumor…

Sorry if beeing too bold it is meant to help - my 20+ years as SW project leader cannot hold back

1 Like
11

I think these might be issues on the EFB itself but we can investigate.

Do you have an example approach? I can’t reproduce this here, and there are also many approaches for which GPS is no longer the nomenclature or which can be RNAV or GPS depending on the data source.

The filed flight plan type is not related to the approach type selected, since in real life you don’t generally file the approach itself. The VFR/IFR switch on the flight plan details page is what determines this value, not the approach type.

Not correct per the spec? What values are you seeing here instead?

A circling approach won’t (and shouldn’t) have a runway in ApproachDetails. Are you saying the user selected runway also isn’t in ArrivalRunway?

These are typos in the docs. ATCWaypoint and WorldPosition (not WorldLocation) work the same as in the previous PLN format.

The current documentation is intended to be the spec.

Thanks,
Matt

1 Like
12

Nobody is asking anyone to work out which category these items are. We’re just asking for what the face-value problems and expected outputs are so we can identify the category ourselves and provide either the appropriate guidance or log the issues for investigation.

While I am sympathetic, as a developer from the community myself, the problem with this attitude is that it just isn’t realistic or pragmatic. You’re totally within your right to draw a line in the sand and just say “it’s busted, it’s your job to figure out all the ways and I’m not going to do that for you”, but it isn’t like WT is a massive team with tens of people just on this one very deep area (the edges of the PLN data survival through all the various in-code transforms, inherited and new). The sim is a massive product with enough code just in the base sim to cover an entire operating system and code in aircraft and SDKs that could fill a normal size indie game each, and unlimited resources can’t just be put on every part of it all the time; so that’s why it is especially helpful (and honestly I would argue critical) to get clear repro cases and expected results for those so that everything can be properly identified, triaged, and ultimately fixed, if necessary.

Thanks,
Matt

1 Like
13

ToMSDEV-EFBissues-20250113.zip (1.2 MB)

Attached a zip with the details I collected

“The VFR/IFR switch on the flight plan details page”
?? did not find this page so far. How to get there?
Was naively assuming to get VFR because the Approach is written as VFR Pattern as I could not find a switch to change it myself…

“Are you saying the user selected runway also isn’t in ArrivalRunway?”
I did not select an Arrival, and btw. was not asking to see it in the Approach either.
As there is no dest runway element anymore it got lost - The WASM FPlan has this as

FsRunwayIdentifier destinationRunway;

Re VFR pattern - below create, export, import

VFRPatIssue-20250113.zip (566.8 KB)

got from RW26L R CROSS AUTO export
to RW08 FINAL after importing the plan

“The current documentation is intended to be the spec.”
How would one implement the spec if it has typos??

14

IMHO it is not about wt and your team you just happend to be frontrunner - but the sim is a released product and payed for and the EFB was heavily marketed as feature. So expectations are obviously high and since at least I assumed we get what we had (with 2020 and also payed for) + more there is some disappointment when things go south in one area.
I remember times where ‘MS’ had a guidance ‘is it good enough’ don’t know if this still holds true - but the EFB implementation and integration including the topics discussed here - for me it feels not good enough.

1 Like
15

What is very frustrating is that you can’t open or import an existing MSFS Flight Plan into the EFB from the EFB user interface. Yo can’t chose where the PLN file is located either.

So, all these flight plans you have created over the years using MSFS, LittleNavMap, or other tools have to be recreated using the EFB UI.

16

That is not correct. Using the LOAD/SAVE PLN button at the bottom of the route page, you can load a PLN file. A dialog will appear that allows you to select the location of your PLN file.

The LOAD FLIGHT PLAN button at the top of the route page is for loading a cloud saved route. I would say that the text there could be better labeled to make it less confusing for the user.

Thanks,
Matt

17

Thanks for the correction. It is much appreciated.

18

Alex Albar of Little Nav Map now has a Beta Build that can export FS’24 specific plans. In fact, you’ll now see distinct options to export to either '20 or '24.

That being said, two things the EFB can modify without your intervention are (note I’m specifically calling out the EFB which is built by Asobo, vs the Flight Planner Code which is by Working Title): Cruise Altitude and Departure / Arrival Procedures - when Importing an FS’24 compatible plan.

So my recommendation is to operate just like you did when Importing FPLs into FS’20 World Map.

  1. Pick your Origin Airport and starting position in the World Map screen BEFORE you LOAD the plan using the EFB.
  2. Load the .PLN.
  3. Triple-check the following: start position in the planning screen, the cruise level in planning tab, the procedures in the planning tab - I recommend setting them to Direct if not already, and the IFR/VFR setting in the other tab.
  4. I have found the Cruise level can revert to a different level even just switching tabs, so type in the value again if this is the case and hit Enter or click outside that value box.
  5. Not that I know any better, but when you click on Send to ATC, wait for the button to turn back to white (it seems to gray out while processing). Then repeat for Send plan to Avionics.

I tend to wait until I’m in cockpit to hear the ATIS and determine the best SID, hence the recommendation to set it to Direct. Same thing for Arrivals, I can pick up ATIS within 40NM of Destination all things being equal. I amend the plan in the avionics as needed to add SID/STARs. But that just me.

Oddities observed:

Planner has you specify a runway. Ideally, that runway should change based on local WX and ATIS (which could vary if you’re using Live vs Preset), but the plan tends to enforce that specific runway even with ATC Plan Enforce = Off in sim Settings.

if plan was properly imported, ATC will simply clear you to cruise, no Step Climbs. That’s an ATC problem, but worth calling out.

Speaking of Cruise Altitudes, be aware that there is a strict enforcement of IFR/RVSM altitude levels based on initial legs (?), so I tend to exercise caution and file for 1000-2000 feet lower than planned or service ceiling, as I’ve been burned by ATC telling me to go to higher when everything in the plan including initial legs points to my proposed cruise altitude is valid based on heading/height.

I already logged all of them as Zendesk Tickets.

1 Like
19

Two quick comments here:

(1) I’m not sure the PLN is currently influencing the runway in MSFS2024. It seems the runway is ‘enforced’ but I suspect that is the EFB app ignoring the runway in the PLN and choosing a runway itself, possibly simply the top one in the select list it generates. I.e. it seems to be a bug in that EFB app choosing a runway to be ‘sent’ to ATC, regardless of the setting of the “ATC Plan Enforce = On|Off” user settings in MSFS2024, or the departure runway in the PLN. To be clear, this (counter-intuitively) may be nothing to do with the sim selecting a runway based on wind direction, i.e. it could be a bug related to the EFB app UI populating the runway with the one at the the top of its ‘runway select list’ if there’s no explicit user selection in that app.

(2) There are definitely use-cases where we DO want the sim to accept whatever runway we have put into the PLN file, so the setting to ‘enforce’ use of the runway in the PLN remains important. Gliding is a well-established use-case where we distribute common tasks as a PLN plus a WPR preset for use in solo or multiplayer and it’s crucial the runway in the PLN is respected. Where we might be unclear exactly what the bug is in (1) above, it is certain this ‘enforce’ option is not working, i.e. the ‘enforce ATC to use runway in PLN’ option definitely will not ensure the departure runway in the sim will be set to that runway. The runway we get instead seems to be random rather than into-wind. A bug report for that has been submitted.