Leaderboard

i took a look at the .CB file and managed to crack it. 1. ENC0 / ENC2 are not encryption ENC is short for *encoding*, and the digit is the method number. *ENC0 — stored, no compression.** The CLSS blob follows the 8-byte header verbatim. That is exactly why CLSS / CTRFImageBuffer / IBUF were readable in a hex editor in the first place. The LZSS chunks live *inside* that blob. Every image resource in SSYF.CB is ENC0. *ENC2 — the whole record is LZSS-compressed.** Same bitstream as below, but with no 4-byte size prefix; the decompressed size is the resource size already in the TOC. Only the 20 .SET files use it. 2. The compression Chunk layout "LZSS" | u32 chunk_size | u32 decompressed_size | bitstream - Bits are read LSB-first within each byte — bit 0, then bit 1, … bit 7. - Multi-bit fields are assembled MSB-first — the first bit read is the field's most significant bit. Grammar. - flag bit 1 → literal: the next 8 bits are emitted directly. - flag bit 0 → match: 12-bit ring position, then 4-bit length, length = field + 2 (so 2..17 bytes). Window. - A 4096-byte ring buffer, initialised to 0x00, write pointer starting at 0. - pos is a 1-based ring index, so the copy source is ring[(pos - 1 + i) & 0xFFF]. pos == 0 never appears in a real token. - Every copied byte is written back into the ring at the write pointer, as usual. - The stream ends as soon as the declared byte count is produced. There is no end marker, and up to 2 bytes of zero padding follow. int bitpos = 0; int getbit (const u8 *s) { int b = (s[bitpos>>3] >> (bitpos&7)) & 1; bitpos++; return b; } u32 getbits(const u8 *s, int n) { u32 v = 0; while (n--) v = (v<<1) | getbit(s); return v; } u8 ring[4096] = { 0 }; u32 r = 0, o = 0; while (o < decompressed_size) { if (getbit(src)) { /* 1 = literal */ u8 c = getbits(src, 8); out[o++] = c; ring[r] = c; r = (r + 1) & 0xFFF; } else { /* 0 = match */ u32 pos = getbits(src, 12); /* 1-based ring index */ u32 len = getbits(src, 4) + 2; /* 2..17 */ u32 s = (pos - 1) & 0xFFF; for (u32 i = 0; i < len; i++) { u8 c = ring[(s + i) & 0xFFF]; out[o++] = c; ring[r] = c; r = (r + 1) & 0xFFF; } } } One chunk decompresses to at most 0x20000 bytes. Bigger images are split across consecutive LZSS chunks that concatenate to exactly width * height * 2. 3. The .dds files — CTRFImageBuffer "CLSS" | u32 len | class name, NUL-terminated ("CTRFImageBuffer") "IBUF" | u32 size | u32 (0) | u16 width | u16 height | u16 pitch (= width*2) | u16 planes (1) | u32 flags (0x00100000) | u32 mask A | u32 mask R | u32 mask G | u32 mask B | u8 bits A, R, G, B (e.g. 0, 5, 6, 5) | u8 top bit index A, R, G, B (e.g. 0, 15, 10, 4) then 1..n LZSS chunksThe pixel data is a plain linear raster 4. The .SET files, and exact frame reassembly Once decompressed, each .SET is a serialised CTRFDataSet that names the textures for a scene and gives the blit rectangles — so reassembly is read from the data. "CLSS" | u32 len | "CTRFDataSet\0" | u32 nrec per record: FF FF FF FF | u32 id | u16 namelen | name | payload CTRFTexture u32 | u32 count | count x NUL-terminated .dds names CTRFPictures u32 | u32 npics npics x ( u16 (0x10) | u16 npieces | u16 W | u16 H | u16 ox | u16 oy npieces x ( u32 texture index u16 sx0 sy0 sx1 sy1 <- inclusive source rect u16 dx0 dy0 dx1 dy1 )) <- inclusive dest rect npics x NUL-terminated picture name <- names come after ALL pictures u32Note that the picture names come after all the pictures, The typical scene is 640x480 built from three pieces: 512x480 from the _00 texture, then the _01 texture folded in half to supply the right-hand 128x480 strip. tex0 src (0,0)-(511,479) -> dst (0,0)-(511,479) tex1 src (0,0)-(127,255) -> dst (512,0)-(639,255) tex1 src (128,0)-(255,223) -> dst (512,256)-(639,479)A few sets sSYf_11) store frames at half vertical resolution and give a destination rect twice as tall — i.e. the game line-doubles them. Other record types are present CTRFContainer, CTRFClipperBuilder, CTRFPictureDraw, and TEXT / PICT / ANIM / LIPS / CLIP sections), but none are needed for images. Script attached: kitae_cb.py python kitae_cb.py .CB FILE -o extracted --assemble python kitae_cb.py .DDS FILE -o extracted # loose CLSS/IBUF file kitae_cb.py

