I understand the approach, but manually compensating for broken ATC behavior is a workaround, not a solution. The sim should handle this correctly without the pilot having to game the system.
Funny enough, I just completed another flight and ATC was completely fine - gave me descent clearance right around TOD, smooth all the way in. So it’s clearly not a fundamental limitation of the system, just inconsistent behavior that needs to be ironed out.
TBF, that’s my experience 90% of the time. Though, in practice, ATC will “step” me down, whereas VNV is smoother, but the two just seem to coincide.
Fair point, and honestly my overall experience is similar — probably 98% of flights go without a hitch. But it’s those occasional edge cases that stand out, where ATC either refuses to clear you down or just gets stuck in a loop. If we can narrow down the conditions that trigger it, I’m sure the devs would be happy to fix it.
One more thing worth mentioning — these issues show up in career mode too, not just free flight. And career mode is genuinely interesting, but it’s also where the ATC quirks hurt the most, since you’re locked into default aircraft and can’t bring in something like PMDG. That combination of limited aircraft options and unreliable ATC makes it hard to fully enjoy what could otherwise be a great experience.
ADANA AIRPORT (LTAI) — ATC Logic Breakdown
Yet another airport with fundamentally broken ATC behavior. Asobo continues to ignore community reports on this critical issue.
The Problem:
ATC is actively interfering with flight plan execution by simply ignoring descent profiles and holding aircraft at cruise altitude. In this case:
Flight plan properly filed with descent waypoints
XTOD reached, descent profile initiated
ATC held aircraft at FL380, ignoring the entire plan
No clearance given, no reason stated
Pilot forced to request meaningless vectors just to work around the system
IFR cancellation finally available only below FL190
The Core Issue:
ATC should NOT control descent initiation. The dispatcher’s role is coordination—preventing conflicts with other traffic, approving routing changes, responding to pilot requests. NOT micromanaging altitude transitions.
How it SHOULD work:
Pilot initiates descent for approach according to flight plan (XTOD, waypoint constraints, or STAR procedure):
ATC approves/denies based on traffic separation only
ATC can suggest speed changes or vectoring if needed
ATC can also remind pilot if top-of-descent is missed (helpful reminder, not instruction)
Pilot remains in command of altitude management throughout descent
Current Broken Logic:
ATC ignores plans entirely
ATC holds altitude arbitrarily
Pilot has no proper mechanism to execute descent
System forces workarounds (vector requests, IFR cancellation)
Example of PROPER ATC Behavior — INSBRUCK (LOWI):
What the Screenshot Shows:
Descent profile visible in FMS (XTOD ahead on the plan)
Pilot descending at FL380
ATC focused ONLY on traffic separation (reporting other aircraft)
No interference with descent timing or profile
Pilot reaches waypoint, continues descent autonomously
ATC coordinates sector handoff to approach control
This is proper ATC coordination. This should be the standard everywhere.
Pro-Tip: How to Fix ATC Descent Logic & Enable “Descend Via STAR”
The Issue
The in-game ATC frequently fails to authorize descent at the correct time. The root cause: ATC is effectively “blind” to your Top of Descent (TOD) if it falls between two enroute waypoints. In that case, it will hold you at cruise altitude all the way until you pass the very last enroute waypoint before the STAR begins — leaving you too high and too fast, with no option for a realistic descent profile.
The Discovery
After extensive testing, I’ve identified the exact trigger condition. For ATC to issue the “Descend Via STAR” command correctly, your TOD must be positioned in one of two places:
The “Grey Zone” — between your last enroute waypoint and the first point of your STAR/Arrival.
Inside the Procedure — after the first waypoint of the STAR itself.
If the TOD is trapped between two enroute waypoints, the ATC will not act until it’s too late.
The Fix (The “Gap” Method)
Check your Nav Display. If the TOD is sitting between enroute points, you need to push it out by creating a geographical gap:
Remove unnecessary waypoints near the end of your enroute phase to increase the distance between your last enroute fix and the start of the STAR.
Aim for at least 80–100 miles between that final enroute waypoint and the first STAR waypoint.
Once you clear that last enroute fix, ATC sees a “void” ahead — no more points to hold you at — and immediately triggers the “Descend Via STAR” command. This gives VNAV plenty of room to capture the VPATH and fly a smooth, continuous descent (CDA) right from the calculated TOD.
Why It Matters
This bypasses the rigid step-down altitude assignments and enables a professional continuous descent approach — which is especially important for jets like the A320, 737, or PC-24, and particularly relevant in Career Mode where third-party aircraft aren’t available.
Notes
Verified for IFR operations. IFR to VFR behavior has not been tested.
Even with lower altitudes pre-set in your flight plan, ATC will ignore them until the TOD is correctly positioned outside the enroute segment.
Note: The FL410 shown in the EFB screenshot is an unrelated tablet bug — the flight plan itself correctly specifies FL390 and it has no effect on ATC behavior.
good detective work. 
FINAL REPORT: ATC Logic & Vertical Nav Triggers (Confirmed 110%)
After 2+ months of exhaustive testing, I am closing this case. I have identified the exact triggers for ATC freezes in both IFR descent and IFR-to-VFR transitions. Asobo’s testers missed it, but here is the raw dependency:
1. IFR Descent (The TOD Bug):
The ATC logic is vertically “blind” within the enroute waypoint segment.
The Trigger: If your TOD is located between two enroute (white) waypoints, ATC will hold your altitude until the last fix.
The Verified Fix: Create a “Grey Zone” (80-100nm gap) between the last enroute fix and the STAR entry. Only this “void” allows the system to process the descent command on time.
2. IFR to VFR Transitions:
The same rule applies. If you transition flight rules within a cluttered sequence of waypoints, the logic loops or fails.
Summary for Developers:
The problem is a processing delay in the ATC’s vertical and flight-rule logic when waypoints are too dense. I have provided the data and the 100% working workaround. Until the core logic is patched to “see” beyond the current waypoint segment, the “Gap Method” is the only way to fly professional IFR.
Method: Tested, Proven, Verified.
I agree, but personally I would like the immersion like I am actually getting coherent instructions from a competent controller and am able to follow it and be okay. Hearing the ■■■■■ say “you are X feet below your assigned altitude, please climb and maintain flight level X” because I descended when I am supposed to instead of when I am already at the airport ruins it for me.
I flew a mission earlier today, saw the top of descent approaching at FL360, was waiting for the ATC to tell me to start my descent but it never came. Was staring at the top of descent marker disappear and the flight computer telling me I am at the top of descent while the controller is asleep at their job. Just for fun I decided to see how far I would get before the controller told me to descend. Turns out it was on the turn to final, I was still at FL360 on my turn to final when the ATC finally chimed in and told me to basically drop straight down to 7600ft. At this point I ignored the mission and tried to see if I could actually make the drop so I deployed full speed brakes, dropped gear, basically let everything hang out to have as much drag as possible to drop as fast as possible. Still zero chance of making it, did a go around doing 250 kts while at 3000 ft above the touchdown, flew a normal VFR traffic pattern and landed it eventually. Somehow the passenger did not complain.
As of right now I am going to avoid airliner missions because it is simply not fun to have to ignore ATC. I know in real life airliners almost always fly IFR so having to fly VFR in an airliner does not appeal to me.
Luckily cargo and charter missions work better and there it actually makes sense to fly VFR.
I completely understand your frustration — flying IFR with broken ATC is immersion-breaking, and what you described (being told to descend on final from FL360) is exactly the bug I’ve been documenting.
The good news: there’s a 100% reliable workaround that doesn’t force you to abandon IFR.
I’ve posted the full breakdown here:
post 1
post 2
The ATC can’t “see” your TOD if it falls between enroute waypoints. You need to create a gap of ~80-100 miles between your last enroute fix and the start of your STAR. This forces the ATC to issue descent clearance at the right time.
Pro tip for keeping your full route intact:
Delete a few waypoints only in the EFB tablet (not in your MCDU/FMC) to create that gap, then sync the changes only to ATC — not to the aircraft systems. This way your navigation instruments keep the full route, but ATC sees the simplified version and clears you to descend on time.
Yes, it’s a workaround. But it’s been extensively tested and verified across numerous routes — including KLAX, KSFO, KJFK, KATL, multiple European arrivals (LOWW, EDLW, UUEE), and others. 100% success rate when applied correctly.
Good luck, and let me know if it works for you!
Just for confirmation: once I reach crz alt I delete waypoints from EFB to create the gap and send to atc only keeping the FMS plan intact. This will 1 let me descend on time and 2 not break the mission logic. All correct? Thanks in advance
I will answer my own question here: already before starting the flight/mission plan the gap of 80 to 100nm between last enroute and first star/approach waypoint to ensure that TOD sits in that gap. Worked every time for me as described in this thread. So thanks again for investigating the issue and coming up with a workaround!!
