Leaderboard

I'm trying my best to make it load somehow

Actually the LZSS provide above, is wrong, for the files. I did the reverse enginner of the algorithim, Try the tool, see if the image get right TenchuWoH_DeCompressor.zip

There is the tool PS2JunjouUnpacker-decompressor.zip

I've just released new version of ImageHeat 🙂 https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.39.1 Changelog: - Added new Nintendo Switch unswizzle modes (2_16 and 4_16) - Added support for PSP_DXT1/PSP_DXT3/PSP_DXT5/BGR5A3 pixel formats - Fixed issue with unswizzling 4-bit GameCube/WII textures - Added support for hex offsets (thanks to @MrIkso ) - Moved image rendering logic to new thread (thanks to @MrIkso ) - Added Ukrainian language (thanks to @MrIkso ) - Added support for LZ4 block decompression - Added Portuguese Brazillian language (thanks to @lobonintendista ) - Fixed ALPHA_16X decoding - Adjusted GRAY4/GRAY8 naming - Added support section in readme file

The textures are compressed with ZSTD - just that type 0 means the whole file is not compressed. But there doesn't seem to be any encryption once decompressed - looks something like ETC format:

Thanks for some info from here and made a tool for unpacking and packing localize map files, if someone is interested in it. https://github.com/dest1yo/wwm_utils

It's been a while since this topic is up and i have found a way to deal with this: -Step 1: From the .farc files, use either the tool mentioned at the first post of this thread, or download QuickBMS and use the virtua_fighter_5 bms script i included in the zip file below to extract them into bin files. -Step 2: Download noesis and install the noesis-project-diva plugin (https://github.com/h-kidd/noesis-project-diva/tree/main , or in the included zip file) in order to view and extract the textures/models and use them in Blender or a 3d modeling software of your choice. KancolleArcade.zip

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

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

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

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