I just figured out how to load external files like materials, textures. But absolute path must be set. I also noticed that *.entity is invoked by skeleton if there's any. External dds loading. But there is still one big issue. How are meshes handled. I still didn't figure out how indices reset. Holy sh!t it automatically converts textures to dds in cooperation with my script for textures

The PVR files look to be LZSS0 compressed from offset 8, and one of the files I tested (IMG0088_A) is 512x512 BGRA5551 with DC swizzling. Something like this:

Inspecting the Pet_Snake.bfz file shows that it indeed is a protected ZIP file with legacy ZipCrypto. The game executable is protected by Themida (😒) so I had to dump the running process to perform some analysis. The ZIP password is derived from the archive's resource path. The loader normalizes the separators, gets rid of the filename, takes the final directory component, and finally converts it all to uppercase. The string is then ran through an embedded lookup table and finally the results are all concatenated resulting in the valid password for this particular BFP file. Here is a script I wrote that will automatically generate the proper ZIP password for the given BFP file: TABLES = [ "as89f7d6af98e7f6a9s87f6as98f76asdf8yasuefyae8f7as6ef9ase87fa6se9", "alkjdfLKDFJeofias4894ewfadfklDFJfsafjlasff89a4fhJLKDSfHdf98daf9s", "afoiefajsfiasdf87ysda987dsfvhsdkvhs8dr7vhsdkfghsie4g8hsdfukzDFDf", "faklsjdfiod9f8asdfjKLDFjds9f8jasdklfjsdf9asd8fuseijkasdkHDFKJDf8", "dflkjasdf98asfuyaiufhaos8efhLHFDJSFhasod8fsdfkLDfd9f8aslkejfDLkf", "dkfjapsdoifjas9d8fajsdfiashdJKFSHdfdfaskdljf9sd8fasd89f7asieufa9", ] def bfz_password(package_path): path = package_path.encode("ascii") return "".join( TABLES[i % 6][path[i % len(path)] % 64] for i in range(64) ) def reconstruct_bfz_path(resource_path: str) -> str: normalized_path = resource_path.replace("\\", "/") separator_index = normalized_path.rfind("/") resource_directory = normalized_path[:separator_index] directory_separator = resource_directory.rfind("/") archive_name = resource_directory[directory_separator + 1:] return f"{resource_directory}/{archive_name}.bfz" def derive_bfz_kdf_input(resource_path: str) -> str: archive_path = reconstruct_bfz_path(resource_path) return archive_path.upper() if __name__ == "__main__": resource = "<FILENAME>" logical_archive_path = reconstruct_bfz_path(resource) password_generator_input = derive_bfz_kdf_input(resource) encrypted_password = bfz_password(password_generator_input) print(f"Resource path: {resource}") print(f"Logical archive path: {logical_archive_path}") print(f"KDF input: {password_generator_input}") print(f"Encrypted password: {encrypted_password}") I am taking the Pet_Snake.bfz file as example and I have opened in my tool. You can also open it in any other tool like 7zip, NotePad++, etc... as long as you can get the names of the files inside of the ZIP archive. You simply take any of the names, in this case we take Models/Characters/Pet_Snake/common/pis-basic-jump.face, and paste it in the <FILENAME> placeholder inside of the python script and run it. Resource path: Models/Characters/Pet_Snake/common/pis-basic-jump.face Logical archive path: Models/Characters/Pet_Snake/common/common.bfz KDF input: MODELS/CHARACTERS/PET_SNAKE/COMMON/COMMON.BFZ Encrypted password: 7aejsjajsauk94fjf8afasf9sefskd7f8aDj6fdsud8Lf8ya7odskos8flhps9sdThe encrypted password can then be used as password to extract the data from the ZIP file. I did not yet take a look at the PKN files you've supplied. I am planning on doing this soon.

