I know that the following script is horrible but I don't have time and interest at the moment: open FDDE "hed" open FDDE "dat" 1 for i = 0 < 3 findloc OFFSET string "--DirEnd--" goto OFFSET get DUMMY string next i padding 8 getdstring DUMMY 0x44 for get OFFSET long get ...

I don't know what compression it is or if it could be an lzss with different parameters (those I tested gave no good results) so the following is the script without decompression: # NO DECOMPRESSION idstring "add" goto 0x10 get FILES long goto 0x20 for i = 0 < FILES get OFFSET long get SIZ...

this is the quickbms script I posted in the thread you deleted: # MegaMind # simply dump each encrypted UDP packet sent/received from *.quazal.net in a file and pass it to this script comtype xmemdecompress endian big idstring "pack" get DUMMY long get DUMMY long get OFFSET long get SIZE l...

the files are compressed and with some of them the compression used by Crysis is better than the one used by quickbms (zlib used in 7zip) while for others is better the one of quickbms. but in this case I guess it's just the problem of the different chars used for the translation that occupy more sp...

script for quickbms: # MegaMind # simply dump each encrypted UDP packet sent/received from *.quazal.net in a file and pass it to this script comtype xmemdecompress endian big idstring "pack" get DUMMY long get DUMMY long get OFFSET long get SIZE long get NAME_BASE long get FILES long math ...

The contents of this post was deleted because of possible forum rules violation.

uhmm do you receive that message immediately? at the moment I don't have other ideas, maybe I will return on it tomorrow. if you want to make a quick try replace the first "get OFFSET longlong" you see in the script (there are 2 of it) with: get OFFSET long get DUMMY long maybe it's the sa...

the extracted xdt are fake xdt.
if you open them with a hex editor you will notice the SNK signature so they are graphic/3d stuff

compressed chunks mean that the file is not compressed directly but it's divided in various pieces and each piece gets compressed separately.

I don't have other solutions, you need someone who wants to write a repacker... a boring job so you need to find someone really motivated.

as already said, for the lzo problem I don't have idea.

while the second one don't worry, I have updated the script posted before (just a one-line fix) and you must use quickbms64_test.exe to extract the files.
now it should be ok.

excellent I have not only fixed the problem but I have even implemented the usage of the folders that was missed in the previous version.
the link is ever the usual:
http://aluigi.org/papers/bms/fightnight.bms

let me know if now it's all ok with all the files

the script is the following but I don't understand why some compressed files are invalid so if you get a "compression" error while using quickbms I don't know how to solve it at the moment: comtype lzo1x idstring "ABE\0" get DUMMY long get DUMMY long get DUMMY long get DUMMY long...

the format is simple but the compression is unknown. if someone is interested in figuring the compression the following is the format in quickbms script. comtype unknown get DUMMY long get FILES long for i = 0 < FILES get ZSIZE long get SIZE long get OFFSET long getdstring NAME 32 clog NAME OFFSET Z...

for a generic step-by-step for reimporting files back in an archive take a look here:
viewtopic.php?p=52546#p52546

unfortunately the method used by MK9 doesn't allow to reimport the files because it uses compressed chunks.
so you can't use the quickbms solution.

reimporting the modified files back in the original xdt archive is possible.
you can find a generic step-by-step here:
viewtopic.php?p=52546#p52546