So, a few things I’ve noticed that I think explain a lot of disconnect users experience in my nearly 800 hours of flying (almost 7/8 of which have been in the A32NX). This is an attempt to translate between Asobo and the FS community based on my numerous years in the simulated cockpit with FSX and now with MSFS):
The Big Win
Firstly, it is evident based on the level of FSX similarities, the fact that MS is behind this, and some of the issues that have presented themselves that Asobo set out to create the best flight simulator ever adapting original FSX coding, eliminating the issues, and applying new technology previously unavailable or not feasible to improve the user experience.
In the most important ways, they are succeeding in a BIG way.
Consider that while FSX was the gold standard in its prime of what a simulator could be, it had two major issues: 1) current technology made the sheer scope of the globe almost impossible to present accurate terrain and imaging, so the terrain, and texturing was limited; and 2) the memory leak meant that no user could maintain more than 3 or 4 good airport sceneries and some great airliners without crashing the system mid-flight, and the simulator failed to utilize all system resources properly. There were other imperfections which could be mentioned, but these were the most notable limitations.
Asobo fixed these things by creating the ability to leverage Internet streaming to enable massive terrain and global imaging to be not only employable but updatable - meaning we all get access to the most up to date Bing mapping (however outdated it may be in areas), with constant improvements being made capable as data improves - this is huge. Where the old way required massive storage and processing capability to even begin to imagine (and would require actual coding updates), the new process means if you have a fast Internet connection, you have what you need with no code changes - they simply update the map data server-side…pretty amazing! The other, more obvious change is that the memory leak is gone - now you can store a virtually unlimited amount of airports, etc, bound only by your storage capacity (the sim now only loads the scenery you’re using and dumps what you’re not) - also huge.
Lost in Translation
Here’s where it gets a bit confusing but I think I’ve figured out the root issue. While the original DNA came from Microsoft and was largely based on US-operating constraints (the FSX ATC used US processes and wording, flight routing, etc), Asobo went with what they were more familiar with - European standards (decimal vs point as an example). However, what wasn’t changed was the way the simulator handles the flight.
So, what happens is you’ve got EASA phraseology and planning capabilities (laid out patterns) but the sim routing processes still handle the flight using the original US methods. Thus, when you fly in the US and expect to get a vector from ATC near the end of your STAR into approach, it doesn’t happen - instead you get false waypoints that Asobo has to create in your flight plan to make up for the lack of vectoring by ATC. Conversely, if you’re flying in Europe, where every waypoint from STAR to approach is mapped out by a transition, the ATC doesn’t know what to do with you when you get to the end of the STAR and it starts turning you back home (the Airbus approach turning bug that keeps showing up always happens at the point where you transit from STAR to transition route).
At least this is my theory…
The Solution
It seems to me that if Asobo could make the ATC handle a flight based on departure and arrival airport operational constraints at both ends, this thing is perfect. Say you’re taking off from LFPO and flying to KORD. Well, the flight plan should include the SID based on EASA standard charts (as selected by you in the planning process), the enroute plan, and the STAR for KORD (as selected by you) with NO FALSE WAYPOINTS. When approaching KORD, the sim should know to use US standards for phraseology and that because of this, you need a vector to final once you’re getting near the final STAR waypoint (the processes are all published - this isn’t top secret info) and ATC should vector you (the way FSX used to instead of creating false waypoints in your flight plan).
Vice versa, if you’re departing KORD, the ATC should know that you’re on a vector departure, and steer you towards your initial waypoint the way FSX used to, and direct you to continue on course thereafter. When you approach LFPO, ATC should know that you’re already flying a specific STAR, Transition to Approach, and Approach and do what it does in MSFS today, simply direct your speed and altitude while the A/C does the rest (again, with no false waypoints).
The waypoint/turn issue would be gone, ATC phraseology would be regionally accurate, and pilots in all areas would be flying what they’re expecting matching the nav data and charts they’re looking at.
I know there are other areas for improvement - this isn’t a bash Asobo thread by any stretch, and this doesn’t address specific VFR issues or specific aircraft issues or anything people are having - this simply addresses interrelated ATC and IFR issues that affect everyone. In fact, this is a massive thank you for the job so far and a suggestion for how to fix several major issues correctly all at once and make a LOT of people very happy, whether they fly FBW or Aerosoft CRJ or simply hop around the globe in a WT CJ-4.
I think at least this is what’s happening - maybe Asobo can prove me wrong, but…it’s the only logical answer I can come up with that explains everything in IFR/ATC we’re seeing, and it fits the known circumstances/relationships.
As Spock once said, “if you eliminate the impossible, whatever is left, however improbable, must be the truth.”
