All Activity

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

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

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.

this tool might unpack demo, but non demo version not released

animewwise just closes instantly if you try it on there. Regular wwise works https://github.com/mortalis13/Wwise-Unpacker BeyondToolsMod-net9.zip

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

I think I’ve seen this format before I think this is Lightwave3D model format

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

Any news ??

Yeah if you are fan of defining almost 800 resource types then go for it. I have faith in you...

Is there tool for the game on GitHub, but the list part still missing

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?

https://store.steampowered.com/app/3357650/PRAGMATA/ its on the re engine and has the same .paks as the re engine

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

Here the Rle logic. Vertical: std::vector<uint8_t> decompress_type1(const std::vector<uint8_t>& data, int width, int height) { if (width <= 0 || height <= 0) return {}; // Aloca buffer de saída (W * H) // Usamos long long para evitar overflow no calculo do tamanho se as dimensoes forem grandes size_t total_pixels = (size_t)width * (size_t)height; std::vector<uint8_t> output(total_pixels, 0); // Coordenadas para escrita vertical (x, y) int x = 0; int y = 0; size_t data_pos = 0; size_t data_len = data.size(); // Helper para escrever pixel na geometria correta (Vertical: Top->Down, depois Left->Right) auto write_pixel = [&](uint8_t val) { if (x < width && y < height) { output[y * width + x] = val; } y++; if (y >= height) { y = 0; x++; } }; while (data_pos < data_len) { // Se já preencheu a largura total, para if (x >= width) break; uint8_t cmd = data[data_pos++]; if (cmd == 0) break; // Marcador de fim // Verifica bit 7 (0x80): Raw Copy (Literais) if (cmd & 0x80) { int count = (cmd & 0x7F) + 1; for (int i = 0; i < count; ++i) { if (data_pos < data_len) { write_pixel(data[data_pos++]); } } } // RLE (Repetição) else { int count = 0; // Verifica bit 6 (0x40): Contagem estendida (2 bytes) if (cmd & 0x40) { if (data_pos < data_len) { // Remove flags e combina com próximo byte (Little Endian) count = ((cmd & 0x3F) << 8) | data[data_pos++]; } } else { count = cmd; } count += 1; if (data_pos < data_len) { uint8_t val = data[data_pos++]; for (int i = 0; i < count; ++i) { write_pixel(val); } } } } return output; } horizontal std::vector<uint8_t> decompress_type3(const std::vector<uint8_t>& data, int width, int height) { if (width <= 0 || height <= 0) return {}; size_t total_pixels = (size_t)width * (size_t)height; std::vector<uint8_t> output(total_pixels, 0); size_t pos = 0; size_t data_pos = 0; size_t data_len = data.size(); while (data_pos < data_len && pos < total_pixels) { uint8_t cmd = data[data_pos++]; if (cmd == 0) { break; // fim dos dados } if (cmd & 0x80) { // Literais size_t count = (cmd & 0x7F) + 1; for (size_t i = 0; i < count && data_pos < data_len && pos < total_pixels; ++i) { output[pos++] = data[data_pos++]; } } else { // Repetido size_t count = 0; if (cmd & 0x40) { // Contagem estendida if (data_pos >= data_len) break; count = ((cmd & 0x3F) << 8) | data[data_pos++]; } else { count = cmd; } count += 1; if (data_pos >= data_len) break; uint8_t val = data[data_pos++]; for (size_t i = 0; i < count && pos < total_pixels; ++i) { output[pos++] = val; } } } return output; }

I found the format documentation with version 700. https://github.com/mp3butcher/Cal3D/blob/fcd00f2504e222f112e20aa61fa7eb4fee7e9ea7/cal3d/tools/converter/fileformats.txt (comparing it to the latest one, they changed stuff about animations and added morphs)

This is the font game uses.

[Mark it as solved] So actually all you need to do is to use your infamous vtec tool properly, this tool works but only under certain conditions: You must have Windows 7 intalled (VM is enough) You must have VC Runtime (all in one) installed You must disable ASLR protection (MoveImages = 0) You must obtain a reloaded .exe version from the "Crack" folder, or from the attachment You type cmd in path bar in the explorer, then you type "vtex.exe [Path to reloaded.exe] C:\" <=It doesn't matter which path you use as long as it points to the reloaded .exe and path doesn't have spaces and minuses virtualtextures.zip

if you've already got the pck files from beyondtools. Try dragging the pck files from the main folder to this python script. Though this only partially extracts the language voicelines but it does extract almost all the music and sound effect files pck_decrypt.py

1. FORMATO DEL ARCHIVO SCRIPT.PTD: Firma de cabecera: "PETA" (50 45 54 41) Tamaño total: 1,728,512 bytes Estructura: Cabecera 32 bytes + SBOX 256 bytes + Datos cifrados SBOX: 256 bytes en offset 0x20-0x11F Datos cifrados: 1,728,224 bytes restantes DESCIFRADO COMPLETO: Algoritmo MIPS con SBOX de 256 bytes Parámetros óptimos: t3 = 0x02, bloques de 288 bytes script.ptd → script.dec (1,722,223 bytes) 2. DESCOMPRESIÓN YKLZ/LZSS FUNCIONA: 249 secciones YKLZ encontradas Formato: "YKLZ" + param_byte=0x0A + tamaño descomprimido + datos LZSS Descompresión exitosa con shift=2, mask=3 3. TEXTO REAL EXTRAÍDO: 純ﾛﾏ = "JUNROMAN" identificado Texto japonés en Shift-JIS encontrado Estructura híbrida: texto + comandos + padding 4. FLUJO DEL JUEGO DESCUBIERTO: text script.ptd → Descifrado → YKLZ/LZSS → Script Binario ↓ fcn.0010e048 (Intérprete) ↓ fcn.0010ded0 (Parser) ↓ fcn.00119fc0 / fcn.0011a0ec (Diálogos) ↓ fcn.00106800 (Configura contexto) ↓ fcn.001068d0 (Renderiza texto) ↓ fcn.0016e400 / fcn.0016e4a8 (Dibujo GPU) 5. ESTRUCTURAS IDENTIFICADAS: c struct TextContext { void* gpu_buffer; // 0x00 uint32_t text_ptr; // 0x04 (¿puntero al texto?) uint32_t param1; // 0x08 (¿posición X?) uint32_t flags; // 0x0C (¡t6! 0→fcn.0016e400, ≠0→0x16e458) uint8_t font_index; // 0x10 (índice de fuente) }; ❌ PROBLEMA PRINCIPAL (LO QUE FALTA): LOS SCRIPTS DESCOMPRIMIDOS NO SE INTERPRETAN CORRECTAMENTE Ejemplo de datos descomprimidos: text 純ﾛﾏ####@###ｼg##@###ﾄ###4.##X)##ｲ*##4... Problema: Cuando decodificamos como Shift-JIS, obtenemos: Hay texto japonés real Pero los bytes de comandos se interpretan como caracteres extraños... Estructura probable de los scripts: text [TEXTO Shift-JIS] [PADDING "####"] [COMANDO "@" + 3 bytes] [MÁS TEXTO]... Lo que debería pasar: Parser detecta @ (0x40) → Interpreta como comando Lee 3 bytes siguientes → Parámetros del comando Procesa texto Shift-JIS → Caracteres de 1-2 bytes Salta padding # (0x23) → Bytes de alineación (segun elf?) ------ EDIT: SCRIPT.PTD (1.7MB) → 249 secciones YKLZ → Archivos binarios estructurados 2. CABECERA UNIFICADA (16 bytes): Todos los archivos YKLZ comparten la misma cabecera: Sección 0x00-0x3F: CABECERA Y METADATOS 0x00-0x0F: Cabecera fija 0x10-0x2F: Offsets/parámetros del script 0x30-0x3F: Flags/configuración Sección 0x40+: DATOS DEL SCRIPT LOS ARCHIVOS YKLZ CONTIENEN: Scripts compilados (bytecode que ejecuta fcn.0010e048) Referencias a diálogos (IDs/offsets, no texto) Lógica de juego (condicionales, saltos, etc.) Parámetros de visualización (posición, fuente, timing) LOS DIÁLOGOS REALES ESTÁN EN???? SOUND.PTD (610 MB) → MÁS PROBABLE (voces + subtítulos sincronizados) ?????

anyone already extracted these .mpk's ? i really wanna badly get the .wem's! i gotta get those music that aren't included in the osts!

Would that be in an SMD or FacePoser file?