Pdub wrote:If you hadn't noticed yet, gregkwaste, The size references for all the container files are right above the names of each file in 0A. I guess my theory that this is just one big bluray disc dumped into different files is correct. This will most likely mean that the entire file has to be extracted in a way that can be read by the game for it to be modifiable, or we have to repack the entire contents of the game to run any future mods. Hopefully the offsets are set in a way that the individual container files can be changed without having to change every single offset.
I also hope that the checksums in the names files aren't hard coded and we can just rename it to reflect modes files. We might be able to modify the zip files if we can make them smaller, and then using padding so no offsets need to be changed.
Yes i have noticed that, and i also believe that, the game thinks of all those archives as one and i have to disagree with nesa on this, the first 9 mb's of 0A are all that the game needs to index all its contents.
Every other way of reading each archives content, may work of course (thats what i have done as well), but its definitely not the correct way of reading the games content. If you don't find your way through these offsets you'll eventually NEED sometime to search for an appropriate header, and that is not correct. It may be working but its not optimal. What each file contains has nothing to do with what those offsets do. I am 99,9999% sure that if we manage to create a similar type of archive section like the ones defined, add this to 0A references last, and put in its offset, we should get brand new content in the game.If it loads it or not has to do with other things like db settings or model material and texture assignments etc. I'll definitely try to work on this way for parsing the game data.
. The number is huge and my program was severly lagging to load them all in lists but i managed to get around by using some additional threads 
