EFB PLN Load is changing runway but "ATC enforce flight plan" = ON

Bug Reporting Hub ATC, Traffic & NAVAIDs
, , , ,
1

ISSUE DESCRIPTION

EFB PLN Load is changing runway

including with “ATC enforce flight plan” = ON

With PLN (attached) setting runway 31, the plane will load into the airport at Runway 13.

The weather doesn’t matter but using Clear Skies in case this is a weather-related ATC runway reassignment, but my suggestion is it’s actually an EFB bug as it is NOT READING DeparturePosition FROM THE PLN FILE.

If applicable, which aircraft is experiencing this issue:

n/a but tested with multiple aircraft incl. Asobo 172

[PC Only] Did you remove all your community mods/add-ons? If yes, are you still experiencing the issue?
yes

FREQUENCY OF ISSUE

How often does this occur for you

Every time for a given airport.

REPRODUCTION STEPS

Please list clear steps you took in order to help our test team reproduce the same issue:

  1. Enter Sim, set weather to “Clear skies” preset, Load the attached PLN which is copied (& updated) from the SDK docs.
  2. Choose plane, open EFB. Click “Load PLN from file”
  3. If you now scroll UP in the EFB app you’ll see Departure Airport already seems to (wrongly) indicate “RUNWAY 13”, not the 31 in the PLN.
  4. Click “File plan with ATC” so the World Map departure gets updated, which shows “Runway - 13” (SHOULD BE 31)

If you try and change the runway on the World Map, the EFB (or whatever) will discard the ENTIRE flightplan loaded from the PLN, which IMHO is a bug also.

YOUR SETTINGS

Includes “ATC enforce flight plan” = ON

[PC Only] Are you using Developer Mode or have you made any changes to it?

Yes have the developer menu up but I really don’t think that affects this issue.

[PC Only] What GPU (Graphics Card) do you use?

3090 - not relevant IMHO.

[PC Only] What other relevant PC specs can you share?

64GB ram - not relevant IMHO

Here’s a SAMPLE PLN:

test_runway.pln (1.8 KB)

MEDIA

Please add a screenshot or video of the issue occurring.

image
image1889×1000 99.1 KB

[END OF FIRST USER REPORT]

:loudspeaker: For anyone who wants to contribute on this issue, Click on the button below to use this template:

Do you have the same issue if you follow the OP’s steps to reproduce it?
•

Provide extra information to complete the original description of the issue:
•

If relevant, provide additional screenshots/video:
•

1 Like
2

helloooo ?

An update - we’re finding the previously typical game usage “external flight planning app” → PLN file → MSFS ->“aircraft gauges” is simply not viable in MSFS2024, so necessarily and VERY reluctantly we’re building external support for PLN files and modifying the aircraft gauges to go outside MSFS to get the flightplan data. If you want to get the information as provided in the PLN there’s simply no other option in MSFS2024 where MSFS2020 had GET_FLIGHTPLAN (html/js) and FlightPlanActivated (simconnect) and FWIW the FS9GPS variables (RPN,JS,WASM)

MSFS2024 leaves only simconnect polling RequestSystemState(“FlightPlan”) as the only (but fragile) way to get the PLN data. The MSFS2020 simconnect systemevent FlightPlanActivated no longer works at all in MSFS2024. However, where FlightPlanActivated in MSFS2020 gives you a reference to the original PLN file loaded by the user, the RequestSystemState polling in MSFS2024 can only give you CUSTOMFLIGHT.PLN which is some new variant of a flightplan constructed presumably by the EFB webapp rather than the original information. The marginal internal API’s in MSFS2024 also only give you information downstream of the EFB webapp which only bears a passing resemblance to the original PLN data.

This issue becomes particularly significant as the flightplan is fundamentally changed if the pilot does any from a range of UI interactions on the World Map involving either the EFB or correcting the departure runway (the EFB PLN load for some reason changes the departure runway from that in the PLN) or possibly simply enters the Flight Conditions menu.

It’s unclear which of the UI interactions causes these radical changes (e.g. a reset) to the loaded flightplan but because MSFS2024 has not issued the FlightPlanActivated event at the time the PLN was loaded, it is now too late for any system inside the sim to recover the original information.

These things surely must be bugs, I can’t believe the intention was to have MSFS2024 nav API support so radically different than MSFS2020 and also fundamentally less functional.

My recommendation would be:

  • Resurrect the FlightPlanActivated simconnect event with a reference to the original PLN file. This at least would give clean access (for a simconnect app) to the original PLN data so providing an ultimate backstop regardless of how opinionated the sim is in filtering/changing the PLN data before providing it over any nav API’s.

  • Rebuild the GET_FLIGHTPLAN MSFS2020 API in MSFS2024 so at least it’s compatible with MSFS2020. If there’s NEW information the EFB webapp wants to put in that API call, then do the obvious thing and extend the JSON to allow that additional data.