Leaderboard

I don't know if there are more models in that unpacked folder, you need to check that so examine each file there. Just remember that characters use shorts in vertices buffer, I think I saw other file with floats but maybe that file is not a character or maybe it is but with floats, I really don't know, lol. Here is the script if you want to test it: fmt_black_ps2_prototype_DB.py

The "repeated offsets" pointing to new blocks indicate that the main BIGFILE.CAT is acting as a master container that holds smaller, self-contained archives inside it. The Master Index: Points to large chunks of data (e.g., "Level 1 Data", "Level 2 Data"). The "New Block": When you go to that offset, you find a new header (signature 01 00 01 00). The Inner Index: This new header has its own list of files. Because this block is treated as a standalone file by the game engine once loaded, its offsets start at 0 (relative to the start of that block), not relative to the start of the whole disc. [ MASTER CAT (BIGFILE) ] |-- Header |-- Index Entry 1: Offset 1000 -> Points to "Level 1 Block" |-- Index Entry 2: Offset 5000 -> Points to "Level 2 Block" | |... [Data at Offset 1000] ... | +-> [ NESTED CAT (Level 1) ] |-- Header (starts at Master Offset 1000) |-- Index Entry A: Offset 10 (Absolute: 1010) |-- Index Entry B: Offset 50 (Absolute: 1050) |-- Data... Why did developers do this? (The Logic) This approach was necessary due to the hardware limitations of the PlayStation 1 (PS1): RAM Constraints: The PS1 has only 2MB of RAM. It cannot keep a massive table of thousands of file offsets in memory at all times. Modular Loading: The game loads the "Master Index" to find the location of the current level's data. It then streams that specific "Block" (Nested CAT) into memory. Relative Addressing: Once the "Block" is loaded into a specific memory address, the game engine reads the inner offsets. Since these offsets are relative to the start of the block (0), the engine can easily calculate memory pointers without needing to know where the block was originally located on the CD.

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

This is actually very helpful. Thank you. I seen the same repeating groups of ~10 unsigned 16-bit value and came to a similar conclusion. The constants like 0, 1632x (~0x3FCx), 21845 (0x5555), 39322 (0x999A), 43691 (0xAAAB), 52429 (0xCCCC), 56798 (0xDDDE), 63488 (0xF800) hex patterns are classic fixed-point / normalized values (fractions of 0xFFFF), which is exactly what you’d expect for compressed curves (rotations, maybe scales or tangents)... I am not 100% sure though. Your step back that you are seeing is because multiple tracks/bones are interleaved via small index tables or there’s a separate header that says “keyframe list starts at X for track Y. I have not figured it out. Also, I am only assuming. It is an educated guess. 2d72 1100 looks more smooth because it is probably for the static pieces. That is also a guess. I don't really know. I haven't found a clean stride/format yet from any area to the extent I was happy with any result. Thankfully your poking proves it isn't baked matrices. However, it might have "junk" data inside of it or switch between the two different formats on the fly which would have a call/read from the game engine the game was made with "elf statements/running". For the last two days I have been looking for a header or track and still haven't found one. I don't know what the meaning "definition" for each of the 10 values per entry (time? quat? s,t,r? tangents? flags?). Also haven't figured out how these numbers convert back to usable floats/matrices for a bone rig. You found the right haystack to be looking for the needle here and I thank you for this. The repeated 16-bit values like 0x3FCx, 0x5555, 0xAAAA, 0xF800, and the way they change over “time” gave light on this. That matches my expectation that GARO is storing proper animation curves rather than just baked matrices which most people would have assumed because of the static model additive animations. Sorry for repeating myself here. I have a client for this game that is CONSTANTLY having me repeat over and over some of this information and it started to turn into habit. Going back to the “step back” jumps you pointed out I believe show the timeline might be split into several blocks (per-bone or per-channel segments) instead of one clean linear stream, which is probably why tools that only understand standard RWANM fail on this game. I don’t have much experience with your viewer. The tools I use are far different and I have been doing a lot of direct hex poking along with using renderware tools, so I’m still trying to figure out the parameters you showcase here. When you mention 2d72 1100 in step 3, is that essentially a stride / FVF setup you’re using to visualize the data as a point cloud? That was my original assumption but now I am second guessing myself. Do you have any thoughts yet on how those 10-value records break down (e.g. time + rotation + something else), or on where the per-track headers might sit? You helped a lot with this and I am very thankful.

the lvl file is essentially like a zip/container file containing a bunch of .rbm/.rba (CAFF) files and the .rbm/.rba files are basically containers with the data for any given asset, eg models will include a model(header), scenegraph, textures and may additional things like hits/animation data packed inside too if its relevant to the model and/or not shared between a bunch of other models in which case they are usually packed inside the zpackage rbm files.

As per i am a good for nothing in 3d model issues., i can´t tell if te unpack works, but studying DB, i can see 2 types of TOC. Attached the py script, if someone wants to take a look. just drop the files DB or bins in .py or double click in .py black_ps2_unpack.py

Hmm, you know there's some hero here who got the trick for PS2? I couldn't get over myself to make use of his dll but it's my firm decision to tackle this and I'll tell the result as soon as I get it working for me. (If it works there's several dozens of PS2 projects I'd need to correct and I fear the amount of work, somehow.) (It's my bet that it has to do with changing the face winding and I'd like to find it out by myself instead of using other people's dll.)

Sounds complicated. Anyways, in gar.rws.dec_be_-15_anim_77.rwanm I found parts which might be animation curves. But the timeline looks somehow cut in pieces. Not talking about gaps (which might be filled by interpolated frames, as you may know), it's these steps "back in time," haha. address 0x10c8: 4392 0 48060 16315 0 0 61541 30111 24841 63488 62256 4416 0 48060 16315 32768 0 21047 30717 23725 63488 62256 4440 0 0 16320 53301 30676 22558 24629 63330 63488 63488 step back? 4152 0 26214 16358 0 0 24224 30693 29960 63488 62256 4176 0 0 16320 52246 24488 61447 30130 30720 63488 62256 4464 0 0 16320 29178 29826 41088 49358 58949 63488 62256 one single interruption? 2616 0 0 16320 19549 62621 53216 29139 26173 63488 62256 4512 0 0 16320 57603 60936 21535 30255 58578 63488 62256 4536 0 0 16320 0 0 61231 30230 24841 63488 62256 4560 0 0 16320 57771 18609 21233 30669 23725 63488 62256 4584 0 0 16320 54112 29811 54832 29180 26173 63488 62256 4608 0 0 16320 25814 28071 57693 30186 58578 63488 62256 4632 0 0 16320 0 0 61565 30096 24841 63488 62256 4656 0 0 16320 52935 22002 20388 30710 23725 63488 62256 4680 0 17476 16324 28679 28658 61447 61426 63420 30697 62911 one single int/ step back 3024 0 17476 16324 44238 15564 43253 30720 57885 63488 62256 address 0x1228: 4248 0 17476 16324 29178 29826 11892 49786 58949 63488 62256 4776 0 17476 16324 20137 62612 53593 29149 26173 63488 62256 4800 0 17476 16324 57236 61086 21117 30230 58578 63488 62256 4824 0 17476 16324 0 0 61456 30162 24841 63488 62256 4848 0 17476 16324 62036 28766 59130 28692 23725 63488 62256 4872 0 17476 16324 54297 29800 55031 29192 26173 63488 62256 4896 0 17476 16324 26484 27725 58682 30174 58578 63488 62256 4920 0 17476 16324 0 0 61606 30070 24841 63488 62256 4944 0 17476 16324 55822 24945 19244 30661 23725 63488 62256 4968 0 34953 16328 53047 30677 22461 24619 63330 63488 63488 step back 4704 0 17476 16324 52133 24362 61452 30130 30720 63488 62256 4752 0 52429 16332 28686 28644 61454 61412 63418 30697 62906 4992 0 21845 16341 10682 15408 39411 30720 57885 63488 62256 5016 0 39322 16345 29178 29826 43782 50136 58949 63488 62256 5040 0 34953 16328 20579 62599 53912 29163 26173 63488 62256 5064 0 34953 16328 56688 61223 20816 30203 58578 63488 62256 address 0x1388: 5088 0 34953 16328 0 0 61592 30079 24841 63488 62256 5112 0 34953 16328 62115 28717 61186 26846 23725 63488 62256 5136 0 34953 16328 54424 29790 55156 29204 26173 63488 62256 5160 0 34953 16328 27053 27110 59618 30138 58578 63488 62256 5184 0 34953 16328 0 0 61665 30032 24841 63488 62256 5208 0 34953 16328 57532 26626 19092 30549 23725 63488 62256 5232 0 34953 16328 52021 24237 61456 30129 30720 63488 62256 5280 0 52429 16332 53754 30675 55574 57291 63330 63488 60606 one single step back 4488 0 52429 16332 20774 62580 54116 29185 26173 63488 62256 5376 0 52429 16332 56853 61202 20694 30206 58578 63488 62256 5400 0 52429 16332 0 0 61788 29946 24841 63488 62256 5424 0 52429 16332 62044 28380 61696 26151 23725 63488 62256 5448 0 52429 16332 54547 29777 55268 29218 26173 63488 62256 5472 0 52429 16332 27445 26230 60149 30073 58578 63488 62256 5496 0 52429 16332 0 0 61728 29989 24841 63488 62256 5520 0 52429 16332 58316 27162 19461 30435 23725 63488 62256 address 0x14e8: 5544 0 39322 16345 52592 30677 22509 24635 63330 63488 63488 5256 0 21845 16341 52111 24340 61455 30128 30720 63488 62256 5568 0 0 16384 28686 28644 61454 61412 63326 30697 62825 5304 0 43691 16362 30693 57026 15938 9533 26173 63488 62256 strange 576 0 4369 16337 20851 62555 54153 29215 26173 63488 62256 5616 0 4369 16337 57604 60892 21068 30267 58578 63488 62256 5640 0 4369 16337 0 0 62039 29750 24841 63488 62256 5664 0 4369 16337 62168 28395 61422 26828 23725 63488 62256 5688 0 4369 16337 54672 29762 55334 29235 26173 63488 62256 5712 0 4369 16337 27496 25516 60464 30038 58578 63488 62256 5736 0 4369 16337 0 0 61802 29936 24841 63488 62256 5760 0 4369 16337 58935 27260 19496 30384 23725 63488 62256 5784 0 43691 16362 53606 30676 55498 57321 63330 63488 60606 5592 0 21845 16341 20844 62524 54074 29253 26173 63488 62256 5904 0 21845 16341 58154 60378 22229 30354 58578 63488 62256 5928 0 21845 16341 0 0 62292 29517 24841 63488 62256 address 0x1648: 5952 0 21845 16341 62256 28360 60963 27198 23725 63488 62256 5976 0 21845 16341 54773 29744 55367 29255 26173 63488 62256 6000 0 21845 16341 27366 25291 60654 30032 58578 63488 62256 6024 0 21845 16341 0 0 61886 29873 24841 63488 62256 6048 0 21845 16341 59449 27129 19091 30370 23725 63488 62256 6072 0 43691 16362 0 0 24688 30684 29960 63488 62256 step back 4224 0 21845 16341 19132 57034 61493 30107 30720 63488 62256 step back 3264 0 39322 16345 14059 16222 10554 30720 57885 63488 62256 5328 0 39322 16345 20817 62489 53965 29295 26173 63488 62256 6120 0 39322 16345 58505 59791 23174 30435 58578 63488 62256 6144 0 39322 16345 0 0 62518 29271 24841 63488 62256 6168 0 39322 16345 62322 28254 60582 27535 23725 63488 62256 6192 0 39322 16345 54856 29727 55388 29274 26173 63488 62256 6216 0 39322 16345 27173 25274 60786 30038 58578 63488 62256 6240 0 39322 16345 0 0 61964 29812 24841 63488 62256 6264 0 39322 16345 59711 26929 17414 30364 23725 63488 62256 address 0x17a8: 6288 0 39322 16345 52220 24462 61451 30128 30720 63488 62256 and so on 5832 0 43691 16362 19209 57095 61486 30110 30720 63488 62256 6336 0 56798 16349 15191 16672 12805 30720 57885 63488 62256 6360 0 56798 16349 29178 29826 46966 49975 58949 63488 62256 5352 0 56798 16349 20837 62449 53905 29341 26173 63488 62256 6384 0 56798 16349 58615 59023 23685 30505 58578 63488 62256 6408 0 56798 16349 0 0 62719 29013 24841 63488 62256 6432 0 56798 16349 62391 28041 60163 27919 23725 63488 62256 6456 0 56798 16349 54925 29711 55403 29292 26173 63488 62256 6480 0 56798 16349 27014 25159 60900 30044 58578 63488 62256 6504 0 56798 16349 0 0 62028 29759 24841 63488 62256 6528 0 56798 16349 59959 26765 47430 30348 23725 63488 62256 6552 0 43691 16362 52854 30676 22596 24625 63330 63488 63488 edit: using 2d72 1100 in step 3 will give some more obvious animation curves, imho edit 2: press 'mesh' to get the visualization. (toggle 'PtCld' to 'noPtC' and press 'table' to get the timeline list)

For the selected values in rectangles you may start at 0x208, 0x20A or 0x20C - none of the point clouds looks promising.

Ok, thanks. You rule that format (besides the anims). I'll check the files tomorrow. (If I can't help maybe someone else can, with all the files provided.) Good night. edt: well, being more the "simple analyzer" I focussed on the skeleton (21 bones?) in the dff file and the gar.rws.dec_be_-15_anim_27.rwanm: I think the 5th column here could be the frame time in msec with translation and rotation values to follow: address 0x1b6: 30486 29945 63488 29628 58856 65209 0 0 51393 54393 57171 30685 30720 63488 29628 58856 65209 0 0 32768 32768 59982 30502 59743 63488 29628 58856 65209 34953 15752 0 0 0 30720 63488 63488 29628 0 0 34953 15624 61841 59913 29289 27424 63488 30459 59522 24 0 34953 15624 22619 21982 18934 30704 58259 63488 29628 48 0 34953 15624 30430 60362 20288 17433 25922 63488 29628 72 0 34953 15624 30136 28721 52832 21347 59344 63488 29628 96 0 34953 15624 48489 62528 16374 29259 25922 63488 29628 120 0 34953 15624 60085 59294 26987 30152 58965 63488 29628 144 0 34953 15624 0 0 62248 29560 24551 63488 29628 168 0 34953 15624 15843 53973 27979 30346 23143 63488 29628 192 0 34953 15624 53430 29725 53792 29292 25922 63488 29628 216 0 34953 15624 26788 24635 22352 30525 58965 63488 29628 240 0 34953 15624 0 0 61788 29946 24551 63488 29628 264 0 34953 15752 22777 25316 22954 30638 23143 63488 29628 288 0 34953 15624 61008 30170 26220 address 0x316: 13303 63488 63488 28399 312 0 34953 15624 0 0 27758 30398 29945 63488 29628 336 0 34953 15624 7522 11482 59715 30545 30720 63488 29628 360 0 34953 15752 32768 32768 59982 30502 59743 63488 29628 384 0 34953 15624 61466 29974 59213 57464 63488 63488 30720 408 0 34953 15624 0 0 28454 30232 29945 63488 29628 432 0 34953 15624 51986 54325 58411 30640 30720 63488 29628 456 0 34953 15752 32768 32768 59982 30502 59743 63488 29628 480 0 34953 15752 59840 61645 28387 29176 63488 30184 63488 528 0 34953 15752 21331 23096 25805 30620 58259 63488 29628 552 0 34953 15752 30629 58637 21582 16964 25922 63488 29628 576 0 34953 15752 30156 28689 53876 51939 59344 63488 29628 600 0 34953 15752 47599 62461 15165 29336 25922 63488 29628 624 0 34953 15752 59092 59464 28203 30010 58965 63488 29628 648 0 34953 15752 0 0 62825 28859 24551 63488 29628 672 0 34953 15752 52057 53845 27997 30341 23143 63488 29628 696 0 34953 15752 55057 29609 55317 address 0x476: 29406 25922 63488 29628 720 0 34953 15752 56171 26016 20052 30608 58965 63488 29628 744 0 34953 15752 0 0 61930 29839 24551 63488 29628 768 0 34953 15752 29497 62179 58598 22637 63488 63488 28399 816 0 34953 15752 0 0 28323 30266 29945 63488 29628 840 0 34953 15752 7817 11470 59999 30499 30720 63488 29628 864 0 34953 15752 29655 61689 27187 25651 63488 63488 30720 912 0 34953 15752 0 0 29009 29954 29945 63488 29628 936 0 34953 15752 52130 54326 59350 30587 30720 63488 29628 960 0 29287 16404 44589 16658 52439 //49164 29287 16404 44589 16658 9 16448 21 0 1 2 I checked 40 blocks with a size of 22 bytes but none of the point clouds resembled an animation curve (although you can get some points in a line sometimes).

