MICROSOFT FLIGHT SIMULATOR DATA FILE STRUCTURES INTRODUCTION Document version 2.0, release date: 15 November 1992. Updates: ù Added static scenery record codes reference ù Completed 5Ah record in mountain description ù Corrected description of 0Bh, 0Eh, 16h, 25h records and "range" records ù Added ATC records and many records used in other kinds of scenery ù Added .DEM and .MOD file structures Many record codes have been added, and more obscure points have surfaced. Document version 1.0, release date: 15 September 1992. This document describes the structures of files created or provided with Microsoft Flight Simulator 4.0 and/or the Microsof Aircraft and Scenery Designer ver 1. The document is ideally addressed to developers and requires a good knowledge of hex notation and some familiarity with programming concepts. 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 often 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 description of the field. ù 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". Additions, corrections or suggestions are welcome. I apologize for English language errors and inelegancies. I would like express my debt to Greg Pierson [72520,1775] whose program DCOD01.EXE has been seminal in my work and to Dan Samuel [70110,434] who contributed a lot of information. Maurizio M. Gavioli CompuServe: 100021,2335 InterNet: "Maurizio M. Gavioli" -------------------------- DISCLAIMER -------------------------- The below information was derived from hours of analysis of FS4/ASD files (often manually generated for this very purpose). The FS4/ASD community as a whole has spent way too much time decoding this information in order to generate useful utilities. It would be nice if the original authors chose to publish an "official" documentation of FS data files. However, the below information is not distributed with an eye towards enabling anyone to rob the original authors of any rightful profits and should be used only for the common good of the FS4 community and to encourage availability and sales of FS4 and related products and utilities. ======================================== GENERAL CONCEPTS FS COORDINATES AND GEOGRAPHIC UNIT FS North and East coordinates are internally coded with code 49,152 (= C000h) representing coordinate 0; therefore codes from 49,152 to 65,535 (C000h to FFFFh) represent coordinates from 0 to 16,383 and codes from 0 to 49,151 (0000h to BFFFh) represent coordinates from 16,384 to 65,535. The reason for this coordinate shift is not clear. Within programs, internally coded coordinates can be convert to external FS coordinated by subtracting 49152 (C000h) from the value considered as unsigned Manually, coded coordinates below 49,152 can be converted to FS coordinates by adding 16,384, and coded coordinates above 49,151 can be converted by subtracting 49152. Judging from how scenery radii are converted to Km by ASD, 1 FS coordinate unit (FSu) seems to be very close to 256 meters. Coded coordinates can appear in object definitions in one of three ways: ù INTEGER (2 bytes): a word containing only an integer coordinate (indicated as "int FSu") ù FRACTIONARY (4 bytes): a double word made of a high order word (4th and 3rd bytes) containing the coordinate integer part and a low order word (2nd and 1st bytes) containing the fractionary part. In most cases, the 1st byte is 0: the fractionary part is therefore expressed in 256th, and each 256th is almost equal to 1 meter. Therefore, fractionary coordinates can also be interpreted as made by 3 high order bytes expressing a distance (from coordinate origin) in meters and a low order byte containing a fractionary part in 256th of meter; this is confirmed by altitude fields, because altitude is almost invariably indicated in this way (with the fractionary byte left often unfilled). Both interpretations are indicated as "fract FSu". ù DELTA (2 bytes): a word representing the difference from an actual coordinate given elsewhere (usually in a previous ref. point record, see below); the high order byte (2nd byte) contains the integer part of the difference and the low order byte (1st byte) the fractionary part; as fractionary part units are equal to 1 meter, delta coords can also be interpreted as distance in meters from the reference point. Contrarily to the other two representations, which are always positive, this representation is signed, and therefore the maximum possible difference (and the maximum possible radius of a scenery object) is 32,767 m. This representation is indicated as "delta FSu". OBJECT ORIENTATION Some objects, like runways, buildings and aircraft positions, are oriented. The angle of this orientation is always given relatively to the North axis of the FS coordinate system. For some kind of cartographic compensation not discussed here, this axis is not necessarily the same as the compass North (this explains why, while flying or slewing in the 0.00 direction, E coordinate also can slowly change). Directions displayed by FS and ASD are relative to the compass North and, therefore, there can be a rotation between the directions as displayed by ASD and as memorized in the files. Unless otherwise stated, orientation or heading fields, as well as "pitch" and "bank" fields, are 2 bytes long and are expressed in 1/182.04ø: 0000h = 0ø -> 10000h = 360ø RECORDS Many kinds of FS data files are made of "records", i.e. chunks whose structure, contents and meaning are determined by the first record byte (thereafter called "record code"); records may contain many values (thereafter called "fields"), and, with a few exceptions, the length of the record is constant for each record code. 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 a file type to another. Some file types (as .SC1 and .DY1) start with a non-record coded portion ("header") containing general information about the file. VARIABLES FS apparently mantains somewhere in memory a set of variables, which affect the display engine and/or the flight simulation engine. These variables are accessed with a value which looks like a memory address (or a table offset) and has been called "variable address". Attested addresses are in the range 0288h - 031Eh. Variables can be set and tested from within a scenery file. Attested variable usages are the following: var at set to in 0288 0001 fuel boxes 028C 2 = day; 4 = night; 6 = dusk? 029C East plane position? 029E Alt. plane position? 02A0 North plane position? 02E2 colour surfaces; the colour code is usually repeated in all the four nibbles 02EF altit. (in m) to set the altitude above sea level of current area 02F6 0001 inner marker 02F8 0001 outer markers 02FA 0001 middle markers 0312 0001 by SEE, before 20h, 1Fh record list 031E 0000 mountains 031E 0001 " BYTE OFFSET Many records contain an offset, pointing to another record. It is used to state the total length of an object definition (or of a relevant portion of it) or to provide some forms of inter-record addressing for conditional (after variable test) or unconditional jumps. These offsets are indicates as "bytes offset" and are always relative to first byte (code byte) of the record which contains them. ====================================================================== STATIC SCENERY FILES (.SC1) GENERAL STRUCTURE Static scenery files are made of: ù a header containing a lookup table for the various file sections, the scenery boundaries, and the scenery name; this header is 73 bytes long; ù 9 sections, containing definitions of Navaids, Polygon, Rivers, Roads, Lines, Runways, Mountains, Timing gates, and Buildings respectively. Each section is terminated by a single byte code 79h. Consequently, an empty scenery file is 82 bytes long: 73 for the header and 1 for the ending byte of each section. Each object definition is made by records describing the different features or parts of the object; the great majority of the records have a fixed length, but objects of variable shape (like polygons) may contain a variable number of records and have therefore a variable length. In static scenery files, some record codes can have the most significant bit set or reset, without any apparent difference. Attested cases are always reported. ==================== HEADER STRUCTURE - length: 73 bytes 0 2 file size 2 2 0003h (a kind of signature?) 4 2 002Ah (= 42, pointer to scenery name) 6 2 0049h (= 73, header length) 8 2 pointer to Navaid section (always 73) 10 2 pointer to Polygon section 12 2 pointer to River section 14 2 pointer to Road section 16 2 pointer to Line section 18 2 pointer to Runway section 20 2 pointer to Mountain section 22 2 pointer to Timing gate section 24 2 pointer to Building section 26 4 E coord. of scenery center (fract. FSu: all 4 bytes used) 30 4 N coord. of scenery center (fract. FSu: all 4 bytes used) 34 2 scenery radius (int. FSu) 36 6 always 0 ?? 42 31 scenery names: up to 30 characters (padded with space, if shorter) plus a 0 ending byte ==================== RECORD CODE REFERENCE Record are listed by code. Field at offset 0 always contains the record code and is 1 byte long. Some records are not found in .SC1 files, but have been detected in other kind of sceneries and have been included for completness (?); usually their meaning is unknown, only their length has been determined. Records found in SEE enhanced sceneries are marked with SEE, while records found in the default scenery F1 are marked DEF. These kinds of scenery have not been completely parsed yet, therefore it cannot be excluded that a record appears in other scenery kind as well. Record description contributed by Dan Samuel are marked with an DS. -- 00h ------DS----- ??? (7 bytes) =SEE= -- 01h ------DS----- ??? (7 bytes) =SEE= -- 02h ------DS----- ??? (7 bytes) =SEE= -- 03h ------DS----- ??? (2 bytes) =SEE= -- 05h ------------- NDB (11 bytes) 1 2 frequency; BCD coded (ex.: 327 kHZ -> 27h 03h) 3 4 E coord. (fract. FSu) 7 4 N coord. (fract. FSu) -- 0Bh ------DS----- Unconditional jump (3/5 bytes) 1 2 byte offset [3 2 signature?] This record tells FS to jump over a given amount of bytes, avoiding rendering some object feature. It is usually used after a test record to providing branching to another point fo the object definition. This record is very problematic: it is probably only 3 bytes long, but it is also sometime used to insert in the file some information (a 2-byte "signature" is a common case) apparently not relevant for the display engine but in some way useful to the scenery editor (either ASD or SEE or whatever) for identifying the object been defined. See also the discussion under record 0Eh. -- 0E/8Eh ---DS----- Jump over 0Bh record (3 bytes) 1 2 byte offset This record has a meaning quite similar to 0Bh, but it is attested only for jumping above a 0Bh record. The length at offset 1 is either 0006h or 0008h, for 0Bh records 3 or 5 bytes long resp. Records 0Eh and 0Bh are often used within many object definitions in a particular construct: 0 1 0Eh: record code 1 2 0006h (when there is no "signature") or 0008h (when there is a "signature") 3 1 0Bh: record code 4 2 lenght [6 2 "signature" corresponding to the type of the object being defined] The given length is the length of the remainder of the object definition or of a part of it; this length, added to the offset of the 0Bh record code byte, points to a single byte 19h record. This construct has been cumulatively called "variable structure construct" and the 19h record "end of variable structure record". -- 0Fh ------------- ?? (6 bytes) =DEF= -- 12h ------------- Line Colour (2 bytes) 1 1 colour code from the following table: 0 Black 1 Dark Green 2 Dark Blue 3 Dark Cyan 4 Orange 5 Light Grey 6 Light Blue 7 Cyan 8 Brown 9 Yellow Ah Dark Grey Bh Light Green Ch Red Dh Gold Eh (apparently not used/transparent?) Fh White -- 13h ------------- ?? (15 bytes) =DEF= -- 14h ------------- ?? (10 bytes) =SCN= -- 15h ------DS----- Orientation/delta point (16 bytes) =SEE= 1 2 "pitch" ? 3 2 "bank" ? 5 2 heading 7 2 E coord. (delta FSu) 9 2 A coord. (delta FSu) 11 2 N coord. (delta FSu) 13 2 always 0010h ?? 15 1 always 19h ?? -- 16h ------------- Orientation (9 bytes) 0 1 16h: record code 1 2 "pitch" (noze down is positive, noze up is negative) 3 2 "bank" (left is positive, right is negative) 5 2 orientation or heading 7 2 always 000A ?? "Pitch" and "bank" come from an airplane analogy and describe object tilting as if it were an airplane. Orientation is relative to the North coordinate axis, not to the compass North. -- 17h ------------- ?? (1 byte) This single byte record has been observed only in timing gate definitions. -- 18h ------------- ?? (3 bytes) =DEF= -- 19h ------------- End of structure (1 byte) This record, made of the single byte 19h, marks the end of a variable structure contruct (0Eh + 0Bh). -- 1Ah ------------- ?? (5 bytes) =DEF= -- 1Dh ------------- VOR (11 bytes) 1 2 frequency; BCD coded (ex.: 109.15 MHz -> 15h 09h) 3 4 E coord. (fract. FSu) 7 4 N coord. (fract. FSu) -- 1Eh xxxx -------- ATC message (xxxx bytes) 1 2 record length 3 2 frequency; BCD coded (ex.: 127.15 MHz -> 15h 27h) 5 4 4 runway numbers (often repeated) 9 4 fixed: 1Eh 37h 52h 3Ch 13 var message text (0-terminated) The message text can include any character from ASCII 20h to ASCII 93h. Characters greater than 93h result in garbage being transmitted. When the message is played back, characters from 80h to 93h are expanded into the following strings (stored in ATC.FS4): 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 " -- 1Fh ------DS----- Branch (3 bytes) 1 2 byte offset A group of 1F records is generally preceded by a 20h record. -- 20h ------DS----- Jump if var between (9 bytes) 1 2 byte offset 3 2 address of variable 5 2 value1 7 2 value2 This record jumps over the given amount of bytes, if variable at the given address tests some way in relation to value1 and value2. value2 is often 7FFFh and the test can be: "branch if var is between value1 and value2". -- 21h ------------- Check 2 vars for range (15 bytes) 1 2 byte offset 3 2 var1 address 5 2 var1 min value 7 2 var1 max value 9 2 var2 address 11 2 var2 min value 13 2 var2 max offset This record, as well as the following, is either: ù oriented toward the display engine and skips over (or steps through) a group of records when the two given variables are outside or inside the given ranges or ù oriented toward the flight simulator engine and performs (or doesn't perform) some task when... The record has been found, among other, in fuel boxes (which are aways displayed), where variables are 029Ch and 02A0h and ranges cover the fuel box surface; one may speculate that these variables, during the simulation, hold the plane E and N coordinates (029Eh containing the altitude) and that refueling occurs when the plane is inside the fuel box surface. This record is widely used in F1, where var1 is often equal to var2. -- 22h ------------- Check 3 vars for range (21 bytes) 1 2 byte offset 3 2 var1 address 5 2 var1 min value 7 2 var1 max value 9 2 var2 address 11 2 var2 min value 13 2 var2 max offset 15 2 var3 address 17 2 var3 min value 19 2 var3 max offset This record is similar to the previous, but involves 3 variables. It has been found in mountain definitions, where vars are 029Ch, 029Eh, 02A0h and ranges include the mountain volume. -- 23h ------DS----- Jump if var not equal (7 bytes) 1 2 byte offset 3 2 var address 5 2 value This record jumps if the given var is not equal to the given value. -- 24h ------------- Reference point (14 bytes) 1 1 always 04h ?? 2 4 E coord. (fract. FSu) 6 4 AGL alt. (fract. FSu) 10 4 N coord. (fract. FSu) A reference point record is used within the definitions of some kinds of object to define a point in 3D, near the center of the object; other points of the object are then defined relatively to this point. -- 25h ------DS----- Set variable (5 bytes) 1 2 variable address 3 2 new variable value This record sets the given variable to the given value. -- 28 -------------- ?? record (8 bytes) 1 1 record sub-code?? (always 36h in .SC1) 2 2 byte offset ? 4 2 var address ? 6 2 value ? Used in suspended bridges, cars and fuel boxes. Attested in F1. -- 29h ------------- Close path (1 byte) This record, made of the single byte 29h, is used to close a path being drawn with 40h and 41h records. A line is drawn from the current point to the starting point of the last executed 41h record. If the surface colour variable (02E2h) has been set, the path is filled with that colour. It is not clear how the display engine is able to detect when the colour var has not been set (var 02E2h will always contain some value), maybe the line colour record (line drawing is the only occasion when surface filling is not required) sets the colour var to a null (0Eh ?) or invalid colour code. -- 2Ah ------DS----- Two delta points (14 bytes) =SEE= 1 2 P1 E coord. (delta FSu) 3 2 P1 A coord. (delta FSu) 5 2 P1 N coord. (delta FSu) 7 2 P2 E coord. (delta FSu) 9 2 P2 A coord. (delta FSu) 11 2 P2 N coord. (delta FSu) 13 1 ?? -- 2Fh ------------- Path list begin (1 byte) This record, made of the single byte 2Fh, is used to start a path. Path are used to draw lines and polygon perimeters. The path list describes a path made of straight lines connecting points. Each path description begins with the single byte code 2Fh. Then, a move record defines the first path point and other draw or move records define the other points. Line paths can contain any combination of move and draw operations to describe interrupted lines. Polygon perimeters have a move to the first point followed by draws to following points. Paths can be 'closed' by a single byte record 29h which draws a line from the current point to the starting point of last move record. Polygon perimeters MUST be closed. -- 30h ------------- ?? (8 bytes) =DEF= -- 31h ------------- 3D-point (8 bytes) 1 1 point number (for mountains, peaks are numbered from 01h to 0Fh, base points from 21h inward) 2 2 E coord of point (delta FSu) 4 2 Altitude in m above ground level 6 2 N coord of point (delta FSu) This record is used in mountain description to set mountain vertices. -- 32h ------DS----- Move to 3D point (2 bytes) =SEE= 1 1 point number Moves the pen (without drawing) to the point. Point numbers have been set by a previous 31h record. -- 33h ------DS----- Draw to 3D point (2 bytes) =SEE= 1 1 point number Draws to the point. Point numbers have been set by a previous 31h record. -- 35h ------DS----- ?? (2 bytes) =SEE= -- 3Eh ------------- Area (9 bytes) 1 2 byte offset: the total length in bytes of the following object definition (this record included) 3 2 N coord. (int FSu) 5 2 E coord. (int FSu) 7 2 area radius (int FSu) An area record starts the representation of each scenery object, gives the total length of the object and defines the area (usually centered near the object center) within which the object is visible. -- 40/C0h ---------- Move to 2D point (5 bytes) -- 41h ------------- Draw to 2D point (5 bytes) 1 2 E coord. of the point (delta FSu) 3 2 N coord. of the point (delta FSu) Move and draw records are used to define points of lines and of polygon perimeters. A move record moves to the point given in the record without drawing anything, a draw record draws a line segment or a polygon boundary from the previous point to the given point. Move record code can be either 40h or C0h, without any visible difference. All coords are delta coords and are relative to a previously given ref. point record. -- 43h ------DS----- ?? (1 byte) -- 45h xxxx -------- Thermal generator (xxxx bytes) 1 2 record length (0025h) 3 4 E coord of generator center (fract FSu) 7 4 altitude AGL of generator center ? 11 4 N coord of generator center (fract FSu) 15 2 orientation 17 1 ??? 18 2 generator width (in m) 20 2 ??? 22 2 thermal effect height (in feet) 24 2 ??? 26 2 generator length (in m) 28 9 ??? This record has been found only in thermal generators. -- 4Ch ------DS----- ?? (2 bytes) =SEE= -- 4Dh xxxx--DS----- ?? (xxxx bytes) =SEE= -- 4Eh ------DS----- ?? (4 bytes) =SEE= -- 4Fh ------------- ILS (15 bytes) 1 2 frequency; BCD coded (ex.: 109.15 MHz -> 15h 09h) 3 4 E coord. (fract. FSu) 7 4 N coord. (fract. FSu) 11 2 Approach course in 1/3ø (0 -> 0, 359 -> 0435h) 13 3 Glide slope in 1/9100 (0 -> 0, 7.20 -> FFFFh) -- 50/D0h ---------- Runway (35 bytes) See below under runway descriptions for details. -- 51h ------------- Side list end (used in mountains, 1 byte) -- 52h ------DS----- ?? (2 bytes) =SEE= -- 53h ------------- Building (variable) The building record defines the aspect of a building, its length and structure varies according to the building type. Here a summary is given, see below, under building descriptions, for details. 2nd byte building type and length 01 Rectangular building record (18 [flat] and 19 [peaked] bytes) 02 L building record (24 [flat] and 27 [peaked] bytes) 03 T building record (28 [flat] and 32 [peaked] bytes) 04 U building record (28 [flat] and 33 [peaked] bytes) 05 H building record (34 [flat] and 41 [peaked] bytes) 06 Reversed L build. record (24 [flat] and 27 [peaked] bytes) 07 Control tower record (20 bytes) 29 Tower record (6 bytes) 33 Suspended bridge record (8 bytes) 34 Bridge record (8 bytes) 3D Timing gate record (17 bytes) 42 Coniferous tree record (7 bytes) 43 Deciduous tree record (7 bytes) 47 Auto record (3 bytes) 4C Multi-sided building record (13 bytes) -- 58h ------DS----- 3D text (43 bytes) =SEE= 1 7 ??? 8 2 text size 10 32 text, 0-terminated 42 1 always 17h ?? (in that case, it could be another occurrence of the 17h record) -- 5Ah ------DS----- 3D-triangle (10 bytes) 1 2 E component of the "triangle vector" (see below) 3 2 A component 5 2 N component 7 3 numbers of the 3 points, listed in anti-clockwise order looking to the triangle from outside This record is used in mountains and is probably used to speed up the hidden surface removing process. The "triangle vector" is the cross product of the vectors for the P2-P1 and the P3-P1 edges of the tiangle, the cross product is then scaled so that no coord value is > 16383. Point numbers at offset 7- 9 correspond to mountain vertices defines in a previous list of 3D points (list of 31h records). -- 6Fh ------DS----- ?? (11 bytes) =SEE= -- 79h ------------- Linked list end (1 byte) Marks end of linked list. It is used to mark the end of .SC1 file sections. ==================== OBJECT DETAILED DESCRIPTIONS The following section contains a detailed description of all the object found in standard .SC1 files, with examples of decoding. With the exception of ATC messages, SEE extensions are not included. ==================== NAV AIDS Like all .SC1 object, navaids begin with an area record; NDB, VOR, and ILS add a specific record (05h, 1Dh, 4Fh, resp.); Markers add a 25h record setting var 02F6h (inner marker), 02F8h (outer marker) or 02FAh (middle marker) to 0001. Adding the 9 bytes of the area record, the total length of each kind of Nav aids is (in parenthesis, the area radius set by ASD): NDB 20 bytes (500 FSu = 128 Km = 69 NM) VOR 20 bytes (500 FSu = 128 Km = 69 NM) ILS 24 bytes (250 FSu = 64 Km = 34.6 NM) OM 14 bytes (2 FSu = 512 m) MM 14 bytes (2 FSu = 512 m) IM 14 bytes (1 FSu = 256 m) Example: 3E 18 00 92 03 8C 04 FA 00 4F 25 09 00 06 8C 04 00 00 92 03 2C 01 FF 6A is interpreted as: 3Eh Area record 0018h object is 24 bytes long 0392h N coord of visib. area is [0392h =] 914 + 16384 = 17298 048Ch E coord of visib. area is [048Ch =] 1164 + 16384 = 17548 00FA area radius is [FAh =] 500 FSu 4Fh ILS record 0925h frequency is 109.25 MHz 048C0600h E coord is [0485.06h =] 1164+6/256 + 16384 = 17548.0234 03920000h N coord is [0392.00h =] 914+0/256 + 16384 = 17298.0000 012Ch approach course is [012Ch =] 300 / 3 = 100ø 6AFFh glide slope is [6AFFh = ] 27391 / 9100 = 3.01 ==================== ATC MESSAGES ASD cannot add ATC messages to sceneries. However, messages added to .SC1 files with other programs (or manually!) are correctly played by FS4 and do not interfere with ASD ability to manipulate the modified .SC1. The following structure has been determined from SEE4-modified sceneries. ATC messages are made by: ù an area record ù a 5-byte jump record with fixed contents: 0Bh 0005h 41h 43h (where 4341h is probably an ID meaning "ATC") ù an ATC message record (1Eh) ==================== POLYGONS Polygon descriptions are made of an area record, a ref. point record, a surface colour record and a point list. As for any object of variable size, area radius is not fixed, like in nav aids, but depends on the polygon size. Triangles are special, because, after the polygon proper, they add a 3-point line corresponding to two of the three sides of the triangle; this line has the same colour of the triangle and cannot be seen. Example: 3E 3E 00 92 03 8D 04 03 00 24 04 00 4D 8D 04 00 0A 00 00 00 B9 92 03 25 E2 02 99 99 2F 40 F2 FF 08 00 41 0D 00 0B 00 41 0F 00 F6 FF 29 12 09 40 F2 FF 08 00 41 0D 00 0B 00 41 0F 00 F6 FF is interpreted as: 3Eh Area record 003Eh object is 62 bytes long 0392h N coord of visib. area is 17298 048Dh E coord of visib. area is 17549 0003 area radius is 3 FSu 24h 04h Ref. point record 048D4D00h E coord is [048D.4Dh =] 1165+77/256 + 16384 = 17549.0273 00000A00h altitude above ground level is [00000Ah =] 10 m 0392B900h N coord is [0392.B9h =] 914+185/256 + 16384 = 17298.7227 25h Set variable record 02E2h variable at 02E2 (surface colour) 9999h set to colour 9 (yellow) 2Fh Point list begin 40h Move record FFF2h E coord of P1: [FF.F2h =] -14/256 + 17549.0273 = 17548.9726 0008h N coord of P1: [00.08h =] 8/256 + 17298.7227 = 17298.7540 41h Draw record 000Dh E coord of P2: [00.0Dh =] 13/256 + 17549.0273 = 17549.0781 000Bh N coord of P2: [00.0Bh =] 11/256 + 17298.7227 = 17298.7657 41h Draw record 000Fh E coord of P3: [00.0Fh =] 15/256 + 17549.0273 = 17549.0859 FFF6h N coord of P3: [FF.F6h =] -10/256 + 17298.7227 = 17298.6836 29h Close and fill (polygons with 4 or more points, would stop there) 12h 09h Line colour is 9 (yellow) 40h FFF2h 0008h same move record as above 41h 000Dh 000Bh same draw record as above 41h 000Fh FFF6h same draw record as above ==================== RIVERS Even if they are created in ASD stretching and bending rectangular strips of colour, rivers are actually memorized in scenery files as polygons, and follow the same format described in the previous section. The reason for keeping them in a specific section resides probably in the order in which scenery object are drawn. Rivers can also contain skips: in this case, the river description contains a single area record and a single ref. point record followed by a surface colour record and a point list for each polygon created by skipping. ==================== ROADS Roads also are memorized as polygons, and follow the polygon format. For skippings, the same observation made about rivers, holds also for roads. Country roads and city streets require no observations. 4-lane roads contain, after the point list describing the road perimeter, a line colour record and a line point list describing the road middle line. Divided highways, after the area and ref. point records, contain a single surface colour record (25h) with two polygon point lists to describe the two road ways, then a line colour record, a conditional jump record (23h) on var 028Ch value and another line colour record to change colour line according to time, and a line point list with 4 jumps to describe the 4 borders of the ways. ==================== LINES Line descriptions are made of an area record, a ref. point record, a line colour record and a line point list. If the line contains skips, a new line colour record and a new line point list are generated for each line section. ==================== RUNWAYS Runway descriptions are made of 2 area records referring to the same point (one for the distance at which the runway is sketchily visible, the other for the distance at which it is fully visible), a 25h record to set area altitude and the specialized runway record: Runway record - code: 50h/D0h length: 35 bytes 0 1 50h or D0h: record code 1 4 E coord of center (fract. FSu) 5 4 Altitude (fract. FSu) 9 4 N coord of center (fract. FSu) 13 1 Design elements (bit is 1 if the element is present): bit 7: always 1 6: always 1 5: Numbers 4: Dashes 3: Fixed distance markers 2: Touchdown markers 1: Threshold markers 0: Edges 14 1 Runway colour (repeated in each nibble) 15 1 Edge colour (") 16 1 Threshold mkr colour (") 17 1 Touchdown mkr colour (") 18 1 Fixed distance mkr colour (") 19 1 Dash colour (") 20 1 Number colour (") 21 1 Runway number (down side) as hex number 22 1 Designator: 0: none 1: LEFT/RIGHT 2: RIGHT/LEFT 3: CENTER/CENTER 23 1 Down side lights: bit 0: End light 1: always 0? 2: REIL 3: VASI high nibble value: 0: none 1: MASLR 2: MASLR with strobes 3: SSALR 4: SSALR with strobes 5: MALSF 6: MALSF with strobes 7: SSALF 8: SSALF with strobes 9: ALSF-I A: ALSF-II 24 2 Down side VASI slope in 1/10ø 26 1 Up side lights (as in byte 23) 27 2 Up side VASI slope in 1/10ø 29 2 Up side direction in 1/182.04ø 31 2 Runway width in m 33 2 Runway length in m Note: up side refers to the runway end located up when placing it, down side is the other end. Example: 3E 3A 00 2B F9 2D 05 32 00 3E 0E 00 2B F9 2D 05 15 00 25 EF 02 0F 00 D0 00 4C 2D 05 00 00 00 00 00 21 2B F9 FF 00 88 DD 88 99 FF FF 04 00 01 1C 00 39 1E 00 5C 15 2D 00 52 08 is interpreted as: 3Eh Area record 003Ah object is 58 bytes long F92Bh N coord is [F92Bh =] 63787 - 49152 = 14635 052Dh E coord is [052Dh =] 1325 + 16384 = 17709 0032h area radius is 50 FSu (12.8 Km) 3Eh Area record 000Eh 16 bytes F92Bh N coord is 14635 again 052Dh E coord is 17709 again 0015h inner area radius is 21 FSu (5.4 Km) 25h Set var 02EFh at 02EFh (area altitude) 000Fh to 15 m above sea level D0h Runway record 052D4C00h E coord. of runway is 17709.2969 00000000h Altitude is 0 F92B2100h N coord. of runway is 14635.8711 FFh runway has all design elements 00h runway colour is Black 88h edge colour is Brown DDh threshold mkr colour is Gold 88h touchdown mkr colour is Brown 99h fix. dist.mkr colour is Yellow FFh dash colour is White FFh number colour is White 04h runway number is 4 00h no designator 01h down side has end lights 001Ch down side VASI slope is [1Ch =] 28 / 10 = 2.8ø * 39h up side has VASI and end light (9) of type SSALR (3) 001Eh up side VASI slope is [1Eh =] 30 / 10 = 3.0ø 155Ch runway direction is [155Ch =] 5468 / 182.04 = 30.04ø 002Dh runway is [002Dh =] 45 meter wide 0852h runway is [0852h =] 2130 meter long Note: down side VASI slope is actually undefined because down side has no VASI. ==================== MOUNTAINS Mountains are among the most complex ASD objects. These are the records used to define a mountain: ù an area record, ù a jump over jump record (0Eh) (variable structure construct) ù a 3-byte jump record (0Bh) spanning the entire mountain definition ù a ref. point record. Then, for each peak and each point of the base, there is: ù a 3D-point record (31h) ù a 25h 031Eh 0000h constant record ù a 22h record with a byte offset of 001Ah and checking values of vars at 029Ch (E coord.), 029Eh (A coord.), and 02A0h (N coord.) ù a 25h 031Eh 0001h constant record Then, for each side of the mountain, two records are given: ù an area colour record (25h 02E2h xxxxh) ù a 3D-triangle record (5Ah) The side list is terminated by the single byte record 51h, and the entire object by the single byte record 19h Example: This example describes a square mountain, with sides 2 FSu long and parallel to the coordinate axes. 3E 00A2 0393 048C 0040 Center: 17299, 17548; radius: 64 FSu 8E 0006 Jump over the next 0Bh record (var. struct. constr.) 0B 0096 Jump over [0096h =] 150 bytes 24 04 048C0000 00000000 03930000 Ref. point: 17548 E, 0 AGL, 17299 N 31 01 0080 0098 0080 1st peak: +0.5 E,+152 m, +0.5 N from ref. point 31 21 FF00 0000 0100 1st point:-1.0 E, + 0 m, +1.0 N from ref. point 31 22 0100 0000 0100 2nd point:+1.0 E, + 0 m, +1.0 N from ref. point 31 23 0100 0000 FF00 3rd point:+1.0 E, + 0 m, -1.0 N from ref. point 31 24 FF00 0000 FF00 4th point:-1.0 E, + 0 m, -1.0 N from ref. point 25 031E 0000 Set var at 031Eh to 0 (fixed) 22 001A 3-var record: byte offset 26 029C FF00 0100 var 029Ch (E range): -1.0 to +1.0 around ref. point 029E 0000 0198 var 029Eh (A range): 0 to [0198h - 0100h =] 152 m 02A0 FF00 0100 var 02A0h (N range): -1.0 to +1.0 around ref. point 25 031E 0001 set var at 031Eh to 1 (fixed) 25 02E2 5555 Surface colour: Light Grey 5A 1300 D000 0000 01 21 24 Triangle thru 1st peak, 1st and 4th points 25 02E2 8888 Surface colour: Brown 5A 0000 D000 1300 01 24 23 Triangle thru 1st peak, 4th and 3rd points 25 02E2 AAAA Surface colour: Dark Grey 5A DA00 E000 0000 01 23 22 Triangle thru 1st peak, 3rd and 2nd points 25 02E2 5555 Surface colour: Light Grey 5A 0000 E000 DA00 01 22 21 Triangle thru 1st peak, 2nd and 1st points 51 End of triangle list 19 End of variable structure ==================== TIMING GATES Timing gate description is not fully deciphered. It is made of: ù an area record ù a jump over jump record (variable structure construct) ù a jump record ù a reference point record ù an orientation record ù a single byte record (17h) ù a specialized timing gate record ù an end of structure record. -- 53h 3Dh --------- Timing gate (17 bytes) 0 0 53h: object record code 1 1 3Dh: timing gate sub-code 2 2 gate width in m 4 2 gate height in m 6 1 front colour (code in both nibbles) 7 1 back colour (code in both nibbles) 8 2 always 0 ?? 10 1 gate number from 0 onward; last gate number has msb set 11 2 ?? 13 2 ?? 15 2 ?? Note: the last 3 field values vary from gate to gate of the same amounts of which E coord., alt. and N coord. vary; they are perhaps connected with the distance from gate to gate. ==================== BUILDINGS All real buildings share the same structure (poles, bridges, trees, autos, fuel boxes and thermal generators depart somewhat from this structure): ù an area record ù a jump over jump record (0Eh) (variable structure construct) ù a 5-byte jump record (0Bh) spanning the entire object definition; the last word contains a value related to building type and detailed below ù a reference point record ù an orientation record ù a first end of structure record (19h single byte) ù a 53h variable record depending on the object ù a second end of structure record. For buildings, the 53h record contains: ù the record code 53h in the 1st byte ù a sub-code related to the building type in the 2nd byte ù a series of 2-bytes fields defining wall distances from ref. point (first horizontal positions from left [negative] to right [positive], then vertical positions from top [positive] to bottom [negative]) ù a 2-bytes field with base height ù a single byte field with peak height (0 for flat roofs) ù a series of single byte fields with wall colours and roof pitches colours (just one if the roof is flat). All distances are in meters, and colour codes are repeated in both nibbles. In the following sketches, for each kind of building, code and sub-code of 53h record as well as the build. type in the last word of the jump record are given; numbers and letters show the order in which wall positions and colour codes respectively appear within the 53h record. Rectangular building (53h 01h) flat roof (type 0003h) peaked roof (type 0005h) 1 2 1 2 ³ a ³ ³ a ³ ÚÄÄÄÄÄÄÄÄÄÄÄ¿Ä 3 ÚÄÄÄÄÄÄÄÄÄÄÄ¿Ä 3 ³ ³ ³ f ³ d ³ e ³ b d ÃÄÄÄÄÄÄÄÄÄÄÄ´ b ³ ³ ³ g ³ ÀÄÄÄÄÄÄÄÄÄÄÄÙÄ 4 ÀÄÄÄÄÄÄÄÄÄÄÄÙÄ 4 c c L building (53h 02h) flat roof (type 0007h) peaked roof (type 0009h) 1 2 3 1 2 3 ³ a ³ ³ ³ a ³ ³ ÚÄÄÄÄÄÄÄ¿ Ä 4 ÚÄÄÄÂÄÄÄ¿ Ä 4 ³ ³b ³ ³ ³ b ³ ³ c ³ ³ h ³ c ³ ÀÄÄÄÄÄÄ¿Ä 5 ³ g ³ /ÀÄÄÄÄÄÄ¿Ä 5 f ³ g ³ f ³ ³/ i ³ ³ ³ d ³ /ÀÄÄÄÄÄÄÄÄÄÄ´ d ³ ³ ³/ l ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙÄ 6 ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙÄ 6 e e Reversed L building (53h 06h) flat roof (type 000Bh) peaked roof (type 000Dh) 1 2 3 1 2 3 ³ ³ c ³ ³ ³ c ³ ÚÄÄÄÄÄÄ¿Ä 4 ÚÄÄÄÂÄÄÄ¿Ä 4 b ³ ³ b ³ ³ ³ a ³ ³ a ³ h ³ ³ ÚÄÄÄÄÄÄÄÙ ³Ä 5 ÚÄÄÄÄÄÄÄÙ\ ³ g ³Ä 5 ³ g ³ d ³ i \³ ³ d f ³ ³ f ÃÄÄÄÄÄÄÄÄÄÄÄÙ\ ³ ³ ³ ³ j \³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙÄ 6 ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙÄ 6 e e T building (53h 03h) flat roof (type 000Fh) peaked roof (type 0011h) 1 2 3 4 1 2 3 4 ³ ³ a ³ ³ ³ ³ a ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿Ä 5 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿Ä 5 ³ ³ ³ i ³ h ³ ³ b h ÃÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄ´ b ³ i ³ ³ j /³\ m ³ ÀÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÙÄ 6 ÀÄÄÄÄÄÄÄ¿/ ³ \ÚÄÄÄÄÄÄÄÙÄ 6 g ³ ³ c g ³ ³ ³ c f ³ ³ d f ³ k ³ l ³ d ³ ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÙ Ä 7 ÀÄÄÄÁÄÄÄÙ Ä 7 e e U building (53h 04h) flat roof (type 0013h) peaked roof (type 0015h) 1 2 3 4 1 2 3 4 ³ a ³ ³ e ³ ³ a ³ ³ e ³ ÚÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄ¿Ä 5 ÚÄÄÄÂÄÄÄ¿ ÚÄÄÄÂÄÄÄ¿Ä 5 ³ ³b d³ ³ ³ ³ ³b d³ ³ ³ ³ ³ c ³ ³ ³ ³ j ³ c ³ m ³ ³ h ³ ÀÄÄÄÄÄÄÄÙ ³Ä 6 h ³ i ³ /ÀÄÄÄÄÄÄÄÙ\ ³ n ³Ä 6 ³ ³ f ³ ³/ k \³ ³ f ³ i ³ ³ /ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ\ ³ ³ ³ ³/ l \³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙÄ 7 ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙÄ 7 g g H building (53h 05h) flat roof (type 0017h) peaked roof (type 0019h) 1 2 3 4 1 2 3 4 ³ a ³ ³ e ³ ³ a ³ ³ e ³ ÚÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄ¿Ä 5 ÚÄÄÄÂÄÄÄ¿ ÚÄÄÄÂÄÄÄ¿Ä 5 ³ ³b d³ ³ ³ ³ ³b d³ ³ ³ ³ ³ c ³ ³ ³ ³ n ³ c ³ r ³ ³ ³ ÀÄÄÄÄÄÄÄÙ ³Ä 6 ³ ³ /ÀÄÄÄÄÄÄÄÙ\ ³ ³Ä 6 ³ ³ ³ ³/ p \³ ³ l ³ m ³ f l ³ m ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ t ³ f ³ ³ ³ ³\ q /³ ³ ³ ÚÄÄÄÄÄÄÄ¿ ³Ä 7 ³ ³ \ÚÄÄÄÄÄÄÄ¿/ ³ ³Ä 7 ³ ³ i ³ ³ ³ ³ o ³ i ³ s ³ ³ ³ ³j h³ ³ ³ ³ ³j h³ ³ ³ ÀÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÙÄ 8 ÀÄÄÄÁÄÄÄÙ ÀÄÄÄÁÄÄÄÙÄ 8 k g k g Example of a peaked L building: 3E 0045 0391 048C 0003 Area record 8E 0008 0B 0039 0009 Jump over next jump record 0B 0039 0009 Jump over 57 bytes, object type is 9 24 04 048C0A00 00000000 03918700 Ref. point record (center of the object) 16 0000 0000 FC6E 000A Orient. record: 0ø pitch, 0ø bank, [FC6E =] -914 / 182.04 = -5.02ø 19 53 02 L building record FFF6 FFFF 000A Ascisses of walls are -10, -1, 10 0007 0001 FFF9 Ordinates of walls are 7, 1, -7 0004 02 base heigh is 4 m, peak height is 2 m 66 88 99 66 88 99 wall colours are L.Blue, Brown, Yellow, L.Blue, Brown, Yellow 55 AA 55 AA roof colours are L.Grey, D.Grey, L.Grey, D.Grey 19 Multi-sided building (53h 4Ch) flat roof (type 001Bh) and peaked roof (type 001D) have the same contents: 0 1 53h: record code 1 1 4Ch: record sub-code 2 1 number of sides 3 2 length in m 5 2 width in m 7 2 height in m 9 2 two alternating colours for sides 11 2 two alternating colours for roof pitches 12 1 peak height in m Control tower (type 001Fh; codes 53h 07h) 0 1 53h: record code 1 1 07h: record sub-code 2 8 four wall positions as for rectangular buildings 10 2 base height 12 2 always 0Ah ?? (irrelevant) 14 4 four side colours as for rectangular buildings 18 1 roof colour 19 1 always 00h ?? (irrelevant) Bridge (type 0025h; codes 53h 34h): 0 1 53h: record code 1 1 34h: record sub-code 2 2 length 4 2 width 6 1 suspension colour (0 for non-suspended bridge) 7 1 bridge colour The following 4 object types lack the orientation record. Tower (type 0020h; codes 53h 29h) and wind sock (type 0022h; codes 53h 2Eh) have the same structure: 0 1 53h: record code 1 2 29h / 2Eh: record sub-code 2 1 always 0 ?? (irrelevant) 3 2 height Coniferous (type 0028h; codes 53h 42h) and deciduous tree (type 002Bh; codes 53h 43h) have the same structure: 0 1 53h: record code 1 1 42h / 43h: record sub-code 2 1 total height 3 1 width 4 1 trunk height 5 1 leave colour 6 1 trunk colour Suspended bridges (type 0027h; codes 53h 33h) and autos (type 002Dh; codes 53h 47h) add a 28h 36h record right before the 53h record. Suspended bridges have the same 53h record as standard bridges (of course, sub-code is 33h instead of 34h). Autos have a 3-byte 53h record containing, after code and sub-code, only a byte with the auto colour. -------------------- Fuel box (type 002Fh). Fuel box descriptions are complex, but the great part is fixed because fuel boxes have a fixed size and are always oriented toward the North. Below a template is given: 3E 0076 xxxx xxxx 0007 Area record (coords may vary, length [118 bytes] and radius [7 FSu=ca 1 NM] are constant) 8E 0008 Jump over next jump (var. struct. construct) 0B 006A 002F Jump over 106 bytes; object type 2Fh 24 02 xxxxxxxx xxxxxxxx xxxxxxxx Ref. point record (coords and alt. may vary) 16 0000 0000 0000 000A Orientation is always flat and North 19 28 36 004C 034E FFFF other 004Ch bytes of description 12 99 yellow line 40 FF80 FF44 the "F", described with normal lines 41 FF80 0098 leg 41 0080 0098 upper arm 40 007A FFF4 jump to 41 FF80 FFF4 lower arm 40 FEFB FEFB the box 41 00F9 FEFB lower side 41 00F9 0101 right side 41 FEFB 0101 upper side 29 close the box 21 0014 2-var record: byte offset is 20 029C FEFB 00FF var 029Ch (E range) from -260 to 255 02A0 FEFB 0101 var 02A0h (N range) from -260 to 257 25 0288 0001 This is a fuel box 19 End of variable structure -------------------- Thermal generator (type 0031h) Thermal generators also have a very special description including some general records. Again, a template is given. 3E 006A xxxx xxxx xxxx Area record (106 bytes long, coords may vary, as well as radius, which depend on size) 8E 0008 Jump over next jump record (var. struct. con.) 0B 005E 0031 Jump over 94 bytes; object type is 0031 24 04 xxxxxxxx xxxxxxxx xxxxxxxx Ref. point record 16 xxxx xxxx xxxx 000A Orientation record 19 25 02E2 xxxx Surface colour record 2F Polygon begin 40 xxxx xxxx generator area as a polygon 41 xxxx xxxx 41 xxxx xxxx 41 xxxx xxxx 29 close area and fill 45 0025 a 45h record, 0025h bytes long, follow: xxxxxxxx E coord of generator center ???????? ??? (4 bytes) xxxxxxxx N coord of generator center xxxx orientation ?? ??? (1 byte) xxxx generator width (in m) ???? ??? (2 bytes) xxxx thermal effect height (in feet) ???? ??? (2 bytes) xxxx generator length ?????????????????? ??? (9 bytes) ======================================== DYNAMIC SCENERIES (.DY1) GENERAL STRUCTURE Dynamic scenery files are made of: ù a header containing various pointers ù a pattern definition section containing the definitions of all the patterns in the file ù a pattern code section containing the actual description of the patterns. ==================== HEADER STRUCTURE; length: 43 bytes 0 2 file length 2 2 0002h (a kind of signature?) 4 2 000Ch (= 12; pointer to scenery name) 6 2 002Bh (= 43; header length) 8 2 number to be assigned to the next pattern that will be defined 10 2 pointer to pattern code section 12 31 scenery names: up to 30 characters (padded with space, if shorter) plus a 0 ending byte ==================== PATTERN DEFINITION SECTION The pattern definition section contains a 48-byte block for each pattern of the scenery. 0 2 pattern number (see note) 2 2 model: 0065h Cessna R182 0066h Boeing 747 0067h Gates Learjet 0068h F14 0069h Schweizer SGS 012Dh Fuel truck 0137h Red car 0138h Blue car 0139h White car 0191h Sail boat Any other model code is rendered by ASD as a Cessna R182. 4 2 pointer to the corresponding pattern code 6 2 length of the corresponding pattern code 8 2 number of the pattern after which this pattern will start, zero if patter starts immediately 10 1 begin code: 0 immediately 1 after other pattern starts 2 after other pattern takes off 3 after other pattern lands 4 after other pattern parks 11 1 status code: 0 - inactive, 1 - active 12 1 end action code: 0 start over 1 park 2 disappear 13 1 display before start: 0 - yes, 1 - no (sic!!) 14 4 ??? (irrelevant) 18 30 pattern name, padded with spaces, no ending zero Note: to each new pattern is assigned the number contained at byte 8 of file header which is then increased; when a pattern is deleted, its record is removed and other patterns are shifted but its number is not made available, nor other pattern numbers are modified to fill a possible gap, as a consequence patterns can have numbers greater than the total number of patterns present in the file. ==================== PATTERN CODE SECTION This section contains all the definitions of the scenery patterns, one after the other. Pattern definitions are made of 5 kinds of records: 00h Initial record 20 bytes FFh Position record 21 bytes 02h Look record 5 bytes 06h Take off/Land record 2 bytes 04h End of pattern record 1 byte -- 00h ------------- Initial record (20 bytes) Used to set the initial position of the object at the beginning of the pattern. 1 4 E coord (fract. FSu; all 4 bytes used) 5 4 alt. AGL (fract. FSu; all 4 bytes used) 9 4 N coord (fract. FSu; all 4 bytes used) 13 2 pitch (noze down is positive, noze up is negative) 15 2 bank (left is positive, right is negative) 17 2 heading 19 1 always 03 ?? Note: Pitch variation is somewhat special: if the object rotates more than 90ø up or down, it is reversed up side down and pitch sign is changed! -- 02h ------------- Look record (5 bytes) Look record defines some visual detail of the object. To my knowledge, a look record may have 3 sub-codes, related to 3 visual aspect; patterns always begin defining the initial values of these aspects with 3 look records, one for each sub-code. 1 2 FFFEh: shadow is visible or not FFFDh: object is flying or landed FFFBh: gear is lowered or not 3 2 value: for FFFEh: 1 = shadow on, 0 = shadow off for FFFDh: 2 = landed, 0 = flying for FFFBh: 4 = gear down, any other value = up Notes: Shadow is switched off by ASD when the object raises above ca. 100 m from ground level. Sub-code FFFDh probably triggers patterns starting after another pattern's landing or taking off. -- 04h ------------- End of pattern (1 byte) End of pattern record Used to mark the end of a pattern. It is made of the single byte 04h. -- 06h ------------- Teake off/land record (2 bytes) A take off (land) record is inserted after the movement that caused the model to rise over (to sink at) the ground level. Each of them is always followed by the corresponding 02h FFFDh record. 1 1 02h: take off (always followed by a 02 FFFD 0000 record) 03h: landing (always followed by a 02 FFFD 0002 record) -- FFh ------------- Position record (21 bytes) Position record is identical to initial record, excepted the record code and the last field. It is used through the entire pattern description to mark successive positions and orientations of the object. 1 4 E coord (fract. FSu) 5 4 alt. AGL (fract. FSu) 9 4 N coord (fract. FSu) 13 2 pitch (noze down is positive, noze up is negative) 15 2 bank (left is positive, right is negative) 17 2 direction 19 2 time between the previous (or initial) position and this one Note: The time interval between positions is apparently measured in ticks, 1 tick every 0.008 sec (or 126 ticks per sec). Time intervals are not constant but shorter when the position (or orientation) variation is greater and longer when it is smaller. It seems never to exceed ca 1500 ticks (12 sec). About other fields, the same observations made for the initial record apply. ==================== Patterns usually begin with: record 02 FFFE to define initial conditions record 02 FFFB " record 02 FFFD " record 00 to define initial point and orientation Then enough FFh records follow to define successive positions and orientations of the object. Change in visual aspects and flying condition are marked by appropriate records. The pattern is closed by the record 04 ======================================== DEMO FILES (.DEM) Demo files, like dynamic sceneries, have a relatively simple structure and record set. Basically, demo files describe successive positions (and orientations) of the aircraft with a flow of position records; these records, however, are intersparsed with single byte codes that correspond to the keys pressed by the user during demo recording. Contrarily to dynamic sceneries, aircraft position is sampled at a fixed rate (either 1 or 5 sec) and all the codes for keys pressed between two samples are grouped and inserted between the two corresponding position records. KEY CODES Key codes correspond, in almost all cases, to the hardware press scan codes generated by the keyboard and are, therefore, less than 80h. Some kind of tanslation is, however, carried out by the demo recorder: ù on all keyboards, some key codes are ignored and some other are converted to 00h ù on 101-key keyboards, function keys are converted to their functional equivalent of the 83-key keyboard and the corresponding scan code is used ù some keys of the numeric pad have the same function in the 101-key keyboard (like Gray /, Gray * and ScrollLock, or Gray + and Gray Enter) and their scan code are merged ù scan code prefixes used by 101-key keyboards to differentiate among duplicated keys (left and right Alt and Ctrl, white and gray cursor keys...) are thrown away. ù release scan code are ignored. Excepted for a few special keys (like Shift, Ctrl and Alt), all key presses are recorded, even if they do nothing. Key presses are executed as soon as they are met during demo play back: they affect the instrument panel, the display and outer world simulation in the same way as during normal flight; apparently, however they do not affect flight simulation which is based on the position records. Subsequent position records are interpolated to simulate a continuous flight. The following table lists all the key codes generated by the demo recorder with their corresponding key; function key codes have two corresponding keys, the first is for 83-key keyboards, the second for 101-key keyboards. All codes are in hex. Alphanumeric keys 01 Esc 0F Tab [1D ù] [2A ù] [38 ù] 02 '1' 10 'Q' 1E 'A' [2B ù] 39 Space 03 '2' 11 'W' 1F 'S' 2C 'Z' 3A CapsLk 04 '3' 12 'E' 20 'D' 2D 'X' 05 '4' 13 'R' 21 'F' 2E 'C' 06 '5' 14 'T' 22 'G' 2F 'V' 07 '6' 15 'Y' 23 'H' 30 'B' 08 '7' 16 'U' 24 'J' 31 'N' 09 '8' 17 'I' 25 'K' 32 'M' 0A '9' 18 'O' 26 'L' 33 ',' 0B '0' 19 'P' 27 ';' 34 '.' 0C '-' 1A '[' 28 ''' 35 '/' 0D '+' 1B ']' 29 '`' [36 ù] 0E BkSp 1C Enter 37 '*'-PrtSc Function keys Numeric pad keys 3B F1/F5 3C F2/F4 45 NumLk 46 Gr /|*|ScrollLk 3D F3/F6 3E F4/F3 47 Home 48 Up 49 PgUp 4A Gr - 3F F5/ùù 40 F6/ùù 4B Left 4C Pad 5 4D Right 4E Gr +|<ÄÙ 41 F7/F7 42 F8/F2 4F End 50 Down 51 PgDn 43 F9/F8 44 F10/F1 52 Ins 53 Del 56 '<'ùùù Notes: ù Scan codes 1D, 2A, 2B, 36, 38 would correspond to Ctrl, Left Shift, '\', Right Shift, Alt respectively; but within demos, Shift and '\' keys do not generate any code, while Ctrl and Alt keys generate a 00 code. ùù No F key of 101-key keyboard correspond to F5 and F6 of 83-key keyboard: therefore those codes are never recorded with a 101-key keyboard ùùù Code 56 is generated (and recorded) only with 102-key European keyboards. RECORDS All records have a code >= 80h and are therefore easily differentiated from key codes. Only 8 kinds of records have been recognized and are listed below. The first four of them are actually found in demo files generated by the demo recorder; the other four have been found in the demo supplied with the program (the default demo as well as the instructor flights of the flight school and the lead plane flights of the formation entertainement which are all regular demo files), but are correctly played back if manually inserted in a recorded demo. A recorded demo has a very simple structure: it is made of sample rate records (either 80h or 81h) followed by long position records; between a position record and the next sample rate record, the codes for key pressed by the user are inserted. The file is not divided in sections (like, for instance, scenery files) nor its end is marked in any way. -- 80h ------------- 1 sec (1 byte) This single byte record marks a sample rate of 1 sec and is usually followed by a long position record. -- 81h ------------- 5 sec (1 byte) This single byte record marks a sample rate of 5 sec and is usually followed by a long position record. -- 82h ------------- Long position record (19 bytes) 1 4 E coord. (fract. FSu) 5 4 Alt. AGL (fract. FSu) 9 4 N coord. (fract. FSu) 13 2 pitch (noze down is positive, noze up is negative) 15 2 bank (left is positive, right is negative) 17 2 heading This record is usually preceded by a 1 sec or a 5 sec record. --84h -------------- Message (mess.length+2 bytes) 1 xx Message text 1+xx 1 00h ==================== Supplied demos contain four more kinds of record, allowing for adding a major feature (mode record) and for saving some bytes. They usually begin with a mode record which sets the initial conditions; a 1 sec position record follows giving the aircraft initial position, then a flow of short position records describes subsequent aircraft positions. As usual, key codes are inserted among position records to interact with the simulator. -- 8Ah ------------- Mode record (528 bytes) 1 526 Mode 527 1 8Bh: end of mode This record embeds a full mode, with exactly the same structure of a .MOD mode file; this allows specifying all the display, environment and flight conditions within a demo. Mode records are usually inserted at the beginnig of a demo to prepare the field; other mode records can however appear anywhere in a .DEM to change simulation parameters. -- 90h ------------- 1 sec/position (19 bytes) 1 4 E coord. (fract. FSu) 5 4 Alt. AGL (fract. FSu) 9 4 N coord. (fract. FSu) 13 2 pitch (noze down is positive, noze up is negative) 15 2 bank (left is positive, right is negative) 17 2 heading This record has the same structure of the 82h record, but contains also a 1 sec sample rate information. -- 91h ------------- 5 sec/position (19 bytes) 1 4 E coord. (fract. FSu) 5 4 Alt. AGL (fract. FSu) 9 4 N coord. (fract. FSu) 13 2 pitch (noze down is positive, noze up is negative) 15 2 bank (left is positive, right is negative) 17 2 heading This record has the same structure of the 82h record, but contains also a 5 sec sample rate information. -- 94h ------------- Short position record (7 bytes) This record describes the variations of the 6 position parameters relatives to a previous position record (either a 90h record or another 94h record). It can be used also after an 82h record, even if MS demos never do so. The record includes also 1 sec of sample rate. 1 1 E coord. delta 2 1 Alt. delta 3 1 N coord. delta 4 1 Pitch delta 5 1 Bank delta 6 1 Heading delta Linear parameters are in m, angular parameters in 1.4ø (= 360ø / 256); all 6 parameters are signed: the max linear delta is therefore 127 m, and the max angular delta is 180ø. Short position records save 12 bytes each over long position records. Apparently, there is no short position record for 5 sec interval. ======================================== MODE FILES (.MOD) Mode files still have many obcure points, but almost all the parameters the can be set from FS menu are decoded. Exceptions are mouse sensitivity parameters, because I do not use a mouse with FS (it seems to me like driving a car with the foots), and joystick parameters because I do not have one (I am a serious person, I don't play games!). There is a lot of undecoded 1-byte fields; they are probably unused and maybe are only the MSBytes of word fields which never exceed an 8-bit value. Screen coordinates (for window positions) are apparently device-independent (I tried on a VGA and a Hercules): ascissae span from 0032h to 1FD6h and ordinates from 0032h to 17D4h; origin is in the upper left corner. The following listing follows the same format used above, but, given the length of the mode "record", a column with hex offset has been added. Key labels (as ) refer to the 101-key keyboard. 0 0000 2 020Eh: file length 2 0002 2 0017h: pointer to mode name 4 0004 1 01h: mode file signature 5 0005 4 Initial E coord. (fract. FSu) 9 0009 4 Initial AGL alt. (fract. FSu) 13 000D 4 Initial N coord. (fract. FSu) 17 0011 2 Initial pitch 19 0013 2 Initial bank 21 0015 2 Initial heading 23 0017 31 Mode name (padded with spaces and 0-terminated) FIRST 3D WINDOW 54 0036 2 Left border position 56 0038 2 Top border position 58 003A 2 Width 60 003C 2 Height 62 003E 1 View: 00h Cockpit 01h Tower 02h Track 03h Spot plane 63 003F 1 Cockpit view direction: counterclockwise 00h front -> 07h front left 64 0040 2 Cockpit view zoom: 0010h .16 x 0020h .33 x 0040h 1 x 0081h 2 x 0103h 4 x 0207h 8 x 040Fh 16 x 081Fh 32 x 103Fh 64 x 207Fh 129 x 40FFh 256 x 7FFFh 511 x 66 0042 2 Tower view zoom (as above) 68 0044 2 Track view zoom (as above) 70 0046 2 Spot plane view zoom (as above) 72 0048 1 73 0049 1 Spot view direction: counterclockwise 00h front -> E0h front left (01h = 1.4ø) 74 004A 2 Spot plane distance (in 1/256 m) 76 004C 2 78 004E 1 Spot plane preference: 00h roll - 01h loop 79 004F 1 Spot plane transition: 00h slow - 01h fast 80 0050 2 Spot plane altitude (in 1/256 m) 82 0052 28 ?? (these bytes change when the cockpit view direction changes, but without any clear pattern) SECOND 3D WINDOW 110 006E 2 Left border position 112 0070 2 Top border position 114 0072 2 Width 116 0074 2 Height 118 0076 1 View: 00h Cockpit 01h Tower 02h Track 03h Spot plane 119 0077 1 Cockpit view direction: counterclockwise 00h front -> 07h front left 120 0078 2 Cockpit view zoom (see byte 64) 122 007A 2 Tower view zoom (as above) 124 007C 2 Track view zoom (as above) 126 007E 2 Spot plane view zoon (as above) 128 0080 1 129 0081 1 Spot view direction: counterclockwise 00h front -> E0h front left (01h = 1.4ø) 130 0082 2 Spot plane distance (in 1/256 m) 132 0084 2 134 0086 1 Spot plane preference: 00h roll - 01h loop 135 0087 1 Spot plane transition: 00h slow - 01h fast 136 0088 2 Spot plane altitude (in 1/256 m) 138 008A 28 ?? (these bytes change when the cockpit view direction changes, but without any clear pattern) 166 00A6 2 Map window left border position 168 00A8 2 Map window top border position 170 00AA 2 Map window width 172 00AC 2 Map window height 174 00AE 1 Current window: 00h first 3D 01h second 3D 02h map 175 00AF 1 First 3D: 00h off - 01h on 176 00B0 1 Second 3D: 00h off - 01h on 177 00B1 1 Map: 00h off - 01h on 178 00B2 1 Position indic.: 00h off - 01h on 179 00B3 1 Instr. panel: 00h off - 01h on 180 00B4 1 Full external view: 00h off - 01h on 181 00B5 1 182 00B6 1 Titles on windows: 00h off - 01h on 183 00B7 1 184 00B8 1 Shader: 00h off - 01h on 185 00B9 1 186 00BA 1 Stars: 00h off - 01h on 187 00BB 1 188 00BC 1 Ground text.: 00h off, 01h dots, 02h small rect, 03h big rect 189 00BD 1 Crash: 00h off, 01h detect, 02h detect and analyse 190 00BE 1 Sound: 00h off - 01h on 191 00BF 1 Pause: 00h off - 01h on 192 00C0 1 Realism, bits (realism scale is at offset 299): 0 engine 1 elevator trim 2 gyro drift 3 light burn 4 fast throttle 5 instrument lights 6 barometer drift 7 [unused] 193 00C1 1 Axis indicator: 00h none 01h V-shaped 02h 4-dots 03h small V 194 00C2 1 Auto coordination: 00h off - 01h on 195 00C3 1 196 00C4 1 Smoke system: 00h off - 01h on 197 00C5 1 198 00C6 1 ATC comm: 00h off - 01h 0n 199 00C7 1 200 00C8 1 Slew: 00h off - 01h on 201 00C9 3 ?? 204 00CB 2 Rotat. slew: negative = right, positive = left (+- 80h each or ) 206 00CE 1 207 00CF 1 Altit. slew: 00h max up -> 40h stable -> 7Fh max down (+- 02h each or , -> 7Fh, -> 00h) 208 00D0 1 209 00D1 1 Longit. slew: negative = forward, positive = rear (+-01h each or ) 210 00D2 1 211 00D3 1 Side slew: negative = left, positive = right (+-01h each or ) 212 00D4 2 ?? 214 00D6 1 EFIS/CFPD: 00h off - 01h on (equal to byte 394) 215 00D7 3 ?? 218 00DA 3 Hours, min and sec as hex numbers 221 00DD 12 ?? Instrument panel display (instr. displayed when bit set): 233 00E9 1 bits: 0 airspeed 1 turn coordination 2 gyro heading 3 altimeter 4 attitude 5 VOR 1 6 tacheometer 7 vertical velocity 234 00EA 1 bits: 0 time 1 transponder 2 NAV 1 3 COM 4 compass 5 fuel 6 oil 7 AUX 2 235 00EB 1 bits: 0 gear and carb heat 1 NAV 2 2 DME 3 VOR 2 4 ADF 5 AUX 1 6 AUX 4 7 AUX 3 236 00EC 5 ?? WINDS 241 00F1 1 Layer 3 speed (in kt) 242 00F2 1 Layer 3 turbulence: 00h -> 0Ah 243 00F3 2 Layer 3 direction (in 1/182.04ø) 245 00F5 1 Layer 2 speed (in kt) 246 00F6 1 Layer 2 turbulence: 00h -> 0Ah 247 00F7 2 Layer 2 direction (in 1/182.04ø) 249 00F9 1 Layer 1 speed (in kt) 250 00FA 1 Layer 1 turbulence: 00h -> 0Ah 251 00FB 2 Layer 1 direction (in 1/182.04ø) 253 00FD 1 Surface speed (in kt) 254 00FE 1 Surface turbulence: 00h -> 0Ah 255 00FF 2 Surface direction (in 1/182.04ø) 257 0101 2 Layer 3 tops (in m) 259 0103 2 Layer 3 base (in m) 261 0105 2 Layer 2 tops (in m) 263 0107 2 Layer 2 base (in m) 265 0109 2 Layer 1 tops (in m) 267 010B 2 Layer 1 base (in m) 269 010D 2 Surface depth (in m) CLOUDS 271 010F 2 Top layer tops (in m) 273 0111 2 Top layer base (in m) 275 0113 2 Top layer coverage: 00h clear -> 08h overcast 277 0115 2 Top layer deviation (in m) 279 0117 2 Bottom layer tops (in m) 281 0119 2 Bottom layer base (in m) 283 011B 2 Bottom layer coverage: 00h clear -> 08h overcast 285 001D 2 Bottom layer deviation (in m) 287 011F 2 Thunderstrom tops (in m) 289 0121 2 Thunderstorm base (in m) 291 0123 2 Thunderstorm coverage: 00h widely scatt. -> 02h dense 293 0125 2 Thunderstorm speed (in 1/2 kt) 295 0127 2 Thunderstorm direction (in 1/182.04ø) 297 0129 1 Reliability: 00h -> 64h 298 012A 1 299 012B 1 Realism: 00h -> 64h 300 012C 1 301 012D 26 ?? this portion contains mouse and joystick parameters 327 0147 1 Keyboard aileron sensibility: 01h = 1 -> 7Fh = 8 328 0148 1 329 0149 1 Keyboard elevator sensibility: 01h = 1 -> 7Fh = 8 330 014A 1 331 014B 1 Keyboard rudder sensibility: 01h = 1 -> 7Fh = 8 332 014C 3 ?? 335 014F 2 Panel instrument top border 337 0151 2 ?? 339 0153 1 Season: 00h winter -> 03h autumn 341 0155 6 COM freq as ASCII string of the form "120;30" 347 015B 1 always 0 ?? 348 015C 1 NAV1 active: 00h off - 01h on 349 015D 6 NAV1 freq as ASCII string of the form "120;30" 355 0163 1 always 0 ?? 356 0164 1 NAV2 active: 00h off - 01h on 357 0165 6 NAV2 freq as ASCII string of the form "120;30" 363 016B 3 OBI1 inbound course as ASCII string of the form "120" 366 016E 1 always 0 ?? 367 016F 1 VOR1 active: 00h off - 01h on 368 0170 3 OBI1 outbound course as ASCII string of the form "120" 371 0173 1 always 0 ?? 372 0174 1 VOR2 active: 00h off - 01h on 373 0175 3 OBI2 inbound course as ASCII string of the form "120" 376 0178 1 always 0 ?? 377 0179 1 VOR2 active: 00h off - 01h on 378 017A 3 OBI2 outbound course as ASCII string of the form "120" 381 017D 1 always 0 ?? 382 017E 1 Transponder active: 00h off - 01h on 383 017F 4 Transponder freq as ASCII string of the form "1200" 387 0183 1 always 0 ?? 388 0184 1 ADF active: 00h off - 01h on 389 0185 3 ADF freq as ASCII string of the form "120" 392 0188 1 EFID/CFPD function: 00h none 01h lock to ILS for landing approach 02h lock to navaid and alt. tracking 393 0189 394 018A 1 EFIS/CFPD: 00h off - 01h on (equal to byte 214) 395 018B 1 396 018E 1 EFIS/CFPD type: 00h rect, 01h bricks, 02h poles 397 018F 1 398 0190 1 EFIS/CFPD density: 00h thick, 01h medium, 02h thin 399 0191 1 400 0192 1 EFIS/CFPD range: 00h short, 01h medium, 02h long 401 0193 1 402 0194 1 EFIS/CFPD navaid: 00h NAV1, 01h NAV2 403 0195 1 404 0196 2 EFIS/CFPD tracking altitude (in m) 406 0198 66 ???? (this portion apparently contains, among other things, the dynamic parameters (velocity vector, angular velocities...), but no clear relation has emerged) 472 01D8 1 Elevator 'carry': 01h when full pushed, FFh when full pulled, 00h otherwise 473 01D8 1 Elevator: C0h full pushed -> 3F full pulled; +-01h each or 474 01D9 1 Aileron 'carry': 01h when at full left, FFh when at full right, 00h otherwise 475 01DA 1 Ailerons: C0h full left -> 3Fh full right; +- 04h each or 476 01DB 1 Rudder 'carry': 01h when at full left, FFh when at full right, 00h otherwise 477 01DC 1 Rudder: C0h full left -> 3Fh full right; +- 04h each or 478 01DE 1 Throttle 'carry': FFh when full, 00h otherwise 479 01DF 1 Throttle: 00h cut -> 3Fh full; +-02h each or 480 01E0 1 Trim 'carry': 01h when full down, FFh when full up, 00h otherwise 481 01E1 1 Trim: C0h full down -> 3F full up; +-01h each or 482 01E2 10 ?? 492 01EC 2 Position indic. window left border 494 01EE 2 Position indic. window top border 496 01F0 4 Tower E coord (fract FSu) 500 01F4 4 Tower AGL alt (fract FSu) 504 01F8 4 Tower N coord (fract FSu) 508 01FC 2 ?? 510 01FE 1 Flap 'carry': FFh when flap down, 00h otherwise 511 01FF 1 Flap: 00h 0ø 20h 10ø 40h 20ø 60h 30ø 7Fh 40ø 512 0200 1 Gear: 00h up - FFh down 513 0201 1 Lights: 00h off - FFh on 514 0202 1 Mags: 00h off 01h left 02h right 03h both 04h start 05h lean 515 0203 1 516 0204 1 Carb heat: 00h off - FFh on 517 0205 1 Strobe: 00h off - 01h on 518 0206 8 .SIM file name. .SIM files define the visual appearance of the aircraft; the name is padded with space if shorter than 8 chars. No path nor extension are allowed (a standard .SIM extension is apparently supplied by the program) FS4 .SIMs: SIM1.SIM Cessna R182 SIM2.SIM Gates Learjet 25G SIM3.SIM Schweizer 2-32 Sailplane SIM4.SIM Sopwith Camel SIM5.SIM Experimental aircraft ASD .SIMs: SIM7.SIM Experimental jet aircraft SIM8.SIM Experimental sailplane SIM9.SIM Boeing 747-400 SIMA.SIM Beechcraft Starship SIMB.SIM Piper Cherokee Archer II SIMC.SIM Cessna 182 seaplane ======================================== APPENDIX: A NOTE ON F1 (DEFAULT SCENERY) HEADER The following note is a first step in attempting to decode the default scenery F1 supplied with FS. Only the initial file header is covered. It has been checked with sceneries supplied with FS veriosn 4.0 and 4.0b. They are different, but perhaps only marginally and, in any case, not in the portion covered here. 0000h 2 02DDh: ?? 0002h 2 0106h: pointer to dialogue descriptor (see below) 0004h 28 ?? 0020h 2 0026h: number of scenery regions in the file Then, a table is given with, for each scenery region: 4 long pointer to region offset in the file 2 region length in bytes Table ends at 0106h. A descriptor of the dialogue window displayed when the scenery is selected follows: 0106h 1 01h: ?? 0107h 2 01F4h: X screen coordinate of text line 0109h 2 0258h: Y screen coordinate of text line 010Bh 25 text line: "Available Flight Areas:" 0-terminated and with a 0 byte added at both ends This is repeated for the 7 text lines up to 0186h 5 00h 3Ch 00h FFh 28h ?? 018Bh 35 two 21h records and one 79h record After that, the first scenery begins. I sampled them at random and they seems to be made of the same record machinery (maybe with some new record types) of other kinds of scenery, but have no header or section tables as .SC1 files do. F1, as well as *.SCN, do not use a linked list of 3Eh records, but a linked list of many kinds of record (21h occurring very often). ==================== FSSTRUCT END ====================