Mythic MPAK file structure

[silakka]

I don't know if someone already did find this already ..

Anyway, I did bit studying about mpak file structure when did build java mpak loader.
Seems that there is bit more information stored in "stage 1" (if check from original dempack.c).

Basically "stage 1" is file index information ..
each information row is size 0x11c .. which original dempack just uses with null terminated char[]
but there is extra information,
row_start_point + 0x11c - 8 = (int) compressed_size
row_start_point + 0x11c -16 = (int) uncompressed_size
.. also those might be "long", but I need to check this

So, it's quite easy to build read class with index for this and only load and un-compress needed parts from package file (if just load two first "stages" and leave it open for future reading)

[Etaew]

Very different from .myp? (Warhammer / Wrath of Heroes)
- Myp extractor - http://code.google.com/p/easymyp/
- Mpak extractor - http://www.dolserver.net/releases/files ... anager.zip

I don't think we have the source for the DOL MPAK tool, so could be nice to outline the methods for another.

[silakka]

I think Warhammer used someway similar structure, except filenames was just hash and I think also some sum checking of files.

Anyway this is "stage1" part code inside my open method.
And I know it's crappy code, but I quickly build this and I didn't have time for cleanup yet
MpakObject is just Object which contains information about those "block" seek location,compressed and uncompressed sizes.
fileContent is Map<String,MpakObject> where I store all index information with filename as key
loc_pointer I calculate seek position for each uncompressed blocks.

Code: Select all

...
ByteArrayOutputStream stage1 = unCompress(null,null);
ByteBuffer indexes = ByteBuffer.wrap( stage1.toByteArray() ).order(ByteOrder.LITTLE_ENDIAN);
byte line[] = new byte[0x11c];
long loc_pointer = fileChannel.position();
while ( indexes.hasRemaining() ) {
indexes.get(line);
ByteBuffer bbline = ByteBuffer.wrap(line).order(ByteOrder.LITTLE_ENDIAN);
String filename = new String(line).split("\0")[0].toLowerCase();
fileContent.put(filename, new MpakObject(loc_pointer,bbline.getInt((0x11c-8)),bbline.getInt((0x11c-16))));
loc_pointer+=bbline.getInt((0x11c-8));
}
...

So yes, it's ugly ... and if those are really "long", then should read 0x11c minus two long and then just getLong() for both sizes

[silakka]

Seems that index have plenty more data .. current working version, though (?) are just guess what those really are.

Code: Select all

{
byte filename[] = byte[256];
int unixtimestamp;
int attribute_count(?); // .. this value is always 4 ..
// attributes?
int uncompressed_seek; // perhaps Gamebryo or Mythic have virtual filesystem which might automatically uncompress whole mpk file content when loading or something.
int uncompressed_size;
int compressed_seek; <- absolute file seek = this + end of stage1
int compressed_size;
//
int uncompressed_filesum(?); // value seems to be +/- integer .. so filesum might be option here :P
}