Home For Developers GFF Introduction 4. Complex Field Data: Descriptions and Physical Format

4. Complex Field Data: Descriptions and Physical Format

[Printer Friendly]

This section describes the byte-by-byte makeup of each of the complex Field types' data, as they are stored in the Field Data Block.

4.1. DWORD64

A DWORD64 is a 64-bit (8-byte) unsigned integer. As with all integer values in GFF, the least significant byte comes first, and the most significant byte is last.

4.2. INT64

An INT64 is a 64-bit (8-byte) signed integer. As with all integer values in GFF, the least significant byte comes first, and the most significant byte is last.

4.3. DOUBLE

A DOUBLE is a double-precision floating point value, and takes up 8 bytes. It is stored in little-endian byte order, with the least significant byte first.

(Both the FLOAT and DOUBLE data types conform to IEEE Standard 754-1985).

4.4. CExoString

A CExoString is a simple character string datatype. The figure below shows the layout of a CExoString:

Figure 4.4: CExoString Format

A CExoString begins with a single DWORD (4-byte unsigned integer) which stores the string's Size. It specifies how many characters are in the string. This character-count does not include a null terminator.

If we let N equal the number stored in Size, then the next N bytes after the Size are the characters that make up the string. There is no null terminator.

Example: The string "Test" would consist of the following byte sequence:

0x04 0x00 0x00 0x00 'T' 'e' 's' 't'

4.5. CResRef

A CResRef is used to store the name of a file used by the game or toolset. These files may be located in the BIF files in the user's data folder, inside an Encapsulated Resource File (ERF, MOD, or HAK), or in the user's override folder. For efficiency and to reduce network bandwidth, A ResRef can only have up to 16 characters and is not null-terminated. ResRefs are also non-case-sensitive and stored in all-lower-case.

The diagram below shows the structure of a CResRef stored in a GFF:

Figure 4.5: CResRef Format

The first byte is a Size, an unsigned value specifying the number of characters to follow. The Size is 16 at most. The character string contains no null terminator.

4.6. CExoLocString

A CExoLocString is a localized string. It can contain 0 or more CExoStrings, each one for a different language and possibly gender. For a list of language IDs, see Table 2.2b.

The figure below shows the layout of a CExoLocString.

Figure 4.6a: CExoLocString Format

A CExoLocString begins with a single DWORD (4-byte unsigned integer) which stores the total number of bytes in the CExoLocString, not including the first 4 size bytes.

The next 4 bytes are a DWORD containing the StringRef of the LocString. The StringRef is an index into the user's dialog.tlk file, which contains a list of almost all the localized text in the game and toolset. If the StringRef is -1 (ie., 0xFFFFFFFF), then the LocString does not reference dialog.tlk at all.

The 4 bytes after the StringRef comprise the StringCount, a DWORD that specifies how many SubStrings the LocString contains. The remainder of the LocString is a list of SubStrings.

A LocString SubString has almost the same format as a CExoString, but includes an additional String ID at the beginning.

Figure 4.6b: CExoLocString SubString Format

The StringID stored in a GFF file does not match up exactly to the LanguageIDs shown in Table 2.2b. Instead, it is 2 times the Language ID, plus the Gender (0 for neutral or masculine, 1 for feminine).

If we let N equal the number stored in StringLength, then the N bytes after the StringLength are the characters that make up the string. There is no null terminator.

4.7. Void/binary

Void data is an arbitrary sequence of bytes to be interpreted by the application in a programmer-defined fashion. The format is shown below:

Figure 4.7: Void Format

Size is a DWORD containing the number of bytes of data. The data itself is contained in the N bytes that follow, where N is equal to the Size value.

4.8. Struct

Unlike most of the complex Field data types, a Struct Field's data is located not in the Field Data Block, but in the Struct Array.

Normally, a Field's DataOrDataOffset value would be a byte offset into the Field Data Block, but for a Struct, it is an index into the Struct Array.

For information on the layout of a Struct, see Section 3.3, with particular attention to Table 3.3.

4.9. List

Unlike most of the complex Field data types, a List Field's data is located not in the Field Data Block, but in the Field Indices Array.

The starting address of a List is specified in its Field's DataOrDataOffset value as a byte offset into the Field Indices Array, at which is located a List element. Section 3.8 describes the structure a List element.

Go to Page (Previous Page - Index, 2, 3, 4)