version: X-Plane 12

Sources of Weather Information in X-Plane 12

Sources of Weather Information in X-Plane 12

There are several places in X-Plane where information about weather are available. This tech note describes each of them and how they relate to each other. Different sources are highly likely to return different information, by design. Weather conditions at any given point will be different to the weather at any other point, in both location and time.

The Weather Configuration

While this is not really a source of weather information, it does have an impact on the weather. When set to 'static weather' mode, very specific conditions may be set. These conditions are applied when you start your flight as a starting point. The simulator's weather system will then, from this starting point, add more details specifically including a small amount of randomness which changes across both time and distance from your starting airport. Any weather information found from any of the simulator's other systems should be expected to be similar to, but not an exact match for, static weather.

The Map Window

It is possible to use the map to get basic weather information about an airport, by clicking on the airport's icon to show the 'Airport Details' popout. On the 'Details' tab, an item labelled "Conditions", or "Current Conditions" in 12.1.0b5 and higher, shows the weather at the clicked airport at the exact time the popout was opened. The displayed information does not change after the popout has opened, so will become stale. Although the text given is similar to an ATIS message, it is not ATIS; it has no rounding, corrections or unit adjustment applied.

ATIS Transmissions

Many airports will offer an ATIS radio service. This is accessed using your aircraft's radio. The conditions given are those that were present at the time and location of recording of the ATIS message, and that recording will have a validity of either 30 or 60 minutes. Therefore, you should expect ATIS messages to differ from current conditions to some extent especially towards the end of their validity period. If conditions change significantly, a 'special ATIS' message will be issued and the ATIS identifier will be changed. ATIS frequencies are listed in the ATC dialog and on the map.

AWOS Transmissions

Similar to ATIS, AWOS messages differ in that they are fully automated messages based on conditions at the time and location of transmission. They are differentiated from ATIS messages by the absence of an ATIS identifier, and the prefix "AUTOMATED WEATHER OBSERVATION".

The simulator provides AWOS services for untowered airports and ATIS for towered airports, where the airport is defined as having an automated weather service. Both ATIS and AWOS services have rounding applied to wind direction and will use local temperature- and elevation-corrected pressure units, and regional units and phrasing.

"Request Departure Information" ATC call

At airports with a tower but no ATIS service, you can request departure information from ATC before you request taxi. This provides the weather conditions at the exact time of the radio response, at the airport's reference point.

"Request Weather" ATC call

While you are in contact with any controller that is based at a specific airport, including regional controllers, you may request current weather at their location. This provides the weather conditions at the exact time of the radio response, at the airport's reference point.

"Request Weather At…" ATC call

While you are flying a planned (IFR) route under ATC control, or if you are receiving flight following and have programmed named waypoints into your FMS, you may request weather conditions along your route from most ATC controllers. This provides the weather conditions at the location of the navaid, at the exact time of the radio response.

Pressure in some ATC messages

Many ATC responses from controllers will include QNH settings. For airport-type controllers (clearance, ground and tower), this pressure will be valid at the time of the call at the exact location of the airport. For regional or tracon/approach controllers, the pressure given will be the single pressure value used for the controller's entire airspace. Currently airspace segments are not simulated. A regional controller, especially a large one, is likely to give you a different QNH value to the one given by an airport.

"/sim/weather/aircraft/" Datarefs

These provide an instantaneous readout of the exact conditions at your aircraft's location.

"/sim/weather/region/" Datarefs

These provide an instantaneous readout of the base conditions for the region surrounding your aircraft; at the time of writing this is approximately one square degree. These conditions will not match conditions at any specific point within that region, since the weather at any given point is also based upon local information where possible (i.e. METAR data), and is further affected by the weather simulation's inherent random variation.

METAR files

These are snapshots of the current weather at an airport at a particular time in the past, used as a data source by X-Plane's 'Real Weather' mode. While many are updated hourly or more, others may not be updated for significant periods of time. They are inherently data reflecting a time in the past.

To produce X-Plane's weather in 'Real Weather' mode, these are blended with another datasource which is based on a forecast of regional weather in the near future. This blending of point samples from the past with a generalised regional forecast for the future, plus the small amount of randomness layered onto the results, means that the simulator's weather should be similar to actual conditions but will rarely if ever be an exact match with any other source of weather information.

External Websites

External sources should never be used for obtaining weather conditions in the simulator, even when flying in 'Real Weather' mode. They are highly unlikely to match due to the random elements to X-Plane's weather simulation, different data sources, and differences in the way that the various data-sources are processed.

Leave a comment

B738 FMOD Studio Sources

The following is a download link for the sources for the Laminar Research default Boeing 737-800 sound bank. The project requires FMOD Studio 2.02.19 or greater. You can download FMOD Studio from the FMOD site.

⬇️ Download B378 FMOD Studio Project.

You can use this project to learn how the sound for the 737 was created and experiment using the Live Reload feature. As the License below explains, you can only use it for learning purposes and you may not redistribute any part of it.

License

LICENSE AGREEMENT: B737 FMOD PROJECT AND SOURCE AUDIO CONTENT

This B737 FMOD Project and Source Audio Content License Agreement
(the "Agreement") is a legal agreement between you and Laminar Research. 
By downloading, viewing, and in any way using this B737 FMOD project file 
(the "PROJECT"), you agree to be bound by the terms of this Agreement. 
If you do not agree with this Agreement, do not use this PROJECT. 
All rights not expressly granted to you here are reserved by Laminar
Research. Upon acceptance of this Agreement, Laminar Research grants a license 
to you to use this PROJECT expressly for educational or personal purposes only.
This license is granted worldwide and in perpetuity.

This Agreement includes license terms for:

a) The PROJECT, and any .bank files built thereof (altogether, the "FMOD
CONTENT"), and

b) The included .wav sound files (altogether, the "SOURCE AUDIO").

GRANT OF LICENSE:

1. FMOD CONTENT:
    
    You may modify, remix, redesign, and build upon the FMOD CONTENT.
    
    You may NOT share the FMOD CONTENT, original or otherwise modified.
    
    You may NOT broadcast video of the FMOD CONTENT, original or otherwise
    modified.
    
    You may NOT use the FMOD CONTENT for commercial or non-commercial purposes.
    
    You may NOT share, copy, or otherwise redistribute the FMOD CONTENT
    or any part of it.
    
2. SOURCE AUDIO:
    
    All SOURCE AUDIO is owned by Laminar Research.
    
    You may NOT share, copy, or otherwise redistribute the SOURCE AUDIO.
    
    You may NOT use the SOURCE AUDIO for any commercial or non-commercial
    purposes.
    
    You may modify, remix, redesign, and build upon the SOURCE AUDIO, provided
    it is strictly for PERSONAL use.
    

If you have any questions about this Agreement, please contact Daniela
Rodríguez Careri at <daniela@x-plane.com>.
Leave a comment

Customizing ground vehicles

Starting X-Plane 12.00 you can customize the airport ground vehicles. Since those are part of the APT.dat defined scenery, they are loaded early and separately from DSF scenery, and cannot be replaced via a EXPORT override on the library.txt like other library objects.

This feature allows you to make vehicles that you can include either locally in a custom scenery or as a part of a library to use in one or many of your airports. Bear in mind, though, that the custom vehicles have to be placed manually at each parking location. There’s no global replacement.

Each “Service vehicle parking location” in WED now has a “Custom vehicle” field where you specify your replacement object. The object itself will be moved around at the same speeds as the selected service truck, for the same purpose (crew car, GPU, fuel truck etc), i.e. the behavior itself is not customizable.

All components of the object (sounds, driver object etc) can be customized by the library author by providing suitably named components to go along with the vehicle object.

