No, no … sorry, I don’t understand this as “blaming us.” I only want to clarify what we have done and why we have done this. All of this is buggy, or at least without any documentation, and it’s nearly impossible to offer a good, valid, working solution/workaround.
We are starting at zero for testing after every patch (and we don’t know how many patches they have made in the last couple of months due to their architecture).
So, I am still puzzled by the fact that there is very little chatter about Navigraph’s navdata and MSFS 2024 issues.
I am still consistently having issues with missing waypoints. What is bizarre is how with one launch of the sim it will be fine, and the next launch it won’t.
How come no one is talking about this? Is it just me?
I’ve done several delete and reinstalls of the sim, I’ve tried no add-ons and various combinations of add-ons. I consistently have this issue.
That’s the thing - the first simulator had an obvious (and manual) way to sort packages. We no longer have this ability in 2024, and it seems like the whole ecosystem is still adapting to the new way of doing things. It has not been clearly announced, so I would not be surprised if a majority is still unaware that this change has even been made.
Until every scenery developer (and maybe other types of add-ons, too) has changed their published products, there will be occasional issues. Even then, the new system they introduced must also work as intended - no guarantees there.
Some users will be entirely unaffected, and others will see more issues, which may explain the lack of further feedback in this forum. I have yet to reproduce these issues myself, so I can imagine that many others simply never see any issues.
Our navigation data for MSFS 2024 is currently in beta, and this sentence is still very much valid:
We’re still actively investigating ways to make this stable. It’s the main priority, and it has been since the launch of the new simulator! Please bear with us while we work on further improvements.
I want to reiterate, again, that I don’t see this as a Navigraph issue, per se. I fully understand the beta aspect, too.
I have just been surprised by how little talk there is of this issue, either here or elsewhere. At times, it feels like “me” problem.
Elevating the Navigraph data to a very high position within Content.xml via the Package Reorder Tool has seemed to keep it working consistently, again. We’ll see, however.
Here’s another data point for your discussions with Asobo.
I am an ex-Xbox pilot. Subsequently, I have a significant amount of Marketplace content. As I have been testing compatibility, I’ve enabled/disabled said content via “My library”.
I believe that doing so breaks the custom load order for Navigraph. In other words, MSFS respects Content.xml on launch, but it may not be respecting its custom load order entries when enabling/disabling content via My library.
I enabled a few things, entered an airplane, started entering a flight plan and immediately found a missing waypoint.
This wasn’t an issue the last time I used the sim; and that time I hadn’t messed with any content in My library.
Hi,
Yes, the loading order is really an issue, but this is fixed with SU1. The problem is that the scenery designer doesn’t know or needs time to implement it.
We have still set the correct flag, but that’s only halfway. The scenery designer must do the same, and that is nothing that we have in our hands.
We hope this “transition phase” is short, but again, there are so many 3rd party devs (freeware and payware) that this needs time.
The logic of loading the packages is wholly changed in MSFS2024. The content.xml file is not as crucial in 2024 as in 2020, at least for the loading order.
The thing is, the issue I’m seeing isn’t scenery-related.
I enabled/disabled a couple of aircraft in My library, which caused the issue yesterday.
Today, I added a mod to the Community folder for an aircraft and the Navdata is, once again, missing waypoints. Again, no scenery added or removed; just a mod that alters the sound of one aircraft.
I do not believe this issue to be fixed in SU1, since I keep running into it in a number of different ways.
…unless today’s latest issue has been caused by today’s AIRAC update. I did update Navigraph today.
Whatever the reasons, it is simply not fixed for me. I keep having to elevate Navigraph higher and higher in priority every time it does this.
To add to this, I barely have any add-ons installed, as well.
Hi,
I’m sorry that this was misinterpreted. To be more precise, it’s a “third-party addon” topic because nearly all third-party addons must follow these new ordering rules.
Here from the current SDK:
It’s also for mods that overwrite some stock models. This is a very complex topic, but it looks like this package_order_hint flag is very important to load all packages in the correct order. Therefore, I would be cautious with packages from MSFS2020 because these packages don’t have such a flag (not necessary in MSFS2020 due to the other loading logic).
Our tests are without ANY! 3rd-party scenery and without ANY! Mod installed to see if the data works as expected in the vanilla state. We can’t test all third-party addons. Therefore, we must trust that the third-party developer follows exactly the SDK.
So am I understanding that Asobo has overlooked this aspect of 2020 add-on compatibility? And, if so, this is going to be a never-ending issue unless they implement a fix for 2020 add-ons?
Hang on, looking at the list of “tags” they have on that SDK page, there is no tag(s) for aircraft and, presumably, NONE would be utilized. I’d have thought that NONE would be the default for add-ons without a tag, such as 2020 add-ons.
I guess I’m confused why enabling/disabling aircraft (which don’t show up in the Package Reorder tool) and their mods would be an issue here.
I get it if scenery and their ilk are problematic, but not aircraft.
I’m not a scenery designer, an add-on aircraft developer, or a mod designer, so commenting on the different tags would be unprofessional. I only know, that we have set the correct tag—confirmed by ASOBO—and that these tags are important and “control” the loading orders. I can’t say more; sorry.