Drag and drop .md6mesh files into the script it will convert them into obj files. md6mesh.py md6mesh.zip

there is a lot of overlap, in fact the Kameo alpha uses the exact same CAFF version as the Conker Demo. the lvl files are just an archive/container of sorts while the assets themselves are packaged inside individual "CAFF" containers. for example: the file struct is fairly basic for the LVL container itself(for imhex): struct LVL_ENTRY { u32 unk_00; u32* address : u32; }; struct LVL_FILE_TABLE { u32 count; LVL_ENTRY array[count]; }; LVL_FILE_TABLE table @ 0x00; they're similar in a sense that Conker stores the assets inside a "ZPackage" CAFF container instead of using an external container(.LVL) to store the individual CAFF assets. unlike the earlier games like GBTG kameo also stores a lot of data inside pushbuffer commands including things like the triangles/shaders/shaderparams. but as far as models go theyre very similar (as thats what i've spent the most time on) not sure about the other assets tho.

When debugging function 0010D850, I found these filenames in the t0 register (after the decryption result; it also loads the filenames of files with the .JRS header into memory): LOGO.JRS MAINSCRIPT.JRS SCENARIO.JRS SCENARIO00_ROMA.JRS SCENARIO00_ROMA_TGS.JRS SCENARIO00_ROMA_TRIAL.JRS SCENARIO01_EGOI.JRS SCENARIO01_EGOI_TGS.JRS RES/SCRIPT RES/SCRIPT/SC RES/SCRIPT/SC/00_ROMA RES/SCRIPT/SC/01_EGOI RES/SCRIPT/SC/02_TERO RES/SCRIPT/SC/10_KAISOU SCRIPT.SVL etc... The flow is: SCRIPT.PTD (disk) → [AT GAME STARTUP] → Decompress YKLZ → Decrypt .JRS → Load into PS2 memory --- Knowing this, I set a read/write/change breakpoint in the PS2 debugger after the initial file-loading process in RAM. In this case, I set it at 0056AC20 (which corresponds to `SCENARIO00_ROMA.JRS`), and as expected, this is the first dialogue shown in the Romantica route. 0011A010 (game_load_resource) ↓ 0010DED0 (file_system_wrapper) ↓ 0010DB58 (process_filename) → Converts "SCENARIO00_ROMA.JRS" to something ↓ 0010DC48 (binary_search) → Searches table using 0018E4FC (optimized strcmp) ↓ 0010DD98 (get_file_info) → Returns data_ptr (already in memory?) ↓ RETURNS to 0011A010 ↓ ...... 00106800 (PROCESS .JRS?) → UNKNOWN ↓ 001068D0 (FINISHES?) → Another unknown --- FUNCTIONS 0010DC48 – Binary Search - Searches for files in a master table sorted alphabetically (only to verify file calls are correct) 0010DD98– Get File Info - Returns data_ptr (already in memory), size, and flags 0010DED0 – File System Wrapper - Orchestrates the search and retrieval process 0011A010 – Game Resource Loader - Manages memory pool - Calls the entire system --- The only thing left to do is trace the flow and see what gets called after the .JRS file is loaded (which is obviously to process and render the text). With the information on how the game processes and displays text, we can process the previously extracted files from script.ptd to view the Japanese dialogues. I need to rest my brain… haha

