• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSX: airport elevation change

Yes, that's pretty much how it was in FS9 and it apparently carries over to FSX.

I think that is awful that we have to resort to dirtying up stock dir's to achieve what should be a commonly-done airport modification.

It should not be that way. I am saying this for the record. :D
I think that is awful that we have to resort to dirtying up stock dir's to achieve what should be a commonly-done airport modification.

It should not be that way. I am saying this for the record.

If I add 1,000 ADE/FSXPlanner airports to the stock Addon Scenery\scenery folder including any modified airports that some have already done am I dirtying up FSX?

Both Scott and Holger have confirmed that what we have done in FS9 for years to correct a airport elevation issue applies the same to FSX. It is not that big of a issue and is done with a very simple process approved by MS.

Explaining why elevations have a priority takes longer then fixing the elevation.

In fact, the process is a little more forgiving in FSX because ACES added a default flatten to the runway border which was not a part of FS9. That now means the Runway, Taxiway and the Apron flatten the default elevation in FSX where as only the Taxiway and Apron had default flattens in FS9.

In the very early days of FS9 Peter McLeland found away to correct airport elevations and since then MS has come out in public to put their stamp of approval on the procedure.

We add modified airports to a higher priority so we can enjoy a Airport that a designer makes more ture to life. We also at times have to add modified headers as a preload to FS9/FSX because of the dangers if we edited a FS9/FSX default file.

I have tested the elevation issue that Scott is reporting and it is a very simple process. Explaining the process is some what a little harder to do.

The first step is to do what ever you want with the ground textures, mesh, terrain for any given airport using all the Utilities available. Forget about the Airport and just make the terrain look the way you want.

The second step is use the process afforded us to add back a correct Hard Floor for both the Airport and the Runways.

I am resurrecting one of my old early FS9 post and will try to keep it short if I can.

There are several elevations that control the airport for Planes.

The default file AP9/APX.bgl is the main elevation control file. If you use AFCAD/ADE and open a default airport and the elevation is 8 ft., that is a base elevation value for the entire airport and the boundry. Boundries are easy to see with a overhead shot and the color of the texture. In FSX these are done with GUID's unlike FS9.

Now if we save our AFCAD/ADE file everything about the ARP Header Airport field elevation, runways, start locations and NAVAIDS agree with the AP9/APX file. At this point the wheels on the USER/AI Plane will make proper contact to the hard floor (8 ft) as long as that aircraft.cfg file has the proper contact points set for that aircraft.

So far everything is correct as long as the AFCAD/ADE mirrors the exact same elevation values that are in the FS default bgl file.

Here comes the first problem. When we made the AFCAD/ADE we copied out of the default bgl file the runway, start locations and NAVAIDS. These also have a elevation associated with them that must always agree with the default bgl file but can now be changed because we unlock them from each other.

When FS9/FSX starts, during the startup process a black bar from left to right tells us that it is Loading many parts of the program including AI Traffic.

During this time a complex algorithm to determine the exact position of all the Traffic in the "Active Airport Visual Zone Sectors" (108NM radius) around our User Aircraft is beening calculated. It then positions all the AI Aircraft at an altitude and speed sensible to the Flight Plan being used by each AI Aircraft.

The gate/ramp aircraft (the ones spawning on the ground) are placed in position at an altitude calculated by examining the default scenery (AP9/APX.bgl) at the aircraft's position to determine the ground altitude at that position.

The scenery is only examined in the layers from the very bottom up to Scenery\0000 (FSX), Africa (FS9) to determine this stationary aircraft altitude...and the aircraft are placed there.

So what are we saying. The algorithim looks at the ground elevation of the AP9/APX ARP Airport Header file for the airplanes sitting at the gates/ramp and then looks at the runway altitude for the planes that are airborne. Of course this should all agree (elevations) both in the root dir bgl's and the AFCAD/ADE.

The airborne AI Traffic proceeds to the airport and when it gets there, the Traffic algorithm determines the altitude at which it is going to land by looking further up in the scenery at Addon Scenery\scenery (AFCAD/ADE files) and upwards even further (3rd party scenery) to find the altitude at its destination.

The AI Plane then touches down at the AFCAD/ADE runway altitude and, if all is correct, the wheels will be rolling along the perceived visual ground.

Now lets say we change a airport scenery elevation like Scott is doing for his test.

When you create your new terrain with a Utility (GUID) you add 4 ft of elevation (now 12 ft) to it for what ever reason (or lower does not matter).

What will happen now is when you start FS9/FSX it uses the default elevation in the default AP9/APX Airport Header (ARP) bgl file (fallback) of 8 ft. and all the gate/ramp planes at the terminals will appear buried 4.0 feet into the ground. This is because they are sitting at default scenery level hard floor of 8 ft not your new 12 ft and furthermore the landing traffic will land 4 feet below the surface at 8 ft and not 12 ft and taxi in this half buried condition all the way to the parking spot.

Ok, we say to ourself I will go into my AFCAD/ADE and raise the airport elevation ARP under properties.

That will not do anything because once again airport elevation is always read back at the AP9/APX bgl as a fallback process.

So we decide to raise the runway and start locations of our AFCAD/ADE to 12 ft. UT OHhhh --- problem ---- Only the planes that are airborne will understand AFCAD/ADE runway elevation so when they land and taxi to the gate/ramp everything appears ok.

However they taxi up to a plane that was sitting there (spawned) from the time FSX/FS9 started up and it is buried in the ground by 4 ft. Once again, airborne traffic seeks the AFCAD/ADE runway elevation and User/AI Traffic on the ground during startup seeks ARP Header elevation in the AP9/APX.bgl.


