
                        MICROSOFT FLIGHT SIMULATOR 5
                            DATA FILE STRUCTURES

VERSION HISTORY

Document version 0.1, release date: 18 October 1993

--------------------------
PREMISE, COMPLAINT and DISCLAMER
--------------------------

This document describes the structures of files provided with Microsoft
Flight Simulator 5.0.  The document is ideally addressed to developers and
requires a good knowledge of hex notation and some familiarity with program-
ming concepts.

The below information was derived by the manual analysis of FS5 files.
To my advice, it would have been positive if the owners of FS5 rights had
chosen to document the structure of FS5 data files, expecially after the
experience with FS4 (the FS/ASD community as a whole has spent way too much
time decoding those information in order to generate useful utilities).
Such a documentation would, in fact, greatly increase the availability of FS
utilities and add-ons, with a much higher probability of useful and nice FS-
related products, eventually increasing the value of FS itself.
Nevertheless, this does not seem to be the case and this document, as its
precedessor FSSTRUCT, has been put together and will be incremented in the
future to overcome this limitation.

However, the below information is not distributed with an eye towards ena-
bling anyone to rob the original authors of any rightful profits and should
be used only for the common good of the FS community and to encourage
availability and sales of FS and related products and utilities.

This file is available, FREE, to anybody asking for it and anybody receiving
it is given the right to re-distribute it via any medium.
I would only ask the reader to refrain from distributing modified versions of
this file: please do not delete anything and, if you have made any discovery
or have any suggestion, addition or correction and you want (and may) to con-
tribute it, please let me know, so that they will appear in future versions
and other peoples can enjoy it.

I apologize for English language errors and inelegancies.

                    Maurizio M. Gavioli

 InterNet:      <Maurizio M. Gavioli>vincigli@idg.fi.cnr.it
 CompuServe:    INTERNET:vincigli@vm.idg.fi.cnr.it

Ŀ
      I would like express my debt to:                            
 Dan Samuel [70110,434],                                          
 Andrew Tuline [70742,3176] and                                   
      for their suggestions and friendly support.                 


--------------------------
CONVENTIONS
--------------------------
 The symbol "m" always means meters, while nautical miles are noted by "NM".
 Hex values are marked with an final 'h', non-marked values are decimal, the
  only exception being code dumps in examples which are in hex.
 Within scenery files, all multi-byte values follow the Intel convention:
  lower order bytes precede higher order bytes; they are always transcribed
  as a single value restoring the correct digit positions ("53h 07h" means a
  byte value 53h followed by a byte value 07h, while "FFFBh" means a word
  value FFFBh made of a first byte FBh and a second byte FFh).
 Record structure is given in columnar form: in the 1st column the offset
  within the record, in the 2nd the length of each field, in the 3rd the des-
  cription of the field.  The byte at offset 0, which is equal to the record
  code, is always understood.
 Unindentified or undeciphered (parts of) records are marked with "???".
 Records fields which have the same value xxxx in all the examples I saw are
  described as "always xxxx ??".
 Fields whose value, when arbitrarely changed by hand, does not affect
  object appearance or behaviour are declared "irrelevant".

========================================


                              GENERAL CONCEPTS

FS5 COORDINATES AND GEOGRAPHIC UNITS

If FS4 world was a flat, rectangular grid of conventional North and East
coordinates, whose correspondence to geographical Latitude and Longitude
values has always been problematic, FS5 world is actually much like a sphere,
whose points are defined by mean of a Latitude-Longitude pair, directly
proportional to the geographical Latitude and Longitude.  No detail is known
yet about the specific geoid model adopted.

LATITUDE: is basically expressed as a linear distance from the Equator, the
base unit being 2 m (henceforth called "Nu").
North latitude is positive and South latitude is negative.
FS5 seems to assume that the Equator-North Pole is 10,001,736 m:
     90 of latitude = 5,000,868        Nu
      1 of latitude =    55,565.2      Nu
      1' of latitude =       926.08666  Nu
      1" of latitude =        15.434777 Nu

LONGITUDE: is basically expressed as an angle from the Greenwich mediridian
and the base unit (henceforth called "Eu") has been chosen in order to have
360 = 1000000h, i.e. in order to have a whole angle exactly fitting in 24
bits (3 bytes):
     90 of longit.  = 4,194,304        Eu
      1 of longit.  =    46,603.377    Eu
      1' of longit.  =       776.72296  Eu
      1" of longit.  =        12.945382 Eu
      1 Eu           = 0.0772476"
