anyway I have updated the script with the additional info of Chipicao, but this doesn't change the behaviour of the script because lzma in quickbms is used dynamically so it automatically finds the uncompressed size, only the compressed one matters. Regarding the first file (battle.unity3d) it's dam...

regarding the arch* archives you can ever use my fear.bms script, it's still the same format:
http://aluigi.org/papers/bms/fear.bms

while for this BNDL format I made this script:
http://aluigi.org/papers/bms/others/bndl_4.bms

so it looks like they introduced chunks, rights?

I have just found in this moment that if I compile quickbms using the gcc option -fno-unit-at-a-time I'm able to decompress the files of Lego Movie PS3 (no problems with PC). Setting that option in gcc costs me less than reviewing the whole dlft code to understand what's the problem :) Anyway I cann...

have you tried the script I released some months ago?
http://aluigi.org/papers/bms/others/next_car_game.bms

I can't help more, the script uses the exact magicdwords reported by Ekey, in fact the bin.arc posted above works.

If you know the correct magicdword for that specific archive, the script will work.

the modification I suggested in the previous post is no longer valid because the script has been deeply modified. If you unpacked the archive with offzip then replace all the "MEMORY_FILE" with "1" and replace the following: clog MEMORY_FILE OFFSET PAK_SIZE PAK_XSIZE with: open F...

Post the files that give problems

I guess it's the same problem of Lego the movie, looks like the developers changed something in the dflt algorithm or added some type of obfuscation in the last chunk of the compressed files.
There is no solution at the moment.

Regarding the script syntax it's ok, the only suggestion I can give is to use DUMMY variables for unknown fields instead of goto. For example "goto 0x1 0 SEEK_CUR" -> "get DUMMY byte" And if there are more bytes but they can't be idenfied as a field, for example a sequence of 5 b...

I guess the cause is some zero before the 56th character of the key that decrease its length.
I have updated the script to force the length of 56 bytes, let me know if it works.

I have updated the script with the suggestions of swuforce because the names are embedded in the first file (that it's not a real file), current version is 0.2a that supports also the xbox files

in this case we can exclude problems with the decompression, additionally the filenames are checksummed so we are sure that the extracted names are correct.