NavData package order broken after updating via Navigraph Hub

So this is based on a discussion with your team member Malte on the BATC discord.
I’ll copy paste the discussion onto here, as it explains it quite well I think:
The issue is described in the very first post in bold, if you want to skip the rest.

Fiorentoni [BATC], 17:34

I’ll provide the info here, if that’s okay for you: Simply updating (green button) the base data can lead to an incorrect package order in MSFS 2024 (I don’t use 2020, so not sure about that), effectively “removing” all SIDs/STARs from the sim. Uninstalling (red button) and then installing (blue button) works fine always. This has been happening since about the beginning of this year, so I think it might be an issue with the Hub application actually and an update around that time

Malte H [NVGR], 17:59

Ideally, the report would be in our forum where our navigation data expert could help you out and dig deeper into this. I am not an expert! Do you mean that we change the order? Or that we should? We have been reliably informed that we should not do this, and instead let their own sorting system (based on the package_priority_hint in the manifest) do the sorting. This is new in 2024 (a few months after release). Unfortunately, not all devs are picking up on this new standard (not even on the marketplace) - and all it takes to break their new setup is one incorrect addon that does not specify a hint (or sets an incorrect one).

Fiorentoni [BATC], 18:01

It’s more like an assumption of mine about what happens when it goes wrong. Package order sounds logical since it fits the issue (like a layer of “wrong” navdata being active)

Malte H [NVGR], 18:05

It’s not impossible. Regardless, we’d be happy to look into it! I’m sure there are ways to test it and narrow things down further. For example, removing all addons except our data, deleting the Content.xml file and then starting the sim - can you still reproduce the issue? And if so, does it only affect simconnect, or does it apply to the flight planner in the simulator too? Same in default aircraft? Etc.

Fiorentoni [BATC], 18:07

I haven’t tried and likely only can on the next AIRAC release, but deleting the content.xml might actually fix it yes. As for the other question: IIRC it affects the entire simulator, so no SIDs/STARs on e.g. the A330, but not 100% sure my memory is correct. It’s been 6 months or so since I had it happen and since then I simply remove->install on every AIRAC update to prevent it

whakamolenz [BATC], 21:01

there isn’t one - the facilities API is the standard for retrieving sim related content for airports and airac from the sim. It gives a one for one map to what the sim knowns - so if it doesn’t return the data - then the data data doesn’t exist in the sim also. So basically the users install is corrupt. We aren’t going to work around that. People have already confirmed that when the data is missing from BATC that we get from simconnect - then they also can’t see it in the sim. This to me is why this is a big deal - over and above BATC not working.

Malte H [NVGR], 21:02

My question is how a user can verify whether the issue is reflected in BATC. Not asking for a fallback, sorry if that was unclear!

  1. whakamolenz [BATC], 21:04

    i mean for a lot of people if they just look at frequencies at an airport in the main menu of MSFS they will see clearance and ATIS are missing on virtually all airports.

  2. or if they try and pick a SID / STAR in the planner - they will be missing there too

Hi,
I don’t really understand (or, better, can’t follow) this conversation, and I’m not really sure what you would expect from us. Do you use BATC as a customer or are you a/the dev?

A few things to clarify:

  1. When you remove our data, the SIM is in the same status as after the installation, clean.

  2. Our packages are following the SDK rules, which means all BGLs are checked against the ASOBO/MS in-game tools without any errors

  3. The loading order in MSFS2024 depends on a specific attribute, which was introduced by ASOBO/MS with SU3. This attribute managed the loading orders. When a package doesn’t have the correct attribute (according to the SDK), the sim loads packages at the end in a specific order.

  4. A scenery should never use the navdata delete-flag inside the project, but this is part of the scenery designer and can’t be overruled by us. It is a design decision.

  5. The content file in MSFS2024 does not have the same functionality as in MSFS2020, where the loading order was managed by this file.

  6. The Hub itself is “only” a distribution tool and can’t break anything in MSFS2024 → back to #1

Missing terminal procedures are 99% due to an incompatible package in your installation. Here is the FAQ for this topic. In nearly ALL!! cases, a bad package was the culprit.

How have you tested the missing procedures? Via in-game EFB? Via a stock aircraft (i.e., C172 with the G1000)? Or how? Do you have 3rd party packages/sceneries installed?

Cheers
Richard

