Assassins Creed PC .forge files

[Pepper]

Nevermind that, Dump mode does it.

Wow. this is confusing, Dialogic vox works perfectly for a bunch of them (some vocals and music) but there are a ton that aren't imported right. It doesnt make sense to me to use multiple audio formats in one game, but when I try to import a good deal of them I get a two or more incompatible streams error.

and even more, alot of the music imports without me specifying a codec/sample rate, like it's just a standard mp3 file.

It appears alot of the sound files are ogg, but all except for the music aren't recognized.

[pixellegolas]

just saw that the new prince of persia is in .forge files too. Tried it on animus but get files that are 0kb big.

I never tried animus on assassins creed but do you get character 3d files from it?

[Shaddy]

Has anyone made any progress with the .forge files?

[Turfster]

Try Maki with the Animus plugin.
Replacement of datafiles in forge files doesn't work correctly yet.

[Turfster]

Updated the Animus plugin to also convert (some kinds of) meshes to OBJ files.

[Gocha]

Why all these? To make some MODs of the game?

Then what a MOD makin if I can't find in those damned .forge files which is FONT and TEXTs to extract and edit font and text and menu names in the game and pack them again?

[Gocha]

Here what I have made out, defined and specified:

Here is two texture file Screenshots from the Russian version of the game (one big table, one small table), which I made by 'TexMod' (which doesn't supports repacking back edited textures of the game).


http://rapidshare.com/files/238528256/AC_Out.rar

Textures definitely are in one of these:
DataPC.forge
DataPC_Common.forge
DataPC_LoadingRoom2.forge
DataPC_Map_Menu.forge

(I want than ever to find the text of the game, menu text, subtitle text and so on)
Can anyone work it out?

[Gocha]

I discovered that in file 'DataPC.forge' exists container 'Game Fix' [178mb], which one contains some texture files.

Maki 1.2 by Turfster, doesn't opens it.

As I've explored extracted files by Maki 1.2, I think textures for font file has to be in 'Game Fix', I hope someone will defeat that

[fedeita]

Turfster i sent to you some pm's take a look at them i need you help please.

[Gocha]

Has anyone made any progress with the .forge files?

[pixellegolas]

don't hink so, the only thing i discovered is that if you look at .forge in a mirror it becomes egrof.


....i am tired

[The Mauler]

Hi !

I've worked on this file format a few months ago (with your well known member Turfster) and i would like to share this because I don't have the time anymore to continue my research.

I've written an application (called Elika like the Turfster's plugin for Maki ) in C# to analyse/extract or create forge archives but it's incomplete. Unfortunately, my code sucks and lacks of optimisations
You can grab the binaries and sources here (sorry for the comments, they are in french...) : http://www.mediafire.com/file/4trtqznm4 ... v0.5.1.zip

Finally, I post here again the structure of the forge archives (my thread on the official Ubisoft's forum hadn't any kind of succes). All of this is based on the published work by Turfster on your wiki and here : http://www.fluffy-demons.net/index.php? ... ile_format.

I hope this will be useful for some coders here

Code: Select all

========================================================================
Forge Archive
========================================================================

Global structure :
- File header
- Archive header
- One or more fragments

Fragment structure :
- fragment header
- index 1
- index 2
- index 3
- Datablocks (aligned on 2048 bytes to match DVD sector size)

REMS :
- Null padding between Special index and first datablock can be null. If it's not null, it's first byte have a not null random value (unknown). If the archive has multiple fragments, there will be the same byte values for each padding.
- Values are little-endian for all plateform (Verified for PC and Xbox360)

------------------------------------------------------------------------
File Header (29 bytes = 0x1D bytes)
------------------------------------------------------------------------

0000	byte[8]	"scimitar" string
0008	byte	0x00 (probably null character of scimitar string)
0009	int32	engine version (AC : 0x19, PoP : 0x1A)
0013	int64	Archive header pointer
0021	int32	0x00000010 (unknown)
0025	int32	0x00000001 (unknown)

------------------------------------------------------------------------
Archive Header (40 bytes = 0x28 bytes)
------------------------------------------------------------------------

