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

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

Today I am gonna show you, how to reverse eningeer any Binary 3D Models, turns out this is not that hard and actually one of the cooolest things in reverse enigneering! (Uncompressed and un-encrypted models obviously). +====TUTORIAL SECTION=====+ =| INTRODUCTION |= But how do all those models store their 3D Data? Well, the answer is simple, there is no magic here, All 3D Models are just made up of *Vertecies*, *Faces*, *Vertex UV Coordinates* and *Vertex Normal Coordinates* They are definatelly *must* somewhere there in your file (this place is called buffer) and there is absolutelly no extra magic in here. This is how the Vertecies look like: v 1.0 4.0 3.0 <= X, Y, Z matrix coordinates (usually from 0.01 to 1000) v 2.0 3.0 4.0 <= Point values so are usually floats v 6.0 2.0 3.0 <= Usually stable, values don't varry to much in max and min values This is how faces looks like: f 1 2 3 <= Takes all those previous vertecies and makes a triangle out of them This is how UV Vertex coords look lke: vt 0.2 0.3 <= 2D coordinate of the first vertex (usually from 0.1 to 1.0) vt 0.5 0.2 <= Point values so are usually floats vt 0.3 0.1 <= Usually stable, values don't warry to much in max and min values This is how Vertex normals look like (not important actually!): vn 0.745 0.845 0.360 <= X, Y, Z matriz coordinates (usually from 0.01 to 1) vn 0.320 0.625 0.270 <= Point values so are usually floats, so "v2 x, y, z" vn 0.430 0.320 0.390 <= Usually stable, values don't warry much in max and min values This is how the simplest 3D Model format OBJ stores their 3D Model data, hovewer we can say that all of the binary models store their 3D Data in OBJ file format there is just one more thing to it. Binary fomrats have two ways of storing the 3D Data (Aside faces) in a Separate way and Structured way, here is how it looks like: Separate way: vertex_buffer = [ v1 1.0 4.0 3.0 <= X, Y, Z matrix coordinates (usually from 0.01 to 1000) v2 2.0 3.0 4.0 <= Point values so are usually floats, so "v2 x, y, x" v3 6.0 2.0 3.0 <= Usually stable, values don't varry to much in max and min values ... ] face_buffer = [ f1 1 2 3 <= Takes all those previous vertecies and makes triangle out of them, so "f1 v1, v2, v3" ... ] uv_coords_buffer = [ vt1 0.2 0.3 <= 2D coordinate of the first vertex (usually from 0.1 to 1.0) vt2 0.5 0.2 <= Point values so are usually floats, so "vt2 u, v" vt3 0.3 0.1 <= Usually stable, values don't warry to nuch in max and min values ... ] vertex_normals = { vn1 0.745 0.845 0.360 <= X, Y, X matrix coordinates (usually from 0.01 to 1) vn2 0.320 0.625 0.270 <= Point values so are usually floats, so "v2, x, y, z" vn3 0.450 0.310 0.390 <= Usually stable, values don't warry much in max and min values ... } Structured way: data_array = [ {v1 1.0 4.0 3.0, vt1 0.2 0.3, vn1 0.745 0.845 0.360} {v2 2.0 3.0 4.0, vt2 0.5 0.2, vn2 0.320 0.625 0.270} {v3 6.0 2.0 3.0, vt3 0.3 0.1, vn3 0.450 0.310 0.390} ... ] =| BINARY DATA |= The data in each file can be viewed as binary no matter if it was readable or unreadable or even empty before, viewing it in binary will spoil immediatelly everything. And while binary files are all the same, the way we read it changes drastically everything! To view your binary file yiou must dump HEX from it or load it into HEX Viewer: Example file: Addres: HEX Bytes: ASCII: 0012BFC0 48 53 68 61 70 65 5F 31 37 00 00 00 00 00 01 00 HShape_17....... <= First line contains ASCII strings 0012BFD0 00 00 0A 00 00 00 22 00 00 10 00 00 00 00 0C 00 ......"......... <= Second line contains ASCII strings 0012BFE0 00 00 61 32 76 2E 6F 62 6A 43 6F 6F 72 64 01 00 ..a2v.objCoord.. <= Third line contains ASCII strings 0012BFF0 00 00 FF FF FF FF 02 00 00 00 47 04 00 00 82 56 ..........G....V <= Fourth line contains interesting "00 FF FF FF FF 00" separation mark 0012C000 F9 40 39 94 59 43 76 26 13 41 BB 61 FB 40 5A A4 [email protected]&.A.a.@Z. <= Fifth line starts containg the actual float Vertex coordinates! But looks random in ASCII strings! 0012C010 5B 43 95 B7 00 41 8F 70 CB 40 C1 4A 5B 43 31 08 [[email protected][C1. <= Sixth line contains actual float Vertex coordinates! But looks random in ASCII strings! 0012C020 12 41 8A 8E C9 40 E7 5B 59 43 E8 82 1D 41 90 A0 .A...@.[YC...A.. <= Seventh line contains actual flaot Vertex coordinates! But looks still random in ASCII strings! 0012C030 62 40 21 90 58 43 05 DD 1C 41 BC B3 78 40 D7 63 b@[email protected] <= Eight line contains actual float Vertex coordinates! But looks again random in ASCII strings! But what are those floats, shorts and ASCII? The Bits are the smallest units of computer data they are either 0 or 1 and comma. The Bytes hgovewer is a combined 8 Bits that can actually start representing some data. Those are Bits ranging from 0 to 255, where 0 is also precieved as an important value (So 256 combinations), (I represented them in HEX, 0-F values, so a 256 combinations) Here is one Byte for example: 10110111 (32 16 8 4 2 1 = 256 bits as sum), combining Bytes together we can make multiple data types. This are all of the data types: Byte/Char => 1 Byte, unsigned/signed (8 Bits) |Example: 48 <= H | ASCII Word/Short => 2 bytes, unsigned, signed (16 Bits) |Example: 48 53 <= HS | ASCII Dword/Int => 4 bytes, unsigned, signed (32 Bits) |Example: 48 53 68 61 <= HShap | ASCII ULONG32/Long => 4 Byte, unsigned, signed (32 Bits) |Example: 48 53 68 61 <= HShap | ASCII ULONG64/Long Long => 8 Byte, unsigned, signed (64 Bits) |Example: 48 53 68 61 70 65 5F 31 <= HShape_17 | ASCII float => 4 bytes, for represnting floating point values (32 Bits) |Example: 48 53 68 61 <= HShap | ASCII double => 8 bytes, for representing more precise floating point values (64 Bits) |Example: 48 53 68 61 70 65 5F 31 <= HShape_17 | ASCII String/Char => A Sequence/Array of Characters terminated by the nulll character |Example: 48 53 68 61 70 65 5F 31 <= HShape_17 | ASCII Big-Endina vs Little-Endian: Reading in Big-Endian for example a float byte will read it normally, left-to-right 48 53 68 61 "HShap", where's Little-endin reads byte in reverse order, right-to-left 61 68 53 48 "paSH". Big-Endians were mainly used in PS3, Xbox360 and Wii platform s where Little-Endians are mainly in Windows, PS4, Xbox One, Nintendo Switch. =| TRYING TO REVERSE THE BINARY 3D FORMAT |= But how do we actually apply this info into reverse engineering the binary 3D file format structure and even converting it into an OBJ Model. Assuming that you have the actual decompressed/uncompressed and decrypted/unencrypted binary 3D model file, you can actually visualize the 3D Data geometry while analyzing the HEX from it in realtime! ModelResearcherUltimate is the program that will enable this opportunities. First of, Level 1: Start with vertecies count 500, type: float, carefully try different offsets while printing the values and render it too, until you see a countinous very stable output without insanelly big or small values. (from 0.001 to 1000). If nothing works try with different Endianess, then try a different type (unlikely). If the mesh appears but random vertecies appear too that means that the Data structure is sctructured and you need to try different Padding or even Pad inters sometimes. Second of, Level 2: Start with vertex UV coordinates count [exactly how many vertecies], type: float, carefully try different offsets while printing the values and rendering it too, until you see a countinous stable output without insanelyy big or small values (from 0.0001 to 1.) If nothing works try different type, since you already know the Endianes and Structure. Third of, Level 3: Start with faces, they are actually very carefully linked with vertecies, so the errors will constantly appear, carefully try different offsets while printing the values, don't render it, it will often just throw the errors. You will need see the full values without floating points that are very stable in output without big and small values, if nothing works try different type or even the format. Fourth of, Level 4: [To be honest I didn't know what to write here, normals are pretty useless though, you can just flip them and calculate, very easily in programs like Blender in just a few clicks, so it's not worth your brainstorming!]