Yeah sorry I was a bit in a hurry and hope copy pasting the chat with Malte would be enough :slight_smile:
So I’m a customer of BATC but also part of the mentoring team for new customers, so part of the greater team if you will.

No I do not just remove the navdata, I “remove” and immediately (re)install.
So in short when a new AIRAC update happens:

  1. Click green “update” for the base data = all terminal procedures missing in the sim, everywhere (world map, in-game EFB, default aircraft, via the facilities API etc.)
  2. Click red “remove” and then blue “install” = all good

This suggests it’s a potential issue with the functionality of the Navigraph Hub and how it handles the context.xml when clicking “update” versus “install”.
So it’s not about the navdata package itself, it’s about how it gets “update”-installed vs fresh “install”-ed.
We have many users who experience that after every AIRAC update and it always gets fixed by removing and immediately reinstalling it, 100% of the time.

I can’t 100% say that it happens for everyone neither every time, so there might be other specifics I’m unaware of.

Hi,
Thanks. As I mentioned before, the content.xml file in MSFS2024 does not have the same importance as in MSFS2020. When you look inside the content.xml file, you see that the entries contain, most of the time, only the name and active attribute, but no information about ordering. When you use the Package reorder tool, you see a third attribute called priority. Priority sorted by ascending order = the lower values being mounted first and the higher values being mounted after. This reorder tool should ONLY! be used by an advanced user with a good knowledge of the buckets and priorities. It is a manual way to override the recommended method for loading packages.

The recommended way to manage the loading order is within 3rd-party packages, using their own flags/attributes.

When you check the reorder tool, you will see that most of the sceneries/packages have “types”, and are ordered correctly (automatically via the SIM).

Here are our navigation packages, AFTER! the default/stock fs-base-nav package. You also see that both packages have their own “type”, called “custom navigation data” and “custom navigation data patch”; these “types” are mandatory according to the SDK and have been since SU3.

Back to the Hub. The Hub does NOTHING with the content file in MSFS2024. When packages are installed, updated, or removed, the content file itself will not be changed. The content file will be updated via the SIM during startup, but NOT by the Hub.

Here is a short video, where I install and remove the package, and where you see that the content file will not be changed:

So, the Hub downloads and installs the files into the community folder, not more, not less. The Hub don´t add/change or delete anything in the background for MSFS2024. It is simply a download/decompression/copy tool.

Conclusion:
It is not a Hub issue, and as I have written before, in 99% of such cases it is a 3rd-party package issue, either not loaded correctly (because the user used the re-order tool incorrectly) or the 3rd-party package does not meet the requirements since SU3.

You wrote that this issue exists for many users. I’m wondering why we don’t see any reports here, in combination with BATC.

What I miss is: do you use 3rd-party scenery? Have you tried the FAQ link above? Clean your community folder, excluding the navigraph-packages, and try all again - I´m pretty, pretty sure that all is working as expected.

Cheers,
Richard

With all due respect but how can something that works when clicking in the Hub “remove” → “install” but not when clicking “update” be a 3rd party package conflict?

EDIT: And to answer your questions, yes I’m using 3rd party scenery like everybody using Navigraph does most likely, and no I cannot try anything of the FAQ because it is already working for me currently since I always do “remove” → “reinstall”. I could only reproduce this on the next AIRAC update.
And people don’t report it here because we tell them how to fix it in the BATC discord and from then on they can always prevent it. They don’t bother putting it on another forum where they need to register etc.

Look I only want to ask you to verify if there were any changes to the Hub application around Jan/Feb this year that changed how the navdata got installed when clicking “update” vs “remove->install”.

The answer is no. There have been no changes to Navigraph Hub in that period. The last update was on Nov 21st, 2025. The update did not contain any changes related to navigation data installs.

When you press “remove” and then immediately “install” in Navigraph Hub, you’re just deleting two folders in the community folder and adding them again. No other file modifications.

We also asked a user on your Discord server to try switching to an empty community folder before updating the AIRAC, and the user reported that it worked without issues that time. So far, there are no signs that this would be related to Navigraph (data or application).


Possibly! Personally I am not one of them, and I don’t have any issues. What we are really wondering is not if you are using third-party scenery, but rather if any of them contain incorrectly configured manifest files.

We’d like to test a verification script that checks your community folder for obvious issues in the manifest of third-party packages. You can download it below:

Check-CommunityPackages.ps1 (11.4 KB)

  1. Download the file to your computer
  2. Open the folder where the file is located
  3. Right-click the file and press “Run with PowerShell”
  4. A terminal window should open. Wait for the script to complete.
  5. A report should be saved to the same location as the script under a name starting with community-packages-scan. Upload it here so we can take a look!

Thank you for your cooperation! We’d really like to narrow this down as well, as we understand that it must be annoying, maybe even a bit frustrating, to do the little “Airac install dance” every cycle release. Ideally, we’d like to find the reason behind it - regardless of whether the issue is on our side or not!

Best Regards,
Malte

Another thing that may be worth looking into:

As far as I understand, one of the current strategies to overcome this issue is to delete the Scenery Indexes. Has that worked for you?

If it has, please do the following next time:

  1. Back up the scenery indexes
  2. Do the normal “dance” until it is up & running, in a working state
  3. Back up the scenery indexes again
  4. Send both the “before” and “after” files to us, so we can determine whether anything changed!

I did a quick analysis of these files, and they seem to contain only quick lookups/references for each separate scenery package. No external references (to our navigation data, for example). It does contain some static data, such as runways… That could be an issue, but presumably only when runways actually change in the navigation data…

To summarize, I don’t have enough data to compare - I have never experienced this issue myself! So being able to analyze a sample from somebody who can reproduce the issue would be great!

Hi sorry for the late answer. Your script does not work, the power shell opens very quickly and it’s saying some generic error message (not from your script) and the window closes again.

And yes I delete scenery indexes regularly.

I have been told that the BATC devs will talk to you about it on a different channel, so I will wait for this. Thank you for your cooperation so far

Hmm, that is odd! It should be compatible with the PowerShell version that comes with any modern Windows installation.

Can you:

  1. Open PowerShell (press the windows flag and type powershell)
  2. Open the location where the script is in a new Windows Explorer window
  3. Drag the script file from the explorer window to PowerShell (it should automatically fill the path to the file)
  4. Press enter

What do you get?


Please don’t. Instead, follow the instructions in my previous message.

It is our understanding that deleting the indexes makes it work. But we have looked at the indexes, and there is nothing in there that would explain the change in behavior - each index is just a cache for each individual package. Our navigation data packages ship with their own index and should not be included in the Scenery Indexes folder. It should therefore not be required to carry out this step manually - we want to figure out why it is!

Since we can’t reproduce this issue ourselves, we rely on someone (you?) to upload the before and after versions of these files so we can compare them byte-for-byte and see what the difference is.


We are talking to BATC, but they are just as lost as we are. We need more information. We can’t proceed without these files or the reports from that script.


Thank you for your cooperation so far!

Hello Malte,

Any chance the dependency on PowerShell 7 can be removed? I’ve just tried running it and found it is required. I’ve just spent 20 minutes trying to install PowerShell 7 and having a fight to get it to load instead of 5.1; bit of a headache.

I might have a bit of patience to install a separate PowerShell version, but I think that’s a big ask for members of the community to do as it would seem PowerShell 7 is not a standard version in Windows and a separate version (that is a separate application it would seem, not a simple upgrade to the existing one) altogether.

Thanks, Jason.

FWIW, the script seemingly does requires PowerShell 7, as noted by Jason.

As far as I can tell, even Windows 11 only/still ships with PowerShell 5.1 built-in (known as “Windows PowerShell”), whereas PowerShell 7 remains a separate install.

That being said, both can be installed at the same time:

As I am not at home, I cannot test whether having PowerShell 7 installed is sufficient for the .ps1 script to be automatically launched in “PowerShell” rather than “Windows PowerShell”.

GG Microsoft, I guess :laughing:

Regards,

Tim

Okay so I’d appreciate not having to install PowerShell 7, but if you change the script to work with 5.1 I’ll happily try it.

Okay I won’t delete the scenery indexes. Just to be clear: By “regularly” I meant a couple of times a year, not nearly as often as the AIRAC updates. Last time I did it was 2 or 3 AIRACs ago, so the current state should be “good” for testing.

I can’t promise however I can reproduce the until the next AIRAC update, if at all. As said since it happened twice to me in Jan and Feb this year I always remove->install and haven’t had any problems any more.

I’ll be off for the holidays (1 week) in 2 days, so if you want me to do the script before that you’d need to post the updated version today.

My sincerest apologies! I sent you an earlier iteration of the script by mistake - the most recent version does support 5.1! I’m sorry for the confusion. Should have double-checked the upload to make sure, instead of running the working version locally.

