Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. 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.
  3. LINK EXPIRED, pls send it again 😞
  4. 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.
  5. Today
  6. anyone who have do extracted the mpkinfo? help me please
  7. 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
  8. 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".
  9. 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.
  10. ive seen that someone got it to work somehow, they ripped diana and her walking and picking up animation
  11. Findings Summary – MPK Patch vs Resource Analysis After an in-depth analysis of the MPK archives, I have identified clear structural and functional differences between Patch*#.mpk files and Resource*#.mpk files. The results so far are outlined below. ------------------------------------------------------------------------------------------------ 1. Patch*#.mpk – Partial Transparency, Direct Asset Access Patch*#.mpk archives use a different internal layout compared to Resource*#.mpk. Although Patch archives are compressed and encrypted using the EZST mechanism, the embedded files: retain near-original offsets preserve recognizable internal structure As a result: ~99% of audio assets can be recovered successfully a subset of Lua scripts is readable after decompression Additionally: I was able to extract several image assets from the latest Patch3100.mpk, confirming that non-audio assets are also present and partially accessible in Patch archives. Conclusion: Patch*#.mpk files act more like delta/update containers, prioritizing fast access and minimal transformation of asset payloads. ------------------------------------------------------------------------------------------------ 2. Resource*#.mpk – Multi-Layer Obfuscation Resource*#.mpk files are also: compressed and encrypted using EZST However, unlike Patch archives: extracted payloads appear to be re-encrypted, recompressed, or further transformed file contents are likely: wrapped in an additional encryption layer compressed again or stored in a reversed / custom-serialized layout Due to this: no successful decryption or reconstruction of Resource assets has been achieved so far standard tools and known compression signatures do not match Conclusion: Resource*#.mpk archives are designed as primary asset containers, with significantly stronger obfuscation to prevent direct extraction. 3. Audio Extraction & Conversion Tooling Ravioli Game Tools proved to be sub-optimal for this specific pipeline: inconsistent parsing of Patch audio assets unreliable WAV output in several cases Instead, I switched to vgmstream, which: correctly parses the recovered audio data produces clean, fully functional WAV files handles the recovered codec structures more reliably 4. Current Status & Achievements ✔ Successfully decompressed and decrypted all Patch*#.mpk archives ✔ Recovered and converted: audio files → valid .wav selected Lua scripts selected image assets ✔ Audio conversion verified and validated Below is a proof-of-concept output, demonstrating a successfully recovered and converted audio file: 🔊 Converted WAV audio (proof): Google Drive Download WAV File 5. Next Steps (Ongoing Research) Reverse additional transformation layers in Resource*#.mpk Identify: secondary encryption keys compression chaining possible stream or block reordering Automate Patch vs Resource handling as two distinct pipelines
  12. Hi, sorry if this is a very basic question. Is there a way to edit the text files in Alan Wake 2? I honestly don’t know much about video game programming or modding, so I’m a bit lost. Any guidance would help.
  13. this tool might unpack demo, but non demo version not released
  14. Yesterday
  15. animewwise just closes instantly if you try it on there. Regular wwise works https://github.com/mortalis13/Wwise-Unpacker BeyondToolsMod-net9.zip
  16. Have You Guys Tried Iso Buster??? I Was Digging In the Conker .ISO File, And Found .RBM Files In The Zpackage. I Can See In Über Winfrey July 10th post, I can See, It Says, "Load RBM" So, Doesn't That Mean I Can Extract The Iso Buster .rbm Conker File And Import It In Blender? I Have Not Been Through Collage, But I Am Pretty Good At Ripping Games, But Have Never Experienced Rare Wares Game Engine Software And Weird Formats. You Guys Could Try Iso Buster So You Can Import The Rbm's And Rba's
  17. I think I’ve seen this format before I think this is Lightwave3D model format
  18. here you go https://github.com/ExIfDev/Cal3d-Noesis/blob/main/fmt_cal3d.py currently didn't bother to add support for animations and morphs but if there is need to ill add them
  19. Yeah if you are fan of defining almost 800 resource types then go for it. I have faith in you...
  20. Is there tool for the game on GitHub, but the list part still missing
  21. Thanks for the script, and I understand it's designed for BeyondTools? I tried using script on .chk files (I downloade full package resources ArknigtsEndfield) and then opening the *.pck file using AnimeWvise, but AnimeWvise simply closes without any errors. And since the BeyondTools link from your post above no longer works, I understand I need to build a project from this resource: https://git.crepe.moe/rfi/BeyondTools.git?
    Hi, I’ve successfully extracted the level data using your tool and currently have: One transform file that contains the transforms (position / rotation / scale) for all assets in the level One level FDM file, which I assume represents the level / map data At this point, I’m not sure what the correct workflow is to: Reconstruct the full scene layout Export or import the complete level (including terrain) into Blender So my questions are: What is the intended way to reconstruct the scene from the FDM + transform data? Is there a recommended export method (FBX / OBJ / custom script) to bring the full level into Blender? Does the tool support terrain / heightmap extraction, or is the terrain stored separately? Are there any helper scripts or example pipelines for importing the level into DCC tools like Blender? Any guidance on the correct workflow would be greatly appreciated. Thanks a lot for your work on this tool!
  22. https://store.steampowered.com/app/3357650/PRAGMATA/ its on the re engine and has the same .paks as the re engine
  23. With the Killzone crossover with Helldivers 2 being brought back, it reminded me of how I wanted to get the Killzone 2 (and maybe 3) models, getting access into the files isn't hard, typical PS3 stuff. One big PSARC file, and that's about it. Extracting it leads to getting the .core files that seem to contain everything (to my knowledge at least the models, and likely the textures, but the file sizes are a bit small), which later versions of the engine (Horizon Zero Dawn, Death Stranding, Until Dawn) seem to still use, although they've been certainly upgraded since this game. id-daemon did a tool for the PS4 Killzone game, Shadow Fall, but unfortunately that tool, nor the one made for Until Dawn, work with this game. Biggest problem seems to be a lot of packages reference each other. I'm a huge fan of the Killzone designs, and it's pretty surprising to me that over all these years no one has really made a true extractor for the older games, I'd love to work with these models but all that's really out there right now is random posts online with unrigged models and no real sources of where they came from. Due to the fact its PS3, I can't use Ninja Ripper, at least not to my knowledge. Hope I'm not annoying anyone with creating some topic every few weeks, but I figure if anywhere would be a good place to talk about this stuff, it'd be here. Archiving stuff is awesome, and being able to work with 3D assets is one of my favorite things, plus porting is my #1 hobby, I'm sure I'm not the only one out there who just enjoys exploring game assets. (Sorry for the external link here, I was having upload issues, even when trying to upload in a few parts I had problems) I'll provide a bunch of example files, of weapons, and characters, and the one and only reference I've found about this version for the model/texture formats from an oldish GitHub repo. https://drive.google.com/file/d/1rbuBPevvYP-XwiSDZSuL17t2g70YX9K0/view?usp=sharing https://github.com/headassbtw/Mantle
  1. Load more activity
×
×
  • Create New...