FAQs for data designers

Where are all the elements of an ILS positioned?

X-Plane requires all ILS components to be placed in their correct, real-world locations.

The localizer aerial is positioned beyond the far end of the runway it serves, pointing back down the runway towards approaching aeroplanes. This ensures that an aeroplane can have localizer guidance on the final stages of its flare to land (after it has crossed the runway threshold, or as it begins its missed approach). The localizer is almost always perfectly aligned with the runway it serves … but sometimes they are slightly offset, usually to provide terrain clearance on the approach. If so, the localizer position will be moved so that it still points across the touch down zone of the runway. You can see an example of this at KBOS.

The glideslope aerial is positioned to one side of the touch down zone, usually perpendicular to the touch down zone markings on the runway, close to the VASI / PAPI location. It operates on a frequency paired to the localizer frequency.

Marker beacons are becoming rarer, but are positioned along the final approach path. The outer marker is usually at the Final Approach Fix, usually 4NM to 7NM from the runway threshold, and is sometimes paired with short range NDB (called a Locator Outer Marker or LOM). The middle marker is closer to the runway, usually at point at which an aeroplane flying the glideslope should be at the Decision Height (DH) for the approach, typically about 3,500 feet out from the runway threshold. The inner marker is very close to the threshold, and is rare – they are used for Category 3 approaches to very low DHs.

How will my custom scenery affect the “master” airport data?

X-Plane scenery packs are loaded in priority order; in order to ensure that you see your payware or custom scenery, it must be higher priority than the global airports.

Scenery packs in “Custom Scenery” are loaded in the order of scenery_packs.ini (a text file in the Custom Scenery folder). Custom scenery packs at the top of the .ini file are loaded first and override packs below them. The scenery_packs.ini file lets users disable and re-prioritize scenery packs without having to rename anything.

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.

Can I use custom nav-aid or fix data in a custom scenery package?

No. Any earth_nav.dat or earth_fix.dat files in a custom scenery package are ignored by X-Plane.

It is not possible to uniquely identify a nav-aid by its ID or frequency, so it would not be possible for X-Plane to match nav-aid information in a custom scenery package against the matching data in the ‘master’ earth_nav.dat file. (This process does work for airports because the airport ICAO codes are guaranteed to be unique.) In addition, the purpose of the custom nav-aid data may be to correct the ID or frequency of a ‘bad’ nav-aid, making making the suppression of the ‘bad’ master data impossible. Similarly, fix names are not unique at a global level.

So, changes to nav-aids must be made in the ‘master’ earth_nav.dat file and fixes must be changed in the earth_fix.dat file. Send any corrected data to be included in the master database via the bug reporter on the Airport Scenery Gateway.

My airport does not have an ICAO or FAA code. What should I use in X-Plane?

Within the USA, almost every airport has either an ICAO or FAA airport code. But in many other countries, smaller, disused or private airports do not have any kind of published code. But, X-Plane requires a unique code for every airport.

The way we traditionally solved this was by allowing airport authors to invent an identifier similar in style to the ICAO codes used in that region. So, for instance, since German civil airports follow the pattern EDxx, someone might have invented ED01. This causes a problem if ED01 gets assigned to another airport in the real world. As of X-Plane 10.40, we’re moving to prefixing these fictitious identifiers with an X. So, German civil airports that have real ICAO identifiers follow the pattern EDxx, while German airports with only made-up identifiers follow the pattern XEDxx.

If you need a new airport identifier created for either an airport with a long official identifier, or an airport with no identifier in the real world, just file a “New Airport Code Request” on the Airport Scenery Gateway bug reporter and we’ll get you taken care of.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn