All Activity
- Past hour
-
erickkingarmy14 joined the community
- Today
-
chara39020 joined the community
-
ali737370 joined the community
-
Arknights Endfield Closed Beta Wwise *wem extract
NoNarluire replied to NoNarluire's topic in Audio file formats
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? -
Grason Balls joined the community
-
Spitfire83 joined the community
-
odin89 joined the community
-
ribbon46 joined the community
-
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!
-
Kus4bi joined the community
-
tina joined the community
-
Smirkles joined the community
-
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
- Yesterday
-
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)
-
[PS3] Zombie Apocalypse **The edited DDS file is not working**
h3x3r replied to yerayay1's topic in Graphic file formats
-
[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
-
chubbiestlando started following michalss
-
Arknights Endfield Closed Beta Wwise *wem extract
Chiu replied to NoNarluire's topic in Audio file formats
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 -
BillyBnMOfficial changed their profile photo
-
[PS2] Junjou Romantica Koi no Doki Doki Daisakusen PTD file extraction
ninoochan replied to Pato's topic in Game Archive
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?
- Last week
-
I've used this software, and it seems to only work with certain image APIs?
-
I also noticed that the file spec linked above for .cmf files is different to the samples provided, i.e. the samples are earlier versions of the format and don't match the spec exactly. Some of the samples are versions 700 and 1100.
-
pororosh2_5 started following MarvelVR-Win64-Shipping.part01.rar
-
[PS3] Zombie Apocalypse **The edited DDS file is not working**
h3x3r replied to yerayay1's topic in Graphic file formats
*.abc is font map. Maybe you can add some characters in it. Now for the texture. Original is 32 bit rgba, yours is DXT5 which is not exact as org. Also i noticed you didn't change alpha channel of the char which is crucial for correct display. -
Oh, my bad should have backread. I’ll make it when I’ll have some more time, if i do ill definitely link it here
-
edit: if you thought (like me) to get some models for free after having installed ATaleInTheDesert: forget about it! It's a subscription based game.
-
I’d make one if this format was actually used somewhere
-
Good luck. Well, first I've to admit I don't like the mesh format, so I'm biased. I don't understand the logic how vertex blocks are built in cally_head.cmf. After getting a stop condition assembling the vertices was not too hard but I didn't get the face indices applied. So I used meshlab for building the mesh.
-
Nya222 started following campcomp0924
-
Please upload original data. Not converted.
-
Eilde changed their profile photo
-
Eilde started following Garou Golden Knight - PS2 Almost fully modifiable except animations
-
This is my first time posting on this website so please forgive me for not formatting this properly if such I made a mistake. Recently I have been reverse engineering a lot of different games for various old consoles or obscure hardware/software. Some due to clients "Paid commissions", other due to personal curiosity. List is rather large. Recently, I came across the game Garou Golden Knight. I was asked to make tools and a system as to where people could easily "mod" the game. So far, I am about 80% there. Packing/repacking tools work. Decompressing the files is required before any file editing, etc. This game like many others uses Renderware for models, animations, etc. You could use the dragonFF model importer for the models though expect issues. Most models use a plethora of static parts "which is common with PS2 games using renderware among others" so you are not going to get a full single solid model but many pieces with a simple underlaying body and armature. Some animations are done literally through text based files and "in game load up" to attach some static models to specific bone/location/orientation. games uses a lot of txt based files making it extremely easy to mod. I have a client begging me to finish tools for this game which I am not fully able to and out of frustration about to tell them to pike off. The animations for this game use a vendor I am not aware of for Renderware flavours. The format is the common rwanm but not the standard vendors/flavours like Climax, Eighting, etc.... For those that don't know about rwanm I will elaborate a little about these in particular. They are RenderWare Animation chunks (chunk id 0x1B). The version is 0x100. With these animations, they behave like expected (multiples of 16 pointing backwards). Others clearly do not. Many offsets point forward to keyframes that haven’t been read yet (e.g. 1248 when we’re only at keyframe 76, and 1248/16 = 78). There are also huge values way beyond keyframes_num * 16. If you were to try known renderware animation importers, they will all give errors or assign a wrong vendor to these. Example being ValueError: 65226 is not in list. Most of the time values, when interpreted as plain floats, are nonsense (gigantic positive/negative values, denormals, etc.), with only some near 0 or a few small fractions looking “reasonable”. These .rwanm are not the same “TM compressed rotation” variant of any vendor I have messed with in the past or for any known blender/noesis/3ds max importer. It’s almost certainly using game-specific compression/packing on top of the base RW structure. If you try the well known blender animation importer for renderware it will try and associate these animations with trashmasters and only give errors due to misinterpretations. This game has been giving me more trouble than any other renderware game I worked on. I spent 3 days straight now and still have made 0 progress while simply doing a whack-a-mole attempt at making a valid working importer for the animations. If I can get help with these animations I could finish the modding suite for this game. With this post I am uploading a rar file that has two animations. One small, one average, the texture file and the base skeleton/body for one of the characters these animations belong to. At this point, with the amount of frustration I have had with this game... If I had some help with the animation format to successfully be able to get them into blender or even noesis.. I would then add that to the tools and make them public. This game was/is more difficult than the King of Fighters Maximum Impact series with their animations..... If I could get help with this I would be more than willing to release tools for many other games that have no public tools nor have a active modding scene. I know people like to steal from these games, that isn't the point of this. My work is for modders only. While I hate writing this.... If you are replying only to try and get assets from this game, that won't happen. Any help with this would be most appreciated. I can't spend weeks on this and have too many other jobs to complete. I will try to reply when possible to those offering advice/information or perhaps even a solution. Thank you in advance even if you just want to poke at the animations. Something is better than nothing. Garou test files for public.rar
-
- animations
- modding
-
(and 1 more)
Tagged with:
-
Stumbled on this thread and it's very cool to see old Rare games being explored this way 🙂 I have an old Kameo Elements of Power prototype iso from the first Xbox (here: https://hiddenpalace.org/Kameo:_Elements_of_Power_(Oct_1,_2004_prototype ) and I would like to explore / extract assets from it, but my knowledge of reverse engineering is very limited. There is this tool that kind of works with the Xbox 360 version of the game : https://github.com/NCDyson/RareView However, it does not with the OG Xbox ISO. The two ISOs are very similar though as the gamefiles are packed in .lvl files. But it seems they're encoded differently, or their headers are different, I'm not really sure. I was wondering if Conker and other OG Xbox Rare games were using that file format too ? I'm eager to see how your tool is going to evolve, do you think it could be used to browse the prototype ISO as well ? 😄
-
PES 2019/eFootball PES 2021 .gani/.mtar file
shak-otay replied to Aoba's topic in Animation file formats
I didn't check that. I merely showed that the "gani to json" problem was not a problem. -
EyeToy Play - ETI Files
randomuser142668 replied to randomuser142668's topic in Graphic file formats
ResHax.com: Empowering Curious Minds in the World of Reverse Engineering
Delving into the Art of Code Unraveling: ResHax.com - Your Gateway to the Thrilling World of Reverse Engineering, Where Curiosity Meets Innovation!