How to

  • Create your vehicle 3D model with animations. The datarefs available for animations and sound are those under sim/graphics/animation/ground_traffic/ (see the Dataref list)
  • Create the FMOD sound bank for the object:
    • Use the template provided in the “Using FMOD with X-Plane” documentation
    • On the SND file (see SND file specification) use start/end conditions according to the datarefs mentioned above. You can also use those datarefs as parameters inside FMOD Studio to modulate the events.
    • Ensure the events are assigned to the Master Bank and routed to the Exterior Processed > Environment bus.
    • If you need to apply signal processing (reverb, EQ, etc) to the sounds, don’t apply them to the Environment bus itself because they will be overriden by the corresponding aircraft bus processing. Instead, create a subgroup under Environment to do so.
  • Expose the object on the scenery or library library.txt (see library.txt specification) so WED can use it, via a EXPORT directive. For example
    • EXPORT MY_LIBRARY/airport/vehicles/crew_car.obj custom_objects/crew_car.obj
  • In WED, place a parking location of the kind of vehicle you want to replace (fuel truck, catering, etc) and under the “Custom vehicle” field, enter the virtual path to your custom vehicle from your library. For example
    • MY_LIBRARY/airport/vehicles/crew_car.obj

Download our example vehicle and FMOD Studio project here

Leave a comment

How to make an open hangar

1 – As a first step, you need to put down an exterior facade. You can use any of the facades from lib/airport/hangars/flat/xxx.fac. Make sure the shape is orthogonal (CTRL + Q).

2 – Rotate the polygon (CTRL + R) until you get the first segment (marked with a small circle) to the place where the open doors should be. This is very important for future steps (aligning interior facade and doors)

3 – Set the desired height of the hangar (8, 10, 12, 16, 18, 22, 26, or 30). This is very important because the exact dimensions of openings and related parts may vary based on facade height.

4 – Now set the correct wall types inside vertices. The most important is of course open doors (blue segment). For others, you can use whatever you need (solid walls, windows, etc).

5 – The exterior part is finished. Lock the shape to prevent unwanted edits (turn on the lock icon).

6 – Draw the hangar interior (lib/airport/hangars/flat/parts/interior_xx.fac) following the exact shape of the exterior. Use "snap to vertices" function. You should not break the exterior shape because it is locked.

7 – Make sure WED preview is turned on (menu View / Toggle Preview). Zoom to the hangar corner and use an appropriate isometric view.

8 – Set the corresponding height of the interior (7, 9, 11, 15, 17, 21, or 29). Note the height is one meter shorter than the exterior.

9 – With SHIFT pressed, drag the polygon toward the inside roughly 0.5 meters.

10 – Drag the segment with open doors towards the inside until reaches the end of the opening side. Make sure you're dragging only the single polygon segment (two vertices at a time), not the entire interior polygon.

11 – Add a new vertex (using ALT + click) to the intersection of the polygon with the opening. Do the same on the opposite side of the doors (with an appropriate isometric view angle)

12 – Now rotate polygon segments (Ctrl + R) to get the first segment (white circle) to the corresponding position with the exterior facade polygon. This is very important for the alignment of both facades!

13 – Set the proper wall type to the opening (and other walls eventually). The Interior is done – you can lock the shape.

14 – Choose the door facade you want (lib/airport/hangars/flat/parts/hangar_door_xx.fac) and draw a single-segment polygon. Points should be placed exactly on the border of the exterior facade polygon (blue segment). Use the isometric preview to fit both endpoints.

15 – Set the corresponding height of the doors (matching hangar height levels – 8, 10, 12, 16, 18, 22, 26, or 30) and set the wall type to "Hangar_doors_open". You are done!

NOTE: All standalone door facades also have a wall with closed doors (Hangar_doors). This makes no sense in combination with the interior of course. But you can use it for making any combination of the exterior facade design and doors. In that case, you don't need to worry about the interior facade but everything else above is still true.

Leave a comment

Ground power in X-Plane 12.0.8+

Ground power provides electrical power to a parked aircraft, so its systems can be operated without depleting the battery even if the engine(s) are turned off.

The ground power plug must be plugged into the aircraft first, then a relay can be closed to actually connect an electrical bus to the external power source.

Plugging the power in

Aircraft made for X-Plane 12.07 and earlier always have voltage on the ground power receptacle if the aircraft is stationary (ground speed is less than 1 knot).

Aircraft made for X-Plane 12.0.8 need to call for ground services to have the ground power plugged in. In order to that, preconditions must be met:

  • The aircraft must be stationary (ground speed less than 1 knot)
  • The aircraft must not be on a runway (it needs to be on a ramp or taxiway area, or on grass)

Then, the user can request to “service the aircraft”. This will cause power to become available. Whether an animated ground power unit will show up in the 3d world to service your aircraft depends on

  • the aircraft author must have specified a location for the generator cart to be parked relative to this aircraft. That’s in Plane Maker, in the “dock ports” tab, “has ground power cart” must be checked and the coordinates specified
  • the airport must have a route for ground service vehicles to reach your aircraft parking position

In the absence of the above, the electrical power will still work, but no animated generator cart will be visible.

Making contact

Once the power is available, the available voltage will be readable in the sim/cockpit2/electrical/GPU_generator_volts dataref. If this reads 0, nothing is plugged in. This information can be used by aircraft to power “hot buss” items that might be available even before the switch in the cockpit is activated. This can also be used to indicate the availability of ground power to the pilot, such as the switch lighting up.

Now, the dataref sim/cockpit2/electrical/GPU_generator_on can be used to switch the GPU relay to on. Now, all connected busses will be powered from GPU power, all equipment can be used and the batteries will be getting charged.

Third-party overrides

At some third-party scenery airports, or with some aftermarket aircraft, the use of X-Plane default ground services might be undesirable. For these, the ground power can be overridden by plugin logic, so the third party product can decide ground power availability rather than X-Plane’s ground service system.

To take control of the GPU power, the plugin needs to set sim/operation/override/override_GPU_volts to 1 and then write the desired voltage to sim/cockpit2/electrical/GPU_generator_volts or 0 if the GPU isn’t supposed to be plugged in right now.

In order to not fry any virtual circuits, the plugin should check the dataref sim/aircraft/electrical/acf_nom_gen_volt to find out whether the user aircraft expects 12V, 28V, 110V or anything else.

Leave a comment

Weather Datarefs in X-Plane 12

Weather Datarefs in X-Plane 12

The old weather datarefs have been marked as deprecated in X-Plane 12 and replaced with two new sets. The old ones will remain in place but anything referencing them should be changed to use the new ones as soon as possible. The good news is that this should be fairly straightforward.

Previously the values returned in the datarefs were relative to the user's aircraft. This was fine for handling instrumentation but not ideal for working with the wider environment. There are now two similar sets of datarefs, one for the weather at the aircraft's exact position, and one for the surrounding region.

Aircraft

In general, all the old datarefs that lived under sim/aircraft/ have been moved under sim/weather/aircraft/ with very similar names. The only real thing to note here is that in some cases, units have changed. Also, all these aircraft-specific datarefs are read-only. This makes sense; the aircraft's immediate environment is a point sample from the regional weather.

Cloud, wind and turbulence datarefs are no longer represented by individual datarefs with an array-like notation, they are handled as real arrays. This means you should do proper array handling of these by querying the size of the array using XPLMGetDatavf() before your first read, and allocating enough space accordingly. Doing this will allow your code to continue to work with no changes if in the future the array size is changed. Temperature and wind arrays have already been increased to 13 elements from 3.

It's important to remember that the aircraft's immediate environment is a snapshot of a single point in a simulated 3D volume. This volume contains deliberate variations from whatever the base weather is, whether that's a fixed preset coming from the UI or a composite of available real-weather data if this is enabled. You should not, in other words, expect any value reported at the aircraft's position to exactly match any value you may see elsewhere that isn’t based on the aircraft’s position.

Region

New for X-Plane 12, the base weather that defines the aircraft's surrounding region is provided as a distinct set of datarefs under sim/weather/region/. Right now 'region' roughly corresponds to a square degree but this may vary in the future. The region base values determine a starting point for X-Plane's own weather simulation, which gets added on top. As with the aircraft's datarefs, this means that you should not expect any value returned in these datarefs to exactly match any value you see elsewhere since the weather at any given point is taken from the combination of the base weather and the weather simulation, not the starting data for that simulation.

Atmospheric Altitude Levels

Atmospheric temperatures are defined at preset altitudes which can be found in sim/weather/region/atmosphere_alt_levels_m . If you are working with temperatures aloft, please use the altitudes given in this array and don't hard-code them. The altitudes, or the number of layers, may change.

Modifying the Region

Most of the regional datarefs are writeable, meaning that you can use these to change the weather in a large volume surrounding the user's aircraft.

