Call of Duty 5: FastFile Format: Difference between revisions
mNo edit summary |
mNo edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
= Decompression = | |||
Remove the header (12 bytes) | Remove the header (12 bytes) using a hex editor like [http://mh-nexus.de/en/hxd/ HxD] | ||
<pre> | <pre> | ||
Line 11: | Line 11: | ||
IW Infinity Ward | IW Infinity Ward | ||
ff FastFile | ff FastFile | ||
u compression | |||
100 version 1.00? | |||
Compressions: | |||
75 fast (pc default) | |||
30 best | |||
73 possibly console / xenon (not ZLIB) | |||
</pre> | </pre> | ||
Decompress the | Decompress the shortened file using [http://www.paehl.de/english.php SimplyZip] or any other application that supports the ZLIB algorithm. | ||
= Structure = | |||
A fastfile can be divided into 3 sections: | |||
#Header | |||
#Index | |||
#Content | |||
== Header == | |||
'''Size:''' 48 bytes | |||
Byte 0-3: (unsigned int?) correlates to the fastfile's size after decompression minus 36 bytes (24h) | |||
Byte 4-15: ''unknown'' | |||
Byte 16-23: empty? | |||
Byte 24-27: somehow related to the filesize, but smaller value | |||
Byte 28-35: ''unknown'' | |||
Byte 36-39: might indicate where the index record starts, calculation unknown | |||
Byte 40-43: separator <code>ÿÿÿÿ</code> | |||
Byte 44-47: (unsigned int) number of records | |||
At byte 48 starts either the index record with an entry size of 8 bytes each, or there's additional content (sort if entities?). At this moment it's unknown, how the offset of the index record can be found if it doesn't start byte 48, but it starts at byte 30 if the bytes 36-39 are 00 00 00 00. | |||
== Index == | |||
'''Size:''' Number of records [byte 44-47] * 8 bytes | |||
Each entry is a pair of 4 bytes, e.g. <code>FF FF FF FF 17 00 00 00</code> | |||
* <code>FF FF FF FF</code> appears to be a separator | |||
* <code>17 00 00 00</code> indicates the filetype of the actual data, called "identifier" in this article | |||
===Identifier=== | |||
*'''00 00 00 00''': ? | |||
*'''00 00 00 04''': ? | |||
*'''xx xx xx 8x''': At the beginning of the EntData lump there are the | *'''xx xx xx 8x''': At the beginning of the EntData lump there are the | ||
**length of the entity string and the | **length of the entity string and the | ||
**ff identifier (?) is 8x in the last byte (80 = mp, 81 = sp, 82 = coop ?) | **ff identifier (?) is 8x in the last byte (80 = mp, 81 = sp, 82 = coop ?) | ||
*'''17 00 00 00''': rawfile | |||
*'''20 00 00 00''': GSC | *'''20 00 00 00''': GSC | ||
Line 51: | Line 84: | ||
== | ===Zone file types=== | ||
<pre> | |||
ignore,*zone* | |||
include,*zone* | |||
include_pc,* | |||
include_console,splitscreen,, | |||
include_xenon,*,, | |||
include_ps3,* | |||
include_wii,* | |||
col_map_sp,maps/*.d3dbsp | |||
col_map_mp,maps/mp/mp_*.d3dbsp | |||
gfx_map,maps/*.d3dbsp | |||
map_ents,* | |||
game_map_mp,* | |||
game_map_sp,* | |||
rawfile,*.* | |||
sound,*alias*,*map*,all_sp | |||
loaded_sound | |||
weapon,sp/* | |||
localize,*,, | |||
material,* | |||
fx,* | |||
ui_map,maps/*.csv | |||
stringtable,mp/playerstatstable.csv | |||
snddriverglobals,singleton | |||
techset,default | |||
physpreset,default | |||
physconstraints,default | |||
menufile,ui/*.menu | |||
image,* | |||
lightdef,light_* | |||
font,fonts/* | |||
impactfx,mp_maps | |||
packindex,* | |||
xanim,* | |||
xmodel,* | |||
xmodelalias,* | |||
xmodelpieces,* | |||
character,* | |||
mptype,* | |||
aitype,* | |||
</pre> | |||
== Content == | |||
'''Size:''' variable, total size [byte 0-4] - 36 bytes<br> | |||
The length of the content (the actual data) is at least sometimes stored in front of the data block ( <code>INDEX ... SIZE ÿÿÿÿ DATA</code> ) | |||
Most files build into a fastfile differ from the source files (compare [[Call_of_Duty_4:_d3dbsp#BSP_data_in_FastFile|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). | Most files build into a fastfile differ from the source files (compare [[Call_of_Duty_4:_d3dbsp#BSP_data_in_FastFile|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). | ||
--[[User:CoDEmanX|CoDEmanX]] | Last entry: name of the fastfile (not always present!) and compiler errors & warnings for this ff | ||
--[[User:CoDEmanX|CoDEmanX]] 17:27, 16 May 2009 (UTC) | |||
[[Category:Call of Duty 5]] | [[Category:Call of Duty 5]] | ||
[[Category:Technical Reference]] | [[Category:Technical Reference]] | ||
[[Category:File formats]] |
Latest revision as of 16:10, 29 July 2009
*** Article and investigation in early progress ***
Decompression
Remove the header (12 bytes) using a hex editor like HxD
IWffu100ƒ... 49 57 66 66 75 31 30 30 83 01 00 00 IW Infinity Ward ff FastFile u compression 100 version 1.00? Compressions: 75 fast (pc default) 30 best 73 possibly console / xenon (not ZLIB)
Decompress the shortened file using SimplyZip or any other application that supports the ZLIB algorithm.
Structure
A fastfile can be divided into 3 sections:
- Header
- Index
- Content
Header
Size: 48 bytes
Byte 0-3: (unsigned int?) correlates to the fastfile's size after decompression minus 36 bytes (24h)
Byte 4-15: unknown
Byte 16-23: empty?
Byte 24-27: somehow related to the filesize, but smaller value
Byte 28-35: unknown
Byte 36-39: might indicate where the index record starts, calculation unknown
Byte 40-43: separator ÿÿÿÿ
Byte 44-47: (unsigned int) number of records
At byte 48 starts either the index record with an entry size of 8 bytes each, or there's additional content (sort if entities?). At this moment it's unknown, how the offset of the index record can be found if it doesn't start byte 48, but it starts at byte 30 if the bytes 36-39 are 00 00 00 00.
Index
Size: Number of records [byte 44-47] * 8 bytes
Each entry is a pair of 4 bytes, e.g. FF FF FF FF 17 00 00 00
FF FF FF FF
appears to be a separator
17 00 00 00
indicates the filetype of the actual data, called "identifier" in this article
Identifier
- 00 00 00 00: ?
- 00 00 00 04: ?
- 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 ?)
- 17 00 00 00: rawfile
- 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?)
Zone file types
ignore,*zone* include,*zone* include_pc,* include_console,splitscreen,, include_xenon,*,, include_ps3,* include_wii,* col_map_sp,maps/*.d3dbsp col_map_mp,maps/mp/mp_*.d3dbsp gfx_map,maps/*.d3dbsp map_ents,* game_map_mp,* game_map_sp,* rawfile,*.* sound,*alias*,*map*,all_sp loaded_sound weapon,sp/* localize,*,, material,* fx,* ui_map,maps/*.csv stringtable,mp/playerstatstable.csv snddriverglobals,singleton techset,default physpreset,default physconstraints,default menufile,ui/*.menu image,* lightdef,light_* font,fonts/* impactfx,mp_maps packindex,* xanim,* xmodel,* xmodelalias,* xmodelpieces,* character,* mptype,* aitype,*
Content
Size: variable, total size [byte 0-4] - 36 bytes
The length of the content (the actual data) is at least sometimes stored in front of the data block ( INDEX ... SIZE ÿÿÿÿ DATA
)
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).
Last entry: name of the fastfile (not always present!) and compiler errors & warnings for this ff
--CoDEmanX 17:27, 16 May 2009 (UTC)