cetacylanol/lyokoQFI: Some half baked tools for extracting Code lyoko: quest for infinity Wii data. This

The BNK files are compressed with XMemCompress. The LZXNATIVE magic starts at 0x7D0. Everything before it is padding. Drop the contents of the 7-Zip archive into the folder with the BNK files and then run: .\decompress_bnk.ps1 Stuntman Ignition.7z

The progress for the Unreal Engine game loader is that the game boots all the way to the Menu and now I'm just implementing a model viewer to debug assets a lot faster Unreal uses the .xbe to load the models and mesh, I haven't implemented the shaders and such yet, just the mesh building

I'm not sure if this is the right place to post this. it's not a help request or anything like that but I just wanted to share the binary template I created for the SF643D .modelgdb format. I made one for the final game (complete with all parameters) and one for the 2010 prototype (incomplete, covering only the geometry structure). SF643D_010Editor_Templates //The size is huge because it contains numerous node options and sub-options, all with specific identification IDs (as far as I recall, mine are 100% correct; I compared them against the .modelgdb.tex versions "original binary-to-text" conversions left behind in the game). //There are some .modelgdb models that contain "Node_Node" structures. These structures consist of matrix values attached to specific geometry IDs; for instance, a model located at the center of the scene might be moved to a different position based on a Node_Node referencing a specific geometry ID. Only about six models actually use this feature the rest simply use the final pose. I wrote a Noesis plugin to load these models, but the way these matrix-based nodes function makes them a nightmare to handle within a tool like Noesis. Consequently, my Noesis plugin is incomplete, and there are still some vertex formats whose structures I haven't figured out yet. This is the kind of format where it's better to build a specialized tool rather than trying to use Noesis. (If there are any errors or signs of amateurism in the template I created, I apologize; it’s the first template I’ve written that is this complex and large.) //If you want to test a sample here SF3D_modelgdb_sample.zip

The .pck is a ZIP file in disguise. However, two things were changed. 1. Every PK signature (50 4B) is written as OD (4F 44). 2. The zlib header byte 78 is written as 02 Plus one structural change: local file headers are omitted entirely. Entry offsets point straight at the raw deflate payload. The .dir and .tbl files are redundant lookup caches. Use the script attached to extract everything/or just the textures. python zpak_extract.py pack_prog_res.pck # extract everything python zpak_extract.py pack_prog_res.pck -o out --verify # + check every CRC python zpak_extract.py pack_prog_res.pck --list # list, don't extract python zpak_extract.py pack_prog_res.pck --textures # dds/tga/bmp/png/jpg only zpak_extract.py

tools should work Rio Tools Final.zip

I decompressed the data with QuickBMS, then you can manipulate it in ImageHeat. The decompressed data has a header of 32 bytes, which includes the image dimensions. I'm not sure if some images use a slightly different format. The swizzle seems to be standard Morton, at least for the ones I tried. Your script probably works, but be aware of rule 17 for using AI to generate scripts.

I see LZSS sign in SSYF.

also trying to get this figured out props were the first thing thanks to you and other forums | World Architecture and UV stuff was insane to get correctly, props rotatet wrong, level mirrored etc uv and lightmaps working (still some missing rocks, prop lighting off and NPCs looking weird) | skybox/backdrop, prop lighting and rotation done edit 19.08.26 got a lot of the missing architecture working | also got water and glass transparency working Also working on NPCs/Characters: edit 21.08.26 still struggling with the character bodies, clothes and accesories are ok edit 02.09.26 getting closer with the faces, also it seems that in my previous extractions i combined low and high poly models (hat placement still off and some tiny holes in the skin) faces and face parts are separate submeshes that are animated edit 03.09.26 decoded native animation tracks and got them working with the skeletons i am playing around with pruning and protecting on the skin and clothes good results with faces and necks so far but not perfect yet