D:\88>py fgo_arcade_mot_parser.py --mot CHARA_POSE_SVT_0088_S01.mot --skl SVT_0088_S02.skl --bone arm_r --frames 100 0 0.000007 0.402854 0.002541 0.915261 1 0.000120 0.975284 0.052175 -0.214706 2 0.069035 0.000000 0.000000 -0.997614 3 0.000000 -0.276927 -0.000008 -0.960891 4 0.000000 -0.736034 -0.000022 -0.676945 5 0.000000 0.738174 0.000023 0.674610 6 0.000000 0.848413 0.000028 0.529335 7 0.000000 0.998036 0.000034 0.062648 8 0.000000 0.955551 0.000035 0.294825 9 0.000000 0.787267 0.000030 0.616612 10 0.000000 0.853046 0.000034 0.521836 11 0.000000 0.978375 0.000040 0.206837 12 0.000000 0.950974 0.000040 -0.309270 13 0.000000 0.988709 0.000043 -0.149846 14 0.000000 0.955742 0.000043 0.294205 15 0.000000 0.335155 0.000015 0.942163 16 0.000000 0.042013 0.000002 0.999117 17 0.000000 0.055729 0.000004 0.998446 18 0.000000 0.600873 0.000037 0.799344 19 0.000000 0.431736 0.000025 0.902000 20 0.000000 -0.474964 -0.000031 0.880005 21 0.000000 0.005943 0.000002 0.999982 22 0.000000 0.472832 0.000034 0.881153 23 0.000000 0.562161 0.000044 0.827028 24 0.000000 0.544627 0.000045 0.838678 25 0.000000 0.498805 0.000045 0.866714 26 0.000000 0.663745 0.000065 0.747959 27 0.000000 0.598301 0.000061 0.801271 28 0.000000 0.237227 0.000025 0.971454 29 0.000000 -0.314591 -0.000039 0.949227 30 0.000000 -0.813891 -0.000100 0.581017 31 0.000000 -0.989480 -0.000131 -0.144672 32 0.000000 -0.995146 -0.000143 -0.098406 33 0.000000 -0.920574 -0.000144 0.390568 34 0.000000 -0.220975 -0.000032 0.975279 35 0.000000 0.662326 0.000116 0.749216 36 0.000000 0.995018 0.000179 -0.099691 37 0.000000 0.960525 0.000182 0.278192 38 0.000000 0.592240 0.000118 0.805762 39 0.000000 -0.021210 -0.000011 0.999775 40 0.000000 -0.047665 -0.000008 0.998863 41 0.000000 0.314114 0.000081 0.949385 42 0.000000 0.421506 0.000118 0.906826 43 0.000000 0.740391 0.000225 0.672176 44 0.000000 0.996086 0.000322 -0.088392 45 0.000000 0.610455 0.000199 -0.792051 46 0.000000 -0.147819 -0.000063 -0.989014 47 0.000000 -0.758611 -0.000329 -0.651544 48 0.000000 -0.633201 -0.000271 -0.773987 49 0.000000 0.144974 0.000071 -0.989435 50 0.327163 0.016943 0.000008 -0.944816 51 0.000075 0.714520 0.031271 -0.698916 52 0.000000 0.231376 0.000223 0.972864 53 0.000000 0.589910 0.000409 0.807469 54 0.000000 0.814108 0.000585 0.580713 55 0.000000 0.510365 0.000383 0.859958 56 0.000000 0.119739 0.000083 0.992805 57 0.000000 -0.291270 -0.000258 0.956641 58 0.000000 -0.409780 -0.000399 0.912184 59 0.000000 -0.622229 -0.000662 0.782835 60 -0.000002 -0.941428 -0.001064 0.337213 61 -0.000002 -0.966760 -0.001144 0.255684 62 -0.000002 -0.940971 -0.001175 0.338484 63 -0.000002 -0.957375 -0.001293 0.288845 64 -0.000003 -0.922744 -0.001354 0.385411 65 -0.000003 -0.793428 -0.001291 0.608662 66 -0.000004 -0.998795 -0.001788 -0.049037 67 -0.000003 -0.836432 -0.001628 -0.548068 68 -0.000004 -0.931258 -0.001932 -0.364356 69 -0.000005 -0.993580 -0.002216 -0.113106 70 -0.000005 -0.983486 -0.002361 0.180970 71 -0.000005 -0.812511 -0.002115 0.582941 72 -0.000005 -0.710143 -0.002080 0.704054 73 -0.000006 -0.820454 -0.002625 0.571706 74 -0.000008 -0.999984 -0.003401 0.004570 75 -0.000007 -0.792709 -0.002817 -0.609593 76 -0.000002 -0.308776 -0.001126 -0.951134 77 0.000004 0.259678 0.001201 -0.965695 78 0.000009 0.733887 0.003312 -0.679263 79 0.000013 0.975185 0.004912 -0.221336 80 0.000014 0.997418 0.005142 0.071628 81 0.000013 0.998641 0.004884 0.051882 82 0.000012 0.999473 0.004623 0.032116 83 0.000012 0.999914 0.004360 0.012337 84 0.000011 0.999964 0.004096 -0.007446 85 0.000010 0.999622 0.003830 -0.027227 86 0.000009 0.998889 0.003563 -0.046997 87 0.000009 0.997764 0.003294 -0.066748 88 0.000008 0.996250 0.003024 -0.086474 89 0.000007 0.994345 0.002753 -0.106165 90 0.000007 0.992051 0.002481 -0.125815 91 0.000006 0.989368 0.002208 -0.145416 92 0.000005 0.986298 0.001934 -0.164960 93 0.000004 0.982843 0.001659 -0.184439 94 0.000004 0.979002 0.001383 -0.203846 95 0.000003 0.974778 0.001107 -0.223173 96 0.000002 0.970173 0.000831 -0.242413 97 0.000001 0.965188 0.000554 -0.261558 98 0.000000 0.959825 0.000277 -0.280601 99 0.000000 0.954086 0.000000 -0.299534

My best bet: edit: fail, at 0x1d934 there's only a copy of the mesh

You could check the MakeH2O_log.txt. If you find a structure like 12 4 4 4 4 4 (for example) the last "4 bytes block" might be alpha uvs (just a wild guess). edit: it's 16 8 8 4 4 here Try using 82ea3, 4 for uvs. Looks promising.