Remember, the scenery is only examined in the layers from the very bottom up to Scenery\0000 in FSX and Africa in FS9 to determine the stationary planes elevation at the parking spot when you start FS9/FSX.

The AI Traffic that is airborne and landing uses a different algorithm to determine the altitude at which it is going to land by looking further up into the scenery at Addon Scenery\scenery folder (AFCAD/ADE's) and upwards (3rd party scenery) to find the altitude at its destination runway.

Adjusting AFCAD/ADE elevations only solves the landing/taxing/parking problem. If you go to the airport by using "Goto airport menu" AI Traffic Planes will be buried by 4.0 feet. Of course, any other AI Planes that arrive will land and taxi very nicely on its wheels but AI traffic that was there already will remain and then taxi out to the runway, buried by 4.0 feet.

If you place a Airport Header which now has a new elevation of 12 ft. into the Scenery\World\scenery folder, then on startup FS9/FSX Traffic algorithm will look at this copy of the header to establish the altitude/elevation of the AI Planes sitting at the gates/ramp and on startup they will be sitting on their wheels properly.

MS calls that a preload of the basic Airport Header (see my post above). A preload does not always work on everyones computer if it is in the FOLDER/DIR that the same APX.bgl is in. Preload means read before that folder not in that folder.

FS9/FSX Traffic algorithm will also now look at the copy of the AFCAD/ADE bgl file in the Addon Scenery\scenery folder which is now set at 12 ft..

This in turn sets the airport hard floor elevation to match the new terrain liquid elevation designed at 12 ft. and sets the landing runway/taxiway/parking to 12 ft.

The simplicity of all this is do all the Terrain work first by either lowering or raising the elevation.

Now a simple ARP Airport Header placed as a preload and a matching AFCAD/ADE (FS9/FSX) will reset the hard floor elevations so nothing is floating, sinking or crashing into a elevated hard floor runway.
Last edited:
Hi all.

As Jim relates, this is an old topic:


Make a folder to contain "AirportElevationCorrections", and place it in the Scenery Library with greater priority than the actual airport files ( lower down in the pile ).

Then make an airport "stub" XML that only uses the correct elevation you require, compile the BGL and place it in the corrections folder.

Now make your new airport BGLs with the new elevations, and all should be well. You'll need an airport BGL , and a terrain BGL with the new elevations.

Peter McClelland found that the first instance of an airport's elevation controls all subsequent elevations at that airport. So, the new elevation must be loaded prior to the default airports.

I had a problem in FS9. I did a rework of the scenery along the Columbia River from Spokane WA to Revelstoke BC. I had to adjust about 5 airstrips/airports. I compiled the airport header ARP data into a single BGL. I'm not 100% if something about that caused a problem, but I tried about every way I could think of to get that file to work, and it never did until I split out all the airports 1 per bgl.

scott s.
If I add 1,000 ADE/FSXPlanner airports to the stock Addon Scenery\scenery folder including any modified airports that some have already done am I dirtying up FSX?

No, that's what the /Addon Scenery directory is for. I wasn't speaking of it.

I am talking about FS(9/X) default /Texture or /Global/Scenery or /Base /Gauges or /Effects etc etc. etc. directories. In an ideal world, in and ideal FS, in my opinion, we should NOT have to ever place add-on files in those directories. Not that we do not, or could not, but I maintain that the whole system should in an ideal world be set up to where we do not have to do that.

Stock can stay stock and add-on can stay add-on. All my opin of course.

Thank you for posting (re-posting) this information. I do not think it will get lost in the bit bucket here as so many of the PAI posts did.

I encountered this effect after modifying stock airport EDDK by adding taxiways and parking spots using ADE, and adding the revision to folder Addon Scenery (P3D 3.4). For some reason not entirely clear to me, but probably due to tweaks caused by installing Orbx and Just Flight addons, AI aircraft spawned in sim time were hovering several feet in the air, like the UPS 747 in the foreground, while AI already present on loading were taxying, landing, and sitting correctly (like the 747 in the background). So apparently it is just as was stated here, there is a conflict between elevations, registered I don't know where. Obviously, in ADE, airport and runway elevations were set identically (at 92 meters).

Without really understanding what the 'stub' airport solution suggested here was all about, I did try to add a fake EDDK to Scenery/World/scenery using a different elevation, but it did not make any difference. I probably made several mistakes along the way.

Just for the heck of it I then tweaked my ADE EDDK version to use a lower elevation, and to my surprise this did work. The steps in detail were as follows.

1. With the sim running I opened ADE and clicked New airport. ADE has a button that allows you to "get location and altitude from sim". Clicking this, the altitude shown was 77m (not 92).

2. As far as I know one cannot directly change an airport's elevation, but ADE does allow you to save the airport as an editable xml file. I did that and in the xml file I changed all 92m elevations to 77m.

3. Back in ADE, I opened the airport "from xml file", checked for faults, saved and compiled to Addon Scenery, and all AI a/c now behave as they should.
In ADE this can be automated by using Tools/Change Airport Reference Data menu. This will place a stub file into the Scenery/World/scenery folder automatically. I don't know if you need the Prokey payware addon for this or not?
Yes you can do with with ADE as Tom describes and it doesn't need the ProKey. It is quick and easy to do. Opening an airport other than via the ADE project file can cause unexpected problems.
Indeed that does the trick nicely. Thanks, guys, just didn't know where to look.