Last year with X-Plane 10.25 we began to share 3-d lego brick airports. X-Plane 10.30 adds more, and with the X-Plane Airport Gateway now live, I’m sure we’ll have even more 3-d airports in the next update.
One thing this means: conflicts between payware airports and the global airports that ship with X-Plane will become the norm, not the exception. This blog post describes how to keep payware and the global airports from getting into each other’s hair.
Prioritization of Scenery Packs
X-Plane scenery packs are loaded in priority order; in order to ensure that you see your payware, the payware must be higher priority than the global airports. The system for prioritizing scenery packs changed in X-Plane 10.20, so please read this carefully!
Scenery packs in “Custom Scenery” are loaded in the order of scenery_packs.ini. Custom scenery packs at the top of the .ini file are loaded first and override packs below them.*
Any time X-Plane runs and finds a scenery pack not in the .ini, it adds it to the top of the file; therefore when you install new scenery, it starts at the highest priority level. Usually this is what you want.
The airports from the X-Plane Airport Gateway are in a scenery pack called “Global Airports” in your custom scenery – this pack should be higher priority than any base meshes but lower priority than any custom airports.
Exclusion Zones Are Needed
The runway and taxiway data for an airport comes from the highest priority scenery pack that includes that airport in its apt.dat. But 3-d objects are overlaid in an additive manner; in order to avoid conflicts between two sets of 3-d objects, the higher priority scenery pack must include one or more _exclusion zones_.
An exclusion zone is a rectangle in an overlay DSF that tells X-Plane to remove any 3-d in that area from lower priority packs. It lets an author “clean out” an area for later use.
Authors: all custom airports should be built with exclusion zones to protect them from other custom airports and the global airports that ship with X-Plane. If you are working on an airport and there is no 3-d in X-Plane, include an exclusion zone anyway – 3-d may appear in an update.
Users: if you have a custom airport and it does not have exclusion zones, all is not lost. Until the author updates the custom airport, you can do the following:
- Build a scenery pack that contains _only_ an exclusion zone over the affected area in WED yourself.
- Prioritize your scenery packs as follows:
- Payware – unmodified
- Your own “Exclusion zone”
- Global Airports – unmodified
Your exclusion zone pack will filter out 3-d from packs “below” it (including the global airports) and leave your payware clean and unobstructed.
Things Not To Do
There are a few things I strongly recommend you _not_ do in trying to resolve scenery conflicts:
- Don’t modify, rename or delete the scenery packs that come with X-Plane. The updater is just going to try to restore them every time there is an update. You’ll be pushing the rock up the hill over and over again. Don’t delete individual airports out of Global Airports – the installer will just put them back.
- Don’t constantly delete scenery_packs.ini. Some users have told me that they like to rename their folders to alphabetical, delete the .ini file and let it rebuild each time. But this violates the renaming rule and means updates won’t go well. Edit the .ini file to get things the way you want – it’s there for you to customize.
* Why did we pick this? The old way of customizing scenery packs (renaming them) didn’t work well with our updater – the updater would see the scenery pack (under its original name) gone and re-download the pack, wasting time, bandwidth, and creation chaos in the custom scenery folder. The scenery_packs.ini file lets users disable and re-prioritize scenery packs without having to rename anything.
Rectangular exclusion zones are too blunt. They end up excluding autogen, leaving huge blank areas. It would be much better if the airport boundary could be used to exclude 3D objects.
Until we get polygonal exclusion (don’t hold your breath) you can use multiple overlapping rectangles to get closer approximations to the actual shape.
Can we get a list of the new lego-brick airports included in 10.30?
They are in the release notes. See here:
//www.x-plane.com/?article=x-plane-10-30-release-notes
I was working on KJAC today and noticed that the Helipads are spawning all types of aircraft. Does this go in the X-Plane bug tracker or the WED bug tracker?
Thanks.
X-Plane, but only after you have ensured that you have proper start locations.
Why to create a separate exclusion scenery?!
Shouldn’t it work the same way, by opening the custom scenery in WED and add the required exclusions?
Is there a way to display autogen,objects and road networks from a base mesh or underlying scenery in WED? Because without a good satalite picture, it’s sometimes hard to guess where to place an exclusion zone.
Separate scenery so that if the custom scenery is not your own, you don’t have to edit it.
– If you edit it and an update is issued, you must redo the exclusion zone.
– If the custom scenery is NOT made in WED, or does not ship with its earth.wed.xml file, editing it is complicated.
It’s not required that the exclusion zone be PART of the custom scenery.
If you ARE the author of the custom scenery, then of course, go put your exclusion zone DIRECTLY into your WED session!
No – there is no way to get the base DSF’s details into WED. You can include reference orthophotos if you have them.
Questions:
1.) To make our own scenery pack with exclusion zones, don´t we have to include at least one runway or helipad to have WED accept it? Would it not be a cleaner solution to import both apt.dat and .dsf files from the airport lacking the exclusions into WED, adding them and then exporting the scenery pack again?
2.) What do we do with the Aerosoft airports residing in the “custom scenery” folder?
In a way these are “custom airports” that get forced onto the user with every update, some of them with questionable quality.
Shouldn´t they turn into “global airports” themselves?
There are instances where improved versions of these airports (EDDH, EDDV, soon EDDF and others) are actually contained in the “global airports” and conflict with these airports.
Thanks, Jan
Hi Jan,
1. No. If you do not include an airport entry, you do not need a runway, and you do not need an airport entry for an exclusion zone!
2. Whatever you want – change the priority or disable them using scenery_packs.ini – one of the main points of scenery_packs.ini was to let you customize usage of the Aerosoft airports without having to get in a fight with the updater. The updater doesn’t touch scenery_packs.ini.
Re: Aerosoft airports:
– Aerosoft airports that do not contain any custom art -will- be merged into the gateway; aerosoft airports that contain custom objects/artwork will not; you can choose to keep or disable them using scenery_packs.ini.
– A few Aerosoft airports were removed in favor of the global scenery submissions in 1030 (due to conflicts) after verifying that (1) the Aerosoft airport in question had no custom elements and the user submission was more detailed.
This process will continue (e.g. we’ll prune any conflicts again for non-custom-art airports) when we next include additional approved gateway airports, e.g. in 10.35.
Referring to your point 1 Jan;
That’t the way I handle this. It gives me the view on what and where to exclude, in combination with the custom scenery. Placing an exclusion just “somewhere” by referring a satellite picture, will not result in a good quality exclusion and custom scenery package. It might lead to exclusions blanking to much of airport surroundings.
I need to see where the airport is, taxiways, buildings, roads etc… And than decide what to exclude.
Open WED, Import the apt.dat, import the dsf and add exlusions, export, perfect. Sure this process has to be redone, everytime a custom scenery package gets updated. But this does not happen everyday and just takes a few minutes…
Ben,
To be clear in my mind, when I download something from the gateway for correction, and the airport does not have an exclusion zone I should create one or more in some semblance to the airport boundary. Is it correct that those exclusion zones should be “forest” and “objects” at a minimum?
Also, do any problems with ILS / Glide slope go to the Gateway bug reporter?
Regards,
Chuck
When working on a gateway airport:
1. If it does not have a boundary polygon, please _do_ create one. It will be used for flattening if the user selects that, AND it will be used to create airport grass the next time a DSF tile is recut.
2. Add an exclusion zone for objects/forests/facades _only_ if the airport conflicts with the current autogen.
When working on a custom airport for third party scenery:
1. If it does not have a boundary polygon, please _do_ create one. It will be used for flattening if the user selects that.
2. Add an exclusion zone for EVERYTHING covering the airport area, to ensure that you disable a gateway airport “below” you.
Why are exclusion zones mandatory for custom work but not gateway work? Because the gateway airport boundary -is used- in the DSF generation process. So if the current DSF doesn’t have “intrusions”, the next render will not because the airport polygon will be turned to grass.
ILS/Glide slope bugs do _not_ go into the gateway bug reporter at this time – they’re not part of the gateway. File them against X-Plane.
“2. Add an exclusion zone for EVERYTHING covering the airport area, to ensure that you disable a gateway airport “below” you.
Why are exclusion zones mandatory for custom work but not gateway work? Because the gateway airport boundary -is used- in the DSF generation process. So if the current DSF doesn’t have “intrusions”, the next render will not because the airport polygon will be turned to grass.”
Oh, so if I have OSM roads on my airport scenery – and I want them there, for example to have an access road to a hangar area – then the next recut will banish them if I have an airport boundary that encompasses them? That can´t be the intention, right?
Hi Jan,
It’s more subtle than that – the DSF recut process does allow roads (but not autogen) on the airport area, but it does cut them if they intersect actual pavement polygons. The results are imperfect – the problem is that we don’t know whether an OSM road should be modeled as a real X-Plane “road” (e.g. draw asphalt over grass with some street lights) or drawn in WED as white line markings on continuous pavement. Cutting at the pavement is the least bad compromise I’ve found so far.
Are the sceneries that are the source of wasted “time, bandwidth, and creation chaos” described related only to the canned Aerosoft ones?
The Aerosoft airports were the first airports to cause a conflict between our updater and a user’s attempt to rename things; but now the gateway airports fall into this category too. As long as LR is shipping airports (and we intend to – otherwise the world is devoid of airports in the default sim, which is sad) then we need to provide users a way to control the airports we distribute without editing them. Scenery_packs.ini is that way.
Thank for this. Adding the exclusion zone in a separate pack solved my problem. I have taken the approach of using one scenery pack for all of the exclusions (multiple airports) I need. Makes it easy and simple. My payware is back to what it should be now.
I think the way with the scenery_packs.ini was the first step to change something, but I think it was not enough. All the history of flight simulators there was only one kind of custom sceneries or better there was just one dialog or one folder to put them into.
But now there is a need that the custom sceneries needs to be grouped. For example Ground Mesh sceneries are different to OSM sceneries or airport sceneries. At all not the user should say when a scenery needs to be loaded by XP. The scenery developer should do that. And for this Laminar should do something that the developer can define the time, when X-Plane loads it.
I offer a possible solution. Similar to the library.txt there could be a scenery.txt which defines a layer.
I made a tool which can deal with that. It can group your sceneries and generates the correct scenery_packs.ini file.
Soon I will upload the installer at x-plane.org at the moment you can get it on gihub:
//lyckade.github.io/xpstart/
I also made script which can generates that exclusion sceneries. You can download them from my webpage. If something is missing you can write me an I will upload them.
//xplaneblog.de/exclusions/
Right – creating groupings is one of the proposed fixes for the chaos; at this point I’m leaning toward holding off on further structure changes until a major version upgrade to keep from creating a moving target, but in the long term it’s a sane idea.
_EUR_France_apt_LFSJ Douzy v5.3
_EUR_France_apt_PARIS_airfields_DSF
_EUR_France_area_overlay_Mont-St-Michel
_EUR_France_area_overlay_PARIS_suburbs_DSF
_EUR_France_area_phoscenery_PARIS
_EUR_Germany_apt_ED03 Pohlheim_Viehweide
_EUR_Greece_apt_LGKO tdg
_EUR_Greece_area_phoscenery_LGSR Santorini
_EUR_Hungary_apt_LHBP Budapest tdg
_EUR_UK_England_apt_EGLL Heathrow
_EUR_UK_England_apt_EGSS – London Stansted
_EUR_UK_England_area_overlay_EGLC_Canary Wharf
_EUR_UK_Scotland_apt_EGPF Glasgow
_EUR_zContinent_area_overlay_Treelines_Farms_v2
_NAm_USA_MA_apt_KACK Nantucket_v1.2
_NAm_USA_MA_apt_KBOS v101
_NAm_USA_MA_apt_KEWB New_Bedford_Regional
_NAm_USA_MA_apt_KMVY Marthas_Vineyard_2.1
_NAm_USA_MA_area_phoscenery_KACK Nantucket Island Photo v1.0
_NAm_USA_MA_mesh Nantucket_Island v1.0
_SPa_NewZeLand_apt_NIUE Niue Intl. Airport
_SPa_NewZeLand_apt_NZCH Christchurch_AP
_SPa_NewZeLand_area_overlay New_Zealand_Overlay
_SPa_NewZeLand_area_phoscenery Christchurch
_SPa_NewZeLand_mesh New_Zealand
Libraries remain untouched and are grouped at bottom
This is a small example of my Custom Scenery Folder, scenery.ini file bedaned. A simple naming standard could be set in place by LR for developers to follow and none of this bs would exists. Andreas grouping suggestion is dead on but we don’t need another app to it. I don’t think any scenery developer would complain about following a naming standard for their creations when it’s going to guarantee their work gets loaded properly and they don’t have to type two paragraghs explaining how to edit the .ini file. In five years that .ini will be a-kind to the windows registry and users custom scenery folder will look like a windows directory, G forbid, instead of what you see above. Just saying….
Hi Thomas,
I have to disagree.
A naming convention implies that there is one right answer to scenery prioritization. (If there isn’t one right answer, packs must be renamed, which is bad for installation.)
An .ini file implies that scenery prioritization is a local user specific configuration, like joystick settings.
I think there are things we can do in the long term to solve basic prioritization problems (e.g. meshes vs overlays). But consider a payware package and an airport included in a virtual airline’s customization pack. Which should be higher priority? How about two payware packs. Which should be higher priority?
Hi Ben, got any baby puke on ya yet?.:)
I guess we can agree to disagree on this but I’m not quite sure why. If there’s no right answer to prioritization, then we can’t prioritize, can we. Now I’ll give you something to consider, a thousand pictures of your childs life, properly named and dated so you can quickly see those 16th birthday pics or when he he took his first dump, OR, those same pictures thrown in a shoebox,,,well, I know there’re in there somewhere..
I think what you are referring to is a pack with multiple elements in it, (something I disagree with) and that’s where file tagging of some sort would be more efficient, I guess, keeping those elements seperate would be a lot easier but I don’t suppose you can dictate that. But regardless I’ll continue to rename my scenery so I know what I have and don’t have. After 5 kids and 5 grand kids I’m running out of shoeboxes….
Now quit this loafing around and go back work
I’m not saying that we can’t prioritize. I’m saying that we can’t prioritize a priori – that is, prioritization must be done by the user on their machine, not for them in advance by multiple developers who are not aware of each other’s work.
Whilst working on my Guam airport scenery package, I noticed something.. which I totally did not note when doing my initial inspection of the island…
with all graphics settings maxed, I’m only seeing the plausable houses being generated on a very small amount of the roads.. Ill list what I am seeing
all settings maxed…
Forest areas: 1/3 of them are filled in.. the ones that are filled in, are filled in nicely
Roadways: 1/2 maybe less has autogenerated houses/buildings attached
no city area anywhere on the Island.. I dont see any scenery texture representing a city tho.. so I suslect that is just down to it not being there.. Never the less.. the roads… Is there a way to force the roads to spawn the houses? Otherwise I have vast swaths of green grasslands, and residential roads laid out in very nice neighborhood layouts, with not a single house for miles.. and then.. a single road leading to the next village, with houses on each side…
I get the impression there is something fundamentally broken and its not just a “bad scenery” deal.. But I wouldnt know where to start, to try and fix it.
This is both with and without my scenery package ..