5 hours ago, Farlis said:

Let me guess they are distributing it over Simmarket?

Then that is Simmarket's fault because they charge developers for uploads.

No, Justsim have released an new Version "LOWL_V2" so its not only an Update, its a new scenery with PBR-textures.

15 hours ago, Reader said:

It makes ALT (elevation adjustment) files redundant, as P3D v4.5 Hotfix 2 no longer looks for them at all.

I did a bit more testing and it's not correct, that P3D does no longer look for these files, but now priority is the key.

Orbx Vector AEC files have been used to state the "new" Vector elevations "first" in the scenery library. At this priority these files now have no effect anymore (in 4.5 HF2).

With HF2 FSAeroData is messing everything up, because it re-introduces an almost complete set of stock-airport stubs with their stock-elevation at the highest priority Even it will not replace any runways or taxiways, etc.

Now a very simple workaround for Orbx Vector users is to just move the AEC-folder to the highest priority in the scenery library.

These AEC airport stub files will then re-define the (correct) airport elevation with highest priority and this fixes the Orbx Vector elevation issues at least.

If one has other addon airports installed (OPENLC also replaces some airports!) then you would have to manually create some stub airport files for these in order to use FSAerodata to update he navaids.

Marc

Hello,

I ckecked the other way around with and without the Airport Elevation stub at the highest area number (according to P3D own scenery list).

I have :

at level 515 - elevation  10ft    - airport elevation stub
at level 460 - elevation    0ft    - region elevation stub
at level 348 - elevation  846ft  - 1105 Base
at level 257 - elevation    0ft    - region NZMF
at level 190 - elevation   10ft   - airport NZMF

I made a test with and without (.off) the airport elevation stub with NO impact on display...

I confirmed with disabling also level 460 (according old rules the airport should have been rised to 846 ft  (not few feets as before)...

The three views are exactly the same (and alt-Z shows the SAME altitude).

As mentionned by Jabloomf, a few minutes ago, this could bring a huge performance improvement especially with sceneries using add-on.xml entries, but can also bring a mess with mesh inteferences (AEC or equivallent would have to be at the top of the scenery ?).

Maybe this could justify a tool to directly patch the airport altitude with the mesh information or to go a step further, P3D would take the altitude directly for the mesh (not sure, but is it not the way XP is working ?...)

Interesting ....

 

Edited October 12, 20196 yr by gaab

23 minutes ago, Mischung said:

Now a very simple workaround for Orbx Vector users is to just move the AEC-folder to the highest priority in the scenery library.These AEC airport stub files will then re-define the (correct) airport elevation with highest priority and this fixes the Orbx Vector elevation issues at least.

 

Moving the Vector folders to the top of the library would be likely to have numerous unintended consequences, in particular on Aerodata.

It seems that the key here is to have the addon airport at the highest level and then P3D will read its elevation from its own files,

instead of from an ALT file or a Vector file?

It seems to be that this new method will solve more problems than it causes.

Edited October 12, 20196 yr by Reader

43 minutes ago, Reader said:

It seems to be that this new method will solve more problems than it causes

I suspect that most 3rd party developers will adjust to the change including fsaeordata.

6 hours ago, Reader said:

Moving the Vector folders to the top of the library would be likely to have numerous unintended consequences, in particular on Aerodata.

Sorry, but I do not understand what you mean?

In my case I created a special set of files just including airport stubs for Orbx Vector and the OpenLC airports.
Then I put them at the top of my scenery database. They are just stubs with no data at all (just with correct elevation data).

In my case everything works absolutely fine. NavData is up to date and elevation issues are gone. I have no other addon-airports in use, so for me this is a perfect workaround.

So I cannot see any unintended consequences or am I missing something? 🙂

Marc

4 hours ago, Mischung said:

In my case I created a special set of files just including airport stubs for Orbx Vector and the OpenLC airports.
Then I put them at the top of my scenery database. They are just stubs with no data at all (just with correct elevation data).

Hello Marc, 

Is this a difficult process to create these stubs and the file structure for them? Can you show how its done if you have the time? 

Thanks

Jose 

Hi Jose,

for Vector this process is very easy, because the folder with the stubs is already there, just move the layer ORBX!VECTOR_AEC to the top of the scenery database.

For the OPENLC product-line this required a bit more work, but this is what I did:

1. Copied all existing OPENLC-airport replacement BGL-files in one folder (they are named 01_APTxxxx.bgl / 02_APTxxxx.bgl / APT_xxxx.bgl - always APT in the name)
2. Then I decompiled all these files (using the tool Bgl2Xml from ScruffyDuck) - I created a batch file for this, not manually done 😉
3. Afterwards I wrote a small python script, which parses these files and creates a new set of files with just the stub information of the OPENLC-airports.
4. Using the bglcomp from the P3D-SDK you can compile them again (of course with another batch-file) and now you have a set of stub-files for OPENLC
5. Just paced this above the Vector AEC layer and up to now it looks good to me 😀

Of course this was not done in 5 min, but now FSAerodata is still updating all airports without having plateaus and dips...

Marc

Contrary to popular belief, those stub ALT BGL files not only were used to change the airport elevation, they were also the only way to modify the airport name (for example, from Jones Municipal to Smith International) for an unchanged ICAO code. From my limited testing, that renaming feature has not been modified in HF2. If the stub file was used just to change the name, a copy must be left in scenery/world/scenery and a new copy (or the ADE file with the new name) must be in a folder that is the highest priority in the scenery library. LM should have put more thought into this before they made the change to the preload files behavior.