The Model File (.mdl)
The FSDS Model File (.mdl)

If you're going to be poking around inside a model file with a hex editor, it sure helps to know something about the structure of the file you're playing with.

Aircraft model (MDL) files contain the all the vertex points, texture and animation information needed for Microsoft Flight Simulator to render a flyable 3D aircraft.

In previous versions of Flight Simulator, the model file (.mdl) was actually a Flight Simulator module (i.e., a Windows DLL).

Flight Simulator 2002 and Combat Flight Simulator 2 use model files built using RIFF.

The RIFF File

RIFF is a file format used for storing a wide variety of data, primarily multimedia data like audio and video. It's also used for flight simulator models.

RIFF files are built from information units called chunks.

The RIFF structure groups file content into seperate chunks, each with its own header and data bytes. The entire RIFF file is actually a big chunk that contains all the other chunks.

The first chunk in a RIFF file must be a "RIFF" chunk, also known as a parent chunk. The RIFF chunk is the container for the whole file and its form-type field identifies the file data format.

All other chunks in the file are subchunks of the "RIFF" chunk.

The RIFF header has the following form:

'RIFF'    fileSize    fileType    (data)

0000 'RIFF' CHAR[4] ASCII Code for 'RIFF'
0004 fileSize [UINT32] Length of the entire file (offset to end of file). This 4-byte value includes the CHAR[4] of fileType plus the size of the data that follows, but does not include the CHAR[4] code for 'RIFF' or the 4 bytes of fileSize.
0008 fileType CHAR[4] Code that identifies the specific file type. For model files generated by FSDS, the fileType is 'MDL8'.
000C (data) ---- Data bytes. Start of 1st chunk.

RIFF files are written in little-endian byte order, in other words, the least significant bits are written first.

For example, the decimal value 255 appears as 0xFF00 ... not 0x00FF.

RIFF file chunks are word aligned, which means their total size must be a multiple of 2 bytes (ie. 2, 4, 6, 8, and so on). If a chunk contains an odd number of data bytes, causing it not to be word aligned, an extra padding byte with a value of zero must follow the last data byte.

This organization method allows programs that do not use or recognize particular types of chunks to easily skip over them and continue processing following known chunks.

Each chunk within a RIFF file has the following form:

ckID    ckSize    ckData

0000 ckID CHAR[4] Code that identifies the data contained in the chunk. ckID is 'MDLH' for model files generated by FSDS. The chunk type is specified by four ASCII characters with no terminating null. Three character tags are padded with a trailing blank space.
0004 ckSize [UINT32] The size of the valid data in the chunk. This 4-byte value does not include the padding, the size of ckID, or the size of ckSize.
0008 ckData [UINT16] The size of the data contained in ckData, and ckData is zero or more bytes of data. The data is always padded to nearest WORD boundary.

Open any FSDS-generated model file with a hex editor. You can find the start of the file by searching for the text string "RIFF." In every FSDS model I've built, the "RIFF" chunk always begins at hex address 0x00005000. The information prior to this address is, I think, related to the file information that appears if you right-click on a model file and select Quick View.

The FSDS aircraft model file (.mdl) is a RIFF file with the following structure ...

   MDLH    Visual Model Header chunk
   DICT     Parameter Dictionary chunk
   BGL       BGL Opcodes chunk

The MDLH Section: Visual Model Header

The Visual Model Header of a MDL file is always the first section in the file. All other sections can be in any order. Any section not recognized by Flight Simulator will be ignored.

The data included in the MDLH Section is derived from settings in FSDS and from the model file itself.

The DICT Section: Parameter Dictionary

The DICT Section contains a list of fixed size records that comprise the model's Parameter Dictionary. The data includes both standard and non-standard variables and the hexidecimal offset to their location in CFS2.

CFS2 automatically and continuously updates the data in the Parameter Dictionary before rendering your model. With a display rate of 35 frames per second, these CFS2 variables are being updated 35 times per second!

Using SCASM code, you can test/check these parameters to determine the current state of the aircraft, test for event occurences, part positions, part visibility, gunfire, bullet impacts, etc.

The Parameter Dictionary is automatically generated by FSDS based on the content of the ASCII text file mdl_ParamDict_cfs2.txt, which is located in your Abacus Design Studio folder.

This file contains all the possible parameters that can be included in FSDS.

Each parameter appears in the DICT Section as follows:

uType    uOffset    uLen    guidParam

uType [UINT32]  Parameter type for this record.
   1 = FLOAT32
   2 = UINT32
   3 = STRING
   4 = UINT16
   5 = GUID
   6 = FLAGS16
uOffset [UINT32] Hexidecimal offset to this parameter (must be greater than 152).
uLen [UINT32] Length of this parameter in bytes.
guidParam [GUID] GUID (Globally Unique IDentifier) that identifies this parameter.

The Standard Parameter Block

The first 149 bytes of the DICT Section ( 0x0000 through 0x0097 ) are reserved. This is the Standard Parameter Block.

The Standard Parameter Block variables being used by FSDS can be seen in the ASCII text file, VarTable.txt, which is located in your Abacus Design Studio folder.

Non-Standard Parameter Dictionary GUIDs

Bytes 152 and up (0x0098 ... ) are used for the non-standard parameters included in your aircraft model.

The Non-Standard Parameter Block variables being used by FSDS can be seen in the ASCII text file, VarTableBase.txt, which is located in your Abacus Design Studio folder. Here is where you can read the actual offsets to each variable used by FSDS in your model file.

The actual offsets in the non-standard parameter block depend on how many of these variables you choose to use.


The last section in your model file contains the BGL opcodes and data used to draw, texture and animate the model in 3D space.

When FSDS generates the object source code (.sca file) for a model, it creates what amounts to a static scenery object. The resulting code is really no different than if it were a building or tree, or any other non-flying object.

Because this code exists as a data chunk in the RIFF file that defines your aircraft model however, CFS2 treats it as code for a flyable aircraft.