here you go : 0x09D01B34E843AC6BE08BD854B3CEDA0C4CA52281C08B02BF827F3ADA77173BCA

When you choose "uncompressed" the file size should be bigger than for a DXT5 file. I'd try some other tool, maybe Gimp, for testing.

hi need help ripping and reverse engineering the Geekjam, Toejam, and the Earl models from Toejam and Earl III for a animation. below are the .funk files (which is located in the bdl folder for some reason idk) and .bmt files for each character. files for toe jammin and fateral.zip

Found a bug with the python script. To the left is the wrist_r data from the .mot file. To the write is the data I got from exporting the .mot file to .csv. Maybe they are actually SUPPOSED TO BE this. I could be wrong. But am curious.

So here's pixel format for ps4. PF_DXT5 = 7 PF_DXT1 = 13 PF_BC7U = 22 PF_UNKNOWN = 2 not sure but can be RGBA

This file stores luac and dat data, so it cannot be processed using the unityfs split script. I wrote a new split script to experimentally disassemble the file content you provided and decompile the lua file. If you want to decompile please enable the -j parameter Basic usage (no decompilation) python pkg.py input.patch output_dir With decompilation (slower) python pkg.py input.patch output_dir -j For decompilation, please download unluac from other locations. After compilation, place the .jar file in the same directory as the script. Due to different compilation environments, errors may occur, so unluac needs to be compiled by yourself. pkg.py

I remember to make a request in your github about it. 👍 Somehow, we were not able to see these textures in ImageHeat, only after extraction and decompression. Anyway, for the Switch textures it seems to be an issue as h3x3r said above and I confirm it too. In the attachment you find all the textures in UNIFORM.TEX (including jersey-color) from the Switch version already decompressed. The stock texture file is in the Switch files in the first post (UNIFORM.TEX). In the screenshot below you see the parameters for the jersey-color texture. Maybe useful when you have time to check it to help you fix ImageHeat. UNIFORM Switch decompressed.zip

Nobody's making fun of you. However, it would have been useful if you had mentioned not having a computer at the start, instead of having people waste their time on things you can't use. It also sounds like you were harassing another user in DMs for help, which you also need to stop doing. People will help if they want to, and if they have the time.

I've moved this topic to graphic file formats, rather than 3d Models where you posted it. Also, please don't start another post for the exact same thing. I've deleted your other post as a duplicate. Please read the rules before posting again.

The game have update and they hard-coded new text in .mpk lua script, because some words have many different meaning depend on the context. With packet sniffing, i observed that the game download some .pak file from easebar.com and put them in .mpk file. These file are encrypted.

Decided to extract some key frames. from that .mot file I shared earlier. Wonder if there is any insight. The NaNs are interesting tho.

I made a blender addon to import models, textures and animations for dolphin wave and other games that used the same engine. it can import lzs and lza files as is. You don't need to decrypt or decompress the files https://github.com/Al-Hydra/blenderBUM

make some ajustments! now its working

I have a basic exporter for 3ds max here https://github.com/taylorfinnell/onbadexporter

Yes! I´ve to create a tool to merge and split image, so i can merge them, edit and later split to insert.