There is a "thanks button" (just in case you didn't know).

animewwise just closes instantly if you try it on there. Regular wwise works https://github.com/mortalis13/Wwise-Unpacker BeyondToolsMod-net9.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...

This is the font game uses.

1. FILE STRUCTURE (script.ptd) | Offset | Size | Content | |--------|------|---------| | `0x00` | 32 bytes | **Header** with signature "PETA" (50 45 54 41) | | `0x20` | 256 bytes | **SBOX** (Substitution Box for decryption) | | `0x120` | 1,728,224 bytes | **Encrypted data** | 2. DECRYPTION & DECOMPRESSION PROCESS script.ptd → Decryption → YKLZ/LZSS → Binary Script 249 YKLZ/LZSS compressed sections found in decrypted data YKLZ/LZSS decompression works correctly 3. DECOMPRESSED SCRIPT ANALYSIS Header identified: `純ﾛﾏ = "JUNROMAN" Current issue:Shift-JIS Japanese text not found - appears encrypted even after decompression Example decompressed output: 純ﾛﾏ####@###ｼg##@###ﾄ###4.##X)##ｲ*##4... 4. SUSPECTED SCRIPT STRUCTURE?? [Shift-JIS Text] [Padding "####"] [Command "@" + 3 params] [More Text]... Parsing logic??? 1. Parser detects `@` (0x40) → Command indicator? 2. Reads next 3 bytes → Command parameters? 3. Processes Shift-JIS text (1-2 byte characters)? 4. Skips padding `#` (0x23) → Alignment bytes 5. GAME EXECUTION FLOW (pcsx2 debugger) fcn.0010e048 (Interpreter) ↓ fcn.0010ded0 (Parser) ↓ fcn.00119fc0 / fcn.0011a0ec (Handles dialogues?) ↓ fcn.00106800 (Context configuration) ↓ fcn.001068d0 (Text rendering) ↓ fcn.0016e400 / fcn.0016e4a8 (Unknown final processing) 6. CURRENT PROBLEM The text appears garbled/encrypted even after YKLZ decompression....... Additional encryption layer** after LZSS decompression??

*.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 first try on this .lwo format.

I think you've already set up the aes-key and the correct version of Octopath Traveler 0 (5.4) on fmodel. You need to add the usmap file, which I attached. To do this, go to Settings->Mapping File Path and select the game's usmap file. Then, in Fmodel, navigate to the correct folder (e.g., Content/Local/DataBase/GameText/Localize/EN-US/SystemText/GameTextUI.uasset) and export the file to .json, with right-click and then Save properties (.json).

I am attaching the fmodel json file. With uassetgui, what procedure did you follow to obtain that result? Maybe I'm missing something, as this is the first time I've used uassetgui. Edit: Ah ok, thanks, with .\UAssetGUI tojson GameTextUI.uasset GameTextUI.json VER_UE5_4 Mappings.usmap I can get the base64 code, but it is unreadable: ����������m_DataList�d��m_id��m_gametext��No data.�������������m_id�m_gametext��Held�������������m_id �m_gametext��None�������������m_id! GameTextUI_fmodel.rar

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.

ImageHeat v0.39.2 (HOTFIX) https://github.com/bartlomiejduda/ImageHeat/releases/tag/v0.39.2 Changes: - Fixed hex input - Changed endianess and pixel formats bindings (required for hex input fix)

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

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

I don’t know if this has any effect. https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=3547

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.

I used the file "tex_DeadSpaceMobile.py" from this GitHub link provided by Sleepyzay Here is the link Sleepyzay mentioned adding the script to the repository in a later post. When you have the file, just add it to the folder "noesisv4474\plugins\python" and you should be good to extract the textures after restarting Noesis or pressing "Reload Plugins" in the "Tools" category on the hotbar.

To whoever ends up here in the future, there is a really simple to use utility to convert files from Xbox ADPCM to PCM and vice-versa on Github: Sergeanur/XboxADPCM Thanks for the thread, I really thought the WAV files I had were lost forever due to an obsolete codec..! In my case, I am porting the PT-BR voiceover of Max Payne from PC to Xbox, which I am surprised wasn't done before.

make some ajustments! now its working

I'm trying my best to make it load somehow

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.

rename it to .awb files then use the lastest vgmstream, works well

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

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

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)

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