Here is the most recent version, which I have verified again works in the way described in my initial post:

Check-CommunityPackages.ps1 (11.5 KB)


I have both installed (PS7 is considerably faster than PS5), but that just means that this script works fine for me directly from the command line. I also had issues starting it the “graphical” way, but I fixed and tested it locally and thought I uploaded that version!

Unfortunately, I was foolish :sweat_smile:

Understood! Sounds good.


Completely understand. We have been informed about that particular situation by BATC as well - once fixed, it “just works” (annoying and good at the same time, depending on whether you are trying to reproduce it or not haha).

To summarize: The next time that you (or anyone reading this thread) are doing an AIRAC cycle update, do this:

  1. Back up the Scenery Indexes folder
  2. Install the new AIRAC in Navigraph Hub
  3. Start the simulator, confirm you have the issue (if not, try again next cycle!)
  4. Close the simulator
  5. Delete the Scenery Indexes folder (keep the backup)
  6. Start the simulator, confirm that the issue is gone
  7. Add the current and backup version of the Scenery Indexes folder to a zip file and upload it here

Many thanks for helping us look into this! We’re still just as puzzled about this as you are.


No worries! If you have a moment to send them before you go that would be awesome. Have a nice vacation!!

Maybe a red herring but just in case. Posted this in the BATC discord too.

Whaka, Fiorentoni, I read the Navigraph Forum post yesterday and it made me think of the livery issue where if the layout.json doesn’t fully match the contents it doesn’t work (an MSFS behaviour change around that time). By chance I had an AIRAC rev to update. So set up a test where I copied both AIRAC community folder instances to another folder, to do a file comparison post each stage (1 pre upgrade, 2 post upgrade, 3 post use of layout generator and 4 post delete and install) unfortunately the Navigraph issue didn’t happen to me this time. One aspect that was interesting was the folder paths were lower case in all bar the layout generated one which were title case.
I will try and repeat these steps for every AIRAC update. Hopefully I’ll get a breakage. But thought it might be worth getting the 2 layout files from those for whom it has broken to eliminate that as a possible cause or not

The layout.json file will be created by the MSFS fspackagetool and not by us. When this file is really the culprit, you would see this everywhere in the sim, not just in one addon.

This is an essential file for the sim, in every addon which uses the in-game bgl files but this is my personal opinion and has nothing todo with the official support by Malte.

Cheers
Richard

Hi,

I agree that it might not be the culprit especially when Navigraph is used throughout. But I have very much seen the issue manifest itself with only one add-on even down to the granular level of a single livery i.e. MSFS would work with aircraft A and livery B but not the same aircraft but with livery C.

I was interested by your comment that you don’t generate it though (maybe a misunderstanding on my part), surely you must use that MSFS tool to create a fully formed package before distribution? Livery creators have been known to not refresh the file between versions so for example the file size is wrong and hence the breakage.

If I get it breaking I will still investigate this option. It is my go to 1st option. And if I find anything I will report back.

Thank you.

Here’s the log. Both MSFS 2020 and 2024 scans are on the same folder, as I have only one “community” folder. But i don’t have 2020 installed anymore anyway.

Some of the “risky” packages are the automatically generated _CVT folders (e.g. “pmdg-aircraft-77er_CVT_”), so that should be fine. The others are:
FlyByWire Simbridge, Fenix announcements (folder for cabin announcements), Headwinds simulation simlink.

community-packages-scan-20260715-093003.txt (33.0 KB)

Exactly - and that is where you get issues. We correctly regenerate this file for every cycle. If we didn’t, the simulator would refuse to read our navigation data - and that would not change with a restart.

It is our current understanding that the issue covered in this topic can be “worked around” by simply uninstalling the data and reinstalling it, which rules out any layout.json issues!

The file system is case-insensitive, so the casing does not matter! You will find a good mix even in official simulator packages.

This is likely a misunderstanding. We run the package tool, but it is the tool that yields the output that you were referencing. It is not modified by us.

We provide a package ready for distribution, and the tool spits out a layout file that corresponds to the package contents. That is the extent of our involvement in this process!

Thank you! Interesting that some folders are blank/missing manifest files. What are these?

We’ll analyze the logs further. If anyone else who is experiencing this issue would like to help out, more logs would still be really helpful!


We’re also still looking forward to the before-and-after files if/when anyone in here can capture them during an upcoming AIRAC cycle update!