Call of Duty 5: FastFile Format: Difference between revisions

From COD Modding & Mapping Wiki
Jump to navigation Jump to search
(New page: Image:Under Construction Small.png‎ '''*** Article and investigation in early progress ***''' == Decompression == Remove the header (12 bytes) <pre> IWffu100ƒ... 49 57 66 66 75 3...)
 
mNo edit summary
Line 26: Line 26:
The bytes from 44 to 47 correspond to the files in the fastfile minus 1 (unsigned int?)
The bytes from 44 to 47 correspond to the files in the fastfile minus 1 (unsigned int?)


At byte 48 starts a block of 336 <code>ÿ</code> (hex: 0x255)
Last entry: name of the fastfile --> the missing file?


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


Files are (often) separated by the following byte sequence:
 
Files are (often) separated by the following byte sequence: [needs fix]
<pre style="overflow:auto;">
<pre style="overflow:auto;">
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ........ÿÿÿÿ....
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ........ÿÿÿÿ....
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
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
</pre>
</pre>
== 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?)





Revision as of 04:52, 10 April 2009

*** 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)