![]() |
![]() |
Forums
Prince of Persia
Prince of Persia - General Discussion
[Modding] Ressources for developers|
Go
![]() |
New
![]() |
Find
![]() |
Notify
![]() |
Tools
![]() |
Reply
![]() |
|
Hello,
First of all, excuse me for my (poor I'm a french programmer and a very big fan of Prince of Persia (of course I would like to know if legally, i can create and distribute a tool to modify Prince of Persia (such changing textures, musics or add 3D objects...) ? I try to understand how scimitar/anvil engine works and i've started to explore the structure of .forge files. So, i would'like to know if i can continue this project (and if it's possible maybe publish specifications of files ?). I've already read the other subjects about the opening of Jade engine (I know it's not possible for the moment). Without do that, it's really not possible to give some tools to Prince Of Persia community ? If all of this is really impossible, i can just encourage your team to create the best possible sequel that all the PoP fans are expecting ! Don't stop the dream This message has been edited. Last edited by: The-Mauler, |
|||
|
![]() |
I hope it is not.
I think the whole PoP community would love that. Just imagine, a Kindred Blades mod in scimitar engine... wonderful. ................... |
|||
|
![]() |
If its discouraged, we can all always discuss it in private ie. Private messaging.
PS: Maybe making a 3D prince of Persia 1 and 2: The Shadow and the Flame Mods (original 2D ones). |
|||
|
|
|
The thing i would need first is a hardcore trainer.
I really hope you can continue your project. this would be awesome. |
|||
|
|
|
Well, I can explain you how to export the wanted ressources,such as object files, textures,commands and soundfiles from the Jade Engined PoP-games. I already planned to do a tutorial about it which I will porbably post at the end of the week if I can finally get a nod from Raide since I planned to port PoP-models for the GMod, if you are aware of that tool. If you are a real programmer, then I really wish you luck for creating a modifying tool for the SoT-games
With the Warrior Within ressources "I grabbed Salma's *** just to keep things moving... -Penelope Cruz |
|||
|
![]() |
Yes definitely with some Warrior Within resources aka the Temple of Time is a direct rip off the Red Cathedral/Temple from PoP 2: The Shadow and the Flame and the Eagle headed enemies from POP: The Two Thrones are in that inhabited that red cathedral/temple as well... |
|||
|
Hey
Thx for reply Yes, I know the whole PoP community would like a such toolset. I just want the Ubisoft point of view because I've read many subjects in this forum about modding and they seems to want to keep the control over their engines/games. Like the problem of the DLC on PC, i don't want a lawsuit for "business raisons"... (even if modify their game would be finally a great advertisement For technical side, I've already writed a tool. But, for the moment, I've stopped it's developement. Anyway, you can always use the Turfster's tool named Maki (the author of Persian Rug, another tool for SoT trilogy In addition, I've writted a little documentation about file format but i don't know if i can post it here... But for the moment, theses tools can't only modify few things. |
||||
|
![]() |
it's not illegal to modify the files of a game as long as you are not allowing people to download content that would allow people to play the game without buying it. also it is technicaly illegal to make a mod for a game using any copy righted material from other IP's without the consent of the copy right owner.
also as long as your not making any money or charging there should be no complaints as you are offering a free tool/mod for the game that is new and unique. |
|||
|
|
|
You can always PM me the stuff, I'll take good care "I grabbed Salma's *** just to keep things moving... -Penelope Cruz |
|||
|
Tristan_129 -> Check your PM
caswallawn_2k7 -> Yes, in theory, but if you read carefully the game license, you cannot even modify game files or do a "retro-ingeneering" the structure of the game. But you're right, many mods had to be stopped because copyrights problems on their contents (for example, Marvel content on LittleBigPlanet or a Stargate Mod on Half-Life 2...) |
||||
|
|
|
I really don't care much about this copyrighting issue. Hell, I vote besides the Green for the Pirate Party.
What I question more is the gameplay value of the mods. For example Devil May Cry 3.Because Capcom was really easy going with their engine, many coders quickly took it as advantage of modding it by improving the Physics and the designs and even the interface of it. We are talking about improoving a game people bought it and have some freedom to do with it what they want,even with the ressources,as long they won't gain any financial profit by it. Also an other pro-argument is that many games couldn't be comepleted of technical issues. That goes down to the PC port of Warrior Within.If compare it with the PS2-version, the PC has endless bugs the developers didn't even bothered to do a patch after the release. So say,we have a modding tool, we could clear those bugs out and help that way many gamers who were left unsatisfied with the PC experience. If now Ubisoft would come over a proposion to delete this tool because we were fixing their game...do you see how stupid that step would be? They would loose many fanbases that way. Of course, I sent an email to Ubi to ask for such a Leveleditor or SDK so we could mod those games, and they said no. That's okay, but they can't forbid us making our own tools. "I grabbed Salma's *** just to keep things moving... -Penelope Cruz |
|||
|
|
|
If you want to publish your work i can help you. |
|||
|
Look at the DLC... That's exactly what they do Keksus => For the moment, we can't modify scripts. I've not enough time to continue to develop my tool. That's why I would like to share my work with modders and programmers. If Ubisoft agrees, I will post here the things I've discover on .forge files. But I repeat, my tool isn't as powerfull as the Turfster's one. However, I've included the sources PS : Two links on forge file format (Warning : there is some errors) http://www.fluffy-demons.net/i...e=.forge_file_format http://wiki.xentax.com/index.p...e=Assassin%27s_Creed |
||||
|
So... if there isn't any problem i post here what i discovered on PoP files.
(Moderators, don't hesitate to delete this post if this is a problem...). Enjoy ======================================================================== 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 file ine 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 int21 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 0008 byte 0x00 (probably null character of FILEDATA string) 0009 byte[382] ressource name (unused bytes are set to zero) 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 (not exhaustive) of ressource types (most significant byte first) : 0x 01 1B 01 00 28 00 00 00 Sound file (AC) (OGG file or ADPCM) 0x 02 1F 00 10 28 00 00 00 Sound file (PoP) (can be OGG file, OGG with truncated header) 0x 33 AA FB 57 99 FA 04 10 compressed archive (PoP et AC). Contains textures, scripts... 0x 01 00 00 00 04 00 00 00 for all "GlobalMetaFile" (AC et PoP) 0x 94 DB E7 26 56 21 43 C0 some files unamed in second position in forge archives 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 0x 02 1F 00 10 28 00 00 00 (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 0x 01 1B 01 00 28 00 00 00 (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 0x 33 AA FB 57 99 FA 04 10 (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 uncompressed 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 |
||||
|
|
|
So...those codes will help us modding the games? "I grabbed Salma's *** just to keep things moving... -Penelope Cruz |
|||
|
Yes, but it's a begining
These "codes" are the structure of files used by the game (Assassin's Creed seems to use the same files). At the top level you have the forge files which are kind of big archives. The forge archives contain the ressources of the game : - sounds (Ogg or Adpcm files with sometimes truncated header) - "datablocs" which are LZO compressed archives with other ressources within... datablocs contains a lot of things like : - textures - 3D models - scripts - localized strings I started to work on this game and i've writted a tool in C# called "Elika" (in tribute to the beautiful princess This text file is what i've discovered and implemented into Elika but now Maki have more powerful options like import/export 3D Models and textures. However, he hasn't relesed his sources. That's why I do it here in the case where a developer would go through there... PS : The last version of Elika is here http://www.mediafire.com/file/...oyy/ELIKA_v0.5.1.zip Warning, the tool has been written in french, comments too but varable names in the source code are in English You have both binary file and source code (Visual Studio 2008 project) |
||||
|
|
|
Hmmm, so the dream to mod the SoT-saga will be a long road still...
"I grabbed Salma's *** just to keep things moving... -Penelope Cruz |
|||
|
| Powered by Eve Community |
| Please Wait. Your request is being processed... |
|
Forums
Prince of Persia
Prince of Persia - General Discussion
[Modding] Ressources for developers
