When editing my launching scripts for Prepar3D I was reminded that there will be certain area numbers in the scenery.cfg file where the corresponding layer number does not increase commensurately. So for example, when the area number increments by 1, the layer number might increment by 2, thus bypassing a particular layer number altogether whereas area numbers never do this (at least from what I have seen). If ORBX Central for example, updates my scenery.cfg file, it will purposely jump 5 layer numbers at one point where the area number only jumps by its usual 1.

I have always wondered....what is the reason for this? Why do the layer numbers jump "ahead" of the area numbers? Is there some technical reasons related to P3D that requires this or is it something that the scenery developer requires?

I stand to be corrected, but I believe it is something to do with the fact that there two ways to add scenery, one through the P3D interface and also through the xml file method. So if you see a gap in the sequence then that is because the scenery holding that place was installed through the other method. 

@JonP01, a lot of scenery packages don’t create an entry in scenery.cfg. They use the Addon method. I don’t know the answer to your question but would strongly recommend you use Lorby’s Addon Organizer.

This allows you to reorder all airport packages irrespective of the system used to install them.

It’s not critical that scenery.cfg entries have consecutive numbers.

Thanks for the replies. Everything works fine - I was just wondering why it did it but I think you are both right about the add-on method. If I count the number of areas I have that use that method, it equates to the numerical gap as it were.

The reason I had some concern is that I have my own scripts to launch P3D since I have a lot of different configurations of a whole lot of things depending on what aircraft I am flying, what region and even what time of day (or night). Everything automatically reconfigures at launch and part of that entails tailoring the scenery appropriately. it is when I buy new airports I notice this (and I do not try to alter it since I have done that in the past thinking I was "fixing" something wrong but with unintended consequences!).

Jon, it sounds you’re using something very similar to the product I bought. SimStarterNG.

I have a different profile for each of my six aircraft. Yes, just six. 😁

https://www.aerosoft.com/en/shop/flight/p3d-fsx/prepar3d/tools-missions/3064/simstarter-ng-p3d

Mine is all "in house" but it would do the same thing. I actually have 168 x prepar3d config files!!!!!!!

12 minutes ago, JonP01 said:

Mine is all "in house" but it would do the same thing. I actually have 168 x prepar3d config files!!!!!!!

Crikey! 😳

7 hours ago, Ray Proudfoot said:

Crikey! 😳

Yes, double crikey!

I just use the P3D Display settings and have 4 sets of configs. That, of course doesn't affect weather or scenery exclusions. Perhaps I might get to those later, if I feel like it.

It does sound crikey but it is not as crazy as it appears. There is obviously only one actual config file - it is just that my scripting changes whatever needs to be changed for a particular run and there are 168 possible variations. One of the reasons I have the prepar3d.cfg file changed before launch is that some parameters would be changed were I to venture into the user interface. Also, it would be a pain to keep changing all the settings (the scripting otherwise changes automatically) every single time I go out and fly.

But the logic is:

1. I have 7 aircraft. So that is at least 7 variations to begin with since the sound parameters and force feedback parameters are different for each aircraft (the controller file is different too but I just get my script to copy in the relevant control file as part of the launch).

2. Within each of those 7 aircraft I have two further subsets - one for night and one for day but all they actually change is the colour of the AI labels (so they are equally visible at night and during the day - dark blue for the day and white for the night).

3. Then there is a further subset for AI traffic variations - since I do not want to overload the sim with too much aircraft traffic (I am not a huge fan of it anyway but like to have some), I have an option to pick either commercial or GA traffic.

4. And finally, I have different settings for road traffic for different combinations of ORBX regions - although I own most of the regions I ended up dividing them up into 6 "regions" - each having different settings that reflect how much of a system load they represent (though in this case the main thing that varies is the density of the road and sea traffic though as we all know that does make quite a difference in some cases).

so the combinations are 7 x 2 x 2 x 6 = 168

On 3/8/2026 at 5:29 PM, JonP01 said:

When editing my launching scripts for Prepar3D I was reminded that there will be certain area numbers in the scenery.cfg file where the corresponding layer number does not increase commensurately. So for example, when the area number increments by 1, the layer number might increment by 2, thus bypassing a particular layer number altogether whereas area numbers never do this (at least from what I have seen). If ORBX Central for example, updates my scenery.cfg file, it will purposely jump 5 layer numbers at one point where the area number only jumps by its usual 1.

I have always wondered....what is the reason for this? Why do the layer numbers jump "ahead" of the area numbers? Is there some technical reasons related to P3D that requires this or is it something that the scenery developer requires?

The area number is the "ID" of a scenery element. You cannot have the same area number twice. The layer number is just the "priority", it tells the sim which scenery element shall be loaded first and which next. Layer numbers are not unique, you could put any number of scenery elements on the same layer number if you wanted to. You can also skip layer numbers, that is not a problem for the sim.

As per the SDK spec, external scenery definitions (add-on.xml) don't need any layer numbers, and they don't have area IDs at all. Instead, they are loaded in the sequence as they appear in the file system and/or in the two add-on.cfg files. Back in the day when I made P4AO, I added the layer numbers to the add-on.xmls anyway - to not leave the secenery loading sequence to chance.

Edited March 19Mar 19 by Lorby_SI