sim/weather/region/change_mode
This controls X-Plane's internal weather simulation, when used with static weather, by setting a general trend over time.

sim/weather/region/variability_pct
This controls the internal weather simulation's variability for those parts which use random noise to generate variation. The base weather also varies with distance from a given reference point. Typically the reference point would be the selected airport if you use the UI to select a weather preset, for example.

sim/weather/region/update_immediately
When this is non-zero, any changes to any regional dataref except clouds will take place immediately. Otherwise, the changes will start to fade in over a short period of time, currently 1-2 minutes. Clouds are handled a little differently because there is a delay between the cloud data being determined and the results of the GPU-based cloud simulation being returned. Even with update_immediately set to true, clouds will generally take a minute or so to update to the new values. When you absolutely, positively got to kill every cumulonimbus in the room, you can use the sim/operation/regen_weather command to trigger an immediate full reset of the current weather.

API Access

For simpler access if you are using a programming language that can use it, the X-Plane SDK contains some basic weather data access functions. These allow you to get a weather snapshot – that is, the equivalent of the aircraft datarefs, the output of the base weather plus the weather simulation – at a specific point.

While you are free to request weather for distant locations, the accuracy of the data returned will drop significantly outside of the current region. Errors are reported via the standard XPLMSetErrorCallback() mechanism.

Leave a comment

X-Plane 3-D HUD

X-Plane 12 features a 3-D HUD – besides drawing HUD markings on top of the 3-d scene, the HUD aligns to the world in 3-d with the same parallax error that a real HUD would have, and looks “far away” to a user in VR.

The HUD consists of three separate authoring elements:

  1. An area of the aircraft’s 3-d panel texture that has HUD markings.
  2. A 3-d mesh in an aircraft attached object with appropriate objects, that will serve as the HUD glass. The HUD image will only appear when the glass covers the screen space area in front of where the pilot “perceives” the HUD to be.
  3. Plane-Maker settings to calibrate the 3-d HUD’s alignment.

Setting Up the HUD in Plane-Maker

Plane-Maker’s viewpoint cockpit screen contains a section “3-D HUD” that requires three types of information:

  1. The field of view angles of the edge of the HUD glass. You may need to calculate these in your 3-d model – it is the number of degrees to the left, right, up and down from from the pilot looking straight ahead at the default pilot viewpoint.
  2. The pixel position on the 3-d texture panel that the HUD image will be taken from. The lower left is 0,0, and the unit is pixels. You will be able to see this rectangle in the panel editor to validate that it is correctly set up, but it must be changed in the viewpoint cockpit screen.
  3. The panel region. If your 3-d cockpit uses panel regions, pick the region number for the HUD here. If your aircraft does not use panel regions, you should leave this as the default “0” value.

Creating the HUD Graphics

In the 3-d panel editor, click the HUD icon in the upper right button bar (just to the left of the “2-D” icon) to view the HUD preview lines. If the panel is set up with a 3-d HUD, you will see:

  • A cyan box showing the edge of the HUD’s image and
  • A HUD ladder showing the horizontal center, horizon, and 2.5 degree vertical increments.

You can use these queue marks to calibrate your HUD graphics.

⚠️ WARNING: as of X-Plane 12.0.8 the “2-d” HUD instruments only work in the 2-d HUD, and the “3-d” HUD instruments only work in the 3-d HUD. We recommend using generic instruments for the 3-d HUD.

Setting Up the 3-d HUD Object

The 3-d HUD needs a glass element in an object, with a special attribute

    ATTR_hud_glass
    TRIS	36 18
    TRIS	54 18
  ATTR_hud_reset

Steps to Debug The HUD

First, confirm the HUD image is present by using the texture browser to view the night panel texture.

Second, confirm the HUD glass is present by temporarily removing the HUD glass attributes and giving it a debug color texture.

Leave a comment

Airport Data (apt.dat) 12.00 File Format Specification

Revision History

20 Dec 2023     Minor addtion of options and values added by 11.30 through 12.00
7 Nov 2022      Minor corrections for  X-Plane 12 early access.
1 May 2022      Add row codes 1402, 1501 for custom service trucks & jetways

16 Nov 2021     Spec created, based upon most recent apt.dat 11.30 spec.
                Add new surface types for runways, taxiways, helipads.
                Add property extensions for runway markings and lights.
                New row code 1500 for moving jetways.
16 Nov 2021     Updated new lines styles added in 11.30, correct wording in row code 21 name field
11 Apr 2019     Updated with new COM frequency capabilities added in 11.30.
14 Feb 2018     Minor corrections to Definition of Data fields
25 Jan 2017     Spec created, based upon prior apt.dat 1050 spec.

Applicability

This specification (APT.DAT 1200) is supported in X-Plane 12.00 and later and by WorldEditor 2.5 and later. The prior specification for airport data was APT.DAT 1130, which is recommended for X-Plane 11.30+.

This spec is an extension to 1130 – all features in 1130 are fully supported.

Support for Deprecated File Formats

The deprecated file specifications (APT.DAT 1050, 1000) are still supported. A dwindling quantity of custom airport data exists only in this format. So airports defined according to these specifications can be included in a file otherwise complying with the most recent specification.

Overview & Scope

This specification defines core airport data for X-Plane.  This includes the locations of runways, taxiway and apron pavement, basic airport ‘furniture’ (VASI/PAPIs, windsocks, light beacons and taxiway signage) and communications frequencies.  It also includes attributes for each of these features to fully describe them (eg. it includes runway surface type, runway markings, taxiway lighting and markings, approach lighting, taxiway sign text, etc).

This specification (1200) introduces new surface types, extensions for runway markings & lights, and new row codes.

This specification does not include scenery objects (such as buildings, static aeroplanes or underlying terrain textures).

Basic concepts

  • Latitudes and longitudes are described in a decimal notation (eg. 20.12345678) up to 8 decimal places.
    • A latitude of 50 degrees 30 minutes south would be defined as -50.50000000
  • North latitudes and east longitudes are positive.  South latitudes and west longitudes are negative.
  • All headings are referenced to true north (not magnetic north).

File Characteristics

The apt.dat files are plain text files:

  • Fields in the data can be separated by one or more white space characters (space, tab).
    • By default, the files are generated so that columns of data are consistently aligned, but this is not required.
  • Blank rows are permitted and are helpful to differentiate between airports.
  • Comments are permitted and are indicated by “#” as the first two characters of a row.

File Structure

It is recommended that all airports be created in WorldEditor (“WED”).  This will ensure that all structural requirements listed here for airport data are met.  WED version 2.5 is required to support all the features in this spec.

In common with most other X-Plane data file specification, header rows of data define the origin of a particular copy of a file, and define the file specification version.   The file specification may be followed by a reference to a sequential release data cycle and build number for the data, and a version information message:

I
1000 Version – written by WorldEditor 2.5.0r2

