by Cristiano Maggi
Revision History
2/12/07 Initial Draft
The purpose of this small tutorial is to show how to use the cool new animating features of Ben Supnik’s new release of the AC3D plug-in for X-Plane.
You will need AC3D 6.1 in order to use this new plug-in.
Drop the two components files of the plug-in into the AC3D plug-ins folder, you will not need to move any other plug-in file out of that folder–now the X-Plane plug-in is perfectly compatible with all the others importers/exporters!
Then download the latest DataRefs.txt from the XSquawkBox site and drop it into the AC3D plug-in folder too in order to let the plug-in permit you to select the datarefs you may need:
We are now ready to use AC3D with X-Plane files, let’s examine the 3 cases in which we may step:
Animated files already in .OBJ format (v8);
Animated files in .ac format;
Animating a new file.
Animated files already in .OBJ format.
There’s absolutely no need to make any action to update animated objects which are in .OBJ format. The plug-in is able to read the animations stored in those files and to show them properly, preserving perfect compatibility.
Once the .OBJ file is open, its animations can be directly viewed in AC3D by selecting Animation Time… from the “X-plane” top menu:
One way you can tell that the animations have been imported is: AC3D represents the axis for rotation or path for translation as yellow lines. In the picture above, we can see the yellow line going through the radar dish on the mast of the Nimitz. This shows that the radar rotates around the vertical axis.
The X-Plane Animation Window shows up and animations can be examined by moving the cursors in it, one cursor for each used dataref.
Animated files in .ac format.
The most “complex” case is the handling of previously released animations stored into AC3D .ac files, our master files, for instance.
After opening a file of this kind the very first thing to do is updating it, since it was saved through the previous version of the X-Plane plug-in. To do this simply select “Update from old plugin”.
All the animations are magically updated and can then be checked in the same way we already learned in the previous section. We are now able to re-save our file to keep an up-to-date version of our master work for reference, modify it, and export it as an X-Plane .OBJ file as usual.
(You will also know that your update has succeeded because you will see yellow animation lines for all of the rotations and translations in the model.)
Animating a new file.
Let’s now consider the most intriguing section of this tutorial: how to make animations from scratch, and examining the new related capabilities of the AC3D X-Plane plugin.
We need a model, of course, let’s take this dump truck as example. (You can download the .ac file from here:)
In this model we need to set some animations: the dump bin must raise, it’s door must open together with this movement to release the dump, the piston under the container must extent following those movements pretending it’s the “engine” of the raising movement.
It’s fundamental that our model is well organized in its internal structure before starting the animation procedure; we need the help of the hierarchy (Tools/Hierarchy View) to group various objects so that everything could properly work.
In my model I’ve separated the objects that will remain still from the objects that need to be animated in order to avoid confusion, remember you can always make visible or invisible any single object by clicking on its eye-shaped icon in the hierarchy.
First of all I need to make the bin raise (together with the dump) rotating by a hinge placed near the back of the truck and this rotation should make the door open in order to pretend that the dump could drop. This first animation is then the result of a nesting of 2 separated movements, 2 separated rotations. The bin raising must involve the door opening, so let’s select 3 objects: “Container” + “Door”, the items that will animate, and “Gravel”, which is the contained dump that needs to move together with the bin.
Now go in the X-Plane menu and select “Make Animation Group” to create a special group, needed for animations purposes.
Let’s now set the first rotation by selecting “Make Rotation” , from the X-plane menu again. A yellow vertical line appears, that’s the axis of our rotation, but it’s set vertical and it’s placed in the origin so we need to move and position it correctly. No need for calculations, we can just simply control it as any AC3D line and place it in the position where the hinge is needed.
It’s really matter of seconds to place the axis where we need it, notice that for AC3D the axis is a normal object, in the hierarchy, we can select it, hide it, but better leave its name as the default given “rotation” in order to immediately understand what it is inside the structure of our model.
To bring the animation to life we need now to choose “X-Plane Object Properties”, the very first item of the X-Plane menu. In the pop up window that will appear we can enter all the values of our rotation and select the dataref that will cause the movement. I have chosen the dataref which animates the oil rigs’ cranes in order to have a cyclic up and down of the bin, this dataref needs to put “-1” and “1” in the leftmost fields and then the angle, in degrees, between minimum and maximum excursion, in the other two fields. I have entered from “0” to “40”.
We can now even check our first movement better by invoking the “Animation Time” item from the X-Plane menu, as already explained in the first section of the tutorial. The bin will show itself in the middle of the excursion due to the characteristics of this peculiar dataref, a cyclic dataref, intended to make the movement endless.
We must then make the door open when the bin raises; this second movement should be synchronized with the first one. To do that we must nest the second movement into the first by creating another “Animation Group” in the same way we created the first, but selecting the “Door” object only. We will then set the proper rotation axis exactly in the same way we just did for the bin and the proper rotation values in the “X-Plane Properties” window. The hierarchy always helps us checking that our nesting is correct in order to end with a perfect union of the two animations. As usual, the “Animation Time” window will permit us to check if everything is well done.
Adding another animation to the piston which must simulate to raise the container is then the last task; we will need to add a rotation to the piston base together with multiple translations for the segments of the telescopic part of it, all the translations will need to be nested into the first rotating part, of course.
Let’s start from the translations, one for each segment of the piston. We will then add the rotation for the whole group at the end.
It’s simple as setting rotations, after making the “Animation Groups” we only need to pick “Make Translation” from the X-Plane menu. Translations are represented by yellow lines identical to the rotation ones, so it’s very simple to drag them around, rotate them and position them where they are needed. The only difference is that the length of the line represents the distance of the translation, very simple. Pay attention, though, when you scale the line, do not shorten them by both sides, shorten them only by the far most side from the origin!
The translation lines can be placed wherever you like, near the object that should translate is the better visual position to evaluate on-the-fly their length, though. In the following picture you can see that I put them side by side, near the segments that have to translate in order to better understand what they do.
The object called “piston 1” will not translate, since it’s the main socket fastened to the truck, all the other segments have their own “Animation Group” containing their proper translation, the longest way the segment need to travel, the longest translation line.
To finish our model we must then make all these segments rotate together while they translate; to do this we will first make an “Animation Group” with the “piston 1” object only selected, assign a rotation to it in the way we already saw before for the truck bin:
Then, using the new cool feature of AC3D 6.1, drag the other “Animation Groups” of the 3 piston sections into this main group using the hierarchy. Move then both the “piston 1” object and its rotation line to the top position of the group to let them “lead” the whole rotation.
This information is historic and only relevant to X-Plane 8 and earlier
Scope
This document describes the file format and codes used in X-Plane’s apt.dat file, 715 version.
This data file format is usable with X-Plane version 7.15 – 8.06. It was superseded by airport file format 810 in March 2005.
This is the “official” definition of the X-Plane file formats. The apt.dat file defines all airport data in X-Plane, including runways, taxiways, and other airport features.
Navigation aids at an airport (such as ILS components) are not defined in this file, but are contained in the nav.dat file.
File structure
The file structure is similar to all other X-Plane data files, with the exception that the sequencing of the data within the apt.dat file is important. Runway, taxiway, location and ATC data for an airport must immediately follow the header data for the parent airport.
The first line of each file indicates if the file was generated on a PC (“I” for Intel or IBM) or Macintosh (“A” for Apple). X-Plane uses this code to help deal with the different ways in which PCs and Macs manipulate carriage returns in text files, and big-endian/little-endian issues. The second line contains a version number used by X-Plane. This usually implies the first version of X-Plane that can utilise the file format (eg. “715 version” implies that this file format was first available for use in X-Plane version 7.15). The version number is followed by my own long copyright message that also includes the sequential build number of the data and my own internal code for the metadata that drives the formatting). This copyright message is very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgement and a disclaimer for the US Department of Defense NIMA for the DAFIF data. The terms of this license require that this copyright message must be left intact if this file is modified and/or redistributed.
The very last line of each file is marked by a “99”.
Here is an example of the two header lines, one airport, one runway and the file termination line:
Each airport has a header line and one or more runway/taxiway lines, followed by lines for an airport tower viewpoint location, a startup location on the airport , airport light beacon location and windsocks, and airport ATC (Air Traffic Control) frequencies.
Line
codes used in apt.dat (715 version)
Code (apt.dat)
Used for
1
Airport header data.
16
Seaplane base header data. No
airport buildings or boundary fences will be rendered in X-Plane.
17
Heliport header data. No
airport buildings or boundary fences will be rendered in X-Plane.
10
Runway or taxiway at an airport.
14
Tower view location.
15
Ramp startup position(s)
18
Airport light beacons (usually
“rotating beacons” in the USA). Different colours may be
defined.
19
Airport windsocks.
50 to 56
Airport ATC (Air Traffic Control)
frequencies.
Note the following sequence of the airport data:
The runway data for each airport must follow the airport header line.
Taxiways should follow the runways.
Tower viewpoints and startup locations.
Airport light beacons and windsocks.
ATC frequencies should be the final entries for an airport.
A blank line can be used to separate different airports – this helps improve readability, but it is not mandatory.
Changes from previous file versions
The previous file version for apt.dat was 703 version.
A flag now controls if a control tower object will be drawn in X-Plane at the location of the control tower (line code 14).
Other issues
The limitations on the number of airports within a region (an X-Plane “region” is a dynamic area of 2 degrees latitude by 3 degrees longitude) changed for X-Plane 7.40. So more recent files generated in this file format (715) are only usable in X-Plane versions 7.40 – 8.06.
Example data
Here is a simplified fragment for part of an airport in apt.dat:
This shows one airport header line, four runways, two taxiways, a tower viewpoint, two gate starting locations, an airport beacon, two windsocks and two ATC frequencies. The meaning of the data in the above example data is:
Meaning
of example airport data (apt.dat)
Airport
header
Example
Usage
1
Identifies this as an airport header line. Note
that a code 16 will identify this as a seaplane/floatplane
base, and a code
17 will identify it as a heliport.
5355
Airport elevation (in feet above
MSL).
1
Airport has a control tower (1=yes, 0=no).
Used by X-Plane’s ATC system. Not used to draw the
default ATC tower building (despite what is stated in WorldMaker!).
0
Display X-Plane’s default airport buildings (1=yes, 0=no).
This is usually ‘no’ if any custom taxiways have been defined.
KABQ
Identifying code for the airport (the ICAO code, if one exists).
It is helpful if these are unique, but this may not be possible in all cases.
Albuquerque Intl Sunport
Airport name.
Usually, the city name is first followed by the airport name (eg.
“London Heathrow”).
Runways and taxiways
Example Usage
10
Identifies this as a data line for a runway or taxiway segment.
35.044209
Latitude (in decimal degrees) of runway or taxiway segment center.
-106.598557
Longitude (in
decimal degrees) of runway or taxiway segment center.
08x
Runway number (eg “25x” or “24R”). If there is no runway suffix (eg. “L”, “R”, “C”
or “S”), then an
“x” is used. “xxx” identifies the entry as a taxiway.
Helipads at the same airport are numbered sequentially as
“H1x”, H2x”.
90.439
True (not magnetic) heading of the runway in degrees.
Must be between 0.00 and 360.00.
13749
Runway or taxiway segment length in feet.
1000.0000
Length of displaced threshold (1,000 feet) for runway 08 and for the reciprocal runway 26 (0 feet). The length of the reciprocal runway’s displaced threshold is expressed as the fractional part of this number. Take the runway 26 displaced threshold length (in feet) and divide it by 10,000, then add it to the displaced threshold length for runway 08. For example, for displaced threshold lengths of 543 feet and 1234 feet, the code would be 543.1234.Note that the displaced threshold length is included in the overall runway length but that the stopway length is excluded from the overall runway length. This code should be 0.0000 for taxiway segments. FYI, the displaced threshold is usually marked (in the real world) with long white arrows pointing toward the threshold. The displaced threshold is not available for use by aeroplanes landing, but may be used for take-off (in practice, if you use these last few feet of the runway for take-off, you are probably in serious trouble!).
0.1000
Length of stopway/blastpad/over-run at the approach end of runway 08 (0 feet) and for runway 26 (1,000 feet), using the same coding structure defined
above. FYI, in the real world the stopway/blastpad/over-run is usually marked with large yellow chevrons, and aeroplane movements are not permitted.
150
Runway or taxiway segment width in feet.
252231
Runway or taxiway segment lighting codes.
The first three digits (“252”) define the lighting for the runway as seen when approached from the direction implied by the runway number (08 in our example).
The final three (“231”) define the lighting for the runway as seen when approached from the opposite end (26 in our example).
Other runway end (26): Runway lighting. Here, code 3 corresponds to REIL, which also implies edge lighting.
Other runway end (26): Approach lighting. Here, code 1 implies no approach lighting.
02
Runway or taxiway surface
code for the runway or taxiway segment. The leading zero is
optional – but I always use it to keep all the columns neatly lined up.
0
Runway shoulder
code. These are only available in file version
701 and later. Here, code 0 implies that there is no runway
shoulder.
3
Runway markings
(the white painted markings on the surface of the runway. Here,
code 3 implies precision runway markings (ie. there is an associated
precision approach for the runway, either an ILS or MLS).
0.25
Runway
smoothness. Used to cause bumps when taxying or rolling along the
runway in X-Plane. It is on a scale of 0.0 to 1.0, with 0.0 being
very smooth, and 1.0 being very, very rough. X-Plane determines a
baseline smoothness based upon the runway surface type, and then uses
this factor to determine the ‘quality’ of the runway surface. The
default value is 0.25.
1
Runway has ‘distance
remaining’ signs (0=no signs, 1=show signs). These are the white
letters on a black background on little illuminated signs along a
runway, indicating the number of thousands of feet of usable runway that
remain. They are inappropriate at small airports or on most dirt,
gravel or grass runways.
Startup locations
Example
Usage
15
Identifies this as a
data line for an airport startup
location (code 15). Multiple startup locations
are allowed as separate data lines.
35.047215
Latitude
(in decimal degrees) of the viewpoint or startup location.
-106.618576
Longitude (in
decimal degrees) of the viewpoint or startup location.
0.00
Elevation of the viewpoint, or the heading of the aeroplane when placed at the
startup location.
Gate B1 (American
Airlines)
Name of
a startup location (used in X-Plane 7.10 and later).
Tower
viewpoints
Example
Usage
14
Identifies this as a data line for a tower viewpoint (code 14).Only a single tower viewpoint is permitted.
35.047005
Latitude
(in decimal degrees) of the viewpoint.
-106.608162
Longitude (in
decimal degrees) of the viewpoint.
100
Height (in feet)
above ground level of viewpoint.
1
Flag to indicate if
a control tower object should be drawn at this location in
X-Plane. 0=no tower, 1=draw tower.
Tower viewpoint
Name of this
viewpoint
Airport light beacons
Example Usage
18
Identifies this as a
data line for an airport light beacon (code 18). Note that if custom data is not defined, then appropriate data will be
generated automatically and included in apt.dat. The light beacon
types available (see list below) are in accordance with the US AM
(Aeronautical Information Manual) – other types may be added to cater
for other light beacons used in other countries.
35.045031
Latitude (in decimal degrees) of the light beacon.
-106.598549
Longitude (in
decimal degrees) of the light beacon.
1
Identifies the
colours of the light beacon. Here code 1 implies a standard
white-green flashing light. Options are:
Code 1: white-green flashing light (land airport).
Code 0: no beacon (can be used at ‘closed’ airports). I
suggest you use a dummy lat/lon based upon one of the airport’s
runways.
Light beacon
Name for this light beacon
(not used by X-Plane).
Airport
windsocks
Example
Usage
19
Identifies this row
as an airport windsock (code 19). Note that:
If custom data is not defined, then appropriate data will be generated
automatically by may data export algorithms and included in apt.dat
alongside the threshold of each runway.
If at least one windsock is explicitly defined at an airport, then
no ‘automatic’ windsocks will be generated at that airport.
Multiple windsocks are
allowed.
If you do not want any windsocks at an airport, then let
me know in an e-mail and I will suppress the generation of all
automatic windsocks at that airport.
35.045176
Latitude
(in decimal degrees) of the airport windsock.
-106.621581
Longitude (in
decimal degrees) of the airport windsock.
Airport ATC frequency, in Megahertz
multiplied by 100 (ie. 121.90 MHz in this example).
GND
Name of the ATC frequency.
This is often an abbreviation (such as GND for
“Ground”).
Codes used to define data
The codes used to define the data are:
Codes used in
apt.dat (715 version)
ATC
frequency codes
Meaning of
code
50
AWOS (Automatic Weather
Observation System), ASOS (Automatic Surface Observation System) or ATIS
(Automated Terminal Information System).
51
Unicom or CTAF (USA), radio (UK)
– open channel for pilot position reporting at uncontrolled airports.
52
Clearance delivery.
53
Ground.
54
Tower.
55
Approach.
56
Departure.
Runway
surface codes
Meaning of
code
01
Asphalt.
02
Concrete.
03
Turf/grass.
04
Dirt.
05
Gravel.
06
Asphalt helipad (big “H” in
the middle).
07
Concrete helipad (big “H” in
the middle).
08
Turf helipad (big “H” in the
middle).
09
Dirt helipad (big “H” in the
middle).
10
Asphalt taxiway with yellow hold
line across long axis (not available from WorldMaker).
11
Concrete taxiway with yellow
hold line across long axis (not available from WorldMaker).
12
Dry lakebed runway (eg. at KEDW
Edwards AFB).
13
Water runways (marked with
bobbing buoys) for seaplane/floatplane bases (available in X-Plane 7.0
and later).
Visual
approach path indicator codes
Meaning of
code
1
No visual approach path lighting.
2
VASI (Visual Approach Slope Indicator).
3
PAPI (Precision Approach Path Indicator).
4
Space Shuttle Landing PAPI (steep 20 degree glide path) – its use is very rare!
Runway lighting
codes
Meaning of code
Note
that for values 1-5, the codes are cumulative – ie. code 3 also assumes code 1
and code 2
when X-Plane interprets
the data
1
No runway lighting.
2
Runway edge lights
(white).
3
Also has REIL (Runway End Identification Lights – the flashing strobes at
the approach end of the runway.
4
Also has CLL (Center Line Lighting).
5
Also has TDZ (Touch Down Zone) lighting.
6
Only has blue taxiway edge lights (use on
taxiways!).
Approach
lighting codes
Meaning of
code
1
No approach lights.
2
SSALS (Simplified short approach light system).
3
SALSF (Short approach light system with sequenced flashing
lights).
4
ALSF-I (Approach light system with sequenced flashing lights).
5
ALSF-II (Approach light system with sequenced flashing lights and red side bar
lights the last 1000’).
6
ODALS (Omni-directional approach light system).
7
Calvert (a British design) category 1.
8
Calvert (a British design) categories 2 and 3.
Runway
shoulder codes
Meaning of
code
0
No runway shoulder.
1
Asphalt runway shoulder.
2
Concrete runway shoulder.
Runway
marking codes
Meaning of
code
0
No runway markings. Also used for helipads (X-Plane will automatically draw the
big “H” based on the runway surface code), taxiways and water
runways. The runway markings available (see list below) are in accordance with
the US AIM (Aeronautical Information Manual) – other types may be added to cater
for different types of runway markings that may be used in other countries.
This information is historic and only relevant to X-Plane 8 and earlier
Scope
This document describes the file format and codes used in X-Plane’s nav.dat file, 740 version.
This data file format is usable with X-Plane version 7.40 – 8.09. It was superseded by the nav.dat 810 version.
This is the “official” definition of the X-Plane file formats. The nav.dat file defines all navigation aid data in X-Plane, including global NDBs, VORs, VORTACs, VOR-DMEs, DMEs, and ILS components (localisers, glideslopes, marker beacons and any associated DMEs).
File structure
The file structure is similar to all other X-Plane data files.
The first line of each file indicates if the file was generated on a PC (“I” for Intel or IBM) or Macintosh (“A” for Apple). X-Plane uses this code to help deal with the different ways in which PCs and Macs manipulate carriage returns in text files, and
big-endian/little-endian issues.
The second line contains a version number used by X-Plane. This usually implies the first version of X-Plane that can utilise the file format (eg. “740 version” implies that this file format was first available for use in X-Plane version 7.40). The version number is followed by my own long copyright message that also includes the sequential build number of the data and my own internal code for the metadata that drives the formatting). This copyright message is very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgement and a disclaimer for the US Department of Defense NIMA for the DAFIF data. The terms of this license require that this copyright message must be left intact if this file is modified and/or redistributed.
The very last line of each file is marked by a “99”.
Here is an example of the two header lines, six nav-ads and a file termination line:
Stand-alone localiser (LLZ),
also including LDA (Landing Directional Aid) and SDF (Simplified Directional
Facility).
6
Glideslope (GS).
7
Outer marker (OM).
8
Middle marker (MM).
9
Inner marker (IM).
12
DME (including the DME element of
an ILS, VORTAC or VOR-DME).
Sequencing of data is conceptually unimportant. But it controls the display of data on X-Plane’s menu options. By default, data is sorted by the “line code”, then alphabetically by nav-aid name.
Changes from previous file versions
The previous file version for nav.dat was 600 version (no documentation available here).
A new field has been added to define the range of a nav-aid. This is based upon DAFIF data, or upon defaults calculated from the nav-aid type and class..
Example data
Here is a simplified file fragment some nav-aids in nav.dat:
This shows an NDB, VORTAC and an ILS (including localiser, glideslope, outer marker and inner marker) and a DME. The meaning of the data (for the first record) is:
Meaning
of example nav-aid data (nav.dat 740 version)
Nav-aid
example
Example
Usage
2
Type of
nav-aid
34.987022
Latitude of nav-aid in decimal
degrees
-106.620384
Longitude of nav-aid in decimal degrees.
5304
Elevation of nav-aid in feet above MSL.
247
Frequency of nav-aid. (Always an integer – so VOR and localiser frequencies multiplied by 100).
50
Range of the nav-aid in nautical miles.
0.000
Used
for several purposes, depending upon the type of nav-aid:
Indicates the slaved variation of a VOR/VORTAC in degrees (ie. how the VOR is aligned
compared to true north). This value often differs slightly from the local magnetic variation. Eastern variations are positive, western ones are negative.
In the above data, Albuquerque VORTAC has a slaved variation of 13.000 degrees East.
Indicates the heading of a localiser in true (not magnetic) degrees. Also required for glideslopes (when it is combined with the glideslope angle – see below for details) and marker beacons.
Indicates the DME bias in nautical miles – often used for DMEs associated with an ILS
that are not located near the runway threshold. This bias must be subtracted from the calculated distance to
the DME to give the desired cockpit reading. This is typically used for a DME located in the centre of an airport that
serves multiple l ILS approaches, so that the DME will read zero at the
threshold of a runway. This is a common set up in Europe.
ILT
Identification of nav-aid (broadcast in Morse code in X-Plane).
Note that these are not unique.
Isleta NDB
Name of nav-aid.
Note that for ILS components these are carefully structured (see below)
to identify the airport and runway..
Localisers (code 4 and 5) are very similar, except that:
They include the heading of the localiser (as described above).
The nav-aid name is replaced by the airport code, runway number and ILS component type (eg. “KABQ 08 ILS-cat-I”). This data is not used by X-Plane, but is used by my import programmes that allocate the ILS elements to a valid runway in the master
database. I cannot import ILS data without these codes.
For a localiser-only (code 5), the name will be similar to “KABQ 08 LOC”.
Glideslopes (code 6) have very similar data to localisers, except that the glideslope angle (typically 3 degrees) is combined with the heading in a slightly complex fashion. A glideslope of 3.00 degrees on a heading of 90.428 (true) will be listed as “300090.428”. This is calculated by:
Rounding the glideslope angle (3 degrees in our example data) to two decimal places
(3.00).
Multiplying the result by 100,000 (giving 300,000).
Adding the result to the heading (300,000 + 90.428 = 300090.428).
ILS marker beacons (codes, 7, 8 and 9) are formatted just like localisers, but note that:
They have no associated frequency (use “0”).
They have no range (use “0”)
The heading is important, to ensure that they are oriented and displayed correctly on X-Plane’s approach charts.
Marker beacons do not have a Morse code identification, so “—-“ is used as a default. X-Plane will automatically generate the correct series of beeps for each type of beacon, if the aeroplane’s instrument panel is equipped with a marker beacon receiver.
For a Locator Outer Marker (LOM), which is an NDB co-located with an OM, the NDB
must be added to nav.dat as a separate, stand-alone NDB (at the same location!). The name of the OM must remain in the “KABQ 08 ILS” format – but the NDB may have the appropriate name (eg. “Wobin LOM”).
DMEs (code 12) are shown for:
Stand-alone DMEs (common in Europe, and often associated with an NDB).
The DME component of a VORTAC or VOR-DME (often identical position data to the co-located VOR)
DMEs associated with an ILS – often co-located with (or very close to) the localiser aerial.
The DME bias is displayed in the heading column, as described above.
This information is historic and only relevant to X-Plane 10 and earlier
REVISION HISTORY
12 Nov 2015 Update to move spec to developer site
7 May 2009 Spec converted to this new format to support new web site (//data.x-plane.com).
8 Sept 2009 Error in usage of row type 13 fixed in “applicability” section below.
31 May 2010 Corrected error in specification of VOR and localizer radio frequencies. Added elevations to NDB spec. Corrected references to apt.dat.
29 July 2011 Fixed minor error in definition of nav-aid frequencies
27 Oct 2011 Fixed minor error in definition of glideslope approach angle
8 July 2012 Corrected error in definition of nav-aid ranges
This specification (XP NAV810) is supported in X-Plane 8.10 to X-Plane 10.52. It is identified in the data files as “810 Version” on the second row of the file. The prior specification for airport data was XP NAV740, which is recommended for X-Plane 7.40 – 8.09.
Changes in the spec for XP NAV810 were:
A new row code for DMEs (13) for which the frequency display will be shown on X-Planes charts. DMEs with a row type 12 will have their frequency display suppressed on X-Plane’s chart to prevent clutter (such DMEs are usually co-located with a VOR or an ILS).
OVERVIEW & SCOPE
This specification defines all radio navigation data for X-Plane, including NDBs, VORs (inc. VORTACs and VOR-DMEs), and ILS components (localisers, glideslopes, marker beacons). The effect of this data is to:
Allow these radio navigation facilities to be used when flying in X-Plane.
Display the navigation facilities on X-Plane’s chart.
Render objects in the X-Plane scenery system to represent each facility
BASIC CONCEPTS
Latitudes and longitudes are described in a decimal notation (eg. 20.12345678).
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). X-Plane has an internal model of magnetic variation
FILE CHARACTERISTICS
The earth_nav.dat (and nav.dat) files are plain text files:
Fields in the data can be separated by one or more white space characters.
By default, the files are generated so that rows of data are consistently aligned, but this is not required.
FILE STRUCTURE
The navigation data can be edited in X-Plane in the “Location | Local Map” view, and by clicking on the “edit” button at the top of the screen. If data is changed here, then X-Plane will ask for confirmation that the new data should be saved when quitting X-Plane. This will ensure that all structural requirements listed here for airport data are met.
[Note that the current version of X-Plane displays headings for an ILS in magnetic degrees on this screen, but that this data is converted to a true heading when the data is saved to earth_nav.dat.]
In common with most other X-Plane data file specification, header rows of data define the origin (PC or Mac) 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 copyright message:
The complete copyright message should be left intact if you redistribute this data. The GNU GPL (general public License) under which this data is released is
designed to encourage modifications, enhancements and redistribution, even in commercial derivative products.
Subsequent rows of data define each nav-aid. Sequence is not important, but by default this file is sorted by row code, then by nav-aid name.
The file is terminated by a ‘99’.
ROW CODES
Each row of data begins with an integer code that defines the type of data:
Row Code
Meaning
Comment
2
NDB (Non-Directional Beacon)
Includes NDB component of Locator Outer Markers (LOM)
3
VOR (including VOR-DME and VORTACs)
Includes VORs, VOR-DMEs and VORTACs
4
Localiser component of an ILS (Instrument Landing System)
5
Localiser component of a localiser-only approach
Includes for LDAs and SDFs
6
Glideslope component of an ILS
Frequency shown is paired frequency, not the DME channel
7
Outer markers (OM) for an ILS
Includes outer maker component of LOMs
8
Middle markers (MM) for an ILS
9
Inner markers (IM) for an ILS
12
DME, including the DME component of an ILS, VORTAC or VOR-DME
Frequency display suppressed on X-Plane’s charts
13
Stand-alone DME, or the DME component of an NDB-DME
Frequency will displayed on X-Plane’s charts
EXAMPLE DATA
Here is some example data for the Seattle, Washington, USA area (note the separate data row for the DME component of the Seattle VORTAC):
This information is historic and only relevant to X-Plane 10 and earlier
This specification defines all fixes (also known as intersections) X-Plane 10. The effect of this data is to:
Allow these fixes to be selected in X-Plane’s GPS and FMC systems.
Display the fixes on X-Plane’s charts.
BASIC CONCEPTS
Latitudes and longitudes are described in a decimal notation (eg. 20.12345678).
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.
Unlike other data files, no ‘row codes’ are used for fix data, since the file contains just one type of data.
FILE CHARACTERISTICS
The earth_fix.dat files are plain text files:
Fields in the data can be separated by one or more white space (space, tab) characters.
By default, the files are generated so that columns of data are consistently aligned, but this is not required.
FILE STRUCTURE
In common with most other X-Plane data file specification, header rows of data define the origin (“I” = PC or “A” = Mac) 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 copyright message.
Subsequent rows of data define each nav-aid. Sequence is not important, but by default this file is sorted by row code, then by nav-aid name.
The file is terminated by a ‘99’.
EXAMPLES
Here is example data for a fix:
37.428522 -097.419194 ACESI
DEFINITION OF DATA FIELDS
Meaning of example fix data (fix.dat)
Fix example
Example Usage
37.428522
Latitude of NDB in decimal degrees. Eight decimal places supported.
-097.419194
Longitude of NDB in decimal degrees Eight decimal places supported.
ACESI
Name of fix. Usually five characters. Unique within an ICAO region.
Comments Off on Fix Intersection (fix.dat) File Format Specification
This information is historic and only relevant to X-Plane 10 and earlier
The awy.dat file defines all airway segments in X-Plane 10. This data is used in X-Plane 10 to draw high and low level airways on X-Plane’s charts.
File structure
The file structure is similar to all other X-Plane data files.
The first line of each file indicates if the file was generated on a PC (“I” for Intel or IBM) or Macintosh (“A” for Apple). X-Plane uses this code to help deal with the different ways in which PCs and Macs manipulate carriage returns in text files, and big-endian/little-endian issues.
The second line contains a version number used by X-Plane. This usually implies the first version of X-Plane that can utilise the file format (eg. “640 version” implies that this file format was first available for use in X-Plane version 6.40). The version number is followed by Robin Peel’s long copyright message that also includes the sequential build number of the data and internal code for the metadata that drives the formatting. This copyright message is very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgement and a disclaimer for the US Department of Defense NIMA for the DAFIF data. The terms of this license require that this copyright message must be left intact if this file is modified and/or redistributed.
The very last line of each file is marked by a “99”.
Here is an example of the two header lines, three airway segments and the file termination line:
Name of intersection or nav-aid at the beginning of this segment (the fix ABCDE in this example).
32.283733
Latitude of the beginning of this segment.
-106.898669
Longitude of the beginning of this segment.
ABC
Name of intersection or nav-aid at the end of this segment (the nav-aid ABC in this example).
33.282503
Latitude of the end of this segment.
-107.280542
Longitude of the end of this segment.
2
This is a “High” airway (1 = “low”, 2 = “high”). If an airway segment is both High and Low, then it should be listed twice (once in each category). This determines if the airway is shown on X-Plane’s “High Enroute” or “Low Enroute” charts.
180
Base of airway in hundreds of feet (18,000 feet in this example).
450
Top of airways in hundreds of feet (45,000 feet in this example).
J13
Airway segment name. If multiple airways share this segment, then all names will be included separated by a hyphen (eg. “J13-J14-J15”)
Comments Off on Airway Data (awy.dat) File Format Specification