Okie dokie, thank you

Hey Uber. I was planning on uploading the ripped models from Live and Reloaded to models resource. But since you made the script to rip the models and import them into blender in the first place, I wanted to get your word on it first before I do anything.

Btw, format was already covered on the wiki https://rewiki.miraheze.org/wiki/Rage_Software_XFS

I'm struggling because I really want to load the model from the master data, no matter what

OK. So I took a look at the Korean Bubble Fighter executable (after stepping into the ring with Themida (😒) again) you've provided and I saw that it uses SNOW 2.0 Stream Cipher but, with a few Nexon introduced twists. this I used the following C++ implementation of the SNOW Stream Cipher from this GitHub Repository as reference and wrote my own version in Python and added the Nexon induced twists myself. Use the attached Python script as follows: python .\BubbleFighterPKN.py "path\to\pkn\file" I have tested the Python script on the samples you've given me so I hope it will work on the rest of the files as well. I have no idea what your future plans are with this but, I wish you all the best. 👍 BubbleFighterPKN.py

The file attached doesn't match the screenshot - intended file? Based on the 0x80###### uint32's found at 0x1690, that's likely a palette, and 0xC0 appears to where pixel data might start: Yep:

Here is experimental version of dump tool for full version of Battlefield 6. (attached in the end of this post) For almost a whole year now since beta versions it was possible to use my set of tools to get ANY files from it, be that beta or full version. The only problem was "update" folder that was not supported as it is. To get it dumped, you had to move files from update folder to data folder. Each subfolder inside "update" has "data" inside, and you have to move contents to main "data" folder. It does not overlap and work as intended. Now i made this new version which must scan update folder and add data from it. Important change of .INI file is that now game path must NOT include "data" in the end: C:\games\bf6 D:\dump all After dumping, you can use same set of tools from here: bf6_update.7z

Try this QuickBMS script to decompress the BMP files. cat.zip

Use this How to rip Textures , Audio and Models | Cocoto Wiki | Fandom Follow the tutorial A file (that ends with .PC and has GFX in it) Cocoto PS2-LZSS Texture Extractor v1.1 Console Texture Explorer by Dageron (from GRAPHIC TOOLS) An example of what can be decompressed Edit: After looking again at the screenshot attached, the problem is that you didn't decompress the file. It is compressed in LZSS. It's after that you can set the format to 32 bit per pixel, and then use arrows to change the preview size Then, save all as PNG so it's easier to zoom in all the texture and take a look

I looked into this game a while ago but only recently got around to publishing what I found. You can read the article here if you’re interested. The only difference is that my research was based on the Steam version of the game. Use the attached script as follows: # Please make sure that the cryptography is installed on your system python -m pip install cryptography python .\wizardry_bundle_decrypt.py .\assetcache .\decrypted-cache # -- OR -- python .\wizardry_bundle_decrypt.py .\assetcache\original-cache-name .\decrypted.bundle wizardry_bundle_decrypt.py

@Hazza12555 man, Hi again! It worked perfectly! I’m truly grateful that you took the time to help me. Thank you so much for your patience, your time, and your expertise! You’re amazing bro!!! 🙌😊