0000	int32	file number in the whole archive
0004	int32	number of records used in index 3 (in all fragments)
0008	int64	0x0000000000000000 (unknown)
0016	int64	0xFFFFFFFFFFFFFFFF (unknown)
0024	int32	maximum files which can be stored in one fragment (in PoP forge archives, this value is always 5000 = 0x00001388 files, in AC this value is exactly the number of file in the archive)
0028	int32	fragment number in the archive
0032	int64	offset of the first fragment

------------------------------------------------------------------------
Fragment header (48 bytes = 0x30 bytes)
------------------------------------------------------------------------

0000	int32	file number in the fragment (can be null)
0004	int32	number of records used in index 3 (in this fragment only)
0008	int64	index 1 pointer
0016	int64	pointer to next fragment or 0xFFFFFFFFFFFFFFFF if this fragment is the last fragment of the archive
0024	int32	index of the first file in the fragment. Each file in the archive have an index : 1st file, index 0, second file index 1 etc... Therefore this value will always be zero in the first fragment and will be equal to 5000 in the second fragment if the fragment capacity is 5000... (we assume all indexes are consecutives values)
0028	int32	index of the last file in the fragment. Therefore, this value will be equal to c*f-1 with c the capacity of one fragment and f the position of the fragment in the archive with a starting by f=1.
0032	int64	index 2 pointer
0040	int64	index 3 pointer

------------------------------------------------------------------------
Index 1 record (16 bytes = 0x10 bytes), one record per datablock
------------------------------------------------------------------------

