No problem. The script I created for MultiEx Commander should enable you to replace (import) files as well in the .CAM archives.

I will take a look at them at get back asap.

Are you saying there's some PAK files not supported by MultiEx Commander ?

Thanks. When I have time I will see if I can fix a script for the altered format.

Well, we would need to have examples of those files and possibly other files that contain the tables that point to where a file can be found in the .asf files.

Is this possible to arrange? Also, what is this encryption, it was figured out already?

I have investigated the .CAM files, and created a script for MultiEx Commander. Please read

viewtopic.php?p=9801#9801

Okay, here's a script you can use in MultiEx Commander to open .CAM files. This will also enable importation (wait until I update the webdatabase for that part). ImpType Standard ; IDString 0 CYLBPC ; Get V Int 0 ; Get V Int 0 ; Get V Int 0 ; Get FT Long 0 ; For T = 1 To FT ; Get DS Long 0 ; Set EXT...

I am investigating them. Have made some progress. Will let you know what I find. Thanks!

This is a file that contains increasingly smaller textures for the same item (like MIP maps in DDS). I haven't quite figured out the format of the images yet. They do not look compressed really, as the image data matches the height*width variables in there. So it should be an 8-bit image format. Do ...

Thanks! I'm on it. Let you know what I find.

PICT2BMP Here's a converter I wrote for you guys in need of conversion. ;) Actually, Watto was a bit off, the second value of 256 and the 'unknown' 512 are height and width of the picture. 512x256 = image size. Check below for the program, a screenshot of it and the picture you attached to this thr...

Well, that is what puzzles me as well, there's still a lot to be figured out. I suspect perhaps certain parts can also be tagged and used elsewhere.

What would really help is to have a decompressed part of that file, to compare with.

On inspection, it looks like bits are used to show how many characters to append. so 0xFF = 11111111 , which is all 8 of them. Thus, 0xFE = 11111110 , so the next 7 should be appended. More: 0x7F = 0111111 -> The immediate next character is a control character, but the 7 after that should be appende...

Actually, the author wrote two different formulas for the same, didn't he? That's kind of weird.

You mean with the TRE Archiver. Our "small organization" is XeNTaX.
Okay, so they are in the old format. Then the TOC may point to the location of files in the old formats to replace with new ones?