Longitude increases toward East: East Longitude is below 7FFFFFh (and can be
considered positive), West Longitude is above 800000h (and can also be con-
sidered negative).

Coordinates are expressed in the sceneries in several forms:
Integral: 24 bits (3 bytes) containing an integer number of lat./long. units
Decimal:  32 bits (4 bytes) containing 3 bytes for the integral part and 1
           byte for the decimals.
Meter:    32 bits as above but with Lat. unit of 1 m (unused for Longitude).

Abbreviations:
Integral form will be indicated by "Iu"
Decimal form will be indicated by "Du"
Meter form will be simply indicated by "m"
The infixes "N" and "E" will be added ("INu", "IEu", "DNu", "DEu") for
clarity, when needed to distinguish latitude ("N"orth) from longitude
("E"ast).


RECORDS

Many kinds of FS data files are made of "records", i.e. chunks whose struc-
ture, contents and meaning are determined by the first record byte (there-
after called "record code"); records may contain many values (thereafter
called "fields"), and, with a few exceptions, each record has a fixed length.
Records appear in the files one after the other; given the start point and
the structure (or at least the length) corresponding to each record code, a
file can be sequentially parsed and decoded.

Record code meanings may change (and usually do) from file type to file type.
Many file types start with a non-record coded portion of fixed structure
("header") containing general information about the file.


BYTE OFFSET AND SECTION OFFSET

Several records used in static sceneries contain an offset, pointing to
another record and used to provide some forms of inter-record addressing.
Offsets can have two forms:
BYTE OFFSET: 2 bytes, giving the distance between the beginning of the
  "pointing" record and the beginning of the "pointed" record.
SECTION OFFSET: 4 bytes, expressing the position of the "pointed" record
  relatively to the beginning of the scenery section.

======================================================================

                         WORLD FILE (.VIS) STRUCTURE
                      (on a contribution by Dan Samuel)

.VIS files are essentially used to define a "world", i.e. a set of .BGL files
which actually contain objects of that world.  .VIS files correspond to the
FS5 Scenery menu items.

0     2   File length
2     2   file ID ???
4     2   Pointer to scenery name
6     2   Pointer to scenery description
8     2   Pointer to .BGL ID table
10    22  11 unknown pointers?
32    4   always 00000076h ??

Sections pointed to in the header follow:

*[4]  x   Scenery name
*[6]  x   Scenery description
*[8]  x   .BGL ID table: a table of 2-byte values (terminated by a 0000h?)

The table seems to contain room for 6 entries both in WORLD.VIS and
CROPW.VIS, possibly 5 'full' entries and a 0000h.

WORLD.VIS contains: 0001 0003 0004 0000 0000 0000
CROPW.VIS contains: 0002 0000 0000 0000 0000 0000

This means that selection of the WORLD.VIS scenery will activate all .BGL
files with ID equal to 0001, 0003 or 0004; selection of the CROPW.VIS scenery
will activate all .BGL files with a 0002 ID.

It may be worth noting that .BGL names are irrelevant: once they have a .BGL
extension and the proper ID at their beginning, they are loaded whatever
their names are.

After the table, both .VIS contains:

00            ???
E9 AB 22 90   8088 code for JMP +22ABh, NOP  ???


======================================================================

                        SCENERY FILE (.BGL) STRUCTURE

Scenery files are made of
 a fixed-strcture header 80h bytes long and
 a variable number of sections, each presumably containing a coherent kind
  of objects.

At this general level, then, .BGL structure is more similar to the systematic
structure of old .SC1 than to the procedural nature of old .SCN.

The great difference is that records in different sections have different
meanings (and structures) and then cannot arbitrarely mixed (as was possible
in .SC1 files).  Below, each section will receive a separate treatment and
its (known) records will be separately listed.

THE .BGL HEADER

The .BGL header contains some values, describing general properties of the
scenery or of a section, and 4-byte some pointers, pointing to the different
sections.  Given that, in the four .BGL files supplied with FS5, several
header field is always NULL, it is somewhat difficult to distinguish between
values and pointers.

The following description assumes that each unused field is actually a
pointer to a section which happens to be lacking in all the 4 .BGLs and is
marked as "unattested"; anything which cannot be a pointer is assumed to be a
2-byte value; some values have been understood, but nine of them still have a
conventional name.

