This is a perfect example of the current ATC logic being inconsistent.
Within a very short time span, ATC issued:
“descend 5000 ft”
then “maintain FL250”
then “climb FL240”
Regardless of the exact altitude at each moment, these instructions contradict each other and show a lack of awareness of the aircraft’s current state and vertical progression.
Instead of providing a coherent descent profile or following the flight plan, ATC keeps issuing conflicting commands.
This isn’t about realism — it’s simply broken logic.
This thread appeared in the fs-2020 threads but obviously it’s been talked about mainly in 2024. For me, this was the biggest problem with FS 2020 when it was released. I was baffled the ATC, over a decade later, wasn’t even as accurate and useful as the ATC in FSX.
I use add-ons such as Beyond ATC rather than the built-in ATC but the problem with that is that they are only IFR. You cant do a VFR flight in Beyond ATC because you can’t do VFR in brief and Beyond ATC requires a Simbrief plan. The MSFS ATC does allow this, but it’s so bad that it’s impossible to use. It really needs to be fixed. In my opinion, we need that way more than we need any more City or World updates at this point . It’s inexcusable that it’s still so bad
Looks like ATC behavior might have improved recently.
No sim updates on my side, but over 5 flights in a row (across different regions) ATC has been consistent. They followed the flight plan properly: sometimes guiding the descent step-by-step (FL250 → FL190, etc.), and other times letting me descend from the expected TOD point in line with the procedure.
No weird early descents, no conflicts, no broken profiles so far.
Still monitoring, but this feels like something has changed - possibly on the backend side.
I get why people suggest third-party solutions, but that’s not really the point.
The default ATC is part of the core sim, so it should work properly on its own. Relying on external tools to compensate for missing or broken functionality isn’t ideal - and it’s not great when those gaps end up being filled by paid add-ons.
The goal here is to highlight these issues so they can be properly fixed in the sim itself, rather than turning them into something users have to pay extra for.
I’m reminded of when I used to contribute to a Windows forum many years ago. Someone would ask for help with a problem with (say) Internet Explorer and people would say, “Download and install Firefox”.
My experience with 3rd party ATC is that, even though they are MUCH better than the default ATC, they have more frequent “disconnects”. I have had both Beyond ATC and FSHUD lose track of where I was when taxing or kind of just stop guiding before the destination (not often), not to mention having conflicts at some airports because of outdated AIRAC and runway number changes, whereas the default ATC doesn’t have to “connect” or “communicate” with the sim and doesn’t need Simbrief and can follow me when flying VFR. I like that I can fly VFR and request a procedure at a “nearest airport. So, having ATC built-in has many advantages. I am repeating myself when I say it’s unbelievable that, with all the technolgy available to MS/Asobo, they could release a flight sim with such poor ATC, having over a decade to plan it (and still haven’t fixed it).
I think I’m just going to start posting ridiculous descents until maybe it’s resolved, or at least, it’s recognized as an issue that needs to be fixed.
It would be much more useful to include the ATC window and flight plan details rather than just screenshots of the descent profile.
Right now it’s hard to understand what exactly is happening - whether this is ATC behavior or something related to how the flight plan is constructed (constraints, STAR, etc.). Screens showing only the vertical profile don’t provide enough context.
If possible, please include:
ATC communication window
flight plan / STAR / constraints
current clearance vs actual profile
Also, we’re trying to provide useful and actionable feedback for the developers here, so the clearer and more complete the information is, the better chance this has to be properly identified and addressed. Just posting isolated screenshots without context makes it much harder to understand and reproduce the issue.
Agreed, although I’m pretty sure by now to developers know it is broken. For me, personally, I find the heading instructions okay, in fact it avoids the numerous heading instructions that I get in other ATC programs which seem over the top but then, all of a sudden, it will have me at 8,000 ft above the elevation of the airport at 5 miles out or tell me to ascend after I’ve already descended….. some ridiculous thing like that.
I do think the developers are likely aware of the issue at this point, but the problem seems difficult to isolate clearly. A lot of reports are based on isolated screenshots or partial situations, which makes it harder to understand what exactly led to the behavior.
Without seeing the full context (ATC instructions, flight plan, constraints, current phase of flight), it’s difficult to determine whether it’s an ATC logic issue, a sync problem, or something related to how the plan was constructed.
That’s probably why it still feels inconsistent — the issue isn’t always presented in a way that’s easy to reproduce and diagnose.
This actually feels like one of those rare cases where everything lines up the way it should.
Surprisingly, I’ve had relatively consistent behavior over the past few days — nothing perfect, but generally stable enough to follow a predictable descent and approach flow.
There are still occasional odd instructions here and there, but so far they haven’t been critical or flight-breaking.
It just highlights how good the system can be when things happen to stay in sync.
Yeah, that’s exactly the thing - when it works, it works really well.
The problem is that it still feels inconsistent. You can have a few good flights in a row, and then suddenly get completely off-profile instructions again.
That’s also why it might be tricky for the developers to pin this down - if their test cases happen to behave correctly, the issue may not be obvious.
It would probably help a lot if reports included full context rather than just isolated moments. Things like the EFB plan, ATC window, and FMC/MCDU flight plan make it much easier to understand what actually led to the behavior.
Without that, it’s hard to tell whether it’s ATC logic, sync issues, or something related to how the plan was set up.
I am more than happy to provide additional feedback to this in-game issue with real-world experience to corroborate the concerns at hand. While you’re asking for specifics to ATC clearances, we all know how lackluster the AI ATC is in this game…this is not something new. Even if I gave my entire filed route, full-route clearance by ATC, and the arrival/approach flown, it wouldn’t change this consistent outcome.
The screenshots provide more than enough information. Based on a standard 3 degree flight path angle, if the avionics are requiring anything greater than 3,000 FPM, that should be more than enough information to see the issue. The ATC descents need to simply be issued based on a normal 3-to-1 descent. This has nothing to do with how the flight plan was filed and this *should* not have anything to do with airport pairings being towered or non-towered, if an approach was filed or in use, or if the airport is VFR or IFR.
The option to cancel VFR when descending through FL180 is highly unrealistic. But, I’m having to use this option routinely just to get down and land. Provide realistic ATC clearances and this will all be resolved. If I have to descend to or below 18,000 just to vector myself for an approach, while in IFR conditions, should have been addressed months prior.
There needs to be far better ATC clearances/support, period. Neither climbing nor descending clearances issued at this point in the PS5 world are realistic and are not conducive to a normal/expected/fun experience…
I understand your point about the 3° path and 3:1 rule, and no one is really arguing against that.
The problem is that without full context, it’s impossible to tell why the aircraft ended up in a situation requiring 3000+ FPM in the first place.
From what I’ve seen, the same route can behave differently across flights — sometimes ATC gives a reasonable descent, sometimes it doesn’t. That suggests the issue is not just the descent rule itself, but how and when instructions are generated.
That’s why saying “the screenshots are enough” is risky. They only show the end result, not the sequence of events that led to it.
For example, without seeing the actual ATC instructions, flight plan (EFB/FMC), and timing of descent clearance, it’s hard to rule out things like late clearance, sequencing behavior, or even how the plan was interpreted by the system.
If we want this to be fixed properly, it really helps to show the full picture - not because the issue isn’t real, but because otherwise developers are left guessing what actually happened.
Right now it’s less about proving that something is wrong, and more about showing exactly where the logic breaks.
Yeah, the issue itself sounds real. But I still think it needs to be looked at case by case — specific airport, specific flight plan, when the descent was issued, and also the aircraft profile. Different aircraft can end up reacting very differently to the same late instruction.
I mostly fly the PMDG 737, and in my case I haven’t run into this kind of behavior with FSHud.
I’ve just run into the same old broken ATC behavior again, this time on a flight from UUEE (Sheremetyevo) to Dortmund (EDLW) - this literally just happened.
ATC kept me at cruise (FL360) far too long, repeatedly issuing hold-level instructions and effectively blocking any descent. They just wouldn’t let go of the altitude, even well past TOD, completely breaking the descent profile.
I ended up having to ignore ATC and descend manually, eventually cancelling IFR around FL190 just to recover the approach.
I didn’t capture screenshots this time - I landed and exited the sim right after, as it was frustrating to see a perfectly fine flight fall apart at the final stage due to ATC behavior.
What makes this particularly frustrating is that things had been working fine for quite a while before this - this is the first time in a week or so of otherwise smooth flights that the issue has resurfaced.
Normally descent is initiated around 10–20 NM before TOD, but in this case it was delayed well past TOD and several subsequent waypoints, which is why I eventually had to intervene manually.
