I posted this on the official MSFS forums but wanted to check in with Navigraph directly.
TLDR: How can I be sure that Navigraph data is overriding the incorrect Asobo data at an airport if I cannot select a priority in the scenery order any more?
I have a problem with AG Sim’s EBBG not showing any SIDs or STARs (in the EFB/CDU/FMS) even though they are visible in Navigraph Charts and the airport runway has the correct name e.g. 04/22. I don’t know if this is a Navdata error from Navigraph or an error from Asobo, so I’m posting this here for clarity.
I spoke with AG Sim who found out that Asobo changed the default runway to 4 instead of 04 with SU2 update. AG Sim advised me to reorder the Navigraph data using number priorities, which don’t exist in SU2.
AG Sim: If there is a place for priority value, make navigraph nav data base “1” and navigraph navdata “2”. fs-base-nav should be 3 or more.
navigraph-nav-base and navigraph-nav-jepp are both below (further down) in the content.xml than the fs-base-nav but the LBBG scenery is placed above both of these. Is that correct? It’s automatically placed there. Shouldn’t fs-base-nav load before everything else?
Thank for any help you can give,
Toby
EXAMPLE FROM MY CONTENT.XML
Line 28 <Package name="communityfs20-agsim-airport-lbbg-burgas" active="Activated"/>
Line 781 <Package name="fs24-fs-base-nav" active="Activated"/>
Line 1311 <Package name="communityfs24-navigraph-nav-base" active="Activated"/>
Line 1312 <Package name="communityfs24-navigraph-nav-jepp" active="Activated"/>
Hi,
It is not relevant whether the runway idents have a leading zero or not. Further, the content.xml file in MSFS2024 does not work the same way as in 2020. In other words, I’m pretty sure this is a 3rd party scenery issue and that this scenery isn’t really MSFS2024 SU2 compatible.
The information from the 3rd party devs (with the re-ordering) indicates this because, since SU2, you must set a special flag in the manifest file when you create the scenery project. This was not done here, and therefore, the 2024 load the packages into the wrong order internally.
Sorry, but that is nothing that we have in our hands. This is not a navdata or ASOBO issue - it is a 3rd party issue.
The yellow-marked information confirms this. When you try to select an approach, you will see that all approaches are included according to our charts.
So, it´s a third-party issue—it is not enough to compile scenery with the MSFS2024 tool and mark such scenery as “MSFS2024 compatible.” A few settings are working differently in 2020. The package loading order is one of these changes and was improved massively, thanks to ASOBO.
Thank you for taking the time to check this and for your comprehensive reply. Much appreciated. I have forwarded the developer a link to this page so that they can see and, hopefully, fix the missing SIDs and STARs.
Thank you
Please replace these lines with the lines in your content.xml file. I have set the priority tag manually here:
-999 = the navigraph-nav-base package
999 = the navigraph-nav-jepp package
The SIM loads the packages from the lowest to the highest priority number. That means:
The nav-package will be loaded first →
followed by all the installed third-party sceneries →
Last, the nav-jepp packages (which contain the terminal procedures).
With this solution, our package (with the terminal procedures) will be loaded at the latest every time and “overrule” all other packages before it.
Please try this “workaround” when you can. When it works (what I expect) - we will consider how we can set this via the Hub.
Thanks, Toby, for the confirmation. We will consider implementing these priorities in the Hub so that no one needs to change anything manually.
In your case (with this solution), you can be sure that every third-party scenery you install on your system should show the correct information and should take it from our data, because every package will be loaded “between” our packages now.
Thanks again (also for your kind words). Enjoy your Monday, and let us know whenever you have a question.
Richard