Each row of data has a numeric ‘row code’ as its first field, to define its content.

  • The top level of this hierarchy defines an individual airport, defined by an airport header row (a row code of ‘1’, ‘16’ or ‘17’).
  • Subsequent rows define elements of an airport:
    • Runways  (including helipads) follow the airport header row (one row per runway).
    • Pavement (taxiway/apron) definitions  have a header row followed by an ordered list of nodes that define its boundaries:
      • Each pavement definition must each have a single boundary with no overlaps with itself.
      • Nodes on this outer boundary must be defined in a counter-clockwise direction.
      • Boundaries must be terminated with a node with a row code ‘113’ or ‘114’.
      • Pavement definitions may overlap with another pavement chunk.  But this is not recommended – instead consider precise alignment of adjacent features by ‘snapping’ nodes to identical locations in World Editor (WED).
        • A pavement definition can never overlap with itself.
          • The sequencing of the pavement definitions is the layering in which they will be rendered in X-Plane, top-down.  So the last piece of pavement in the file will be rendered underneath any others with which it overlaps.
          • Holes  can be defined for pavement (through which the underlying terrain texture will show):
            • Hole boundaries should follow the termination of the pavement definition in which the hole occurs (starting with a row type ‘111’ or ‘112’).
            • Hole boundaries are defined in a clockwise direction (ie, opposite  direction to the boundary nodes).
            • Hole boundaries must form a closed loop (ie. must terminate with a row code ‘113’ or ‘114’).
            • Each pavement definition can have zero, one or multiple hole boundaries.
            • Hole boundaries must be contained within the outer boundary of the pavement definition.
            • Holes cannot overlap each other.
            • After creating a hole boundary, it can be ‘filled’ with a new pavement chunk (probably using a different surface type).
              • Linear features  also have a header row followed by an ordered list of nodes that define the line:
                • Linear features can be closed loops (terminating in a node of type ‘113’ or ‘114’) or just strings (terminating with ‘115’ or ‘116’).
                  • An airport boundary  is defined with nodes in a counter-clockwise direction.  A boundary can contain holes (see above) and must form a closed loop (terminating in a node of type ‘113’ or ‘114’).
                  • Airport traffic flows  have a header row (row code ‘1000’) followed by multiple rows that define rules of multiple classes (time, wind direction, ceiling, visibility, runway in use, VFR traffic pattern) that indicated that a flow should be used (wind rules, minimum ceiling rules, visibility rules, time rules, and operations rules).
                    • A flow is acceptable if any rule of a class is acceptable, or if there are no rules of a given class. So to permit a flow with no time restrictions, simply exclude any traffic time rules (row code ‘1004’).
                    • Rules use ‘or’ logic.  For example, a flow may have two wind rules (row code ‘1001’)  – one for slight winds very generally aligned with a runway, and one with strong winds only if they are almost exactly with the runway.
                    • A flow will be used only if all its rule classes are ‘passed’.
                    • The flows are evaluated in sequence.  The first flow to ‘pass’ will be used.  So, the most specific-but-useful rule should be listed first (eg. parallel VFR approaches on a clear, calm day) and the most general (but least useful) rules should be listed last (eg. a single ILS cat III approach to a single runway).
                    • If the rules prevent any defined flow from being ‘passed’ then X-Plane’s AI engine will create a flow.
                    • ‘Runway in use’ rules (row code 1100) are also evaluated in sequence.  The first ‘runway in use’ rule to ‘pass’ will be used for the parent flow.  So rules should be listed in preferential sequence.
                      • Airport taxi routes & networks begin with a row code ‘1200’ and are defined by a set of nodes (row code ‘1201’) and ‘edges’ (the taxi routing) that connect two nodes (row code ‘1202’):
                        • Nodes can be defined as ‘init’ (a point at which X-Plane will try to start a taxi route), ‘end’ (where X-Plane will try to end a taxi route), or ‘both’.  ‘junc’ can also be used for junctions between taxi routes.
                        • Edges must specify an allowed width, sizes A-E, and may be followed by multiple rows (row code ‘1204) defining an ‘active zone’ ‘for that parent edge (eg. if the edge conflicts with arrival or departure runways, or an ILS-critical area).
                        • Taxi routings begin or end at ramp locations (row code ‘1300’), which are also available as startup-locations in X-Plane.  These locations may not be directly connected to the taxi route network – X-Plane’s ATC engine will calculate how to direct an airplane between the taxi route network and each location.
                        • Ground truck route edges (row code ‘1206’), parking locations (row code ‘1400’), and destinations (row code ‘1401’) are included under row code header ‘1200’ for taxi networks.
                          • Other airport features  are defined with one row for each feature.

The file is terminated by a ‘99’:

99

Row Codes

Each row of data begins with an integer code that defines the type of data:

Row Code Meaning Comment
1 Land airport header
16 Seaplane base header
17 Heliport header
100 Runway
101 Water runway
102 Helipad
110 Pavement (taxiway or ramp) header Must form a closed loop
120 Linear feature (painted line or light string) header Can form closed loop or simple string
130 Airport boundary header Must form a closed loop
111 Node All nodes can also include a “style” (line or lights)
112 Node with Bezier control point Bezier control points define smooth curves
113 Node with implicit close of loop Implied join to first node in chain
114 Node with Bezier control point, with implicit close of loop Implied join to first node in chain
115 Node terminating a string (no close loop) No “styles” used
116 Node with Bezier control point, terminating a string (no close loop) No “styles” used
14 Airport viewpoint One or none for each airport
15 Aeroplane startup location *** Convert these to new row code 1300 ***
18 Airport light beacon One or none for each airport
19 Windsock Zero, one or many for each airport
20 Taxiway sign (inc. runway distance-remaining signs) Zero, one or many for each airport
21 Lighting object (VASI, PAPI, Wig-Wag, etc.) Zero, one or many for each airport
1000 Airport traffic flow Zero, one or many for an airport.  Used if following rules met (rules of same type use ‘or’ logic, rules of a different type use ‘and’ logic).  First flow to pass all rules is used.
1001 Traffic flow wind rule Zero, one or many for a flow.  Multiple rules use ‘or’ logic.
1002 Traffic flow minimum ceiling rule Zero or one rule  for each flow
1003 Traffic flow minimum visibility rule Zero or one rule  for each flow
1004 Traffic flow time rule Zero, one or many for a flow.  Multiple rules use ‘or’ logic.
1100 Runway-in-use arrival/departure constraints, 10kHz frequency resolution First constraint met is used.  Sequence matters!
1110 Runway-in-use arrival/departure constraints, 1kHz frequency resolution Alternate option to row code 1100.
1101 VFR traffic pattern Zero or one pattern for each traffic flow
1200 Header indicating that taxi route network data follows
1201 Taxi route network node Sequencing must be 0 based, ascending by ID.  Must be part of one or more edges.
1202 Taxi route network edge Must connect two nodes
1204 Taxi route edge active zone Can refer to up to 4 runway ends
1205 Taxi route edge control Replaces 1203
1206 Taxi route edge Ground vehicles only
1300 Start up location (deprecates code 15) Not explicitly connected to taxi route network
1301 Start up location metadata Consists of an ICAO width code, an operations type code and zero or more space separated 3-letter airline codes
1302 Airport identification metadata Zero, one or many for each airport
1400 Truck Parking Location Not explicitly connected to taxi route network
1401 Truck Destination Location Must not allow car pile ups due to bad one way designs
1402 Custom Truck Objects Overrides objects used in last preceeding 1500 rowcode
1050 –1056 8.33kHz communication frequencies (11.30+) Zero, one or many for each airport
50 – 56 Legacy 25kHz communication frequencies Zero, one or many for each airport. Ignored if row codes 1050-1056 exist.
1500 Active jetway
1502 Custom Jetway Objects Overrides objects used in last preceeding 1500 rowcode

Example Data

Here is some example data for KBFI.  It is not real and is very incomplete, but it illustrates examples of most types of data found in an apt.dat file.  This data includes an airport header, runway, water runway, helipad, PAPI, taxiway definition, painted line, viewpoint, startup location, light beacon, windsock, taxiway sign and an ATC communications frequency:

1    21 1 0 KBFI Boeing Field King Co Intl

100  29.87   1   0 0.15 0 2 1 13L  47.53801700 -122.30746100   73.15    0.00 2  0 0 1 31R  47.52919200 -122.30000000  110.95    0.00 2  0 0 1

101 49 1 08 35.04420900 -106.59855700 26 35.04420911 -106.59855711

102  H1   47.53918248 -122.30722302   2.00   10.06   10.06   1 0   0 0.25 0

21   47.53666659 -122.30585255  2 150.28   3.30 13L PAPI-2L

110  1 0.25 150.29 A2 Exit

111  47.53770968 -122.30849802

111  47.53742819 -122.30825844   3

112  47.53752190 -122.30826710  47.53757385 -122.30824831   3 102

114  47.53768630 -122.30834929  47.53768690 -122.30838150   3 102

120  Line B1

111  47.53969864 -122.31276189  51

111  47.53977825 -122.31255145   1

115  47.54002296 -122.31189878

14   47.52917900 -122.30434900  100 0 ATC Tower

15   47.52926674 -122.29919589 304.16 A8 Run Up

18   47.52920400 -122.30412800 1 BCN

19   47.53900921 -122.30868700 1 WS

20   47.54099177 -122.31031317 235.71  0 2 {@L}A1{@R}31R-13L

50   12775 ATIS

Here is some example data for KSEA showing the 1000 version traffic flow and taxi route data:

1000 Calm and South flow

1001 KSEA   000 359 5

1001 KSEA   070 250 999