All integers are little-endian. 1. File header | offset | type | value | | 0x00 | char[8] | "TEXTURES" | | 0x08 | u32 | version — 0x00001200 | | 0x0C | u32 | texture count — 26805 | | 0x10 | u32 | 0 | | 0x14 | u32 | 0 | | 0x18 | u32 | name-table size in bytes — 546198 | 2. Name table (at 0x1C) count consecutive Pascal-style strings: u8 len ; includes the trailing NUL u8 bytes[len] ; CP1251 text, last byte is 0x00 Names are Russian (CP1251), e.g. Городишко_Мерия_1_0. The table ends exactly at 0x855B2, where the record table begins. 3. Record table (0x855B2, count × 136 bytes) A record is a u32 storage type followed by a verbatim MicrosoftDDSURFACEDESC2 / DDS_HEADER (dwSize = 124), then the block location. Because the DDS header starts at +0x04, the usual DDS offsets are shifted by four: | offset | field | | 0x00 | u32 type — 0 = raw, 2 = compressed | | 0x04 | dwSize = 124 | | 0x08 | dwFlags = 0 | | 0x0C | dwHeight | | 0x10 | dwWidth | | 0x14 | dwPitchOrLinearSize — unreliable, ignore | | 0x18 | dwDepth = 0 | | 0x1C | dwMipMapCount = 0 | | 0x20 | dwReserved1[11] — all zero | | 0x4C | DDPIXELFORMAT: dwSize = 32, dwFlags = 0x41 (32bpp) or 0x40 (24bpp), dwFourCC = 0, dwRGBBitCount = 32 or 24, masks R=0x00FF0000 G=0x0000FF00 B=0x000000FF A=0xFF000000 | | 0x6C | dwCapsCaps2Caps3Caps4dwReserved2 — all zero | | 0x80 | u32 dataSize | | 0x84 | u32 dataOffset — absolute file offset | The channel masks describe a 32-bit ARGB DWORD, i.e. B, G, R, A byte order in memory. 592 records store pitch = width × 3 even though the pixel format is 32bpp - a stale field left over from a 24-bit build. Derive the stride from width instead. The 12 genuinely 24bpp records are all type 0 and are tiny UI fills. Data blocks are perfectly contiguous; the last one ends exactly at EOF. 4. Payload — type 0 (18 records, raw) width × height × bpp bytes, row-major, no padding: BGRA for 32bpp, BGRfor 24bpp. No colour transform. 5. Payload — type 2 (26,787 records, compressed) u16 width u16 height u8 bytesPerPixel ; always 4 4 × { u24 compressedSize ; little-endian u8 compressedData[compressedSize] } Each of the four chunks is one independently compressed 8-bit plane that decompresses to exactly width × height bytes. 5.1 Plane codec — NRV2B (UCL) The planes use NRV2B, the LZ77 variant from Markus Oberhumer's [UCL] (https://www.oberhumer.com/opensource/ucl/) library (the algorithm UPX uses), in its 32-bit-bit-buffer form: a 32-bit bit buffer is refilled with a little-endian u32 taken from the stream whenever it runs dry, and its bits are consumed LSB-first; literal bytes and match-offset bytes are read as raw bytes from the same stream, interleaved with those refills - so the byte layout of a plane is word · literals · word · … · 0xFF; M2_MAX_OFFSET is 0xd00 (3328): a match longer than that gets one extra byte; the stream ends with the standard 0xFFFFFFFF offset marker, which is why every plane's final byte is 0xFF. last = 1; for (;;) { while (getbit()) emit(nextbyte()); /* literal run */ m_off = 1; do { m_off = m_off*2 + getbit(); } while (!getbit()); if (m_off == 2) { /* reuse previous offset */ m_off = last; m_len = getbit(); } else { v = (m_off - 3)*256 + nextbyte(); if (v == 0xffffffff) break; /* end of stream */ m_len = getbit(); m_off = v + 1; last = m_off; } if (m_len) m_len = 3 + getbit(); /* 3..4 */ else if (getbit()) m_len = 2; /* 2 */ else { /* >=5 */ m_len = 1; do { m_len = m_len*2 + getbit(); } while (!getbit()); m_len += 3; } if (m_off > 0xd00) m_len++; copy m_len bytes from distance m_off; } 5.2 Colour transform The four planes are not B, G, R, A directly. Green is hoisted to plane 0 and the other two colour channels are stored as differences against it, biased by 128 - a reversible decorrelation that makes the planes far more compressible (planes 1 and 2 of a typical texture sit tightly around 128): G = p0 B = p0 + p1 - 128 R = p0 + p2 - 128 A = p3 6. Tools in this zip. | file | what it is | | extract_tex.py | full extractor → PNG (uses nrv2b.dll, falls back to a pure-python decoder) | | nrv2b.c | the NRV2B decompressor in C, plus a helper that decodes all four planes of a block | | nrv2b.dll | prebuilt x64 build of the above (MSVC) | malgrimia-tex-tools.zip

