first off, thank you very much Shokoniraya for that awesome script.
The MIPS hacker for the translation project also took a look at this issue, and he found out this:
I figured it out! After blankly staring at hex for too long I figured thisthing out.
Remember all those silly spaces at the end of every file? They are CRITICAL, all of them pad out the files for them to snuggly fit inside an
LBA (0x800 chunks that divide the game disc logically) the game will simply refuse to read in-between LBA's for speed (and because they have ~4GB to
work with anyways
) as such, if the file doesn't start at a disc location where 0xLocation % 0x800 == 0 the game will just discard the part that
isn't and will do direct copy starting from a location that is multiple of 0x800.
THAT'S why it breaks when the changes are big enough, but leaves a little wiggle room where if small enough it can work by pure luck, and that's also
why the defined .DAT size isn't really honoured.
Every .DAT file is like this and that explains why the .flk's inside were multiples of 2, now I haven't tested this yet, but a comparison of two
instances of the game running confirms this suspicion (and also confirms that the game can handle relocating bigger files, assuming enough memory is
available) so we only need to automate this.
And lastly some funny observation, I actually pointed at something like this in a previous email, past me basically had it resolved xd
Just tested, all working ok after padding the file manually.
A really nice person over at the quickBMS forums replied to my post too, and with his quickBMS script it seems like the dumping of the .DAT files is
Oh wow, this guy is god, we got mostly the same understanding of the file
format, but he actually figured out more fields in less time, awesome!
I guess because of the broken file sizes (0xLocation % 0x800 == 0), which
affects a lot of files now, even with his script the game will not load the
I'd say his script is pretty good, the issue now seems to be due the way
you dealt with the flk's (or rather STXT) that wasn't accounting for this
change in the actual file definitions, assuming they are "mishandled" in
the same way it is rather easy to fix
How many bytes would i need to add to the script file in order for the
game to be able to read it properly?
Thi is very simple, the file needs to end with 0x000 or 0x800
when i tried to load the endgame save the whole game was suuuuuper slow
(not inside the menu though) and crashes after opening the menu and closing
It seems that some files got offsetted by 0x80 in some places, it's
probably that offset the one causing the issues, can't check right now.
Anyway, checking Shokoniraya's very awesome script, it actually seems to do
most everything for remaking the .DAT file (this guy is god)
So, theoretically you would only need to make the STXT's a size multiple of
0x80 it seems, and ideally it should be just a script of some sort (as the
new STXT, are flk's with SDF files, which themselves have a format) to have
it in just one step.
Gotcha, Shokoniraya actually send me an updated version for the script:
Perfect! Now the files are padded to 2048 (0x800) it should work as-is now,
now it's time time to test it
Gotta say, quickbms is awesome considering its generic nature, this script
is awesome considering it made unnecessary to code a parser ourselves
I didn't have time to test the script yet, but i really appreciate all the help from you Shokoniraya!
I will update this thread once i tested it.Edit: But just for my understanding, i'm using reimport2 for this script, right?