0000	int64	datablock pointer
0008	int32	identifier 1 (unknown, this value is always 0x000000010 in the first file of any archive named GlobalMetaFile, the game will crash if you change this value, it's probably an identifier used to retrieve the ressources)
0012	int32	length of the datablock

------------------------------------------------------------------------
Index 2 record (188 bytes = 0xBC bytes), one record per datablock
------------------------------------------------------------------------

0000	int32	length of the datablock
0004	int64	identifier 2 (unknown, maybe a checksum, the game still work if we change this value)
0012	int64	0x0000000000000000 (unknown)
0020	int64	0x0000000000000000 (unknown)
0028	int32	next file index value or 0xFFFFFFFF if this is the last record of the archive
0032	int32	previous file index value or 0xFFFFFFFF if this is the first record of the archive
0036	int32	0x00000000 (unknown)
0040	int32	unix style timestamp
0044	byte[128]	ressource name (unused bytes are set to zero), some files are unamed
0172	int64	flag 1 (unknown). Always 0x0000000000000002 for the first record in the archive and 0x0000000000000004 for the other files (except in AC where all files have 0x0000000000000004)
0180	int32	flag 2 (unknown). Always 0x00000002 for the first record in the archive and 0x00000004 for the other files (except in AC where all files have 0x00000004)
0184	int32	flag 3 (unknown). Always 0x00000001 for the first record in the archive and 0x00000000 for the other files (except in AC where all files have 0x00000000)

Maybe, flags are used to differentiate types of files (like unix with directories, block files, regular files...)

Changing flags and the name of a ressource seems to don't have any consequence on the game...

------------------------------------------------------------------------
Index 3 record (164 bytes = 0xA4 bytes), one record per datablock but unused records are zeroyed (for the moment there was only one record used for all archives analysed in AC and PoP)
------------------------------------------------------------------------

0000	int32	maximum file index number of the archive. (equals to file number - 1)
0004	int64	0xFFFFFFFFFFFFFFFF
0012	int64	0xFFFFFFFFFFFFFFFF
0020	byte[128]	null bytes (maybe to store a name)
0148	int32	0x0000000D or 13 (unknown)
0152	int32	0x00000000 (unknown)
0156	int32	0x00000000 (unknown)
0160	int32	0x00000004 (unknown)

Maybe this records store folders. There seems to be unused by the games (you can zeroyed this records and the game will work fine...). The only used record could be the root directory of the archive.

------------------------------------------------------------------------
Datablocks (440 bytes = 0x1b8 bytes)
------------------------------------------------------------------------

0000	byte[8]	"FILEDATA" string (without null end byte)
0009	byte[128]	ressource name (unused bytes are set to zero)
0009	byte[255]	null padding
0391	int32	identifier 1
0395	int32	ressource length
0399	int64	identifier 2
0407	int64	0x0000000000000000
0415	int32	flag 3
0419	int32	flag 2
0423	int64	flag 1
0431	int32	timestamp
0435	int32	0x00000000 (unknown)
0439	byte	0x00 (unknown, probably to realign the data)
0440	byte[]	ressource data

========================================================================
Ressource
========================================================================

Each ressource begin with a 64bit identifier which is the type of the ressource.

List of ressource types (most significant byte first) found in PoP and AC :

0x0000002800011B01 Sound file (AC) (OGG file or ADPCM)
0x000000281000210F Sound file (PoP) (can be OGG file, OGG with truncated header)
0x1004FA9957FBAA33 compressed archive (PoP et AC). Contains textures, scripts...
0x0000000400000001 for all "GlobalMetaFile" (AC et PoP)
0xC043215626E7DB94 some files unamed in second position in forge archives
0x0000002810001F02 some sound files

The ressources are plateform dependant regardless the endianess :
- PC versions have little endianess ressources (including their identifier)
- Xbox version (and probably PS3 version too) have big endianess ressources

========================================================================
Ressource : PoP Sound (40 bytes = 0x28 bytes)
========================================================================

0000	int64	0x0000002810001F02 (identifier)
0008	byte[16]	(unknown, probably an hash value but which algorithm)
0024	int64	0x0000000000000000 (unknown)
0032	int32	0x50000000 (unknown)
0036	int32	0x00000002 (unknown, maybe channel number)
0040	byte[]	data

========================================================================
Ressource : AC Sound (40 bytes = 0x28 bytes)
========================================================================

0000	int64	0x0000002800011B01 (identifier)
0008	int32	(unknown, but never greater than 0xFF)
0012	int32	(unknown, but never greater than 0xFF)
0016	int32	0xFFFFFFFF (unknown)
0020	int32	0x00000000 (unknown)
0024	int64	probably a timestamp but unknown algorithm
0032	int32	0x50000000 (like PoP sound ressource)
0036	int32	encoding used : 0x15F3F950 for OGG stream (with or without header or two ogg files concatenated but unreadables) or 0x355C6300 for IMA-ADPCM (this sound ressources can be read in Audacity with RAW import and selecting VOX-ADPCM and 32000Hz)
0040	byte[]	data

OGG files in AC are probably a kind of archive.

========================================================================
AC OGG Archive (32 bytes = 0x24 bytes)
========================================================================

0000	int32	0x00040008 (unknown)
0004	int32	(unknown)
0008	int32	0x00000002 (unknown, maybe number of files in the archive)
0012	int32	(unknown, always 16 bits values)
0016	int32	0x00000010 (unknown)
0020	int32	0x00002808 (unknown)
0024	int32	(unknown, always 16 bits values)
0028	int32	(probably the offset or the length of the 1st file, always 0x00001400)
0032	int32	(probably the offset or the length of the 1st file, always 0x00001400)
0036	byte[]	data

========================================================================
Compressed ressources
========================================================================

A compressed archive is always composed by 2 concatenated metablocks :
- first metablock contains a compressed index
- second metablock contains compressed data

Each metablock can be uncompressed independently.
------------------------------------------------------------------------
Metablock
------------------------------------------------------------------------

0000	int64	0x1004FA9957FBAA33 (identifier)
0008	int16	0x0001 (unknown)
0010	byte	0x01 or 0x02 : compression algorithm
0011	int16	0x8000 (unknown, probably the maximal size of compressed blocks)
0013	int16	0x8000 (unknown, probably the size of decompressed blocks)
0015	int16	number of LZO blocks
Block table (one record for each block)
XXXX	int16	uncompressed block size
XXXX	int16	compressed block size
Blocks table (one record for each block)
YYYY	int32	(unknown, probably the block checksum)
YYYY	byte[]	data

Algorithms :
0x01	LZO1X_1
0x02	LZO2A

Other algorithm could be used. I have found these string in the executable file of the games :
- LZO1X_999 (can be uncompressed with LZO1X algorithm)
- LZX (based on LZ77 algotirhm)

If a block is uncompressible (means compressed data is bigger than uncompressed data), the block remaind uncompressed. You can localise these blocs which have same value for compressed and uncompressed size. (don't try to uncompress a such bloc or your program will probably crash !).

------------------------------------------------------------------------
Compressed ressources : index
------------------------------------------------------------------------

0000	int16	record number
Records (one record per file)
XXXX	int32	identifier 1 (seems to be an identifier used by the game to retrieve the ressource)
XXXX	int32	length of data (including header)

------------------------------------------------------------------------
Compressed ressources : data
------------------------------------------------------------------------

Datablock are concatenated without padding between them

0000	int32	identifier 2 (seems to be the type of ressource)
0004	int32	length of ressource + 8 bytes (probably to include identifiers 1 and 2)
0008	int32	length of ressource name (without null terminating character !)
0012	byte[]	ressource name (variable length)
XXXX	byte	0x00 or 0x01. If this byte is 0x01, it's followed by a additional table (unkwnown utility) :

YYYY	byte[3]	0x 02 00 00 table header
YYYY	int32	number of records in the table
YYYY	byte[] records in the table

ZZZZ	int32	identifier 1
ZZZZ	int32	identifier 2
ZZZZ	byte[]	data

Table record structure (12 bytes = 0x0C each):
0000	int32	0x00000000 (unknown)
0004	int32	(unknown,maybe flags, there is values like 0x00070000,0x00050000,0x00030000)
0008	int32	(unknown, first record contain big value like 0x18EE, others weaker values like 0x04,0x03...)

Exemple of identifiers 2 :

0x 17 E9 B7 A2	DDS Texture with modified header
0x 60 35 A8 E5	File list or directories ?
0x E7 33 81 AF	Table of identifiers
0x EC 19 78 0E	Parameters (binary)
0x 5E 41 84 09  Probably compiled scripts
0x 29 8C C4 3B	String table
0x 16 1C 43 DA	Script ?
0x D2 F1 E9 23	Function name ?
0x BA 23 4A 82	Animation ?

========================================================================
DDS Texture
========================================================================

0000	int32	dimension 1 (width or height)
0004	int32	dimension 2 (width or height)
0008	int32	0x00000001 (unknown)
0012	int32	0x00000000 or 0x00000005 (unknown)
0016	int64	0x0000000000000001 (unknown)
0024	int64   type of texture (7 = DXT1, 8 = DXT5, maybe other values...)
0032	int64	0x0000000000000000 (unknown)
0040	int32	0x00000001 (unknown)
0044	int32	0x00000001 (unknown)
0048	int32	0x00000001 (unknown)
0052	int32	0x00000007 (unknown)
0056	int64	0x0000000000000002 (unknown)
0064	byte[3]	padding ?
0067	int32	0x13237FE9 (unknown)
0071	int32	linear length of uncompressed texture (from DDS format documentation)
0075	byte[]	data

[shekofte]

welcome The Mauler
i hope the nightmare of forge files end here ...

[The Mauler]

Ty for your message

I don't know if there is other file format like that but you're right : this is a nightmare !
- All the files seems to reference themself by using identifiers (some files/ressources don't have a name)
- There is many ressources with a well-known format like DDS textures or OGG sounds but their headers are truncated or modified
- The forge archive itself looks more like a file-system (optimised to add files but no to remove them) that an archive...
- All the ressources types are mixed in the archives/datablocs (except for the sounds) : textures, models, texts, animations, compiled code and even piece of C++ source code !

I will try to add some explications here (sorry for my bad english )

The format is exactly the same in Prince of persia 2008 and Assassin's creed. Only the strategy of adding files is different, in princce of persia, all the archives have a fixed fragment size (5000 files) and have 1 or 2 fragments (eg : for the sound archives where you have aproximately 8000 files). In Assassin's creed, the fragment size is equal to the number of files in the archive and you always have 2 fragments, one with the files and one empty. With my tool, you can change the fragments size/number without any problem to be recognised by the games The comparaisons between the 2 games help me a lot !

You can change many values without crashing the games even the (probably) checksums but the Identifiers 1 and 2 seems to be important for the game to find the ressources.

I've also analysed the code of the main executable files : when the game start, it search for all the forge archives in it's directory and probably load their indexes. There is a lot of hidden parameters. Some of them refer to test levels and crash the game at startup. Some others doesn't anything ("log" log nothing even in stdout if the game is started in cmd). But I'm not experienced with debugging tools...

Code: Select all

========================================================================
Exe Command Line (Prince of Persia)
========================================================================

Syntax is
/<name of option>:<parameter1>,<parameter2>,...

Options available are (non exhaustive) :

/startupmenu:off|on
Enable or disable debug menu. Anyway, you cant see the debug menu if bink video are enabled (see /bink)
/log:on|off
Probably to log game activity, but in reality, seems to do nothing
/fullScreen:off|on
No comment :)
/world:<string>
It's the entry point of the game. Default value is "POP0WORLD". Maybe the name of the forge archive DataPC_POP0WORLD.forge (but if you change the filename AND this parameter, the game will don't work too...)
So, it can be too name of the ressource named "POP0WORLD" located in DataPC_POP0WORLD.forge/POP0WORD Compressed Archive/
/fast
If this parameter is not present, the game try to load remote ressources throught an middleware called "perforce". This software seems to be a version manager probably used in the developpement.
/shadows:on|off
Enable/Disable dynamic shadows
/lightmode:normal|?
Probably to modify light renderer
/fardist:1500
Maybe to change dynamic LOD limits, in reality, this parameter seems to have no effect
/mission:<string>
No effect, by default, his value is "pop0_root". Maybe an entry point for debug ?
/localbigfile
Any idea. Maybe to tell to the game to search forge file in the local machine (see /fast)
/noconsole
No effect. If you erase this parameter of the default command line (by modifying the executable) this has no effect. Maybe you must enter a secret key combination to enable a developper console (as in Half-Life)
/langage:<string>
Change langage used (texts and sounds). Possible values : eng,fre,ger,ita,spa depend of your game version).
/resolution:<width>,<height>
Screen resolution

