Difference between revisions of "BGL file format (FSX airport)"

From FSDeveloper Wiki
Jump to: navigation, search
(Undo revision 10100 by MichaelCox (talk))
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{:Ambox-Content-WIP}}
 +
 
{{Infobox-Applicable-FSVersion
 
{{Infobox-Applicable-FSVersion
 
| FSXI = false
 
| FSXI = false
Line 97: Line 99:
 
The type code for a library object in FSX appears to be 0x0b (for FS9 it is 0x02).  This makes it relatively easy to decide between objects in FS9 and FSX bgls.   
 
The type code for a library object in FSX appears to be 0x0b (for FS9 it is 0x02).  This makes it relatively easy to decide between objects in FS9 and FSX bgls.   
  
[[category:Scenery design]]
+
[[Category:Airport Design]]
 
[[category:File Formats]]
 
[[category:File Formats]]

Latest revision as of 15:05, 3 March 2016

Structure of Airport files in FS X

(The structure was tested with APX31250 from the FS X Demo release)

1. File header

The file header has the same format as in FS9. It consists of a fixed length section of 0x38 bytes and a variable number of section pointers, each 0x14 bytes long.

The first 4 bytes of the fixed section contain the file signature (0x19920201), the same as for FS9 ne format files. At offset 0x0004 from the file start there is the size field: a DWORD which contains 0x00000038. The function of the next 3 DWORD data fields is unknown, possibly they contain a kind of date stamp for the file. A DWORD field at offset 0x0014 from the file start contains the number of section pointers following the fixed part of the header. After this there are 8 DWORD data fields of unknown function, possibly indicating which part of the earth surface is covered by the contents of this file.

The section pointers in the variable part of the header start at offset 0x0038 from the file start and follow each other without interruption. Each section pointer has the following structure:

The first DWORD field contains the section ID. The following values are found in aiport files: 0x0003 (primary airport records); 0x002c (secondary airport records); 0x0022 (waypoint records); 0x0025 (scenery object records); 0x002a (unknown function); 0x0027 (name list). A DWORD data field at offset 0x0004 from the start of the section pointer has an unknown function. In APX31250.bgl the following values are found at this location: 0x0001, 0x0004, 0x0003. The DWORD field at offset 0x0008 from the start of the section pointer gives the number of subsection pointers in the section header; the DWORD at offset 0x000c contains the offset of the section header from the start of the file, followed by a DWORD giving the size of the section header in bytes.

2. Section header

Each section header consists of a variable number of subsection pointers of 0x10 bytes length, following each other without interruption. The subsection pointers have the following structure: The first DWORD seems to specify the section of the earth surface to which the following records belong (somewhat similar to the Latband in the old FS file format). A DWORD field at offset 0x0004 from the start of the header contains the number of records belonging to this subsection. A DWORD field at offset 0x0008 gives the offset of the subsection start from the file start, a DWORD field at offset 0x000c the total length of the subsection in bytes. The records of the subsection begin at the subsection start and follow each other apparently in the same order they had been written in the xml source code.

3. Primary airport records

Each primary airport record consists of a fixed part with a length of 0x38 bytes and a variable number of subrecords. The size of the record given in the fixed part includes all subrecords; thus it is sufficient to add this value to the offset of the subsection from the file start to arrive at the start of the 2nd airport record (or at the end of the subsection).

The fixed part has the following structure: It starts with a WORD data field containg the signature of the record (0x003c for primary airport records in FS X; in FS9 this was 0x0003). A DWORD data field at offset 0x0002 contains the total size of the record (including all subrecords). After this there are beginning at offset 0x0006 six BYTE data fields giving the number of runway subrecords, the number of Com subrecords, the number of start subrecords, the number of approach subrecords (?), the number of apron subrecords(?) and the number of helipad subrecords (?). In the field for the apron subrecords only bits 0..6 are used to give the count; bit 7 is used as flag indicating whether a deleteAirport subrecord is present. The DWORD data field at offset 0x000c represets the longitude, the DWORD at offset 0x0010 the latitude and the DWORD at 0x0014 the elevation of the airport reference point. The DWORD data fields at 0x0018, 0x001c and 0x0020 contain longitude, latitude and elevation of the tower. The next data field at offset 0x0024 represents the magnetic variation as float value. At offset 0x0028 is a DWORD field containing the ICAO identifier in a special format (same as in FS 9). Note: there seems to be a new convention for giving an identifier to those airports which have neither an official ICAO nor an IAA identifier, otherwise identifiers like "CODR" or "COCO" found in APX31250.bgl cannot be explained. Beginning at offset 0x002c there are 3 more DWORD fields in the fixed part, of which the function is unknown.

After the fixed part there are usually one or more subrecords with a structure depending on the type of the subrecord. All have their type ID in a WORD field at the start and their size in a DWORD field at offset 0x0002 from the start.

Many of this subrecords are in the same format as in FS9. following ones exost in APX31250.bgl:

ID = 0x0019: airport name

ID = 0x0004: runway

ID = 0x0011: start

ID = 0x0012: com

ID = 0x001a: taxiway point

ID = 0x001c: taxiway path. There is a new type in the type field of each path (offset 0x0004 from start of path)

ID = 0x001d: taxiway name

ID = 0x0037 and 0x0030: apron

ID = 0x0031: apron edge lights

ID = 0x0024: approach

The subrecord with ID = 0x001b (taxiway parking) does no longer exist. Apparently it was replaced with a new type with the ID of 0x003d; the structure of this subrecord is still partly unknown. After the size field at offset 0x0006 there is a WORD field giving the number of points defined, and there is for each point a 0x24 byte long record, which has at the start a DWORD, then at offset 0x0004 and 0x0008 two float values (probably diameter and heading), then unknown DWORD (?) values, and then at offset 0x001c and 0x0020 two DWORD fields with the point coordinates.


There are two other types of subrecords with new IDs: ID = 0x003b and ID = 0x0039. One of them probably contains the data for the fences which are drawn at the perimeter of the airports.

The subrecord with the ID of 0x003b contains after the size field 3 WORD fields of unknown function and then a large number of DWORD pairs defining point coordinates.

The subrecord with the ID of 0x0039 has after the size field a field giving a count of something, then 0x20 bytes of unknown function (maybe one sequence contains a GUID ?), and then DWORD pairs giving point coordinates; the number of points corresponds to the value given in the count field.

4. Secondary airport records

The same structure as in FS 9.

5. Waypoint records

The same structure as in FS 9.

6. namelist

The same structure as in FS 9.

7. Scenery object records

Here are the taxiway signs coded. The type code for taxiway signs has changed to 0x0e (apparently all kinds of objects have new type codes!), and the record structure for the fixed length part has become 0x10 bytes longer: at offset 0x001c there are four DWORD's added (they are all 0x00000000 ?), so that the DWORD count field is at offset 0x002c. The code for each sign seems to be unchanged from FS9.

The type code for a library object in FSX appears to be 0x0b (for FS9 it is 0x02). This makes it relatively easy to decide between objects in FS9 and FSX bgls.