Hello, I have noticed that some waypoints in the VHHH SID and STAR are at incorrect coordinates. This issue only occurs when the third-party scenery, specifically VHHH from WF Scenery Studio is installed. I have emailed the developer regarding this issue, and they mentioned that their scenery does not contain any navdata file and they are unsure why this would happen.
I have tried setting both navigraph-navdata-base and navigraph-navdata to top priority in the Content.xml file, but the issue still exists. I have also seen that other users are experiencing this problem, so I hope the Navigraph team can look into this.
I found that this happens if you use a third-party airport. But why a third-party airport would cause this is worth investigating by asobo. In addition, I also found a solution to install navigraph and then adjust the priority. Ensure that navigraph-navdate has the highest priority, and airports with navigation bugs have a smaller priority than it.
Same here. It looks like it only happens at some 3rd party airport. All SID/STAR waypoints are thousand miles apart. Not sure if a different database have to be selected in the MCDU but it doesnât seem to be the case. Any idea anyone?
Can confirm. Canât get any of the VHHH RW07 approaches to load correctly. The waypoints are thousand of miles away and this is with stock and the Navigraph beta that was released today. I tried putting the Navigraph data on top using the scenery reorder tool but got the same result.
Before msfs2024 was updated to 1.2.7.0, this method was available. But after the update, the format of content.xml changed, so I donât know if the method of adjusting the priority still works. In addition, I found that the content.xml of navigraph navdate for msfs2024 is still in the old format.
Hi gents,
First of all, Merry Christmas, and we hope you can enjoy a few free days with your families.
To the topic:
I can confirm that there was a change between 1.2.7. and the current version of the sim, which was released for a few days. You canât set the loading order as in the past via priorities. It also seems that the ordering/loading of the packages is now prioritized via the filenames, which is very strange, but what would also explain the solution with the A?
All is a little bit unknown at the moment, and we try to make more analyses in the next couple of days to know exactly what the ASOBO/MS guys expect. Also, I will open a case today about this in the development forum to get an answer.
We do our best (also in the next few days) to fix issues and solve problems in the data if you find some. In this special case, we must wait on ASOBO/MS ⌠but we will see if we can offer a workaround.
Can confirm the SIDs works, for the STARs only 1 waypoints has invalid coordinate but removing it from the fligth plan does not affect the approach.
Edit: SID waypoints do not contain any speed and altitude constrains
Merry Xmas all!!. Same thing happened to me in VHHH once out of 3 flights. When selecting the SID FPS suddently dropped to 2 digits. Not sure if it is AIRAC related but it was not happening before. BTW. I added an âAâ at the biginning of the scenery as suggested by @Super6uo and now all distances and coordinates are correct. I really donât understand what kind of nav database is stored in the airport scenery
According to WFSS, their airport scenery does not include navigation data.so he was also confused as to why this happened.In addition, before msfs2024 1.2.7.0, I tried to put the navdate of navigraph 2020 version in 2024. The same situation will occur with the ZBAD of navigraph.
This topic is very confusing due to so much noise behind ⌠therefore a few words from my side to this topic:
the MSFS2020 AIRAC data are not 100% compatible with the MSFS2024 therefore, to compare data from MSFS2020 in MSFS2024 doesnât make any sense, even when it looks equal
It seems (we have also seen this in the last two days) that the package loading order is now in the alphabetical order of the files. That means forget the content.xml file or the priorities thereâthey are useless.
Try to avoid increasing complexity with third-party sceneries. We can also test against the stock scenery only because itâs impossible to know where and if there is an existing third-party add-on. When everything is working with the stock sceneries, it should also be okay with third-party sceneries.
In my eyes, MSFS2024 is also a beta version because you see different results in different aircraftâso the only valid result is that in the in-game EFB. When terminal procedures are okay there, you should expect that they are also okay in the in-game aircraft. When not, you know that the developer of these aircraft uses another/outdated/old framework or that the aircraft itself has a bug.
When you compare only the last posting with the LEKEA1A departure, thatâs 100% an aircraft issue because the data itself contains only sequences of waypoints but no distances. The distances will be calculated using the FMC itself.
⌠and the waypoint sequence is correct so far - here from the EFB in the WorldMap (which should be the reference):
You see a perfect pattern. All waypoints are in the correct sequence, and there is no 0.0 waypoint or waypoint outside the area.
Again, the in-game EFB in the WorldMap is the real reference here because this tool uses the up2date framework from WT. When you discover any issue in the aircraft, you can almost be sure that it is an aircraft issue.
I know itâs possibly complex to understand even when all in-game aircraft use the same data source - but it looks like each aircraftâs development is different, resulting in such issues.
So, my wish for reports, please. Try the in-game EFB first. When the procedure there looks good, you can be sure the data behind it are okay. After that, look into your FMC/S and compare the results.
Wish you a Merry Christmas too.
It works now with rev2 beta. I donât know what is happening before when i tried earlier today.
Many thanks for looking into the issue
Thanks for taking care of the issue!
All my tests are showing that the flight path can be messed up by a scenery. No matter which built-in airliner I am using.
Fenix is different, because (as I understand it from the Navigraph hub) itâs using Navigraph data in a different way (external to the sim) and wonât be affected by the scenery behavior.
Once I load VHHH from WF Scenery Studios, HH* waypoints are not available anymore.
Without the scenery loaded, no matter whether planning with WT or Navigraph, I have the perfect pattern (e.g. ABBEY4A STAR). Since these WPs are not in the navdata anymore once the scenery is loaded, their coordinates are set to 0.0 and hence these distances will be calculated.
Loading the scenery first (by adding an A_ prefix to the directory name) did not solve it.
Without this scenery, everything is fine in VHHH.
I totally understand that Navigraph canât solve scenery issues, but it would be great to hear from your experience what a scenery developer can do wrong in general and how we users could possibly fix a situation like this.
