I get this same type of discrepancy between Navigraph flight plan and MSFS.
I don’t do C&D, i.e. no parking.
I have made the plan in Navigraph and loaded in MSFS.
I have made the plan in MSFS and loaded it into Navigraph desktop.
I have simply made a plan in MSFS and used the Navigraph in-game chart.
In all cases, I have differences.
The only thing that is correct is the moving icon in Navigraph - it follows the MSFS actual plan (G1000NXi) but some (many) of the way-points are typically different, especially upon approach.
It took me a long time to realize that something is wrong, not due to me.
I can now reproduce my latest flight with screen captures. if needed.
But since this seems to be a common issue, maybe I should wait until there is a proper synchronization between what Navigraph believes and what MSFS believes…
Thank you
Navigraph Ultimate - MSFS up-to-date 22 Oct 2023.
The very reason I cancelled my subscription, nothing worked for me, just spent hours jumping through hoops trying trying to resolve issues that were not caused by me or my community folder.
Regardless of how or where the plan was created or saved Navigraph simply did not work for me and my aircraft would just wander away from the flight plan as I was about 100 miles out. This was very annoying after a long haul flight.
I’m sticking with the world map in MSFS to create my plans, its not accurate but at least it works in the majority of flights!!
1-KALB-KMHT-ILS-Low.zip (5.3 MB)
Thanks for trying to understand this Richard.
I attach a zip-file with the .pln created using the desktop app.
Also included are 7 screen-captures of the various stages of the flight showing the differences between MSFS and Navigraph.
What seems clear is the MSFS does what it likes with procedures, simply not taking into account what the .pln says, except for departure and arrival airports/runways.
MSFS also added in 2 MANSEQ, one on departure and one before arrival which I had to bypass via Direct-to manually.
In short, MSFS is a mess - I don’t know what Navigraph can do about that.
Good luck in following my sequenced screen-shots and don’t hesitate to ask for clarification.
Not that I understand much
btw, no Parkings were used in this flight.
btw2: I only sent one flight because it seems to show the differences mentioned.
Also, it is such a pain to reload MSFS and document every aspect of every flight…
@NAVData-Richard:
Addendum to previous 1-KALB-KMHT-ILS-Low-by-MSFS.zip (6.4 MB)
KBOS-KMHT:
I attach the same flight as previously, but defined in MSFS instead of NaviGraph.
Although G1000NXi adds a MANSEQ between take-off and SMYTH (yellow on screenshot), I just delete it in G1000 FLP and SMYTH becomes part of the route.
All else seems to correspond between MSFS and Navi-inGame chart (note that inGame Chart shows the MANSEQ as a dotted line which is also in my G1000 flight plan.)
Also, the inGame Chart shows a purple line between SMYTH and TEETO for some reason (just for distance info?).
Now the weirdo:
I close the inGame Chart and re-open it - it says ‘Load Flight?’ which I do and then I get different Arrival (transition CRIBB instead of SMYTH) and Approach (transition TEETO instead of Final)?
I can only guess that since this reload inGame is done inFlight, then NaviGaph re-calculates from where I am at that moment in time - maybe?
Go figure that one out.
If I didn’t inadvertently close the inGame panel, I wouldn’t have seen this…
In any case, see the attached zip and don’t hesitate to get back to me for clarification.
My general consensus is:
Navigraph gives me Jeppsen charts (which cost a fortune otherwise, and by region!).
Also, Navigraph allows a two-monitor MSFS flight to be followed simply using the desktop app on a secondary monitor.
That is, providing that I define my flight using Navigraph desktop and then duplicate it within MSFS World.
So:
MSFS is a mess, but Navigraph does manage to do some weird stuff.
I will keep Navigraph, but only for flight plan creation which I then duplicate in MSFS.
And, I will not use the NaviGraph inGame charts, rather simply the desktop app.
We shall see.
Thanks again for any insights…
Magnus
Simple example:
KALB-KMHT:
KALB/Rwy19 Dep:ALB7
KMHT/ILS06
ARR:ROZZE2/via/SMYTH
This flight plan (in both MSFS and NAVI) can be examined/analzyed by anybody.
My analysis process:
Load this flight plan in NAVI as well as in MSFS.
Save both with an identifying name.
Step 1:
Compare the two XML .pln files with a text editor - the differences are considerable.
Then, load each saved .pln into the other program.
Then, save the .pln just loaded from the other (MSFS/NAVI) with another name.
Then, compare the two XML files.
They are, in my situation (Win11-22H2:MSFS-1.34.16.0, different.)
Now, I have no desire to try and analyze the reasons for the differences in the XML files.
But they are there, the differences.
The obvious difference is that NAVI cannot save a Flight Plan in IFR-Low.
Systematically, it saves the FLP as HIGHIFR@38 000 Altitude!
Enjoy the puzzle - and please come back with any new thoughts and/or ideas!
So far so good, as far as I can see! Same procedures, same waypoints and same route.
It is worth noting that MSFS does not simplify their “route pills” by showing the procedure names, instead showing the waypoints that they are made up of. For example, TEETO, JAAZZ and FITZY are all part of the approach:
But MSFS displays them as separate route items in their pills:
The result should be the same, regardless. You can tell by the colorization of the route in the world map that MSFS is aware of the types of each part of the route, from departure to approach (blue, green, magenta).
Visual anomalies
However, when you dig into the difference between a file exported from Navigraph Charts and MSFS, things get weird quickly.
First and foremost - I started this flightplan in Navigraph Charts, and exported it for MSFS. I then loaded this PLN file into MSFS, and all procedures were correctly identified - as they should, since we follow the PLN specification. This was shown in the previous section.
But when comparing the routes side by side, we can clearly see a difference. Let’s start with the visual part and then the technical stuff!
Based on the first look, you might assume that our flightplan is missing waypoints. At least it looks that way right? Well, if you zoom in (and check the technicals, shown later) you can see that our plan does pass by the same exact waypoints. But they are not highlighted! When you zoom in, you can see the labels of these waypoints too! Here are two examples:
Now, how come this is the case? Let’s take a deeper look!
Analyzing the PLN file differences
To begin with, let’s see what MSFS does to our PLN once it is loaded into the simulator. To do this, I loaded the PLN that was just exported from Navigraph Charts and loaded it in the world map, then immediately exported it again. This resulted in a new PLN file, which I will now compare to the original!
Below is the diff between these two files. You can also see it here if you prefer to see a side-by-side comparison over a unified view.
We find that quite a lot happened. Let’s summarize!
The cruising altitude has been modified from 16000 to 16000.000 .
The departure runway was added as an extra <DeparturePosition> tag
An invalid/unused <AlternateName> with a default value of… AlternateName was added It is even mentioned as deprecated in their own documentation.
A couple custom waypoints called TIMECRUIS and TIMEDSCNT was added to mark specific phases of the flight.
LUCIC, FLYZZ, FYSHR, PNARD, TEETO - a majority of the waypoints that make up the arrival, were all stripped of their role as Intersections. This means that they are no longer treated as navaids, but as coordinate-based custom user waypoints.
Some waypoints had their coordinates ( <WorldPosition> ) changed as well.
Conclusion?
I don’t know if any of these changes that MSFS did would cause any issues for you while flying. It does not look like it! However - I can see a few issues that we could look into!
Using this plan as an example, we have issues with the departure procedure. This is because the specification (found here) wants us to define the departure procedure on any and all waypoints included in the procedure. In this case, that is a problem because the first waypoint in the flightplan is both the end of the departure and the start of the arrival at the same time - not a super common scenario, and not a case that has explicitly documented solutions.
We can investigate this and see if we can find a reliable solution, but it is not straightforward. MSFS sometimes works around this by injecting made-up waypoints to act as placeholders, but it’s not the prettiest thing to see either…
When loading this PLN, or any PLN for that matter, back into Charts - the approach transition is lost. This is caused by the fact that it is not actually ever specified in the PLN file! However, we could do the same thing that MSFS seems to be doing in this case - looking at the last waypoint in the route and trying to find a matching approach transition based on that.
Both of these are edge cases that we have so far barely realized ourselves. I will add them both to our bug tracker!
Bonus answers
This is not true. If you set the Cruising Altitude to a value below18 000 in the flight options, your flight will look like my example in this post, which is:
Likewise, if you set the Flight Mode to VFR - the exported file will instead use the type.
If this does not work for you, your flight is not being saved correctly. Feel free to open a new, dedicated topic in that case, and we’ll look into that!
The screenshot you provided looks totally crazy, and that is because this is your theoretical route:
KALB ALB7 SMYTH <enroute waypoints, all part of ROZZE2> SMYTH ROZZE2 KMHT
Lots to unpack here but most importantly:
SMYTH is in there twice. One time as the departure transition, and one time as the arrival transition for some unknown reason. This causes an abrupt jump back and fourth, sort of like: ORIGIN -> SMYTH -> ENROUTE -> SMYTH -> ARRIVAL (Same as enroute) -> DESTINATION
All the waypoints that make up the arrival are in there twice, once as explicitly added “enroute” waypoints, and then again as part of the ROZZE2 arrival. This adds to the above issue.
The ZIP file you uploaded contains a PLN file, but it is completely empty - containing only the origin and destination airports but nothing else. Unfortunately, I can’t see how that file caused the mess that is shown in your screenshots!
If that flightplan was exported by MSFS, then something went terribly wrong somewhere. Here is the same route, same procedures etc. exported directly from MSFS without Navigraph Charts involved:
Try loading this one into Navigraph Charts! You will find that it works just fine, albeit with the exceptions mentioned in my conclusion in the earlier section.
We don’t recalculate anything based on your situation, no. When you open the panel, we check the simulator to see if it has loaded any flightplan, and if it has - we ask you if you would like to load that flightplan. We don’t make any modifications - if you got the TEETO transition then that is what the simulator believed that you had loaded.
What are you comparing to in this sentence? I’ll see if I can clarify why that is important!
If you import a PLN that has been exported from MSFS into Navigraph Charts, you will always get a “Final” approach transition - the reason is mentioned in the conclusion.
However, if you import the flight directly from the simulator inside of the panel - you do get the correct transition since the simulator (and our panel logic) does not use the PLN format at all, instead having access to much more data.
This could very well be the reason why you saw these changes!
I hope some of what I have written here is of any help in understanding the situations you have seen.
If you have any follow-up questions, or you would like to add things that I have missed in my analysis, feel free to do so!
Thanks a million for your deep-dive, Malte!
You have allowed me to see the wood instead of the trees - but it is a complex situation.
One quick point re the plan I sent you - KALB-KMHT.
It does only have the 2 airports and that is normal.
Given that Navigraph strips out the Approach waypoints and given that I had (inadvertently?) not put in an Arrival procedure, then there is nothing left in the .pln, apart from origin and destination!
So, in a nutshell, it does not matter what Approach procedure one chooses in Navigraph, MSFS doesn’t even get to see it and thereby makes its own decision as how one is to land (apart from the type of landing choice in Navigraph - ILS/RNAV etc).
I have come across some interesting things regarding the ‘EnRoute’ portion of a flight, but I’ll leave that for another post (I want to see if the strange ‘max 3 replies’ I received previously happens again).
Attached are screen shots and the original KALB-KMHT flight plan
These are only shown to make a clear break-point in these considerations - so far so good.
In the next post, I would like help in understanding what happens in-game - I am at a loss 0-KALB-KMHT from NAVI.pln (1.6 KB)
Back again with a true puzzle, or something weirder…
Having loaded the above plan, I simply went flying, no parking, in a C172.
On the runway, I immediately opened the FLP on my G1000.
When I saw that horror, I opened the Navigraph in-game panel.
I attach a screenshot of the FLP, as well as a close-up of KMHT.
I understand nothing - too many things to correlate.
Where did G1000 invent all of those waypoints - ROZZE/NUUKM/JSTNN?
At a guess they would correspond to the ROZZE2 24 seen in MSFS WorldMap, i.e my missing Arrival Procedure. Then a MANSEQ so I can join up with the original Approach ILS RWY 06 via GDM.
So, I have learned that I must NEVER forget an Arrival leg, otherwise MSFS will choose one, randomly! (why ROZZE2 24 when I am on ILS 06?).
That having been ‘learned’, I can’t make head nor tail of the NaviGraph In-Game panel.
OK,
I just redid the above, this time choosing an Arrival procedure - there were many transitions for the only available procedure ‘ROZZE2’.
In choosing the closest to my exising Approach procedure, I took CRIBB which then allowed me to choose a different transition for my ILS 06 Approach - ‘TEETO’.
So all is well - even the In-game panel shows the same.
So, for the moment, I can see how much disaster can be caused by an inadvertent lack of Arrival procedure.
It all looked simple and straight forward, even in the World Map, but obviously MSFS had second thoughts by the time I went in-Game.
And poor NAVI-In-Game got very confused.
In conclusion (at the moment because I have some minor things/questions to follow through on):
Knowing that MSFS ignores the actual Approach procedure defined in NaviGraph, one cannot have an ‘illogical/outrageous’ Arrival procedure, and one MUST have an Arrival.
There is still an issue with (at least my G1000) - I cannot even see my transition CRIBB - the next waypoint for my MANSEQ in G1000 is ROZZE , halfway up the Navi Arrival (green-coloured line on the desktop NAVI, but purple on the ingame Navi).
I think? that for some reason MSFS has decided that the En-Route gooes all the way to ROZZE and not to CRIBB.
It’s looking better, but these discrepancies are not good when one flies IFR at night, relying on the visual s…
I shall deep-dive further and see if I can find a logic somewhere…
Thanks for listening Malte
Just to clarify a little, in my G1000 FLP, I see my KALB departure, then a MANSEQ all the way to ROZZE.
So when I fly this G1000 FLP, I will see the moving map moving horizontally until ROZZE, therefore the in-game visuals are off the wall.
Unless I spend time, on the ground in the cockpit twiddling knobs, with difficultly, to insert and delete way-points in the G1000.
Sort of defeats the purpose of the whole shebang in actual fact.
I do understand that in MSFS we have the easy life.
IRL, pilots do a ton more preparation than we simmers do.
But, at least, they can rely on their procedures, hopefully!
I shall follow through - and “I’ll be back” (as the other guy said)
I see! Yes, the waypoints are stripped out, but the approach is specified on the destination (as per the specification). So you’re right - technically it is the origin, DCT to approach, and then destination.
The one known caveat is that no transition can be specified here - it is instead often based on the last waypoint in the enroute section of the flight, as mentioned earlier. MSFS should absolutely be able to pick it up though!
The correct approach is indeed selected! MSFS also decides to add an arrival, even though none exists in the flightplan. That’s odd for sure…
The departure is also missing, and that is an issue on our side that has already been mentioned. We’ll look into that when we get resources to do so!
I can confirm this! I don’t see any way that we can prevent it in the PLN file though, so that’s on MSFS.
It’s odd that it believes itself to know better than the flightplan that is presented to it…
I tried ditching our PLN and making the same exact flight plan from scratch in the world map, then exporting that as a PLN, and then importing said PLN into MSFS again. Believe it or not - the result is worse!
I think we can conclude that this is not on Navigraph to fix. The panel will import exactly what the simulator tells it to, and in this case that data is… subpar
It does not seem like it ignores the approach, but an arrival seems to be necessary in this case either way, you’re right!
I am not able to reproduce this. Here is what I exported from Charts (web app):
Thanks again Malte.
There is stuff to be cleared up for sure - especially on MSFS side.
I’m sure I have noticed that MSFS can choose different Transitions for a given Procedure.
Since MSFS doesn’t allow, in the WorldMap, choosing Transitions, it must be that it calculates the waypoint itself, probably based on distance.
In my case, I had SMYTH as a transition, set automatically by MSFS when I chose ROZZE2 (or rather that was the only one available - albeit with different arrival runways).
I just now, in MSFS redid the same KALB/19-KMHT/ILS06 and it gave me SMYTH again - and not MUCOW.
Also, when I said:
<>
I was actually inside the FLP - En-route all the way to ROZZE with no intermediate Waypoints.
But that is what MSFS is.
Just for you to check on, if you have time:
In NAVI-Win (nothing to do with MSFS here):
Unload current flight for a clean slate
Add KALB/19/ALB7 and KMHT/06/ILS
Add Arrival ROZZE2/SMYTH
Remove ROZZE2
-Add ROZZE2/MUCOW
-Remove ROZZE2 again
-Add back ROZZE2/SMYTH
What always happens when removing and changing Arrivals/Transitions is that the previous partial legs stay on the map.
I have found situations where the new Arrival actually uses the remnant leg as a part of the whole plan.
It didn’t do it for me just now, but I have seen it quite a few times.
The only way is to do an Unload and restart the whole flight definition.
It would be great if the purple En-route legs were cleared as well when removing a procedure.
In any case, a rather minor issue, but annoying.
Thanks again for your deep-dives
I have decided, just to be able to use the NAVI-Win plan as a visual Moving Map, to use NAVI to see what options are available for a given flight.
Then define it in MSFS and go back to NAVI and duplicate it.
I don’t need the in-game NAVI because I have 2 monitors, but maybe I should use it since it loads from MSFS directly.
I can now put these issue to rest, for the moment, and get back to some flying.
But I must thank you again for all of this info as I now have a much better understanding of the intricacies of flight plans.
Let me know if something new crops up
Cheers,
Magnus
Final comment about MSFS.
We now know that it takes shortcuts in its flight-plans based on whatever logic it uses.
On that issue, I wonder what database MSFS uses for procedures?
I have a different case where NAVI waypoints on ILS Approach are different from MSFS waypoints on same Approach.
Nothing we can do about this particular issue, but I’m curious - see these shots:
I will take a look at this example as soon as I get some time to spare!
If you have installed Navigraph navigation data through the Navigraph Hub, it should be using our data for procedures. That said, it does not necessarily mean that they will look identical - they could still be doing some unexpected things with it!
Your quote:
<<they could still be doing some unexpected things with it! >>
You say they “could” and yet we know that they “DO”! @skysail - I have no blocking issues.
I truly appreciate your reflections.
We all know that MSFS/ASOBO are quite cryptique what with documentation & general information.
Also, they are extremely bad at helping to solve issues on their various forums.
MSFS/ASOBO attitude is:
<<Live and let die>>
or, rather just <>
I take pleasure from MSFS flying - I have spent over 50 years of my life professionally in Tech IT and International Tech Training, I’m now in retirement.
So, my professional past always makes me deep-dive whenever I find issues, just like you have done.
I am happy to keep this door with you @ Navigraph open as I am sure that the NAVI/MSFS coordination needs to be fine-tuned.
Take care and I wish you and yours happy year-end festivities.
Best,
Magnus
For completeness: The approach procedure here just looks like it has been rendered a bit sloppy. The procedure has been coded to perform a turn at that location, and the world map likely shows a simplified version. Any aircraft that renders procedures correctly will show a normal turn and not the ~180 shown on the world map!
It is even mentioned as deprecated in 