Bumping this again because I really don't want this thread to quietly die, as it seems the edits to my message are not enough to constitute a bump. Every single possible 16 bit float format I've tried does not work. Indicating this is some proprietary cursed format. Maybe a LUT. Maybe encrypted. Maybe something else. Which probably explains why the .mot files still have not been decrypted all these years. I do suspect what certain bits mean but I am really unsure. I have the model .bin and some other examples of .mot in hand as well so if you would like me to send it I will gladly do so. Just note I do need these files decrypted for a project so I would like this done as fast as possible it would be nice. What I do know is that this is little endian. Z-Y-X order. I have no clue what else. Help is much appreciated please 🙏 (I am not sure what y'all want but I am interested in a way to export the .mot to .csv with a Frame # column. For my application, that is enough.)

Well, I did a little research on Flash Cookies (SOL files) and I put it all together in the article on RE Wiki https://rewiki.miraheze.org/wiki/Flash_Cookie_SOL I saw notes on your github and you were sligthly wrong with some fields, so you can compare it with my article on the wiki and make some corrections in your tool. The most important thing is that you should understand that SOL file is an Adobe format and payload (data block) follows AMF file format documented by Adobe https://web.archive.org/web/20220122035930/https://www.adobe.com/content/dam/acom/en/devnet/pdf/amf-file-format-spec.pdf So anything after data block header is a payload section that needs to be properly serialized by your tool. There are many tools that allow you proper serialization like: minerva, SOL Editor, Adobe AIR SDK, JPEXS Free Flash Decompiler etc. Some code for serializing is available on JPEXS github page: https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/sol https://github.com/jindrapetrik/jpexs-decompiler/tree/master/libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/amf/amf3 You can test this code by going to Tools > Sol cookie editor in JPEXS Free Flash Decompiler: So you shouldn't ask "what are those three bytes". You should ask "how can I properly parse AMF3 serialized data" 🙂 There are lots of information (articles) about this, for example on wikipedia: https://en.wikipedia.org/wiki/Local_shared_object https://en.wikipedia.org/wiki/Action_Message_Format Good luck. 🙂

by the way if you need names of audio files put thesescript.zip in AetherGazerLauncher\AetherGazer\AetherGazer_Data\StreamingAssets\Windows folder , run process.py then it will change every audio .ys files to proper names.

I have one as an example I notice in this section Ran XXD with groups of 12 and noticed a pattern. This is the pinky intermediate joint. It is known that the pinky intermediate joint has one degree of freedom. meaning that movements in the other two DoF should be minimal. The second set of each float is stable. 16 bit floats. Little endian likely. Meaning that [3f], [00], [ff], etc. is the major bits. Given the ffs I do not think it is Big Endian with an offset. I have attached the file in question so you can look yourself EDIT: These are signed LE numbers. Circular angular floats (not IEEE 754 standard) so ffff/0000, 3fff/4000, 7fff/8000, bfff/c000 are each 90 degrees apart. EDIT 2: It could also be a LUT. But then I checked for any tables and I can't find any useful. EDIT 3: I have no clue anymore. These are proprietary obfuscated numbers using some cryptic format and if anyone knows how to decode them it would be absolutely amazing. SVT_0015_S01_ATK_A01.zip

Bump numero 3

car_ambulance, extracted using hex2obj (after decompressing pxc with simplified bms from ky123):

Bumping this, if anyone would be an absolute unit to solve the animations it would be greatly appreciated! 🙃

Did you ever figure out the animations format? I'd love to get access to the animations for some stuff but of course, the MOT files are formatted differently 😔

I wrote a VSF UNPACK/PACK program and a new decompressor/compressor for zlib. Now, it accepts large files and there's no need to use QuickBMS anymore. The .vfs file can now be larger than the original. I did a test, and it worked with the image below, maybe you can put music and soundeffects as well, If the .py file doesn't work, you must install tkinter via pip. VFS_PackUnpack_Tool.py zlib_DeCompressor.py

Mostly, PNG files are decompressed, so it's fairly easy to edit and reimport them. However, you need to compress your PNG files using the site iLoveIMG. For example, if the original PNG is 10 KB, your PNG must be 10 KB or less, so you will need to compress it on the site. I’ve attached 3 files: Two BMS scripts: One script will unpack the data, decompressing all files. The other script will unpack the file without decompressing it (this is the one you should use for reimporting; reimport with -r, not reimport 2 in quick bms). A Python script (.py): This program decompresses and compresses zlib files individually. I have set a compression level to reduce the file size even further. Use this if you need to handle compressed files. zlib_DeCompressor.py BMS.ZIP

How exactly should I use it? First I have to decrypt the farc files, right? To decrypt the 3D Models I was using quickbms and the script that was on XeNTaX, but that script can't decrypt the farcs from the trading cards

yeah i guess so. but I think we need to find something to differentiate between rotate data or transform data, and it's hard to find that, so we need something reverse work

Has anyone managed to extract the trading card images? I tried using the script for the 3D models. but it just doesn't work.