The screenshots were taken with “OrbX AS Himalaya and Central Asia Mesh” installed.
I started writing this post with the intention of trying different configurations (no rolling cache, no add-ons, etc.), but after quitting MSFS to disable the Community folder, the sim won’t start at all for me now. Last time I started MSFS, I received an update (apparently in preparation for the Maverick DLC), but I did not download the Maverick DLC (I have no interest in military aviation). Time to reboot and try again. – edit: Rebooting fixed the “won’t start” issue.
Disabling and deleting the rolling cache did not fix the terrain issue.
Disabling most add-ons, including the OrbX mesh, fixed the terrain issue.
I ran “Verify” from OrbX Central, the process completed without re-downlading any files, apparently all the files successfully passed the check.
After re-enabling only the OrbX mesh, the terrain issue is back.
I don’t remember receiving an update of the OrbX mesh in the past two months. Perhaps something about MSFS interprets locally installed DEM data has changed. I’ll take this to the OrbX support.
Thanks for moving the post. Did you register that the post talks about a new bug in MFS, and is this a known issue?
Just asking out of curiosity.
I won’t bother to open a Zendesk ticket, because Zendesk is a black hole for bug reports (once they’re marked as “solved”, they vanish beyond the event horizon), and OrbX must be aware of the issue and I sure hope they have more leverage.
You might look into “C:\Users[User_Name]\AppData\Roaming\Microsoft Flight Simulator\Content.xml”.
In this file find the “OrbX AS Himalaya and Central Asia Mesh” entry and move it to the top.
Alternatively you can make a copy and then delete the file.
FS-2020 will create a new one, then hopefully with the entries in the correct order.
As I mentioned, I did try it with just the OrbX mesh in the Community folder. Doesn’t that imply that the order of the Content.xml doesn’t really matter?
I’ll try deleting the content.xml, and will report back.
The problem you have seems identical to the problem that EDDS has.
Moving EDDS up in the order solved the problem that EDDS is very bumpy and has big elevation changes on the taxiwys.
Did that problem at EDDS appear with SU9? If not, I doubt it’s related. Because my hill, just like the terrain spikes in New Zealand, definitely appeared at some point after early April, and the DEM data didn’t change. SU9 seems to be the most likely culprit. Or sunspots.
PS: Also, the terrain issues don’t affect the hand-modelled airport itself. They start where the exclusion area for the airport ends. I feel this is a completely different issue.
PPS: Deleting the content.xml had no effect. And I can’t see an entry for the mesh I could manually move to a different position, it looks like meshes don’t even get an entry in content.xml.
Okay, that seems to confirm that it’s a different issue. My issue is most likely that existing elevation data is parsed / interpreted / rendered differently since SU9, that seems to be the only explanation that fits the evidence I’m seeing.
There is nothing you can do about it until Orbx fixes the DEM with all of their mesh. Alaska/NZ/Himalayan mesh is all affected. Some areas are worse than others. There is nothing end users can do until Orbx pushes a fix. Asobo made DEM changes for WU9.
Yes, and you also accepted as a solution that Orbx needs to fix this airport since there was a DEM update. That’s not a bug. There are always changes made to the sim, whether it’s code or some scenery, that third party makers haven’t or won’t test in advance of the next update.
