Call of Duty 4: FastFile Format: Difference between revisions

From COD Modding & Mapping Wiki
Jump to navigation Jump to search
No edit summary
Line 204: Line 204:
--[[User:CoDEmanX|CoDEmanX]] 01:28, 4 November 2009 (UTC)
--[[User:CoDEmanX|CoDEmanX]] 01:28, 4 November 2009 (UTC)


--[[User:Daevius|Daevius]] 23:59, 1 November 2009 (UTC)
--[[User:Daevius|Daevius]] 14:32, 4 November 2009 (UTC)


[[Category:Call of Duty 4]]
[[Category:Call of Duty 4]]
[[Category:Technical Reference]]
[[Category:Technical Reference]]
[[Category:File formats]]
[[Category:File formats]]

Revision as of 17:32, 4 November 2009

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


Header

  • Byte 0-3: decompressed fastfile size minus 44 (0x2C)
  • Byte 4-7: about the total size of referenced data, e.g. the required memory for IWI textures if material files are in the ff
  • Byte 8-11: unknown, might be a flag
  • Byte 12-43: unknown
  • Byte 44-47: equal to number of entries in "1st index" and amount of (model tag/joint/notetrack) strings (times 4 for index length)
  • Byte 48-51: separator? (FF FF FF FF)
  • Byte 52-55: number of records* ("2nd index", times 8 for index length)
  • Byte 56-63: separator? (FF FF FF FF FF FF FF FF)
  • Byte 64-x: string list (xmodelsurfs?) --> not always, depends on the content (required offsets are in the FF header)*

* under re-investigation


Example: mp_backlot_load.ff

Contains:

  • 2x shaders
  • 3x materials
  • (1x fastfile name)


Materials:

  1. $victorybackdrop - mile_high_victory_screen.iwi (699,092 bytes)
  2. $defeatbackdrop - (none)
  3. $levelbriefing - loadscreen_mp_backlot.iwi (524,316 bytes)
-----------  [start of file and header]

71 03 00 00  decompressed filesize - 44 (hex: 371 + 2C = 39D; dec: 881 + 44 = 925)

B8 AA 12 00  size of both IWIs the materials in FF point to - 56 (2x28, 28 bytes = IWI header)
             0x12AAB8          = 1,223,352
             699,092 + 524,316 = 1,223,408
             difference:                56

A4 00 00 00  might be a flag

00 00 00 00  unknown
00 00 00 00  unknown
00 00 00 00  unknown
E5 00 00 00  unknown
00 00 00 00  unknown
00 00 00 00  unknown
00 00 00 00  unknown
00 00 00 00  unknown

-----------  [end of header] (44 bytes), [start of index]

00 00 00 00  unknown, is sometimes FF FF FF FF

06 00 00 00  number of records in index (6)
FF FF FF FF  separator

05 00 00 00  FF FF FF FF  1st: shader
05 00 00 00  FF FF FF FF  2nd: shader
04 00 00 00  FF FF FF FF  3rd: material
04 00 00 00  FF FF FF FF  4th: material
04 00 00 00  FF FF FF FF  5th: material
1F 00 00 00  FF FF FF FF  6th: ff name
FF FF FF FF  separator

-----------  [end of index]

Index

4 byte identifier (fastfile entry type), 4 byte offset (FF FF FF FF = -1, meaning right after the previous block?)

Separator (FF FF FF FF) after last 4-byte couple + 00 00 00 00 ?

Types

  • 00 00 00 01 - physpreset
  • 00 00 00 02 - xanim
  • 00 00 00 03 - xmodel
  • 00 00 00 04 - material
  • 00 00 00 05 - shader / techset
  • 00 00 00 06 - image?
  • 00 00 00 0B - map_ents (d3dbsp)
  • 00 00 00 0C - related to col_map_mp (d3dbsp)
  • 00 00 00 0E - related to game_map_mp (d3dbsp)
  • 00 00 00 10 - related to col_map_mp / gfx_map (d3dbsp)
  • 00 00 00 13 - font
  • 00 00 00 14 - menu
  • 00 00 00 16 - localized string asset
  • 00 00 00 17 - physpreset??
  • 00 00 00 19 - fx
  • 00 00 00 1F - string / raw file / fastfile name
  • 00 00 00 20 - stringtable (comma separated list)


Content

00 00 00 04

FF FF FF FF  [start separation]

00 2B 01 01  First 4 bytes seem to be 4 (unsigned) char's.
             First byte is so far always 0x00 (perhaps it's a short together with the second byte).
             Second byte so far either 0x2B or 0x00, I think this is a length.
             Third byte so far 0x01, when 0x00 (all 4) the content is only a number of 0x00's, then the filename (0x00 termination)
             Fourth byte either 0x00 or 0x01. Can be a length or a bool.
             Then 0x10 bytes of more header.
FF FF FF FF  Separator
00           When fourth byte is 01, there's a 0x00 following?             
             Then there's garbage (0xFF) and some shorts it looks of length in the second byte.
             Then more information...

FF FF FF FF  [end separation]

00 00 00 05

FF FF FF FF  [start separation]

00 00 00 00  0x90 times 0x00
             Then filename (0x00 termination)             

FF FF FF FF [end separation]

00 00 00 1F

Often at the end of the FF file.

FF FF FF FF  [start separation]

00 00 00 00
FF FF FF FF
             Then filename (0x00 termination)   
00           Another termination, of the FF file? Or padding?

             [end of file]

--CoDEmanX 01:28, 4 November 2009 (UTC)

--Daevius 14:32, 4 November 2009 (UTC)