the archive begins directly with a bitmap file so the only other location where was possible to find the index table was at the end. so here we find the size of the index (which includes also this 12 bytes header), a number which I have not verified and the "3DR\0" signature. figuring the ...

the following is the BMS script for extracting the 3dr files with quickbms: goto -4 idstring "3DR\0" goto -12 savepos MAX_OFFSET get INFO_OFFSET long math INFO_OFFSET *= -1 goto INFO_OFFSET savepos INFO_OFFSET set FILES long MAX_OFFSET math FILES -= INFO_OFFSET math FILES /= 4 get OFFSET l...

well, having created the extractor probably I need to reply.
in this period the max I do is writing the extractors on the fly for quickbms so any other project (moreover rebuilding which is something that I don't like because it's boring) is out

usually it's not needed to rename the files, just open them directly with 7-zip and if they are a known compressed format the job is done (like in this case)

you can specify the desired compression method using the comtype command. by default it's the zlib one (RFC 1950, windowbits 15) so if you need the raw inflate (RFC 1951, windowbits -15) it's enough to use: comtype inflate then the decompression can happen in the classical "clog FILENAME OFFSET...

uhmm maybe I'm wrong but I think that the lzss.c version with N, F and THRESHOLD (like http://dev.gameres.com/Program/Other/LZSS.C) is the oldest one, or at least is the most used.

another interesting thing I noticed some months ago about LZSS.
the following is the latest source of Okumura
http://oku.edu.mie-u.ac.jp/~okumura/compression/lzss.c
but even if you change the EI, EJ and P parameter to make them compatible with the classical algorithm it's not compatible at all.

N=10? so basically the data is almost uncompressed :)
other games other than s2?

@rheini do you have a list of games that use modified lzss parameters (N, F and THRESHOLD) and these customized values? if I'm not in error I saw only a customized N value one time (I don't remember well) but for the rest I have never seen games which use the LZSS algorithm with customized F and THR...

imho it's only needed a bit of usage of phpbb code without useless pdf stuff

create the folder c:\output and then: c:\output is needed because xor uses fopen(..., "wb") and reads 8kb of data each time (for using less resources) so the output file can NOT be the same of input

remember that thing I said about the size of the compressed blocks, so you can't just compress the whole HOG file and then adding a new header.
anyway I guess that the game could work also with the HOG files without recompressing them

there is the find utility which does this job executing a specified executable and its parameters over any found file in a directory. http://gnuwin32.sourceforge.net/downlinks/findutils-bin-zip.php http://gnuwin32.sourceforge.net/downlinks/libintl-bin-zip.php http://gnuwin32.sourceforge.net/downlink...

no, doesn't seem LZR.
I have spent various time using LZRDecompress on various blocks at the beginning without success.

the following is the bms script for extracting the files from these HOG archives: # Resistance Retribution (HOG extractor) # for generating the HOG file from an HGZ one: # use "offzip -a -1 UNFREED.HGZ c:\ 0x14" # rename c:\00000014.dat to UNFREED.HOG # script for QuickBMS http://aluigi.or...