1002 KSEA   0

1003 KSEA   0

1004 0000 2400

1100 16C 11920 arrivals jets|turboprops|props 160340 161161 Arrival 16C

1100 16R 11920 arrivals jets|turboprops|props 341159 161161 Arrival 16R

1100 16L 11920 arrivals heavy 000359 161161 Arrival Heavy Jets

1101 16R right

1200

1201  47.46360812 -122.30613338 both 5416 A_stop

1202 5258 5266 twoway taxiway B

1204 ils 34R

1300  47.43931757 -122.29806851  88.78 gate jets|turboprops A10

Here is some example data for KSEA showing the 1050 metadata and 1100 ground truck additions:

1302 city Seattle

1302 country United States

1302 datum_lat 47.449888889

1302 datum_lon -122.311777778

1302 faa_code SEA

1302 iata_code SEA

1302 icao_code KSEA

1206 107 11 twoway  C

1300  47.44158755 -122.30116873  44.78 gate jets A3

1301 D airline dal

1400  47.44374472 -122.30463464  88.1 baggage_train 3 Svc Baggage

1401  47.44103438 -122.30382493  0.0 baggage_train Luggage Train Destination South 2

Definition of Data Fields

Each column in each row code is defined below, using the example data from KBFI & KSEA shown above.  Note that:

  • Some row codes store data in an identical specification, and these have been grouped together in the table below.
  • The specification aims to be consistent.  For example, the format or latitudes and longitudes is always the same, and all headings/orientations are defined as true (not magnetic) degrees.
