Not showing all arrivals of ROAH

[tonykwon79]

MSFS2024 SU 1 beta (steam)
AIRAC 2502 Rev.1 bata
Windows 11

There is only three selectable arrivals showing in FMS.

I try to find GUPTIN arrival, but where is it? Is it missed?

I have up-to-date Navigraph HUB and AIRAC 2502 rev.1 beta with MSFS 2024 SU 1 beta.

Here is available STARs which I could see in the Navigraph app.

[NAVDataOld]

Hi,
You also have all these procedures on your system, but the sim turns them off due to the missing runway 18R/36L. That is a sim issue because the scenery is outdated here, and the logic in the sim is: “suppress the terminal procedures when they can’t be assigned to an existing runway.” - That happens with no existing runways (as in this case) or when the runway idents are not correct (e.g., due to a magnetic variation change).

MSFS2024:

Real-World, which we offer:

You see, the second runway is completely missing.

That is not in our hands. We reported this on day one of MSFS2020, but ASOBO/MS hasn’t changed it. We may not add or change runway idents on existing stock airports, even when we could, because, as you see in other add-ons (Fenix, PMDG, all with external databases) and/or our charts, we have all these procedures and the correct airport layouts.

I’m sorry. Please report the outdated scenery to ASOBO/MS. As soon as they add or change the real-world airport layout, you will see all terminal procedures.

Cheers,
Richard

[tonykwon79]

Hello, Rechard,

First of all, would you please correct me if i am wrong?

I had some trials to check and test it. You could refer to the below table.
Fyi, I could uninstall the AIRAC rev.1 beta by removing it in Navigraph Hub.

Is this result firmly related to your explanation above? My understanding is that it is related to the AIRAC cycle data.

but the sim turns them off due to the missing runway 18R/36L.

You said the sims turns off by the missing RWY 18R/36L. However, you could see the result that the three selectable STARs only showing when AIRAC rev.1 beta is available.

Here is a screenshot of capturing AIRAC default and ROAH MK-Studio scenery installed.

Thank you.

[NAVDataOld]

Hi,
Thank you again for contacting us …

I assume that with “default” AIRAC, you mean the stock AIRAC cycle. When yes, your observation is correct, and I will explain why you see all STARs here.

A procedure can be runway-related or can be used by all runways. And that’s the wrong workaround that WT does here. They changed the runway-related procedures (not only stars but also SIDs) to ALL. That means the sim doesn’t check if this procedure can be assigned to an existing runway because it is available for ALL runways - as a result, you see all procedures.

The side effect is, and I use your example, that you can also select the GUPTIN for runway 36R and the GUPTIS for 18L, which is simply wrong. That comes because WT changed the procedures to using “ALL” runways to avoid the runway check and to avoid missing procedures.

We don’t do this because it is wrong; therefore, some procedures are missing, as in this case. The root cause is the missing runway and/or wrong runway idents.

I hope that helps. We reported this shortly after the release of MSFS2020 to ASOBO/WT, but as you can see in MSFS2024, there is still the same limitation, but this “workaround” to set the procedures for all runways is the exact wrong way to “solve” this.

I hope that helps
Richard

[Rodeo314]

What I find interesting here (and also there where Yardbird1975 is seemingly using a custom VTBS) is that installing a custom scenery pack with up-to-date runways no longer seems to fix the issue like it usually does in MSFS 2020, if I understand it correctly?

That’s really unhelpful if that’s really the case

Kudos for still trying to come up with usable MSFS 2024 navdata, if I were Navigraph I would have just given up already

Regards,

Tim

[NAVDataOld]

@Rodeo314

If I understand correctly, installing a custom scenery pack with up-to-date runways no longer seems to fix the issue like it usually does in MSFS 2020.

Yep, Tim, correct - the problem is that we (and I also assume ASOBO/MS) don´t know the rules of loading orders the packages. We only know that it´s not the same as in MSFS2020 because the priority attribute in the content.xml file is not valid as in MSFS2020. We have gotten an answer to our question about how the rules how you can control the loading order of the packages in the ASOBO/MS dev forum and we have added it with 2502, but it seems, that doesn´t work as expected.

So, long story short, we have no clue, at the moment, how we can handle third-party scenes. Personally, I assume that the third-party add-on devs must also follow the rules according to the SDK and the PackageOrderHint selections - but again, I don´t know

Cheers
Richard

[tonykwon79]

Yes, it means the stock AIRAC cycle.
Your explanation is very useful to comprehend the bug occurred.
BTW, I hope it could be fixed very sooooon.