updated tools for broken weights

Interesting. My tool initially failed, but I have added support for it. Here’s a quick ’n dirty script for decrypting the bundles. Let me know how it goes. 👍 python .\holodreams.py "path\to\hololiveDreams\game\folder" "path\to\folder\for\decryption" # Example python .\holodreams.py "D:\Steam\steamapps\common\hololiveDreams" "D:\Steam\steamapps\common\hololiveDreams\decrypted" holodreams.py

All in all, we’ve released a script for *300 Heroes*; anyone interested can test it and provide feedback regarding any bugs. https://github.com/DennisHerrm/io_scene_eg3d-1.14.0-300-Hero-importer-

Each bundle uses a unique key derived from a password and its filename. Give the script a try and let me know if you run into any issues. 👍 # Make sure the cryptography package is installed before running the script python -m pip install cryptography python .\decrypt_srwy.py "path\to\folders\with\bundles" decrypt_srwy.py

Hi @Falkrian , thank you so, so much!!!! It worked perfectly, and all the textures are displaying flawlessly. I truly appreciate it from the bottom of my heart! 🙏

The ZSTD compress algorithm is hide into the exe About the script udpate , i have done an update .. perfectible but it work i haven't share it before because no one have give me a response to test it deeper scripts.npk, shaders and mtlgen can be unpack all .pyc from the script.npk still have a ZSTD compression Once_Human_NPK_2026.7z

@UZ.- simple .pak unpacker. Extracted data might be compressed i think, need deep analysis, but .png images not compressed unpack.py

Hi @Hazza12555 Thank you so much for your help! It worked perfectly and extracted all the textures without any errors! I hope you have a great day! You’re very smart! Best regards!

You can use this Blender plugin to import and export *.dff models form RenderWare and GTA https://github.com/Parik27/DragonFF

