Airport developers did nothing wrong in this matter. Because it was asobo’s fault. The same file works fine in msfs2020, but it is broken in msfs2024. And, it is obviously a priority problem. If you add an “A” to the beginning of the wfss file name, the WFSS scenery priority will be first, and there will be no such problem.
1 Like
Hi,
Yes, this is correct. The priority system, like in MSFS2020, doesn’t work any longer. The loading order now depends on the package filename only, and that is the case here, which is why the solution with the “A” works.
That was also why we renamed our navigation files so everything would be loaded correctly.
I don’t know if this is now a new feature or, again, a simple bug. We will open a ticket in the dev form to get a clear answer in the next few days.
Cheers
Richard
Not true here, unfortunately. A prefix does not help. content.xml is showing the WFSS scenery in first line of all packages.
But still, HH* waypoints are not valid anymore. Asobo A330, A321, A320neo.
No matter if Navigraph is loaded or not.
Unload the WFSS scenery and the waypoints are back.
Kind regards, Sailando
The priority system is changed and the content.xml file is useless. This is a ASOBO/MS issue and has nothing todo with our data.
Cheers
Richard
Have you ever thought about why the same file has no navigation data offset problem in msfs2020, but it happens in msfs2024? Obviously, it is unfair to blame wfss for this problem, as they have no way to solve it. We players can only rely on powerful developers like Navigraph to work with asobo to investigate and solve this bug. Please wait for Navigraph’s follow-up news.
Kind regards, Roger
1 Like
content.xml is not completely useless. Your first navdata beta for MSFS2024 deleted the content from this file and just added your (outdated at this point already) priority settings, thus disabling all 2020 packages. But either way, adding the prefix does not fix the issue with missing waypoints - Navigraph data or not.
off topic but for clarification: WFSS is claiming that their scenery works with 2024. So talking about 2020 is misleading here. And even if Navigraph can fix it with their dataset, WFSS would still have an issue with plain MSFS2024. And the issue disappears if the scenery is not loaded. So who is to blame here for not testing full functionality before going to market?
Kind regards, Sailando.
Again, the content.xml in the current version and the current version of the MSFS2024 are useless for the package loading order. When you have more details and know how we can set up our package so that we don´t need to rename it, please let us know. Thank you very much!
Cheers,
Richard
It´s not “only” a Navigraph issue—it´s possibly a combination—but when this happens with the stock data, too, it can´t be the only issue we can fix.
That’s exactly the issue … the packages will be loaded in the wrong order … believe it or not.
Cheers,
Richard
I would be careful with calling that an aircraft issue. Only a few aircraft like the Fenix are using a separate navdata set. The built-in aircraft are using what the sim is presenting (WT built-in or Navigraph add-on). Without the scenery, the sim is presenting matching waypoints with correct data and the distances can be calculated by the FMC correctly. With the scenery loaded, the HH* waypoints cannot be found in the presented dataset. This is leading me to the assumption that the scenery is adding some navdata layer or filter or wrong pointer or what have you. Of course this is not intentional, but testing would have revealed the issue and should have led to thorough investigation and more dev work before release.
Just my2c. Sailando
I have closed the topic for now … I will reopen it, when we have any updates to this!
Thank you very much,
Richard