Suggested edits for bigfile definition
Closed this issue · 7 comments
Bigfile
Shouldn't the heading be 'Tiger Archive Filesystem' since all these (bigfile)|(patch\d*)|(title).*\.\d{3}\.tiger files are basically the same file format with FourCC T A F S (magic 0x54414653).
I think 'bigfile' and 'patch' are just keywords, and a clever solution to avoid unnecessary download of unchanged assets. Big files are laid side by side and then patched incrementally (patch*, patch2*,...,patchN*).
File formats
Extension Definition Description .dep Unknown Some build process file
Don't you think the definition is Dependencies list.
I don't know what build process file you came across in your research but I think everything should be already built and compiled before distribution and this file might just describes runtime assets' or modules' dependencies.
But that's my take on it, I have not really encountered a .dep file in my Tomb Raider modding hunt.
Tiger archive files were only introduced in Tomb Raider 2013, the research here refers to the archive files in earlier games (Legend, Underworld, Guardian of Light). I don't have research about the Tiger archive files in later games but contributions are always welcome.
The term 'bigfile' seems to be used by the developers too sometimes, they refer them as 'bigfile' and 'patch bigfile', Archive or Archive Filesystem would work too (though maybe 'FileSystem' should be omitted since that seems more of a game interface to read files see MSFileSystem, XenonFileSystem, MultiFileSystem, ArchiveFileSystem).
--
The .dep files were found between files that seemed the be leftovers from the build/cook process that should not be shipped, I'll attach a ZIP with sample files to this comment.
--
I also noticed I haven't updated this in quite some time so I guess I should keep this more up-to-date with my current findings
Hello there my friend from the beautiful Netherlands.
Wicked sorry for the delayed response on my part.
Yes I am working with Tomb Raider 2013 files. These files are just iterations of previous games file formats such as TR8, 7, AS, Anniversary...
I looked at those files you uploaded, maybe you only have to care about these files in the early TR games and/or on the Wii platform. Cause I don't see these dependencies files in the later series or at least on the PC.
I have one more doubt though, are you sure about this relocation struct field typeAndSectionInfo having 13 (not 12) most significant bits dedicated as the index/offset to SectionInfo data?
Or that too only applies to the games before TR10 since at least 4 bits are needed to represent Section types of TR10 and:
enum SectionType
{
#if TR7
GENERAL = 0,
EMPTY = 1,
ANIMATION = 2,
PUSHBUFFER_WC = 3,
PUSHBUFFER = 4,
TEXTURE = 5,
WAVE = 6,
DTPDATA = 7,
SCRIPT = 8,
SHADERLIB = 9,
NUM_SECTION_TYPES = 10
#elif TR8
GENERAL = 0,
EMPTY = 1,
ANIMATION = 2,
PUSHBUFFER_WC = 3,
PUSHBUFFER = 4,
TEXTURE = 5,
WAVE = 6,
DTPDATA = 7,
SCRIPT = 8,
SHADERLIB = 9,
MATERIAL = 10,
OBJ = 11,
MESH = 12,
UNK13 = 13
#endif
this excerpt is from github user Gh0stblade's cdcEngineTools repository.
Some .drm, OGRE .mesh resources and stripped .tiger headers from the TombRaider2013.zip
--
I was initially thinking that it might be possible just to drop another patchN.000.tiger file with modified assets and the game executable might load it with the other patches.
But I found out that these patch strings are just hard-coded into the exe itself. I didn't dig around any further into reading disassembly, being almost certain that the developers never intended it that way. Maybe they would also have to redistribute an updated exe with the new assets, anyway.
I looked at those files you uploaded, maybe you only have to care about these files in the early TR games and/or on the Wii platform. Cause I don't see these dependencies files in the later series or at least on the PC.
It's probably just a leftover, it came with some IDMap files too which are only used for the debug menu in those early versions of the engine.
I have one more doubt though, are you sure about this relocation struct field typeAndSectionInfo having 13 (not 12) most significant bits dedicated as the index/offset to SectionInfo data?
Type in this case refers to the relocation type, not the section type. I will update that in the docs together with some other pending changes I had for the bigfile page.
Some .drm, OGRE .mesh resources and stripped .tiger headers from the TombRaider2013.zip
Thanks, I own all the games on Steam so I can get the files but these will also help with documenting the Tiger Archive files on the docs.
I was initially thinking that it might be possible just to drop another patchN.000.tiger file with modified assets and the game executable might load it with the other patches.
But I found out that these patch strings are just hard-coded into the exe itself.
The patch files are usually hardcoded, you might be able to abuse the DLC bigfiles but I'm not sure if those are associated with an ownership check. In the end they are all added to the same MultiFileSystem but that is hardcoded.
So this is relocation type, represented by 3 bits? That would surely be helpful if you could elaborate on that in the DRM/Relocation paragraph.
But I learnt from this code that is probably messy but works. The author had used the same packed bit field as section type.
I have also confirmed that typeAndSectionInfo & 0xF == sectionType is true, at least in the DRM files that I've upload.
SectionInfo
col 4 corresponds to sectionType
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3
0x00000020 280c 0000 0a00 0000 247c 0100 5101 0000 ffff ffbf
0x00000034 6405 0000 0900 0000 0000 0000 1d00 0000 ffff ffbf
Relocation and Section data
col 3 corresponds to typeAndSectionInfo & 0xF
- offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F
0x00002c6c 5101 000a 104c 3c04 b502 0000 f063 0400
0x00002c7c 1d00 0009 10f4 3c04 8405 0000 50a0 0500
This matches the description in TR8's SectionType enum. Why relocation type and section type would have the same values?
Thanks, I own all the games on Steam so I can get the files but these will also help with documenting the Tiger Archive files on the docs.
You sure do. I too, brought Tomb Raider off of this year's summer sale and I think I'll play Rise and Shadow too, albeit, modded as I want. I did so anybody interested won't have to unpack and/or dd it themselves.
I have not looked into detail since I haven't needed to use it before, but the relocation type can be 4 values; the first one being just a simple pointer relocation to a section offset. And the others are related to pointers to resources with an ID like textures.
I'll update the drm page after I'm done with the Bigfile page, since I'm currently trying to document the format of that from Soul Reaver to the latest game before Tiger archives.
If it helps, I'm not sure if you know but the Linux versions of Tomb Raider 2013 should have debugging information embedded.