Row Meaning Comment
Explanation Valid values
1 Land airport header Row codes 1, 16 and 17 share a common format (see below)
16 Seaplane base header Row codes 1, 16 and 17 share a common format (see below)
17 Heliport header Row codes 1, 16 and 17 share a common format (see below)
1 Row code for an airport, seaplane base or heliport 1, 16 or 17
21 Elevation of airport in feet above mean sea level (AMSL)
1 Deprecated.  Use default value (“0”) Use 0
0 Deprecated.  Use default value (“0”) Use 0
KBFI Airport Identifier.  X-Plane internal use only, not used for user-facing functions, NOT used to determine the “ICAO code”  by X-Plane >10.45.. See rowcode 1302. Use X + local identifier to create fictional on not Sceney gateway coordinates ID’s. Maximum seven characters.  Must be unique and all upper case.
Boeing Field King Co … Airport name.  May contain spaces. Text string (up to 40 characters)
100 Land Runway
100 Row code for a land runway (the most common) 100
29.87 Width of runway in metres Two decimal places recommended.  Must be >= 1.00
1 Code defining the surface type (concrete, asphalt, etc) Integer value for a Surface Type Code (see below)
206
(= 2x 100 + 6) Code defining a runway shoulder surface  type + 100x width of each shoulder in whole meters. See Surface Type Code below  – all asphalt and concrete styles supported.
If the number is >100, the 100-digit (and optionally 1000-digit) define the width of the shoulder in meters.
If the number is <100 (i.e. only the surface code), width is same as X-Plane 11, scaling with runway tpe and width, some 3-5 meters.
0.15 Runway smoothness (not  used by X-Plane yet) 0.00  (smooth) to 1.00 (very rough).  Default is 0.25
0 Runway centre-line lights 0=no centerline lights, 1=centre line lights
2 Runway edge lighting (also implies threshold lights) 0=no edge lights, 2=medium intensity edge lights
1 Auto-generate distance-remaining signs (turn off if created manually) 0=no auto signs, 1=auto-generate signs
The following fields are repeated for each end of the runway
13L Runway number (eg. “31R”, “02”).  Leading zeros are required. Two to three characters. Leading zero’s are printed, if present.
Valid suffixes: “L”, “R”, “C” (visible in markings on paved surfaces)
Suffixes “W”, “S” and “T” are valid, but never printed.
47.53801700 Latitude of runway end (on runway centerline) in decimal degrees Eight decimal places supported
-122.30746100 Longitude of runway end (on runway centerline) in decimal degrees Eight decimal places supported
73.15 Length of displaced threshold in metres (this is included in implied runway length)A displaced threshold will always be inside (between) the two runway ends Two decimal places (metres).  Default is 0.00
0.00 Length of overrun/blast-pad in metres (not included in implied runway length) Two decimal places (metres).  Default is 0.00
2 Code for runway markings (Visual, non-precision, precision) Integer value for Runway Marking Code (see below)
0 Code for approach lighting for this runway end Integer value for Approach Lighting Code (see below)
0 Flag for runway touchdown zone (TDZ) lighting 0=no TDZ lighting, 1=TDZ lighting
1 Code for Runway End Identifier Lights (REIL) 0=no REIL, 1=omni-directional REIL, 2=unidirectional REIL,
101 Water runway
101 Row code for a water runway 101
49 Width of runway in metres Two decimal places recommended.  Must be >= 1.00
1 Flag for perimeter buoys 0=no buoys, 1=render buoys
The following fields are repeated for each end of the water  runway
08v Runway number.  Not rendered in X-Plane (it’s on water!) Valid suffixes “W” (or blank)
35.04420911 Latitude of runway end (on runway centerline) in decimal degrees Eight decimal places supported
-106.59855711 Longitude of runway end (on runway centerline) in decimal degrees Eight decimal places supported
102 Helipad
102 Row code for a helipad 101
H1 Designator for a helipad.  Must be unique at an airport. Usually “H” suffixed by an integer (eg. “H1”, “H3”)
47.53918248 Latitude of helipad centre in decimal degrees Eight decimal places supported
-122.30722302 Longitude of helipad centre in decimal degrees Eight decimal places supported
2.00 Orientation (true heading) of helipad in degrees Two decimal places recommended
10.06 Helipad length in metres Two decimal places recommended (metres), must be >=1.00
10.06 Helipad width in metres Two decimal places recommended (metres), must be >= 1.00
1 Helipad surface code Integer value for a Surface Type Code (see below)
0 Helipad markings 0  (other values not yet supported)
0 Code defining a helipad shoulder surface  type 0=no shoulder, 1=asphalt shoulder, 2=concrete shoulder
0.25 Helipad smoothness (not  used by X-Plane yet) 0.00  (smooth) to 1.00 (very rough).  Default is 0.25
0 Helipad edge lighting 0=no edge lights, 1=yellow edge lights
110 Pavement (taxiways) Defines an arbitrary pavement shape
110 Row code for a pavement chunk header (must be followed by a set of nodes) 110
1 Code defining the surface type (concrete, asphalt, etc) Integer value for a Surface Type Code (see below)
0.25 Runway smoothness (not  used by X-Plane yet) 0.00  (smooth) to 1.00 (very rough).  Default is 0.25
150.29 Orientation (true degrees) of pavement texture ‘grain’ Two decimal places recommended
A2 Exit Description of pavement chunk (not used by X-Plane) Text string
120 Linear feature Painted surface markings & light strings
130 Airport boundary Boundary for future terrain ‘flattening’
120 Row code for a linear feature or airport boundary 120 or 130
Line B1 Description of feature or boundary (not used by X-Plane) Text string
111 Node Node (plain)
112 Node Node with Bezier control point
113 Node Node (close loop), to close boundary
114 Node Node (close loop) with Bezier control point
115 Node Node (end) to terminate a line
116 Node Node (end) with Bezier control point
112 Row code for a node.  First node must follow an appropriate header row 111 thru 116
47.53752190 [All nodes] Latitude of node in decimal degrees Eight decimal places supported
-122.30826710 [All nodes] Longitude of node in decimal degrees Eight decimal places supported
47.53757385 [112, 114, 116 only] Latitude of Bezier control point in decimal degrees Eight decimal places supported.  Ignore for 111, 113, 115
-122.30824831 [112, 114, 116 only] Latitude of Bezier control point in decimal degrees Eight decimal places supported.  Ignore for 111, 113, 115
3 [Not for 115 or 116] Code for painted line type on line segment starting at this node Integer Line Type Code (see below).  Not for 115 or 116
102 [Not for 115 or 116] Code for lighting on line segment starting at this node Integer Line Type Code (see below).  Not for 115 or 116
14 Viewpoint Maximum of one viewpoint for each airport
14 Row code for a viewpoint 14
47.52917900 Latitude of viewpoint in decimal degrees Eight decimal places supported
-122.30434900 Longitude of viewpoint in decimal degrees Eight decimal places supported
100 Height (in feet) of viewpoint above ground level Integer
0 Code deprecated.  Use ‘0’ 0
ATC Tower Name of viewpoint (not used by X-Plane) Descriptive text string (optional)
15 Startup location Startup locations for airplanes at an airport Should be converted to new row code 1300
15 Row code for a startup location 15
47.52926674 Latitude of startup location in decimal degrees Eight decimal places supported
-122.29919589 Longitude of startup location in decimal degrees Eight decimal places supported
304.16 Heading (true) of an aeroplane when positioned at startup location Two decimal places recommended
A6 Run Up Name of startup location (list will be displayed in X-Plane for each airport) Short descriptive text string – ten characters or less
18 Light beacon Maximum of one beacon for each airport
18 Row code for an airport light beacon 18
47.52920400 Latitude of beacon in decimal degrees Eight decimal places supported
-122.30412800 Longitude of beacon in decimal degrees Eight decimal places supported
1 Code for type of light beacon.  Determines colors of beacon. Integer Beacon Type Code (see below)
BCN Name of viewpoint (not used by X-Plane) Descriptive text string (optional)
19 Windsock Multiple windsocks permitted for each airport
19 Row code for a windsock 19
47.53900921 Latitude of windsock in decimal degrees Eight decimal places supported
-122.30868700 Longitude of windsock in decimal degrees Eight decimal places supported
1 Flag for windsock lighting 0=unlit, 1=illuminated
WS Name of viewpoint (not used by X-Plane) Descriptive text string (optional)
20 Signs Taxiway signs or runway distance-remaining signs
20 Row code for a sign 20
47.54099177 Latitude of sign in decimal degrees Eight decimal places supported
-122.31031317 Longitude of sign in decimal degrees Eight decimal places supported
235.71 Orientation of sign in true degrees (heading of someone looking at sign’s front) Two decimal places recommended
0 Reserved for future use.  Ignore. 0
2 Code for sign size Integer Sign Size Code (see below)
{@L}A1{@R}31R-13L Text to be rendered on sign front and/or back Text string formatted by Sign Text Definition (see below)
21 Lighting objects VASI, PAPI, wig-wags, etc.
21 Row code for a lighting object 21
47.53666659 Latitude of lighting object in decimal degrees Eight decimal places supported
-122.30585255 Longitude of lighting object in decimal degrees Eight decimal places supported
2 Code for type of lighting object Integer Lighting Object Code (see below)
150.28 Orientation of lighting object in true degrees (looking toward  object) Two decimal places recommended
3.30 Visual glideslope angle in degrees Two decimal places.   0.00 if not required.  Default is 3.00
PAPI-2L Name of lighting object (not used by X-Plane] Short text string (optional)
1000 Traffic flow Arrival and departure traffic flows
1000 Row code for an arrival/departure traffic flow 1000
Calm and south flows Traffic flow name Descriptive name (max 50 characters)
1001 Traffic flow wind rule Zero or multiple wind rules permitted per flow
1001 Row code for a traffic flow wind rule 1001
KSEA METAR reporting station (may be a remote airport, eg KSEA for KBFI) ICAO code, up to 7 characters
000 Wind direction minimum (magnetic) 000 – 359
359 Wind direction maximum (magnetic) 000 – 359
5 Maximum wind speed.  Use 999 for ‘all’ wind speeds. 0 – 999
1002 Traffic flow ceiling rule Zero or one ceiling rule permitted per flow
1002 Row code for a traffic flow ceiling  rule 1002
KSEA METAR reporting station (may be a remote airport, eg KSEA for KBFI) ICAO code, up to 7 characters
0 Minimum reported ceiling in feet AGL at reporting station Positive integer
1003 Traffic flow visibility rule Zero or one visibility rule permitted per flow
1003 Row code for a traffic flow visibility rule 1003
KSEA METAR reporting station (may be a remote airport, eg KSEA for KBFI) ICAO code, up to 7 characters
0 Minimum reported visibility in statute miles Float (eg. “1.5”)
1004 Traffic time rule Zero or multiple time rules permitted per flow
1004 Row code for a traffic flow time  rule 1004
0000 UTC time from which rule is valid 0000 – 2400
2400 UTC time at which rule ends 0000 – 2400
1100 Runway-in-use rule Multiple rules for each flow.  First to ‘pass’ is used
1100 Row code for a runway-in-use rule 1100
34C Runway end identifier Two to three characters. Valid suffixes: “L”, “R” or “C” (or blank)
11920 Arrival or departure frequency Five digit integer, rounded DOWN where necessary. 10kHz resolution only.
arrivals Rule type (arrivals, departures) Pipe separated list (“
jets turboprops Airplane types to which rule applies
181359 On course heading range ((ie. first leg of flight plan  for departures, last leg for arrivals) 000000 – 359359
341341 Initial ATC assigned departure heading range.  Not used for arrivals. 000000 – 359359
Arrival 34C Rule name Descriptive name (max 50 characters)
1110 Runway-in-use rule Replaces 1100 row code, supports 8.33kHz radio frequencies. Multiple rules for each flow.  First to ‘pass’ is used.
1110 Row code for a runway-in-use rule 1110
34C Runway end identifier Two to three characters. Valid suffixes: “L”, “R” or “C” (or blank)
118325 Arrival or departure frequency Six digit integer, rounded DOWN where necessary, 1kHz resolution
arrivals Rule type (arrivals, departures) Pipe separated list (“
jets turboprops Airplane types to which rule applies
181359 On course heading range ((ie. first leg of flight plan  for departures, last leg for arrivals) 000000 – 359359
341341 Initial ATC assigned departure heading range.  Not used for arrivals. 000000 – 359359
Arrival 34C Rule name Descriptive name (max 50 characters)
1101 VFR pattern rule Zero or one VFR pattern rule permitted per flow
1101 Row code for a VFR traffic pattern 1101
34L Runway end identifier Two to three characters. Valid suffixes: “L”, “R” or “C” (or blank)
left VFR traffic pattern direction “left” or “right”
1200 Taxi routing network (for readability only)
1201 Taxi routing node All nodes must be used in at least one edge
1201 Row code for taxi routing network node 1201
47.53752190 Latitude of node in decimal degrees Eight decimal places supported
-122.30826710 Longitude of node in decimal degrees Eight decimal places supported
both Usage of node in network (begin or end a taxi path, or both) “dest”, “init”, “both” or “junc”
5416 Node identifier (defined in 0 based sequence, ascending) Integer.  Must be unique within scope of an airport.
A_start Node name.  Not currently used. String (max 16 characters)
1202 Taxi routing edge Segment in taxi routing network
1202 Row code for taxi routing network edge 1202
5416 Node identifier for start of edge Integer.  Must refer to valid node (row code ‘1201’)
5417 Node identifier for end of edge Integer.  Must refer to valid node (row code ‘1201’)
twoway Edge can be used in both directions “twoway” or  “oneway”
taxiway_a Edge ATC restrictions. If “runway” a clearance is needed from ATC. If “taxiway_a” the trailing single letter denotes maximum wingspan for aircraft routed on that taxiway. “runway” or
”taxiway_”
with = a b c d
A Taxiway identifier.  Used to build ATC taxi clearances (eg. “.. .taxi via A, T, Q”) String.  Taxiway or runway identifier (eg. “A” or “16L/34R”)
1204 Edge active zone Identifies an edge as in a runway active zone.
1204 Row code for an edge entering a runway active zone 1204
arrival Active zone classification “arrival” or “departure” or “ils”
16L,16C Runway(s) to which active zone refers Comma-separated list up to 4 runway identifies
1206 Taxi routing edge (ground vehicles) Segment in taxi routing network (ground vehicles only)
1206 (See 1202) (See 1202)
107 (See 1202) (See 1202)
11 (See 1202) (See 1202)
twoway (See 1202) (See 1202)
1300 Start up location Start or end point for aircraft.  Not linked to taxi routing network by edges (row code 1202)
1300 Row code for taxi route start/end point 1300
47.44158755 Latitude of location in decimal degrees Eight decimal places supported
-122.30116873 Longitude of location in decimal degrees Eight decimal places supported
44.78 Heading (true) of airplane positioned at this location Decimal degrees, true heading
gate Type of location “gate”, “hangar”, “misc” or “tie-down”
jets Airplane types that can use this location Pipe-separated list (“
A3 Unique name of location Text string, must be unique within a single airport
1301 Row Code For ramp start metadata
1301 1301
d ICAO width code A, B, C, D, E, F
airline Operation type none, general_aviation, airline, cargo, military
dal Airline permitted to use this ramp 3-letter airline codes (AAL, SWA, etc)
1302 Row Code Airport metadata
1302 row code Takes zero, any or all applicable Key_values
icao_id key_value for ICAO code icao_id, faa_id, iata_id, city_id, country_id, region_id, local_id, local_authorithy, transition_alt_,_ transition_level, gui_3d, is_oilrig, allows_circuits
KSEA ICAO for airport Unique identifier up to 7 characters long
1400 Truck Parking
1400 row code
47.44374472 Latitude of location in decimal degrees Eight decimal places supported
-122.30463464 Longitude of location in decimal degrees Eight decimal places supported
88.1 Heading (true) of the OBJ positioned at this location Decimal degrees
baggage_train type string baggage_loader, baggage_train, crew_car, crew_ferrari, crew_limo, pushback, fuel_liners, fuel_jets, fuel_props, food, gpu
3 0 to 10 if type is baggage_train, 0 if not
Svc Baggage Name of parking Text string
1401 Truck Destination
1401 row code
47.44103438 Latitude of location in decimal degrees Eight decimal places supported
-122.30382493 Longitude of location in decimal degrees Eight decimal places supported
0.0 Heading (true) of the positioned at this location Decimal Degrees, true heading
baggage_train Truck types allowed to end up at this destination Pipe separated list (“
Luggage Train Destination South 2 Name of Truck Destination Text string
1402 Custom service truck
myLib/myCrewCar.obj vpath to custom  object to replace default object for vehicle in in last 1400 row code preceding this If vpath is not defined, this rowcode is silently ignored and the last preceeding 1400 record keeps using the default vehicle.
1050 ATC – Recorded AWOS, ASOS or ATIS
1051 ATC – Unicom Unicom (US), CTAF (US), Radio (UK)
1052 ATC – CLD Clearance Delivery
1053 ATC – GND Ground
1054 ATC – TWR Tower
1055 ATC – APP Approach
1056 ATC – DEP Departure
1052 Row code for ATC COM Frequency Supercedes row codes 50-56.
128730 Frequency in kHz, 833kHz capable radio channels only 118000 – 135995
ATIS Descriptive name (displayed on X-Plane charts) Short text string (10 characters or less recommended)
50 ATC – Recorded AWOS, ASOS or ATIS
51 ATC – Unicom Unicom (US), CTAF (US), Radio (UK)
52 ATC – CLD Clearance Delivery
53 ATC – GND Ground
54 ATC – TWR Tower
55 ATC – APP Approach
56 ATC – DEP Departure
51 Row code for an ATC COM frequency 50 thru 56 (see above)
12775 Frequency in MHz x 100 (eg. use “12322” for 123.225MHz) Five digit integer, rounded DOWN where necessary
ATIS Descriptive name (displayed on X-Plane charts) Short text string (recommend less than 10 characters)
1500 Active jetway
46.512345 Latitude of location in decimal degrees Location of base of telescoping jetway tunnel
-123.00345 Longitude of location in decimal degrees
42.0 Heading of parked tunnel Decimal Degrees, true heading
0 Jetway style code 0 = light color, solid (metal) sidewalls
1= light color, glass side walls
2 = dark color, solid (metal) sidewalls
3 = dark color, glass side walls
2 Jetway size code 0 = tunnel length 11 –  23m
1 = tunnel length 14 –  29m
2 = tunnel length 17 –  38m
3 = tunnel length 20 –  47m
0 Do  not use or change not used, in X-Plane 12.00
17.5 Parked tunnel length In meters, must be within the extension capabilities according to the size code
127.3 Parked cabin heading True north heading. Must be within the articulating capabilities of the jetway, which is from 0 to 90 degrees counter clockwise from the heading of the tunnel.
1501 Custom jetway
myLib/myJWgate8.obj vpath to custom cabin/tunnel object for replace LR default object in last 1500 row code preceeding  this If vpath is not defined, this rowcode is silently ignores and the – default cabin/tunnel object is used as for the last preceding 1500 record

Codes

Codes used to define airport data:

Codes Comment
Code value Code meaning Code applicability
Surface Type Code Surface type of runways or taxiways
1 Asphalt
2 Concrete
3 Turf or grass
4 Dirt (brown)
5 Gravel (grey)
12 Dry lakebed (eg. At KEDW) Example:  KEDW (Edwards AFB)
13 Water runways  (do not use in XP10+, use rowcode for “sealane” instead)
14 Snow or ice Poor friction.  Runway markings cannot be added.
15 Transparent Hard surface, but no texture/markings (use in custom scenery)
20-23 Light colored asphalt Each “shade” of asphalt comes in  4 different subtypes differing in cracks, seams or dirt added to the base texture.The first subtype adds a moderate amount of seams, representing mid-aged asphalt that has not been repaired.
The 2nd subtype adds dark, patched cracks, indicative of older, but well maintained asphalt.
The 3rd subtype is “plain”, intended for manual additions of particular cracks & seams as a separate layer on top.
The 4th subtype adds more cracked and discolored areas, aka “worn, fair shape or not well maintained” asphalt.
1,24-26 Asphalt, comparable in brightness to XP11 asphalt
27-30 Darker colored asphalt
31-34 Very dark colored asphalt
35-38 Near black, ‘new’ looking asphalt
50-52 Light “new” looking concrete Each “shade” of concrete  comes in  3 different subtypes differing in cracks or dirt added to the base texture.The first subtype looks very uniform, has no cracks, representing very good shape asphalt.
The 2rd subtype is “dirty” looking, non-uniformly colored.
The 3rd subtype is “worn” with cracks developing in addition to non-uniform coloring.
2,53-54 Concrete, comparable in brightness to XP11 concrete
55-57 Dark concrete
Runway Marking Code Markings on runway
0 No runway markings Disused runways appear like taxiways
1 Visual markings
2 Non-precision approach markings
3 Precision approach markings
4 UK-style non-precision approach markings UK uses distinctive touch-down zone markings
5 UK-style precision approach markings UK uses distinctive touch-down zone markings
6 EASA style non-precision approach markings EASA differs from FAA for location and number of distance marks on runway before/after touchdown zone bars
7 EASA style precision approach markings
Approach Lighting Code Approach lighting systems
0 No approach lighting
1 ALSF-I
High intensity Approach Light System with sequenced flashing lights
2 ALSF-II
High intensity Approach Light System with sequenced Flashing lights
Red side bar lights (barettes) the last 1000’, that align with TDZ lighting.
3 Calvert
British – High intensity
4 Calvert ILS Cat II and Cat II
British – High intensity with red side bar lights (barettes) the last 1000’
Barettes align with TDZ lighting
5 SSALR
High intensity, Simplified Short Approach Light System
With Runway Alignment Indicator Lights (RAIL)
6 SSALF
High intensity, Simplified Short Approach Light System
With sequenced flashing lights
7 SALS
High intensity, Short Approach Light System
8 MALSR
Medium-intensity Approach Light System
With Runway Alignment Indicator Lights (RAIL)
9 MALSF
Medium-intensity Approach Light System with sequenced flashing lights
10 MALS
Medium-intensity Approach Light System
11 ODALS
Omni-directional approach light system
Flashing lights, not strobes, not sequenced
12 RAIL
Runway Alignment Indicator Lights
Sequenced strobes and green threshold lights, with no other approach lights
Line Type Code Painted lines and light strings
Note that for all linear features that involve runway entrance hold lines and associated lights (4, 5, 6, 103 & 104 below), the runway is assumed to be to the LEFT of the string and the taxiway to the RIGHT (looking along string from its first node)
0 Nothing.
1 Solid yellow line Taxiway centre lines
2 Broken yellow line Miscellaneous boundaries
3 Double solid yellow lines Taxiway edge lines
4 Two broken yellow lines and two solid yellow lines.  Broken line on left of string. Runway hold positions
5 Broken yellow line with parallel solid yellow line. Broken line on left of string. Other (non-runway) hold locations
6 Yellow cross-hatched line ILS hold
7 Solid yellow line with broken yellow line on each side Taxiway centerlines in runway safety zones
8 Widely separated, broken yellow line Mark ‘lanes’ for queuing aeroplanes
9 Widely separated, broken double yellow line Mark ‘lanes’ for queuing aeroplanes
51-59 Line types 1-9 above with a black border Use on concrete surfaces for higher contrast
20 Solid white line Roadway markings
21 White chequerboard pattern Roadway markings
22 Broken white line Roadway centreline
Note that lights added to the edge boundary of a piece of pavement (or hole) will be placed off the edge of the pavement (about one meter).
101 Green embedded lights, bidirectional along string axis Taxiway centrelines
102 Blue lights, omnidirectional Taxiway edge
103 Closely spaced, embedded amber lights.  Unidirectional to right of string Hold lines
104 Closely spaced, pulsating embedded amber lights.  Unidirectional to right of string Runway hold lines
105 Alternating green and amber embedded lights, bidirectional along string axis Centrelines in runway safety zones
106 Red lights, omnidirectional Edge lights in dangerous/critical zones (eg. on bridges)
107 unidirectional steady green lights Runway lead-off lights
108 unidirectional, alternating green and amber lights Runway lead-off lights inside runway safety zones
Beacon Type Code Airport light beacons
0 No beacon.  Suppresses automatic creation of beacon by X-Plane. Use a dummy airport lat/lon for the location.
1 White-green flashing Civilian land airport
2 White-yellow flashing Seaplane base
3 Green-yellow-white flashing Heliport
4 White-white-green flashing Military airport
Sign Size Code Taxiway sign sizes & types
1 Small taxiway sign
2 Medium taxiway sign
3 Large taxiway sign
4 Large distance-remaining sign on runway edge Alternatively, can be auto generated for a runway
5 Small distance-remaining sign on runway edge Alternatively, can be auto generated for a runway
Lighting Object Code Lighting objects
1 VASI Location is centre point between the two VASI units
2 PAPI-4L (four-light) on left of runway Left-handed:  red indication appears first on right 2 lights
3 PAPI-4R (four light) on right of runway Right-handed:  red indication appears first on left 2 lights
4 Space Shuttle PAPI, 20 degree glidepath Deprecated.  Use normal PAPI with an appropriate angle.
5 Tri-colour VASI
6 Runway guard (“wig-wag”)  lights Pulsating double amber lights alongside runway entrances
7 APAPI L (two-light) on left of runway
8 APAPI R (two-light) on right of runway

Further Information

Resources are available for airport designers at the X-Plane Scenery Gateway at http://gateway.x-plane.com/

X-Plane Airport Data (apt.dat) File Specification Page of 1200 Version, 1-May-2022

1 Comment

Airport Pavement and FX

X-Plane 12 has a new set of textures and other art assets. The main idea behind this pack is the general improvement of airports – particularly the depiction of the ground surface. All features in this pack comprise POL, LIN, or simple OBJ assets, and all of them are “ground” oriented. Here is an example of what can be achieved:

The assets in this pack are divided into four categories:

lib/airport/ground/pavement

lib/airport/ground/pavement_FX

lib/airport/ground/terrain

lib/airport/ground/terrain_FX

We can understand these four categories as different groups of layers in the following order:

4 – pavement FX effects placed on, or snapped to paved surfaces (cracks, dirt, grunge, drains, etc.)

3 – pavement main hard surfaces (asphalt, concrete)

2 – terrain FX effects placed on, or snapped to natural surfaces (paths, grass patches, lawn tracks, etc.)

1 – terrain natural terrain (grass, desert, etc.)

A higher value means a higher priority of visibility. In other words, terrain FX won’t be visible through the pavement but the pavement FX over the grass will be shown. That means you can paint a dirt path across the border of asphalt, but you shouldn’t paint asphalt cracks across the border of grass.

1 – Terrain

We have brand new textures and shaders for all basic airport terrains. The grass is completely new, the desert is new, and so on.

In addition, we have unique grass textures with lawn-mower tracks. This is a typical detail that can make the terrain look more realistic. These textures are directional so for better plausibility, it is very important to set the proper direction in WED polygons.

Next, we have textures for sand and soil. It can be useful for various patches in the grass.

2 – Terrain_FX

This is a group of effects that can be placed on top of natural terrain.

lawn_tracks

The lawn-mower tracks effect comes in different forms. POL (polygon) files have a similar visual effect to those above. This time, however, they are transparent and contain only the lawnmower tracks themselves. It can be placed on top of any type of underlying terrain (which can be handy for locations where nice green grass is not desired).

LIN (line or stripe) files are useful as a natural border between grass with a lawn-mower effect and surrounding areas. Typically these can form the natural shape of grass islands in between taxiways. We have various strips with corresponding colors of grass.

Typical use:

OBJ (object) files are mostly spots with a couple of tracks in circular form. These can be placed typically in corners, or under various things in the middle of the grass (like taxi signs).

patches

Patches are available as single OBJ (various sizes and shapes) and as LIN (various widths). We also have all corresponding colors for basic terrain polygons – grass, dark grass, dry grass, light and dark sand, and soil. They’re useful for modeling various imperfections in basic terrain, spots, broken lawns, and so on. Also, these can be used along the edge of a taxiway, as an extension of the natural edges (see below).

paths

Path LIN are available in various widths and materials (concrete, sand, and soil).

taxi_sign_base

These are paved bases for taxiway signs. Single OBJ are available in various sizes, and two colors (light and dark). If you can’t find the desired size for a certain situation, you can also use the LIN variant. These OBJ have an exception to the layer system described above. They render above the pavement so you can use them also on top of taxiways.

3 – Pavement

In X-Plane 12 we also have a brand new shader designed particularly for hard airport surfaces. Generally speaking, it can make better-looking asphalt and concrete, with less obvious texture repetitions over large areas (almost invisible repetitions).

asphalt_

Asphalt surfaces are available in five basic colors (light to dark).

Each color variant is available with four different effects:

1 – plain:  this variant is omnidirectional. It is useful for specific situations (typically taxiway shoulders) in conjunction with various effects (see below).

2 – strips:  this is probably the most common variant with typically visible strips.

3 – worn:  same as (2), but a bit worn. Gaps between strips are sometimes cracked or patched.

4 – patched:  highly worn, irregular, and more visible cracks.

concrete_

Concrete doesn’t have a unified system like asphalt. We have three main colors (gray, light gray, and dark gray) but with slightly different effects for each of them. In addition, we also have the fourth color group which is tinted (red or yellowish). Here are some samples of the variants:

4 – Pavement_FX

This is a group of effects that can be placed on top of hard surfaces.

edges

Probably the most important asset. Edges are dividers of pavement and natural surrounding terrain. They are available in two colors (light and dark) and have three variants:

1 – soft:  basic edge with a slight plastic effect. Suitable for most common situations, particularly for grass.

2 – elevated:  pavement surface looks slightly elevated, and the edge is a little worn.

3 – cracked:  a lot more cracked and worn.

gaps

These are dividers of adjacent asphalt or concrete surfaces. A wide patch line can be used for manually painted large-scale cracks, however we recommend you do not repeat this small texture to cover large areas.

taxiway

Here we have four different types of taxiway structures. Imagine transparent strips, with the very subtle effect of dirt on asphalt. These were designed to be used in conjunction with the plain variant of asphalt. These are useful for curved segments of taxiways and particularly shoulders, and are available in different widths, which should roughly match the usual sizes of shoulders.

taxiway_cracks

Another kind of effect that is useful, especially for shoulders. Also available in different widths.

taxiway_dirt

In this group, you can find subtle dirt effects. Some are designed for placement along the centerline, others are for the edge of the taxiway.

drains

Various drains and manhole cover lids.

General hint:  most LIN effects have end caps. That means the line needs some minimum length. Any time you see an artifact (black rectangles), it is probably due to insufficient length of the line.

1 Comment
  1. Pages:
  2. 1
  3. 2
  4. 3
  5. 4