EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

MH1212, developer of the Prefab Airports for X-Plane, requested this feature, and it looks like we are going to be able to sneak it into X-Plane 10.45. (If we hit bugs, it might get pushed out to 10.50, but so far things look okay.)  The feature is: the ability to exclude objects by airport ID without using exclusion zones.

Right now when a custom scenery pack replaces an airport (via apt.dat), the old apt.dat is completely ignored. But the DSF-based overlay objects, facades, etc. are included; the custom scenery pack has to use exclusion zones to kill them off.

With this extension, the DSF-based overlay objects in a scenery pack can act as if they are in the apt.dat file, disappearing when the apt.dat airport is replaced. This means that when you replace an airport (via apt.dat file) not only do the runways go away, but so do the overlay elements.

Here’s the win: we can export our global airports from the X-Plane Scenery Gateway this way, and custom scenery will remove the overlay elements automatically just by replacing the apt.dat, even if no exclusion zones are present.

Here are some details:

  1. The scheme works if the underlying airport is correctly marked as having its objects and facades “inside” the airport. So unlike exclusion zones, this scheme works if the underlying airport is modified, not the overlaying airport.
  2. This is a new scheme – no existing scenery already does this; scenery must be re-exported to gain access to this functionality.
  3. The functionality requires the latest version of X-Plane, but is harmless to old X-Planes – the DSFs will still load.
  4. Exclusion zones still work and are still recommended; if you are making custom scenery and you are on top of autogen or an old scenery pack that is not modified using this new scheme, only an exclusion zone will save you.

There are two big advantages of this scheme:

  1. We (Laminar Research) re-export our collection of thousands of airports on a regular basis, so we can tag the entire set of global airports using this new scheme and have them ready for by-airport-ID exclusion very quickly. So this scheme will start to help conflicts immediately.
  2. The scheme doesn’t require modifying the overlying scenery at all. There are freeware airports that are effectively orphaned – the author cannot be found and the license doesn’t allow the community to modify them*. Since these airports cannot be legally redistributed with exclusion zones, this technique will help.

Once X-Plane has this extension and the global airports are re-exported using it, global airports will fully disappear when any custom scenery pack replaces the airport by apt.dat, even if the custom scenery pack doesn’t have good exclusion zones.

This functionality will be available to third parties in WED 1.5 when it goes beta. In WED 1.5, if an overlay element is in the folder for an airport, it will be excluded when that airport is excluded. If an overlay element is ‘loose’ in the outer level hierarchy, it will not be excluded by airport (but will be affected by other pack’s exclusion zones).

Since gateway airports already have the objects “in” the airport folder, they are already authored to make this scheme work.

If you create your own DSFs using a low level tool like DSF2Text, the DSFLib source code, or something else crazy, I have posted the proposed schema here. That’s a technical link for people tinkering with the DSF format itself, but if you’re in that category, please do ping me to get early test materials. (The new code is also on GitHub.)

Two warnings to custom scenery authors: if you are creating a custom airport scenery pack, especially payware, please read these very carefully:

  1. This is not an invitation to stop using exclusion zones. There are plenty of scenery packs in the wild that do not have their objects tagged by airport, as well as autogen and all sorts of junk that can be under your payware. If your airport doesn’t have an exclusion zone and it conflicts with another pack, it is your fault. Go add exclusion zones, like I told you to do years ago.
  2. If a scenery pack from X-Plane Airport Gateway is removed by your pack (by airport ID) then our exclusion zones are removed too. This means that if trees on the runway have been removed by an X-Plane Airport Gateway airport, you will no longer get those exclusion zones for free.  You must exclude those trees yourself!  (If you put exclusion zones in from point 1 this is a non-issue.) Test your airport with global airports enabled and disabled to make sure your pack is good.

 

 

* As a side note I consider it a real problem that airports get uploaded and shared with the community under licenses that don’t allow for abandon-ware to be maintained. It’s clearly the right of the author to use any license you want, but as a community I hope we can encourage freeware authors to use a permissive open license.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

15 comments on “A New Way To Exclude”

  1. Another great step forward! I am sooo tired of hearing about how bad the new global airports are, because they “show up” on the premises of your favourite custom airport.

    It is a good way out of the current dilemma, because it is next to impossible to educate some people – some designers are stubbornly opposed to placing exclusion zones…

    In the end it´s the result that counts, and having two airports with the same ID display simultaneously will only be desired in the most remote circumstances…

    Good idea, Jan

  3. Ben, in the “X-Plane 10\Resources\default scenery\sim objects\apt_lines\taxilines.dds” i can see a red line, though it’s not available to select in the WED, it shouldn’t be too hard to fix, can you do that? I need these red lines! 😀

    Thank You in advance!

  4. Thanks for addressing that issue, unfortunately the fix could only come from a global reference, individual fixes were always going to be problematic because one many developers are just not very good at even the most simple of details (exclusion zones) and two a lot of scenery gets created then just left in the (download and) custom scenery folder. There is nothing wrong with the actual good scenery, but the developer is sometimes long gone off the scene.
    Yes you can fix the scenery yourself, but I have spent way too much time just doing that this year just to make my custom scenery folder even workable…. a relief! thanks SD X-PlaneReviews

  5. Well done Ben, this is one of the most welcome feature since the introduction of the Gateway airports. My fav custom sceneries will no more fear any new xp update 😉
    By the way can we have the list of the new 722 apts added with 10.45? Thanks.

  7. A question: one airport ID on my Custom Scenery folder prevents the corresponding Global .dsf file from being loaded. Ok, but what if on that same .dsf other objects and exclusions referring to other airport IDs exist, which I may be willing to preserve? Do I lose the whole tile or only the objects connected with my Custom airport ID? Thanks.

    1. You do not lose the whole tile – overlay elements (polygons, objects, exclusions) are associated with the ICAO code on a -per element- basis. (We need this to make sure the right stuff is excluded for the right set of custom airports.)

  8. I know this is probably not the best place to post this but is it possible to work on a measuring tape like tool to put into WED that way when we are drawing out taxiways we can drop a tape measure node then drop another at a distance that we can see then connect the taxiways to it and when we are done we can remove the tape nodes?

Comments are closed.