By default, the game is launched with following command line (options are writed in exe file) :
/log:off /fullScreen:on /world:POP0WORLD /fast /shadows:on /lightmode:normal /fardist:1500 /noconsole /bink:on /mission:pop0_root /startupmenu:on /localbigfile

In addition, the executable contains some interesting strings. These are probably other options and values avalaible. Some may crash you game (especially test* options because the associated ressource has probably been removed)

Options found in exe file :

gcmreplay
vsync
help
startupmenu
usesharedobjects
flushdiskcache
nodiskcaching
DynamicMip0MemoryBudget
testvideo
turbodebug
ps3floodmeminfo
smallFakeEntitiesActivationRange
gpuprofiler
customphysmemalloc
defaultallocator
memvalidate
memgearstats
memgeartracker
meminfodump
memall
memdebugfreequeuemaxalloc
memdebugfreequeuesize
memdebug
memtag
memworldstats
memtypestats
memlog
heartbeat
profilerout
sanitycheck
logtime
noconsole
invertcameraverticalaxis
invertcamerahorizontalaxis
testmissiontemproot
testmission
missiontemproot
mission
missions
nochangeworld
loadingrange
startpos
walkthroughsmoketest
walkthroughloading
walkthrough
loadondemand
startanvil
quit
noscimitaroutput
consoleout
darespy
nosoundchangelistprotection
soundsystemdebug
language
fast
gfxassert
useptcoptim
skipmips
msaa
lightmode
transparency
noindirectlight
shadows
postfx
fixedfov
fardist
neardist
worldarea
world
importforge
revert
syncsound
sync
localbigfile
dataservice
maxthread
autoprofileworst
autoprofile
soundengine
nosound

Parameters founds

default
normal
full
4x
2x
none
edge

Finally i analysed the DLC of Prince of Persia (XBox version) : all the forge files have the same format but if you put them in the directory of the PC version of the game, the game crashes... Actually, the forge archives are coded in little endian in both XBox and PC plateforms (probably on the PS3 too) but the datablocks are in big endian format on XBox (probably for the PowerPC based architecture).

That's all

[shekofte]

thanks , golden information