Call of Duty 5: FastFile Format

*** Article and investigation in early progress ***

Decompression

Remove the header (12 bytes)

IWffu100ƒ...
49 57 66 66 75 31 30 30 83 01 00 00

IW   Infinity Ward
ff   FastFile
u100 version 1.00?

Decompress the rest using ZLIB algorithm (e.g. SimplyZip)

Structure

The first 4 bytes (unsigned int?) of the decompressed fastfile are assumed as file size, counted from the 37th byte to the very end.

Byte 8: h (hex: 0x68)

Byte 40-43: ÿÿÿÿ

The bytes from 44 to 47 correspond to the files in the fastfile minus 1 (unsigned int?)

Last entry: name of the fastfile --> the missing file?

At byte 48 starts a block of 336 ÿ (hex: 0x255), but not always

Files are (often) separated by the following byte sequence: [needs fix]

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ........ÿÿÿÿ....
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00

Identifier

• xx xx xx 8x: At the beginning of the EntData lump there are the
  • length of the entity string and the
  • ff identifier (?) is 8x in the last byte (80 = mp, 81 = sp, 82 = coop ?)

• 20 00 00 00: GSC

• 21 00 00 00: CSV

• 01 00 00 00, 02 00 00 00, 07 00 00 00, 11 00 00 00, 0C 00 00 00, 0D 00 00 00, 0F 00 00 00: D3DBSP (db layout per lump?)

Files in FastFile

Most files build into a fastfile differ from the source files (compare BSP data in FastFile). The linker re-interprets the data of the files and saves it more compact. One could think of an optimization process, but there are indications for a database-like data handling. Important advantage are the fast accessibility and the possibility of using data references (relations).

--CoDEmanX 23:32, 5 April 2009 (UTC)