Please don't publish tutorials until you finish them. Also, Raw Texture Cooker is outdated. It's better to use ImageHeat https://github.com/bartlomiejduda/ImageHeat It supports more pixel formats etc.

Introduction This question is probably the most asked one and it makes total sense why, the answer unfortunatelly is pretty generic in it's nature, it depends but if we dive deeper turns out it's not as hard as you think might be here is why I personally think this way... Reverse engineering the game, specifically for asset extraction, requires 4 different steps to create: 1. Extract Game Archive, (Reverse enigneer game's extractioon method, spot a compression method, decrypt xor keys (Rarely)) 2. Reverse Enigneer Binary 3D model files 3. Reverse egnineer Binary Texture files 4. Reverse egnineer the Binary Audio files While those are not extreamly hard to topics to learn, it can took some time to figure them out yourselfe. There are numereous ways to reverse engineer those tasks, you can do it manually via binary inspection, or by using, exploits or even by using leaked Beta Builds or reloaded versions, that often are packed with .PDB files (debug symbols) that can be loaded into Ghidra for near source code, code debugging experience. While the best one is still a binary inspection, there are already dedicated tools for this, for inspecting and extracting manually sample by sample, but currently in time being there aren't any automated programs for this so you must choose to rely on Python scripts. For extracting game archives I recommend QuickBMS for model extraction Model Researcher for Textures Raw Texture Cooker and Audacity for Audio... By extracting all of the game content don't forget about the Headers and Magic Numbers, No matter how Payload loos like, the headers are always the same and often contain super usefull info with them. Graphic Debuggers vs Reverse Engineering This is hot topic is the most intersting one, since yes, Dumping 3D Models and Textures + Recording the Audio's using Graphic Debuggers like RenderDoc, nvidia Nsight Graphics and NinjaRipper Exploit obviously way, way easier than any reverse engineering the proprietary files, it can be done in few minutes vs it can took a few days to mounths in Reverse Engineering so the difference is huge sometimes, hovewer after you reverse engineered the binary files you have access to extreamly fast asset "ripping" speeds without relying on the drawcalls and of course you have access to all of the cut contents and very very easier and faster Map/World "ripping". There are obviously upsides and downsides in both of the methods, I personally recommend using exactly what you need for, if there are already scripts for extracting and maybe even converting some binary proprietary assets then go for it!

My first try on this .lwo format.

Skeleton deformations for the character creator is probably a more accurate term for Veilguards “morph targets” (DAO/DA2 use straight up targets while I/VG use the skeleton to deform morphs with different bone positions) But I’m not a game dev. 😉

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

Yeah, the DWord face indices totally don't fit but I have a déjà vue of this picture, maybe on former Xentax? edit: correct vertex start is 0x144

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

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

O.K. so here's script for ps4 format. Inside unpacked file is texture width/height and pixel format all in 6 bytes. Rest is image data. Also i don't know about pixel fomat so you must figure out. get BaseFileName basename comtype lz4 getdstring Sig 0x8; get Unknown_0 uint32 get Unknown_1 uint32 getdstring Platform 0x4 get TextureCount uint32 get Unknown_2 uint32 get UnknownCount uint32 get TotalCompressedSize uint32 get TotalDecompressedSize uint32 get Unknown_6 uint32 get Unknown_7 uint32 for i = 0 < TextureCount getdstring TextureName[i] 0x40 getdstring Unknown_0 0x10 get CompressedSize[i] uint32 get Offset[i] uint32 # + BaseOffset get Unknown_3 uint32 get DecompressdSize[i] uint32 get Unknown_4 ushort get Unknown_ ushort get Unknown_6 uint32 get Unknown_7 uint32 get Unknown_8 uint32 savepos WidthHeightPos[i] get TextureWidth ushort get TextureHeight ushort get Unknown_9 uint32 savepos PixelFormatPos[i] get PixelFormat ushort get Unknown_10 ushort get Unknown_11 uint32 getdstring Unknown_12 0x4 get Unknown_13 uint32 get Unknown_14 ushort get Unknown_15 ushort get Unknown_16 uint32 getdstring Null 0x10 next i math UnknownCount * 40 getdstring UnkInfo UnknownCount savepos BaseOffset for i = 0 < TextureCount math Offset[i] + BaseOffset string FileName p= "%s/%s.dat" BaseFileName TextureName[i] append 0 log FileName WidthHeightPos[i] 4 log FileName PixelFormatPos[i] 2 clog FileName Offset[i] CompressedSize[i] DecompressdSize[i] next i

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.

tool.py Here a working script that will output json file with { hash: text, ... }

Here my analysis: Header: 24 bytes: [ Int64 EntryCount Int64 ValueCount Int32 Timestamp Int32 Padding ] Buckets: [24-528] bytes, based on allocated bucket TableEntries: EntryCount * [ 8 Bytes Hash(or id?), Int32 RelativeOffset, (formula: text_start = current_entry_offset + 8 + value) Int32 TextLength ] Values: ValueCount * [ Byte[ValueLength] Data ] Null value have zero length and no hash. Successfully unpack and pack, the game load new text normally.

Hello, I have managed to get the game files and uploaded to AssetStudio to view them, and I found Texture2Ds and Sprites but some of the assets are missing. For an example, there are literally no audio/voice files at all. Then, I noticed AssetStudio doesnt recognize the assets inside a folder called "ondemand" and there are about 2k assets there and I think they are encrypted/compressed. Here is one of the examples of the encrypted assets: Is there a way to decrypt/decompress this type of file? I think those are the remaining assets. If anyone can help me I would really apprecaite it. 5db8fd68-da55-9c4a-c71f-84af76d61103.7z

.ilv.txth: codec = PSX channels = 2 sample_rate = 44100 interleave = 0x4000 num_samples = data_size

You can either use this QuickBMS script to extract the msv audio files out of the rp2: get UNK long get FILES long goto 0x20 for i = 0 < FILES getdstring NAME 7 getdstring DUMMY 25 get OFFSET long get SIZE long get DUMMY2 long string NAME + ".msv" log NAME OFFSET SIZE next i Or you can use this txth file to play the audios out of the rp2 directly (needs vgmstream + an audio player like foobar2000): subsong_count = @0x04 subsong_spacing = 0x2c base_offset = 0x20 name_offset = 0x00 subfile_offset = @0x20 subfile_size = @0x24 subfile_extension = msv Save the text above as ".rp2.txth" and put it on the same directory as the rp2 file. Also if you're using foobar2000, make sure to check "Enable unknown exts" on the vgmstream preferences page.

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

No, mané game extractor! attached my .exe try it you can drop the file into the .exe as well the tool looks like StarWars3PakExtractor.zip

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.

They are still pck files. I can find many wwise .bnk files in AA462ABBFEC319B665666E14585F97D9_EndfieldBeta with ravioli explorer , RavioliGameTools_v2.10.zip (if you need)and I think quickbms also work. By the way I guess the really wem audio files are in another pck files. there are over 5000 bnk files in AA462ABBFEC319B665666E14585F97D9_EndfieldBeta. That means the bnk files may not store any actual audio files

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

Anybody could share mot, tex_db.bin and a model file .bin of a character

bumping this 2

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 😔

use my plugin for Noesis arc_zlib_plzp_lang_vfs.py (which I mentioned earlier) it recursively unpacks all files, at the output you will get *.png, *.wav, *.pm3, *.vram, *.text, *.pvr and e.t.c You can also find a link to the plugin for 3D models *.vram above in the same topic. (*.pvr can open in PVRTexTool)

zlib_DeCompressor.pyHere the DeCompressor update, now works with every file

The WAVE files just use XBox ADPCM (not that obscure) and you can play and convert them with Foobar + vgmstream (note: some files don't contain audio). You don't really need to do anything else.

Maybe you should open a new thread and ask in there, not here, because this thread is for discussing the motion file.

I'm still not sure how to run it, unless I'm doing something wrong, it doesn't seem to be working

for fgo's script, you just need run this: python FGOArcade-FARC.py "your farcfile path" for farcpack tool, Run it in the shell to see the cli commands.

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

for fgo arcade, you can use this to extract the farc file: https://github.com/Silvris/RandomScriptsAndTemplates/blob/main/FGO Arcade/FGOArcade-FARC.py for kancolle arcade, you can use farcpack tools to extract it: https://github.com/blueskythlikesclouds/MikuMikuLibrary/releases/download/v2.2.0/FarcPack.7z the trading card images was in ./rom/trading_card

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

https://github.com/h-kidd/noesis-project-diva AFAIK this uses the same (or highly relevant - Virtua Fighter 5 based) engine as other arcade games such as Project DIVA Arcade or Fate Grand Order I guess the animation format would be relevant (and hope this be helpful for REing)