XeNTaX

in my unlzss.h there is no usage of int, I have used stdint.h which applies the correct size of a variable on any system in which is compiled.
so uint32_t generates a 32 bit variable anywhere stdint.h is supported.

for implementing the file-to-file mode it's enough to make a quick modification to the code using fgetc in UNLZSS_CGET and fputc in UNLZSS_CPUT and using FILE instead of in, out and their relative sizes.

I linked that code only as example of what worked here in my quick tests so that then you could do your tests and use a similar code which works better for your needs.

Yes, I think so... It is abstracted from 3D-Gamestudio ACKNEX.DLL.

uhmmm I don't have understood this.

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

GREAT TOOL!I TRIED IT AND SO COOL!

Still,I just want to ask one more for the Nancy Drew games source extractor,because they are just amazing,and very popular.If it dose not trouble much.

Again,thanks man

asmxtx:

Could you add a support for this game .vbf files?
The game's name is Chronicles of Mystery - The Scorpio Ritual.
You could download a sample file from here:
http://netload.in/dateiMzE1MjQ2ND/datas.vbf.htm

Maybe it is a quick and easy format? Thanks.

wqzss wrote:Maybe it is a quick and easy format?

Yes, it is.

- The programmers decided not to include original full file names, but created checksums or hash values for each file and stored them instead. Therefore the original file- and path- names are lost.

- Inside the VBF are some NMO/CMO-files (Marker: "Nemo Fi").They contain ZLIB-compressed and other data, stored in chunks. I don't know what to do with these files so I leave them untouched. Maybe a game editor handles them.

The GAUP plugin for TotalCommander supports this format, too.

Short file description:

I guess the ones for Final Fantasy 1 aren't so simple?

If there's anything I can do to help, please let me know.

asmxtx

Very thanks! It worked.
It is a game made by Virtools Engine ・3DVIA Virtools.

edit: ops, question already answered

@slackbabbath:
Your two files don't reveal much, but at a first glance it looks like a "quick and easy"-format. I need to investigate more files.
If you can, post links to a demo or something on an OCH where downloads can be done fast as a free user (no rapidshare, vipfile!)

Well, like I said, there's about 1,960 of the .pck files. So I would hope they'd be quick and easy lol.

Let me know of a good hosting site, and I can upload a few more for you. If you want I can put them into a .rar file or something if that would be better.

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

netload.in has a neat looking folder option, so I'll try that.

Here's the link to the online folder. And if you want me to add some more files to it, I can.

http://netfolder.in/folder.php?folder_id=NTc1Mjk

Bugfixes/Updates:

- One module caused the format recognition process to end prematurely if EXE file with some special header-data constallations were given.

- Now the FS format extraction seems to work, finally. This format is used by many FPS-games wich use the "Havok"-engine ("Gene Troopers", "Chaser", the "History Channel" series and many others).
It took me a long time to discover the last "secret" about the strange zero-size of chunks in the chunk-tables.
Almost all files in such a container are compressed (not primarily for space reduction, but for data camouflage). For each compressed file in the FS-container there exists a separate chunk table, which again contains values for the length of each chunk. Much often these values are zero, and I wasn't sure how to handle them. Now I found out if such a value occurs, the corresponding chunk has a length of 4000h Bytes and has to be simply copied to the output.
Last but not least there was an error in the file-loop procedure.


@slackbabbath:

Sorry, but I have to disappoint you. Your files don't meet any structure of "classic" container files. Both the short file sizes and the large number of such files in your game makes me wonder. This might be rather a task for a data converter but not a file extractor - but if somebody knows some hints then he might let me know.

Added: LZSS-decompression algorithm.
This was necessary to support some formats, e.g. "Baggersimulator" (3D-Gamestudio) and others.

I had to write my own implementation because I couldn't find any library with a ZLIB-like interface. Unfortunately my algorithm is pretty slow, but works.

Nice work mate!!