What's new

Metroid Prime .pak format?

Elpenguino

New member
Is there any way to extract the files from within these .pak files? Attempting to extract files manually with a hex editor has been nothing but a pain so far.

so far, I've noticed that the first bytes in each one is 00 03 00 05 00 00 00 00 00 00 00...
then a byte containing the number of entries...
 
Last edited:

thakis

New member
groupz said:
Hmm... thakis might be of help. He's the master of GameCube file formats. :D

Who could resist these kind words... ;-)

I've taken a look at metroids pak files. I understand the header well enough to write a program to split a pak file into several files. Maybe I'll post it in the next few days, but it's probably not of much use because the files contained in a pak are probably in some custom format as well.
 

thakis

New member
I don't have the time to continue this, though, because I want to continue to work on my bmd viewer.

If anyone wants to continue working on this, tell me...here's a list of what I've done so far:

- A .pak extractor that splits a pak file into all the files contained in them. Some of the contained files are compressed, a decompressor is still needed.
- A tool to convert a metroid texture file (.txtr) to a super mario sunshine texture file (.bti) (which can then be converted to a dds file with another tool).


Interesting things left to do:
- A metroid model viewer (.cmdl viewer)
- A metroid level viewer (.mrea)

Viewers for about 25 other file types.
 
Last edited:
OP
E

Elpenguino

New member
thakis, if you would...could you email me the source and any data you know about? You should still have my email address... Thanks in advance.
 

thakis

New member
I'll post everything here, if someone else wants to to take a look...

pak file format
-------------

The pak file format starts with a file header and a list that stores file name entries for some of the files in the pak (not for all). After that, there's a file header for each file stored in the pak file. This header stores the type of a file (called 'tag' in the source, for some reason it's stored in the file name entries as well), a unique identifier for this file (if the file has a name in the filename table, then the name has the same id), where in the pak this file is stored and a flag that says if the file is compressed or not (I'm not completely sure on this - but it's quite likely. Files which don't have this flag set look "normal" in a hex editor, files which have this file set look "compressed").

mpakdump takes a pak file and extracts all files found in it. Files are not decompressed, though - you can see in the filename if a file is compressed (compressed files start with 1, uncompressed files with 0). The filename table in the pak file is ignored.


File types
---------

There a several file types in a pak file. .txtr files are texture files. mtexdump takes an uncompressed (!) txtr file and converts it to a bti file (that's the image format used by mario sunshine, it required the least amount of code to convert to this format. You can use btidump to convert bti to dds, which is supported by most image viewers).



Here's a list of the other file types together with some notes:

STRG - strings (unicode or japanes shift-jis)
CMDL - model
TXTR - texture
CSKR
HINT
FRME
ANCS
ANIM
AFSM
DGRP
EVNT
FONT
CINF
MAPA uncompressed files start with 0xdeadd00d
MAPW uncompressed files start with 0xdeadf00d
MLVL uncompressed files start with 0xdeafbabe
MREA - level geometry, uncompressed files start with 0xdeadbeef
PART - particles?
PATH
SCAN
SAVW
SWHC
WPSC
ELSC
DPSC
CRSC
DUMB
CTWK - tweak
CSNG - midi data


Stuff to do:
- write a decompressor for the compressed files
- write viewers for the more interesting file types (mrea, followed by cmdl imo)


EDIT (three months later ;-) ): I wrote a decompressor for the compressed files, it is attached (mdecomp20051222.zip, source included). It takes a compressed file and decompresses it (if the input file is called "1_....", the output file is called "01_....").
 
Last edited:
OP
E

Elpenguino

New member
here's a few formats from metroid prime 2 that may also be in metroid prime:
CLSN
CSPP
PLTT
ANMS
MADF
SAVA
SPSC
SRSC
DCLN
AGSC - Scan data?
ATBL
HMAP
PTLA
STLC
EGMC
RULE
FSM2
MAPU

also...that texture converter doesn't seem to work with metroid prime 2. it keeps producing textures that are either 128 bytes or more than 10 MB in size. I do not have a metroid prime iso at the moment, so I cannot compare the formats myself.
 

thakis

New member
HMAP - probably a height map and similar to .ymap in sms
FSM2 - sounds a lot like finite state machine ;-)
MAPU - probably similar to MAPA and MAPW (what are the first 4 bytes in an uncompressed file?)

Be sure that you only give uncompressed txtr files to mtexdump...(I don't have m2, so I can't take a look either ;-))
 
OP
E

Elpenguino

New member
MAPU begins with 0xABCD EF01.
there's one in GGuiSys.pak that contains strings such as "Sand", "Swamp", "Cliff", "TempleHub", and "TempleInt".

oh, and none of the textures seem to work. either they're all compressed, or they use a different format...
 
OP
E

Elpenguino

New member
alright, I never noticed that. so the uncompressed textures do indeed work with the program. heh...
 
OP
E

Elpenguino

New member
interesting note:
uncompressed .RULE files begin with the string 'RULE'
uncompressed .SCAN files begin with the string 'SCAN'
uncompressed .FONT files should begin with the string 'FONT'
uncompressed .CMDL files should begin with 0xDEADBABE.
uncompressed .MAPU files begin with 0xABCDEF01
uncompressed .SAVW files begin with 0xC001D00D
uncompressed .STRG files begin with 0x87654321
uncompressed .PTLA files begin with 0xDEAFBEEF
uncompressed .MREA files begin with 0xDEADBEEF
uncompressed .MLVL files begin with 0xDEAFBABE
uncompressed .MAPW files begin with 0xDEADF00D
uncompressed .MAPA files begin with 0xDEAFD00D
that's all that I've found so far.
 
OP
E

Elpenguino

New member
as of right now, none.

but eventually, the format will be figured out and a viewer will be written.
 

DarkTitan

New member
Elpenguino said:
alright, I never noticed that. so the uncompressed textures do indeed work with the program. heh...

so the files that start with a 1 are already compressed (how can i view the texture if its already compressed)? Does this mean the program that thakis posted will not work with these. also will the bti dds converter program work on a compressed file (the files starting with 1, then put into the bti converter program)?
 
OP
E

Elpenguino

New member
all files that begin with 1_ use an (as of now) unknown compression format. there is nothing we can do with these right now.

so no, textures that begin with 1 cannot be used with that texture converter.
 

SarahHarp

New member
Just found this thread today, because just recently I've gotten into cube emulation, because I wanted to see if I could get data out of the Prime games.. and appearnly it's possible.. kinda. So I'm just wondering if anyone is still working on this?
And I would LOVE to help.. only thing is that am not too sure on how to make programs that read unknown files. Though I have made programs before (heck, I even make video games.) so... yeah.
I've also been dieing to have the samus model from this game.. ho man..! So if anyone has gotton the CMDL file cracked please inform me : )

-Sarah
 

thakis

New member
Hey Sarah, you could try to reverse the CMDL format yourself. If you're experienced with 3d graphics, it's really not that hard. Get yourself a hex editor (I use frhed with some patches) and look if you can find a small (uncompressed) CMDL file. Check if you can see some byte blocks that look like floats, this could be coordinates. Write a program that reads theses floats and displays them as points - repeat until it looks correct. Then get back to us ;-)

I did the same with super mario sunshine files, search the "szs format explained" thread for bmdview2 + source and take a look at vtx1.h/cpp to see how mario stores vertex data - there really is not much to it.
 

Top