All Activity

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?

I've used this software, and it seems to only work with certain image APIs?

fun

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.

*.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.

Please upload original data. Not converted.

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

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 ? 😄

I didn't check that. I merely showed that the "gani to json" problem was not a problem.

Here is one

Basically, I'm patching the smali code and can't solve the problem with the textures because I don't know if it's a problem with the native code or the textures themselves.

Please upload some samples.

so what can you do? can you extract pes 2017 and pes 2020 exlusive celebrations and add them to pes 2019?