0     2   Scenery ID (selected via .VIS files; see above)
2     4   Max North covered by the scenery; in meters, NOT in DNu
6     4   Min North covered by the scenery; in , NOT in DNu
10    4   Max East  covered by the scenery; in DEu
14    4   Min East  covered by the scenery; in DEu
18    4   Absolute pointer to SECTION 00 (VOR and ILS)
22    2   Min frequency present in section 00 (108.00 = 0, 117.95 = 199)
24    2   Max frequency present in section 00 (108.00 = 0, 117.95 = 199)
26    4   Abs. pointer to SECTION 01 (Textures, buildings)
30    4   Abs. pointer to SECTION 02 (   "               )
34    4   Abs. pointer to SECTION 03 (   "               )
38    4   Abs. pointer to SECTION 04 (   "               )
42    4   Abs. pointer to SECTION 05 (   "               )
46    4   Abs. pointer to SECTION 06 (   "               )
50    4   Abs. pointer to SECTION 07 (unattested)
54    4   Abs. pointer to SECTION 08 (unattested)
58    4   Abs. pointer to SECTION 09 (bitmaps, rwys, bldgs, lines, poly.)
62    4   Abs. pointer to SECTION 10 (??)
66    4   Abs. pointer to SECTION 11 (Airports)
70    4   Abs. pointer to SECTION 12 (??)
74    4   Abs. pointer to SECTION 13 (ATIS)
78    4   Abs. pointer to SECTION 14 (NDB)
82    4   Abs. pointer to SECTION 15 (Dynamic scenery)
86    2   Value 0
88    2   Value 1
90    2   Value 2
92    2   Value 3
94    2   Value 4
96    2   Value 5
98    2   Value 6
100   2   Value 7
102   4   Abs. pointer to SECTION 16 (??)
106   4   Abs. pointer to SECTION 17 (??)
110   4   Abs. pointer to SECTION 18 (Magnetic variation?)
114   4   Abs. pointer to SECTION 19 (unattested)
118   4   Abs. pointer to SECTION 20 (unattested)
122   4   Abs. pointer to SECTION 21 (unattested)
126   2   Value 8

If, in a .BGL, a section is lacking, the corresponding pointer is set to
00000000.

======================================================================

                        DESCRIPTION OF .BGL SECTIONS

-----------------
Overall structure
-----------------

Many sections are made of a big table, listing available facilites or fea-
tures.  In order to speed up access to these tables, many of them are divided
in sub-tables grouping facilities by Latitude ranges.
At the beginning of a sub-divided section, a header is inserted, made of many
records 15h (one for each sub-table) defining the division criteria and
pointing to the individual sub-tables, which acts like a sort of table of
contents for the section.

All these tables, i.e.: the general section table, the header table and each
sub-table, are terminated by a record 00h.

The general structure of a sub-divided section can be represented as:

Ŀ                 Ŀ
 15h:  Lat min - Lat max  >  xxh:  ................. 
Ĵ                 Ĵ
 15h:  Lat min - Lat max  Ŀ        xxh:  ................. 
Ĵ                
 15h:  Lat min - Lat max  Ŀ             00h:  End of table 
Ĵ               
..........                                Ŀ
Ŀ             >  xxh:  ................. 
 00h:  End of table                      Ĵ
                      xxh:  ................. 
                                           Ĵ
                                            xxh:  ................. 
                                           
                                            00h:  End of table 
                                           
                                           Ŀ
                              >  xxh:  ................. 
                                            
                                             00h:  End of table 
                                            
                                            Ŀ
                                             00h:  End of table 
                                            

Note that several sections deviate from this scheme:
 Section 00 has a three-layer structure (see below)
 Sections 01-06 have a header of records 16h, instead of 15h
 Section 11 has a header made of records 01h, instead of 15h.


--------------------------
GENERAL RECORDS
--------------------------

The following records have the same meaning and structure in all the attested
sections and are probably general instructions.

-- 00h ------------- End of Table (1 byte)

The great majority of the tables present in a .BGL are of variable length and
this 1-byte record is used to signal the end of each table.

-- 15h ------------- North range pointer (9 bytes)

1     2   min Lat.; contains only the two most significant bytes of a INu
3     2   max Lat.;    "      "
5     4   Section offset to the relevant table.

Note that the offset at byte 5 is a SECTION OFFSET, i.e. is relative to the
beginning of the section and not to the beginning of the record 15h.


--------------------------
SECTION 00 : VOR - ILS
--------------------------

Section 00 contains VOR and ILS facilities.
The overall structure of this section has been discovered by Dan Samuel: the
navaids are grouped by frequency and a navaid table is set up for each fre-
quency. As a consequence the frequency does not appear in the navaid records
themselves.
The section starts with a table of records 01h giving the offsets of the var-
ious frequency tables.  The first record points to the navaid table with a
frequency equal to the First frequency given at byte 22 of the .BGL header
and each next record 01h points to the table for the frequency 0.5 MHz above
the preceeding.
Often, each frequency table is divided in sub-tables, each pertaining to a
certain North range, via a pre-table of records 15h.

The general structure of Section 00 can then be represented as:

Ŀ          Ŀ          Ŀ
 01h: 1st freq.  >  15h: Lat range  >  xxh:  ........ 
Ĵ          Ĵ          Ĵ
 01h: 2nd freq.  Ŀ     15h: Lat range  Ŀ     xxh:  ........ 
Ĵ         Ĵ         
.........                  .........                   00h:  EoT 
Ŀ              Ŀ              
 00h:  EoT                00h:  EoT               Ŀ
                        >  xxh:  ........ 
                                                       Ĵ
                                                        xxh:  ........ 
                                                       Ĵ
                                                        xxh:  ........ 
                                                       
                                    End of range table  00h:  EoT 
                                                       
                            Ŀ         Ŀ
                       >  15h: Lat range  >  xxh:  ........ 
                             Ĵ         
                              15h: Lat range  Ŀ    00h:  EoT 
                             Ĵ        
                             .........                 Ŀ
                             Ŀ          >  xxh:  ........ 
                              00h:  EoT               Ĵ
                                            xxh:  ........ 
                                                        
                                     End of range table  00h:  EoT 
                                                        

-- 01h ------------- Frequency table pointer (5 bytes)

1     4   Section offset of a table of navaids with a given frequency.
          00000000 if no table for this frequency.

-- 04h ------------- VOR (44 bytes)

1     1   Range in 2048 m units
2     2   Magnetic deviation (in 1/182.04)
4     1   ??
5     3   Latitude  in INu
8     3   Longitude in IEu
11    2   Altitude  in m
13    2   always 0000 (approach course???; see rec. 05h below)
15    5   VOR ID; string padded with spaces
20    24  VOR Name; string padded with spaces

-- 05h ------------- ILS (54 bytes)

1     1   Range in 2048 m units
2     2   Magnetic deviation (in 1/182.04)
4     1   ??
5     3   Latitude  in INu
8     3   Longitude in IEu
11    2   Altitude  in m
13    2   Approach course (in 1/182.04)
15    5   VOR ID; string padded with spaces
20    24  VOR Name; string padded with spaces
44    3   Glideslope latitude  in INu?
47    3   Glideslope longitude in IEu?
50    2   Glideslope altitude  in m?
52    2   Glideslope angle?

Note: the first 44 bytes are equal to a record 04.  Given that, from an FS
perspective, an ILS is basically a VOR plus a glideslope, the last 10 bytes
have to refer to the glideslope position and angle.


--------------------------
SECTIONS 01-06 : ??
--------------------------

Sections 01 to 06 are made of the same stuff. The following table lists what
some sections display, when all other section pointers are zeroed in .BGL
headers.

           WORLD1.BGL                   WORDL5.BGL

Sect. 01   base textures, altit. info   Synthberg base text., mount. alt.
Sect. 02       "            "           ??
Sect. 03   ??                           Crop Dust.    "           "
Sect. 04   ??                           ??
Sect. 05   ??                           --
Sect. 06   some textures and alt.       Synthberg bitmaps, bldgs, some mount.

Sect. 09   bitm., bldgs, lines, polyg.  ??

It is noteworth that real world bitmaps, buildings, lines and polygons are
displayed by section 9, while Synthberg's are displayed by section 6.

These sections usually start with a table of records 16h, each one defining a
Type (?) and pointing to a related table; these tables are made primarily of
records 04h and 05h which, in turn, define IDs and state some properties of
them.

-- 04h ------------- Single ID (10 bytes)

1     2   ID (??)
3     2   ??
5     2   ??; often of the forms 1111h or 2222h
7     1   ??
8     2   ??

-- 05h ------------- Multiple IDs (5 bytes + 7*no.ofIDs)

1     2   First ID (??)
3     2   Last  ID (??)

Then, for each ID from First to Last, is added the structure:

5     2   ??
7     2   ??; often of the forms 1111h or 2222h
9     1   ??
10    2   ??

similar to record 04h body.

-- 16h ------------- Type table pointer (7 bytes)

1     2   ID (??)
3     4   Section pointer to the table for that Type

--------------------------
SECTIONS 07-08 : UNATTESTED
--------------------------


--------------------------
SECTIONS 09 : ??
--------------------------

Section 09 is attested in WORLD1.BGL, where it is very long (almost a half of
the entire file) and contains buildings, lines, polygons and bitmap
references, and in WORLD5.BGL, where instead it is very short (35 bytes).

The below analysis is very provisory: many records of this section are of
unknown length (indicated by an ellipsis) and very often seem to be very long
(often hundreds bytes); they will probably break into more specific records
once the analysis will improve.

Several records have always a second byte equal to 00 and may possibly be not
records at all, but kind of selector fields within larger records

These sections seems to be similar to the procedural nature of FS4's SDL.


-- 05h -------------  AREA test (12 bytes)

1     4   Latitude in m units
5     4   Longitude in Du
9     1   range in 2km units
10    2   Jump byte offset

This record jumps to the given byte offset if the point of view is outside
the defined area (much like records 3Eh did in SDL4).

-- 08h -------------  ??? (... bytes)

1     2   ???
3     2   ???
5     4   Latitude in m units
9     2   ???
11    4   Longitude in Du
15    ....

-- 0Bh -------------  AREA test (12 bytes)

1     4   Latitude in m units
5     4   Longitude in Du
9     1   range in 2km units
10    2   Jump byte offset

This record seems similar to the record 05h.

-- 0Dh -------------  JUMP (4 bytes)

1     1   always 00h ??
2     2   Jump byte offset

This record inconditionally jumps to the given byte offset.

-- 20h -------------  ??? (... bytes)

1     2   ???
3     2   ???
5     4   Latitude in m units
9     2   ???
11    4   Longitude in Du
15    ....

-- 22h -------------  RETURN? (2 bytes)

1     1   always 00h ??

This record may be a return from subroutine call.

-- 32h -------------  ??? (4 bytes)

1     1   always 00h ??
2     2   byte offset

This record points to another records; any relationship is possible!

-- 39h -------------  BITMAP (... bytes)

1     1   always 00h ??
2     2   record length?
4     ...

This record contains the name of a bitmap file (*.r8)...

-- 3Fh -------------  ??? (4 bytes)

1     1   always 00h ??
2     2   byte offset

As for record 32h, this record points to another records.

-- 40h -------------  ??? (... bytes)

1     2   ???
3     2   ???
5     4   Latitude in m units
9     2   ???
11    4   Longitude in Du
15    ....

-- 44h -------------  RUNWAY (64 bytes)

1     1   always 00h ??
2     2   ???
4     4   Latitude in m units
8     2   ???
10    4   Longitude in Du
14    2   ???
16    2   Altitude in m
18    2   always 00h ??
20    2   Heading in 1/182.04
22    2   Length in feet
24    2   Width in feet
26    1   ???
27    1   rwy ID; bit 6 on = L, bit 7 on = R, both on = C
28    2   always 0000h ??
30    2   runway surface
32    32  always 0 ??

-- 52h -------------  ??? (... bytes)

1     1   ???
2     2   ???
4     2   ???
6     2   ???
8     2   ???
10    2   ???
12    2   ???
14    2   ???
16    2   ???
18    2   ???
20    4   Latitude in m units
24    2   ???
26    4   Longitude in Du
30    ...

-- 74h -------------  CALL? (4 bytes)

1     1   always 00h ??
2     2   subroutine byte offset

This record may be a subroutine call.

-- 76h -------------  RETURN? (2 bytes)

1     1   always 00h ??

This record may be a return from subroutine call similar to record 22h

-- 77h -------------  ??? (11 bytes)

1     1   always 00h ??
2     2   byte offset
4     2   ???
6     2   ???
8     2   ???
10    1   ???


--------------------------
SECTIONS 10 : ??
--------------------------

The only attested section 10, in WORLD1.BGL, is only 75h bytes long and has
not been analyzed successfully yet.


--------------------------
SECTIONS 11 : RUNWAYS
--------------------------

This section is organized with an initial table of records 01h, naming a
geographic area and pointing to tables of airports pertaining to each area.

-- 01h ------------- Geographic area (7 bytes + area name)

1     2   record length
3     4   section pointer to runway table
5     -   Variable length 0-terminated ASCII string with the area name

These records probably contribute the items used to build up the area selec-
tor list in the Airport Menu of FS5.

-- 03h ------------- Airport (27 bytes + airport name)

1     2   record length
3     4   Latitude  (in Du)
7     4   Longitude (in Du)
11    4   Altitude in 1/256 meters
15    2   Runway heading in 1/182.04
17    2   COM1 frequency (BCD coded: 30h 21h = 121.30)
19    2   NAV1 frequency (as above)
21    2   OBI1 course
23    2   NAV2 frequency (as above)
25    2   OBI2 course
27    -   Variable length 0-terminated ASCII string with the airport and
          runway name

This record defines the data required to place the plane at the given runway
of the airport/runway.

--------------------------
SECTIONS 12 : ??
--------------------------

This section is made of the usual record 15h table grouping facilities in
North ranges each pointing to a record 04h table.

-- 04h ------------- ??? (23 bytes)

1     22  ??? (to be analyzed yet)


--------------------------
SECTIONS 13 : ATIS
--------------------------

This section is made of the usual record 15h table grouping facilities in
North ranges each pointing to a record 04h table.

At the current analysis status, this section, present in WORLD4.BGL, looks
like it contains an unseemingly large amount of code which is not linked to
any table.

-- 04h ------------- ATIS (16 bytes + ATIS text)

1     2   frequency (BDC coded: 65h 28h = 128.65)
3     3   Latitude  in Iu
6     3   Longitude in Iu
9     1   Range in 2Km units (=2048m?)
10    2   record length
12    1   preferred runway 1 (bit 6 and 7 may be set: ??)
13    1   preferred runway 2 (bit 6 and 7 may be set: ??)
14    1   preferred runway 3 (bit 6 and 7 may be set: ??)
15    1   preferred runway 4 (bit 6 and 7 may be set: ??)
16    x   Variable length 0-terminated ASCII string with the ATIS message

The message text can include any character from ASCII 20h to ASCII 93h.
Characters greater than 93h result in garbage being printed. When the message
is played back, characters from 80h to 93h are expanded into the following
strings (reported from FS4's FSSTRUCT, but not checked):

80h   " Whether - "
81h   " OBSERVATION "
82h   " XX:00 ZULU " (where XX is replaced by the current hour time)
83h   "" (empty string)
84h   " TEMPERATURE 25 - "
85h   " INFORMATION "
86h   " LANDING AND DEPARTING RUNWAY XX - " (where XX is replaced by the
      runway number given at offset 5)
87h   " ADVISE CONTROLLER "
88h   " ALTIMETER 29.95 - "
89h   " VISIBILITY 10 - "
8Ah   " WIND XXX at YY - " (where XXX and YY are replaced by wind
      direction and speed defined by the wind menu or generated by the
      weather generator; if both are off, this character is ignored)
8Bh   " MEASURED CEILING 00600 OVERCAST "
8Ch   "" (empty string)
8Dh   "" (empty string)
8Eh   "Microsoft Flight Simulator"
8Fh   " requesting "
90h   "clearance "
91h   ", your are cleared "
92h   "... "
93h   "7777 "


--------------------------
SECTIONS 14 : NDB
--------------------------

This section is made of the usual record 15h table grouping facilities in
North ranges each pointing to a record 04h table.

-- 04h ------------- NDB (42 bytes)

1     2   frequency integral part (BCD coded: 59h 03h = 359 kHz)
3     1   frequency decimal part (00h = .00 kHz; 05h = .50 kHz)
4     3   Latitude  in Iu
7     3   Longitude in Iu
10    2   Altitude in m
12    1   range in 2 Km units (= 2048m?)
13    5   NDB ID; string padded with spaces
18    24  NDB Name; string padded with spaces


--------------------------
SECTIONS 15 : DYNAMIC SCENERY
--------------------------

This section is made of the usual record 15h table grouping sceneries in
North ranges, each record pointing to a "table".

FS5 dynamic sceneries repeat by and large the same language as FS4 .DYN
files, with some additions and some modifications.  The most striking point
is that the old "delta" coordinates, familiar to FS4, are still used in FS5
dynamics, taking the simple meaning of linear meters.

The most significant change is the modification of inter-record references
from absolute to byte offsets.  Some new records are added and the model
drawing routines, which appeared in .DYN, no longer appear here and are
replaced by conventional codes referring to the objects.

Each "table" pointed by a record 15h starts with a 50-byte long record 04h;
given that another, 2-byte long, record 04h appears in the dynamics them-
selves with the same meaning it had in .DYN files, this initial record 04h is
probably responsible for passing the control to a different specialized
processor, possibly kept with few changes from FS4.

-- 04h ------------- ?? (50 bytes)

1     49  ???


Dynamics records are described below in another section of this document.


--------------------------
SECTIONS 16 : ??
--------------------------

This section is made of the usual record 15h table grouping facilities in
North ranges each pointing to a table.

-- 04h/05/06h ------ ??? (11 bytes?)

1     1   record length
2     3   Latitude  in Iu
5     3   Longitude in Iu
8     2   Altitude in m ??
10    1   ???

Records 04, 05 and 06 seem to share the same structure.

-- 07h ------------- Airport (24 bytes + airport name)

1     1   record length
2     3   Latitude  in Iu
5     3   Longitude in Iu
8     1   ???
9     2   Altitude in m
11    3   Another latitude  in Iu
15    3   Another longitude in Iu
18    1   ???
20    2   Another altitude in m
22    x   Variable length 0-terminated ASCII string with the airport name
22+x  1   runway 1 ID (bit 6 and 7 may be set: ??)
23+x  1   runway 2 ID (bit 6 and 7 may be set: ??)

This record defines two placement points for airport runways.


Other occuring, but unanalyzed, records are:

3Eh     1 time  in WORLD1.BGL
64h   140 times in WORLD4.BGL
65h     4 times in WORLD1.BGL


--------------------------
SECTIONS 17 : ??
--------------------------

This section is attested only in WORLD5.BGL, taking almost 6/7 of it; it is
essentially made of 0's, with some sparse values.


--------------------------
SECTIONS 18 : ??
--------------------------

This section is attested only in WORLD3.BGL, takind almost 1/3 of it; it is
essentially made of a 2-byte value table.  If this section is unlinked, zero-
ing its pointer in the WORLD3.BGL header, compass readings are affected and
is then probably related with magnetic deviation.


--------------------------
SECTIONS 19-21 : UNATTESTED
--------------------------


========================================


                               DYNAMIC RECORDS

Dynamic records are basically the same as FS4's .DYN files; they are the only
istance of a procedural programming language, like SDL, identified in FS5
sceneries.

Dynamic record section of FSSTRUCT is added below with the necessary
modifications.

The original FSSTRUCT section was based on a John Mechalas contribution.


-- 01h ----- Rotate model to pitch attitude (5 bytes)

1     2   Pitch angle
3     2   Speed

This record rotates the model about its lateral axis to the desired pitch
angle.  It displays the rotation process, and the speed of rotation is
defined by the bytes 3-4.  This is a signed value with the sign determining
the direction of rotation (clockwise or counterclockwise, etc..).  Fastest
rotation rate is 0000h, and slowest rotation is 7FFFh.  If the record is fol-
lowed by a move record (12h-18h), the rotation is performed during the move
and not before.

-- 02h ----- Rotate model to bank attitude (5 bytes)

1     2   Bank angle
3     2   Speed

Same as record 01, but for bank attitude.

-- 03h ----- Rotate model to yaw attitude (5 bytes)

1     2   Yaw angle
3     2   Speed

Same as record 01, but for yaw attitude.

-- 04h ----- Gear up/down  (2 bytes)

1     1   0 = gear up, 1 = gear down

-- 07h ----- Set heading (3 bytes)

1     2   New heading

Instantaneously sets the heading of the model.  In FS4 the final heading is a
CANTED value, not a geographical heading.

-- 08h ----- ??? (7 Bytes??)
-- 09h ----- ??? (7 Bytes??)
-- 0Dh ----- ??? (6 Bytes)

These 3 records are no longer attested in FS5 dynamics.

-- 12h ----- Move East (5 bytes)

1     2   Time in seconds
3     2   East displacement in m

This record moves the object from its current position to the delta position
in the defined number of seconds; a negative delta means West..

-- 13h ----- Move Alt (UNATTESTED, 5 bytes)

1     2   Time in seconds
3     2   Alt. displacement in m

Same as record 12h, but for altitude.  The record has not been actually
found, it has been inferred from the general pattern of record codes.

-- 14h ----- Move North (5 bytes)

1     2   Time in seconds
3     2   North displacement in m

Same as record 12h, but for North coordinate.

-- 15h ----- Move East / North (7 bytes)

1     2   Time in seconds
3     2   East  disp. in m
5     2   North disp. in m

Same as record 12h, but for East and North coordinates.

-- 16h ----- Move East / Alt (7 bytes)

1     2   Time in seconds
3     2   East disp. in m
5     2   Alt. disp. in m

Same as record 12h, but for East and Alt. coordinates.

-- 17h ----- Move Alt. / North (7 bytes)

1     2   Time in seconds
3     2   Alt.  disp. in m
5     2   North disp. in m

Same as record 12h, but for Alt. and North coordinates.

-- 18h ----- Move 3D (9 bytes)

1     2   Time in seconds
3     2   East  disp. in m
5     2   Alt.  disp. in m
7     2   North disp. in m

Same as record 12h, but for East, Alt. and North coordinates.

-- 19h ----- Accelerate East (7 bytes)

1     2   Time in second
3     2   Rate
5     2   East disp. in m

This record accelerates object motion from it's current position to the delta
position in the defined number of seconds.  The Rate parameter influences the
acceleration rate in a yet unclear way.

-- 1Ah ----- Accelerate Alt (UNATTESTED, 7 bytes)

1     2   Time in second
3     2   Rate
5     2   Alt. disp. in m

Same as record 19h, but for altitude.  The record has not been actually
found, it has been inferred from the general pattern of record codes.

-- 1Bh ----- Accelerate North (7 bytes)

1     2   Time in second
3     2   Rate
5     2   North disp. in m

Same as record 19h, but for the North coordinate.

-- 1Ch ----- Accelerate East / North (7 bytes)

1     2   Time in second
3     2   Rate
5     2   East  disp. in m
7     2   North disp. in m

Same as record 19h, but for the East and North coordinates.

-- 1Dh ----- Accelerate East / Alt (9 bytes)

1     2   Time in second
3     2   Rate
5     2   East disp. in m
7     2   Alt. disp. in m

Same as record 19h, but for the East and Alt. coordinates.

-- 1Eh ----- Accelerate Alt. / North (9 bytes)

1     2   Time in second
3     2   Rate
5     2   Alt.  disp. in m
7     2   North disp. in m

Same as record 19h, but for the Alt. and North coordinates.

-- 1Fh ----- Accelerate 3D (11 bytes)

1     2   Time in second
3     2   Rate
5     2   East  disp. in m
7     2   Alt.  disp. in m
9     2   North disp. in m

Same as record 19h, but for the East, Alt. and North coordinates.

-- 20h ----- Turn left/right about point (7 bytes)

1     2   Time in seconds
3     2   Final heading
5     2   Turning radius (m)

Turns the model to the new heading in the given amount of time.  The center
of the turning circle is defined in delta FSu from the current position along
the lateral axis.  Left/right turns are performed depending on the current
and final heading so that no turn is greater than 180 degrees.

Final heading was a CANTED value in FS4.

-- 24h ----- Jump (3 bytes)

1     2   Byte offset to jump to

-- 25h ----- Call subroutine (3 bytes)

1     2   Called subroutine byte offset

-- 26h----- Return from subroutine (1 byte)

-- 27h ----- Hold position (3 bytes)

1     2   Wait time in seconds

This freezes the model at its current position for the given number of sec-
onds.

-- 28h ----- Define position (13 bytes) OBSOLETE

1     4   E coord (fract FSu)
5     4   A coord (fract FSu)
9     4   N coord (fract FSu)

This record no longer appears in FS5 dynamics and its functions is superseded
by record 33h.  In FS4, it used to define the "starting point" for the pat-
ter, used at the very beginning of the pattern definition.

-- 29h ----- Sleep (1 byte)

Puts the pattern in sleep; the model remains at the current position until
awakened by another pattern.

-- 2Ah ----- Awaken (3 bytes)

1     2   Byte offset of the rec 32h defining the pattern to awaken

Awaken the specified pattern, if it was in sleep.

-- 2Eh ----- Test variable ?? (7 bytes)

1     2   Jump absolute address
3     2   "variable"
5     2   value

Jumps to the given address, if the given "variable" is equal to the given
value.
Used to test the contents of "variable" 0004 in a way that lets presume that
0004 contains the dynamic scenery detail.  0004 is probably not a variable in
the FS4's sense, but some conventional index.

-- 31h ---- Pattern setup (4 bytes)

1     1   parameter?
2     2   value?

Used 4 or 5 times at the beginning of each pattern, with parameters 00-04 and
a restricted number of values.

-- 32h ---- Pattern declaration (8 bytes)

1     2   Model:         FE0Bh = Cessna
                         FE0Ch = Learjet
                         FE0Dh = sailboat
                         FE0Fh = truck
                         FE10h = large size jet
3     2   Byte offset of pattern definition
5     2   Always 00h ??
7     1   ???

This record is used at the beginning of a dynamic "table" to declare the pat-
terns contained in the table.

-- 33h ---- Set pattern position (19 bytes)

1     2   ???
3     3   Latitude
6     2   ???
8     2   ???
10    3   Longitude
13    2   ???
15    2   Altitude above MSL in m
17    2   ???

This record defines the initial position of the pattern object.

-- FFh ----- Exit (1 byte)

Exits the DDL processor.


Note that records 28h (replaced by 33h), 2Ch, and 2Fh no longer appear in FS5
dynamics.

===================  FS5STRUCT.TXT  END  =============================
