All Activity

There is a "thanks button" (just in case you didn't know).

02020201 is a texture packaging format that contains multiple mip blocks. The file header has the texture type, mip number, width and height. This game uses astc most of the games. The encryption is EZST and ZZZX, the installation package uses resource as its name, and the hot update uses patch as its name (this is the same in almost all Messiah games) There are multiple versions of the index data, a version without hashed names, and a version with hashed names, this game is the latter Resource and patch are the same. Patch will re-update some of the resource's old assets when updating. Patch uses a database format, which contains the hash key owned by the resource, file location, offset, length, and some unavailable network data values, such as file id, file size, whether it is metadata, etc. These data are associated with the file list. The file list is XOR encrypted. You can download the resource from the network by id, or obtain it locally by offset and length. There should also be a repository file that stores the conversion from uuid to actual name, but I never get

After reading your reply, i'm not sure if you mean morphs which allow to make a new character from universal face, or facial expressions of one existing character. Also no, i dont know a way to get custom charaters made in character creator because the process is complicated and includes 3 source head meshes and a lot of modifications upon it.

there is a list on retools github

How did you rip the files without a list?

Thank you so much! and why does it detect .cfg files in the same folder as the .cmf files? can't you change it to load the .cfg files first? also add this .cfg template to your repository cfgtemplate.zip

There's a PSP game in the same series that uses a similar 3D model format, but it's simpler, so it might be easier to visualize things in them. Tenchu PSP.zip

oops sorry about that, i used retool to extract the .paks and those files you see dont work with alphaZomega's noesis script, so im kind of at a loss

You've created a duplicate topic for the same thing, so I've deleted the other one. Please give more explanation on what you've tried with the files.

The functions reads the big file as sectors as mode 2352 resuming. it will extract millions of file. maybe some with better idea can help u

i used retool to get the files out, here are the raw files and textures sample.rar

You can get them as captures, but you won't get any armature. Xemu + Renderdoc is an old way of doing it as it is and the more known one. You need to do a lot of fixing to even get it to work properly and the texture fix just requires the alpha channel to be disabled/removed. Piss easy.

Have You Guys Ever Tried Render Doc On Xemu??? Experiencing A Shader Problem Right Now While Running Render Doc + Xemu On OpenGL Backend, Here Is The Photo. I Did A Strategy, (Which Requires Very Good Capture Timing) I Did Grab Character Textures, But This Strategy Feels Hard During Switching Vulkan To OpenGL And Capturing A Very good Time Before It Crashes, Is There Anything I Can Do To Fix This??? No Character Models Yet Though... Note: Some Of The Textures Are Transparent For Some Reason... Like Bugger Lugs Texture (MAIN PROBLEM IMAGE WITH AN X)

You may be able to find the .RBM files, but you can't import them into Blender because Blender doesn't have a script that works well yet for such a thing. Über Winfrey is working on one, but there's no estimate for when it'll be finalized or if he'll even release the models and/or script. Let the man cook till he's ready. Opening an ISO is one thing, but figuring out file formats is another. Just wait instead of being impatient and overly eager.

Yes, RenderDoc have problems sometimes with other games I had no luck extracting models from Far Cry 3 for example but this is because those games are based on DirectX 9 and RenderDoc supports only: • DirectX 12 • DirectX 11 • Vulcan • OpenGL 3.2 <- Core profile • OpenGL ES 2.0-3.2 <- ES Versions

Helllo, I saw your posts before, I can definatelly try and reverse engineer the game extraction but I am not really sure about the repacking, I'll still try to do someting with it just let me know and we will mine some data infos together.

Your guess is as good as mine. Though I don't think it's an SMD as that's a format for a totally different engine. Inquisition it was easier to see where they were since it was straight up a MorphTargets file.

LINK EXPIRED, pls send it again 😞

You are broadly correct, but there are a few important nuances worth clarifying based on deeper analysis of the container behavior. Structure-wise, Resource*.mpk and Patch*.mpk indeed follow the same container format, and both are indexed through mpkinfo / mpkdb entries containing FileID, Size, Offset, and MpkIndex. Semantically, however, they behave very differently: Resource*.mpk act as the base asset pool. Patch*.mpk act as overrides, where a matching FileID replaces the corresponding entry from Resource*.mpk. While both containers use the same compression stack (LZ4 / ZSTD / LZMA, with EZST being AES-encrypted), Patch MPKs are generally much closer to “flat assets”, whereas Resource MPKs contain a significant amount of indirection and shared data. The presence of: a fixed 56-byte header (02 02 02 01 …) or the size + size × 20 bytes header is correct, but these headers often represent logical structures or lookup tables, not necessarily standalone files. A critical detail is that in Resource*.mpk, the Size field frequently represents a logical or expanded size, not the physically stored payload size. Treating it as a raw read length will materialize padding, alignment, and shared blobs that are not real assets. This explains why naïve extraction pipelines can easily inflate a ~2 GB Resource*.mpk set into tens of gigabytes: the extractor ends up writing engine metadata, alias entries, and shared blocks as if they were unique files. In short: ✔ same container format ✔ same compression/encryption stack ❌ not the same extraction semantics Patch MPKs are mostly straightforward; Resource MPKs require additional validation (deduplication, strict decompression checks, and asset-type verification) to avoid false positives and artificial size inflation.

anyone who have do extracted the mpkinfo? help me please

I've been looking up things about the Disney's Dinosaur games and the PS1 version seems to have all data packed into a file called BIGFILE.CAT The only thing I was able to do was view the voices of the characters in jpsxdec and I've tried looking around in Tiledggd but can't figure out the palette If anyone has an idea of how I can extract the assets such as the textures it would be helpful https://drive.google.com/file/d/1sREyna187mDIzmG6dsxgOZstAbs2TXRz/view?usp=sharing

Resource*.mpk and Patch*.mpk have the same structure. Resource*.mpk are the original files, Patch*.mpk are the modified files. A file from Patch*.mpk with the same FileID replaces a file from Resource*.mpk. Information about files (FileID, Size, Offset, MpkIndex) is stored in mpkinfo/mpkdb. The files are compressed in various formats. EZST is additionally encrypted. Some files have a fixed header of 56 bytes (0x02, 0x02, 0x02, 0x01, ...), followed by the body the file. Some files have a header "size (4 bytes) + size x 20 bytes".

Sadly, I'm afraid not. I tried plugins for Blender, Noesis, Softimage and Lightwave3D itself. Nothing was able to import those files. Checking them with hex viewer show they lack headers that typical Lightwave3D models have.

ive seen that someone got it to work somehow, they ripped diana and her walking and picking up animation