@Falkrian Just tried your script on the Chinese (2011-04-11) & Korean (2026-05-08 & 2025-12-17) version but it doesn't seem to get the key right, the version I'm working with can be found on archive.org (don't wanna link it cause anti piracy rules and stuff) Config0000.zip

@DKDave, @wq223 and @Champs: hi! I'm trying to create an Italian localisation for Once Human and I'm currently stuck with the newer script.npk format. I noticed the discussion about COMP_TYPE 4, ZSTD, the 28 B5 2F FD magic number, and Champs' updated BMS script. neox-tools detects my script.npk as NPK Version 2 but cannot unpack it (embedded file names), while older tools don't work correctly either. Does anyone still have the updated BMS script mentioned by Champs, or know where I could find it? I'd be happy to test it on the current Steam version and provide samples if needed. Thanks!

I checked a few other titles and found the same build mask in each one: Bladequest Anesthetic Dissension Resonant Dusk Concealment 22 80 3E 61 22 4B 54 20 54 15 25 08 E3 10 A9 24 16 AE 8A BF A3 34 0A 30 B3 80 DB 8F 62 1C B1 8EAt this point, it looks like the same build mask is reused across other titles as well. 😋

Hi. Thanks. I read the blog article and it was pretty interesting. Good job with all the findings. If you want to make your script more generic in the future, I have a long list of Leadwerks password-protected games which you can test your script on and adjust if needed :D Anesthetic (PC) Bladequest (PC/Steam) Crazy Auto Present Dash (PC) Crazy Scorpion (PC) d4Shmup (PC) Despair of Ordinary Man (PC) Dissension (PC) Dread Loop (PC) Dungeon Skunk (PC) Dwarf Beard (PC) FPS Game Demo (PC) FotoMuseo 3D (PC/Steam) Grimlight (PC) Halloween Pumpkin Run (PC) Hanks Funhouse (PC) Hause in the Hollow (PC) J-TRAIN (PC) Last One Standing Wins (PC) Little Dagon (PC) LockDown (PC) Lone Water: Prologue (PC) Next Monday (PC) Nightmare (PC) Oblique (PC) One More Day (PC) Present Hunt (PC) Realm of the lamb (PC) Rogue Snowboarding (PC) Run Jump Climb (PC) Science (PC) Sentinal Defect (PC) Sewer Survival (PC) SIEGE (PC/Steam) Slafstraf 2 (PC) Snow Rider (PC) Sot Kaal (PC) Sound Game (PC) The Borrower (PC) The Garden (PC) The Mower (PC) Twisted Minds Demo (PC) Vectronic Demo (PC) White Out (PC) Wolf Tale (PC) Zelrio (PC) Zombiezi (PC)

Did some manual testing using LZSS0 / BGRA5551 / Morton - seems correct

I have researched this container. Format BLK\PLK. struct Entry { u32 offset; }; struct File { u32 count; Entry entries [count]; u32 allFileSize; }; File a @ 0x0;And simple extractor, possible drag-and-drop file on .py script to extract all data. In PLK contains pvr images, other data in container not researched, save as raw data. extractor.py

Hi, I'm trying to figure out how bone flags work in the game, since I'm working with some friends on exporting/importing models for this game. Unfortunately, I don't want to be selfish by not sharing the page (since we built it in HTML), but I can't post links like that. I'll send you a sample of what I've been working on for the game. The problem is this: The game expects bone flags that I don’t quite understand yet, since the vertices explode or get messed up. I’ve only managed to get as far as what’s shown in the image; I haven’t quite succeeded yet. I’ve run many tests, but honestly, I don’t understand it. I also tried looking into the source code, but I didn’t find anything. Maybe someone with some free time could help me achieve the perfect port. If so, I’ll give you credit on my GitHub when I release my HTML (along with the code resources). I’ll include samples of what I’ve managed to do, as well as samples of the original files and the buuhan file Since I can't convert URLs like GitHub or downloads, I'm going to post the monstrous HTML I created for editing DBL files. Also, if you don't want to use the .bms file, I'll post the other HTML I've been working on to view .dbu files (replace/extract files) from the content files.rar image.pngimage.png files.rar

I just figured it out at meet the robinson. It use same skeleton. Here is struct. Alot of unknowns and guess work. float Rotation[12]; float Transform[3]; float Scale[1]; float Matrix4x4[16]; uint32 Unknown_0; uint32 Unknown_1; ubyte Unknown_2; ubyte Unknown_3; ubyte Unknown_4; ubyte Unknown_5; uint32 Unknown_6; uint32 Unknown_7; float BBoxMin[3]; float BBoxMax[3]; float BBoxRadius; char BoneName[16]; uint32 Unknown_8; uint32 ParentBoneId; ubyte Unknown_9; ubyte BoneId; ubyte Unknown_10; ubyte Unknown_11; uint32 Unknown_12; float BBoxMin0[3]; float BBoxMax0[3]; byte Reserved[8];

Wow it looks like mere one step away from the destination

Solved with IA. Sprites compréssed with LZRW1-KH

I don't have an issue with audio files atm at least for the PS2 version I am mostly done with the mod all I need to do is make texture changes. What I'm trying to change are text files in the game, they are in texture form. Since the game only got released in english and got the 4kids dubbing there was a lot that was changed in translation that doesn't make sense with the actual one piece story like characters' names and other stuff.

Here are my findings for both gamedata.fat and gamedata: gamedata.fat Contains the file allocation table and is zlib compressed. It contains a list of numeric resource IDs and offsets for the main archive after decompression. gamedata One of the many archive and contains a lot of zlib compressed resource bundles. Every bundle contains one or more Onyx engine objects, which are identified by numeric class hashes instead of file names or extensions. These files belong to Ubisoft's proprietary Onyx Engine. So far I have managed to get all texture objects and converted them to PNG for viewing pleasure. Still figuring out the rest...

Release on github for us!

Hey everyone, I absolutely love the animations in Marvel's Spider-Man 2 — does anyone know how I can extract animations from this game?