Hello I want to extract the tintin.bf file, as I think it contains the models from the player and enemies etc. (This would make sense as the other 2 Bigfiles are the audio and the cutscenes)
I am however unable to do this using the tintin.bms script, as it gives an error code.
Does anyone have an idea if it would be possible to extract these files? Thanks in advance
In my previous post it's written that any lzma decompression failed, I'm quite sure I correctly tested it because I have experience with the various lzma formats. So if lzma_dynamic running on various positions of that input data failed, it means it's not real lzma.
i had to take a look at the game executable to see what kind of compression was it actually using for most of its files. i was sure it was using more than lzo1x but i had to dig deeper to find out.
that took me a long time than expected, i was looking at the functions that i believed would do the actual decompression work but turns out it was just memory handling. then i turned to the leftover Wii exe (LynWiiTintin.elf) and the funcion names were already there so i had little to no difficulty in locating the decompression functions at all.
so i pinned down a few functions (most of which had a "Lzma" name on them, the primary function for handling lzma compression is named "Lzma86_Decode" on the Wii executable i just mentioned previously) that did the actual decompression work, and compared the Wii exe to the exe i was previously looking at when it came to these functions. turns out they're almost identical to each other.
by the time i did i already decided it was using lzma86.
math OFFSET = 0 # set your desired position in the file comtype lzma_dynamic get SIZE asize math SIZE - OFFSET clog "dump.dat" OFFSET SIZE SIZE
You can also set the desired offset in case you want to try different positions in the raw data. The lzma algorithms in quickbms also support some settings in case the game uses a raw headerless lzma data (in quickbms it's called LZMA_0), in this case the only setting is the dictionary size, for example: comtype LZMA_0 0x400000
Ok I have updated the script to version 0.2. I also checked some of the few old samples that were still available and it works with them too so I hope it has not lost any compatibility. My only doubt is about a specific field which was used in the old script when TEST is 4 but it wasn't available in a sample I checked.
If someone can test this new script with other games I would be happy to know the results, hopefully better than the old one (more coverage?).
the script tried to compress a lzma file that isn't actually such. and that's just the tintin game, i don't know how the other games fare in this regard.
In the first example the input and output size seem correct so I suppose that's a chunk not compressed with lzma. Can you check it or provide a dump of the portion of data from offset 0x345a3840 of 0x2fab bytes? We need also to check the value of the TEST field because it may be different than 6 in that chunk. You can print that variable at runtime with this command at line 57 after it's read with Get: print "%TEST%"
In the second example it looks what I mentioned in my post, some archives have the TEST field 4 but some with and others without an additional field before CHUNKS. Can you check this one too?
We only need to find a rule that works with all the samples.
i satisfied all that was requested above. except for the third request. here are the results. there are some files with TEST 2, and one with TEST 0 (it's the one you asked me to provide a dump of). all are included here. though i had only had to include 3 files here since i thought that's just about enough for what i had to include here. https://krakenfiles.com/view/Asoi7Yh0ZR/file.html
some TEST 4 archives (RGH.bf, MJ.bf) work fine with the script to a point.
Error: incomplete input file 0: C:\[REDACTED]\RGH.BF Can't read 370984 bytes from offset 0000000039e1feac. Anyway don't worry, it's possible that the BMS script has been written to exit in this way if it's reached the end of the archive so check it or contact its author or verify that all the files have been extracted. Please check the following coverage information to know if it's ok.
Back to this topic but honestly I don't have any updates (also because I came here too late). Anyway I don't know if 0x345a3840_0x2fab is compressed and how because most of the text is visible and the words aren't truncated. While regarding the TEST field, it's a mess. I think that it's more convenient for me to no longer touch that script, but obviously if someone provides a patch I will be happy to implement it
