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

I'm trying my best to make it load somehow

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.

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 PS2, level_00, chardata.db it's a matter of assembling sub meshes (and maybe a better face creation algo):

The armature is with the model. When you import the DFF using DragonFF in blender it will have the armature with it. The bones are very small. You can use the side menu GUI to better find the bones. Models and Skeletons are 100% workable. It is the custom renderware animation format that is the problem here. In the files I uploaded in the topic post, there should be two rwanm files. Those are some of the animations. If you have the game I can give you one of my scripts that will extract everything for you so you can go through all the files for testing. I tried figuring this out through the elf file. Let me know if you want my script so you can poke at all the animations in the game. There are two different sets of animations per character even if they don't have a weapon. The animations specific for weapons would be much easier to look at since they are smaller. There are mot files that give some additional information but for the most part they are irrelevant. Mot files for this game is more of a listing of animations and positioning for static model pieces. Not the main animations. I am uploading the mot file so you can see it is mostly just for static pieces. The txt file for the character abbreviated with gar that states all the files for him and the gmobj data base text for it as well. I used a renderware tool "forgot the name of it" that allows me to look at how the files are structured. Sending you a section_tree.txt that was made by that program. I was offered a job to make a modding tool for this game that would include editing animations..... As it stands, I don't believe I will be able to finish it. Will just make everything I have for this game public if that happens. Adding two scripts as well. The gar_rws_test.py script does a simple test on the files for the correct compression to decompress the files so you can get everything basically. The garou_rws_extractor is a slightly upgraded version that needs work and is for extracting the models/animations. On aluigi's website there is a bms script called ougon_kishi_garo. That would be your first step to getting all the files out. Then you will have to use the scripts I posted here. The unfinished one will have errors. The test one will work better. gar_mot.rar gar_files_txt.rar gmobj_DB_Files_txt.rar Section_Tree_txt.rar gar_rws_test.py Garou_RWS_extractor.py

if there are any unreleased models they should be pretty easy to find, afaik most(probably all?) of the package files have the same checksums as the retail game (dvddata\aid\zpackage) - i cant say ive tested every single one but of the ones i have that has been the case. there are some other assets that are in the file system but i dont know if any are different, eg dvddata\aid\bfdmodel\characters\SinglePlayerVehicles\MachineGunTurret is actually the model shown in my original post, theyre not compressed so you can easily use a texture viewer to see if anything looks interesting (almost all textures are DXT1/DXT5) sometimes theyre just the same model as the original but with a larger texture, eg 512x512 instead of 128x128, the demo version of conker is an example of this as well, his texture on the demo is higher res than the retail game. if anything most of the "easter eggs" are probably buried in the original/actual game and just go un noticed, for example in one of my chats with Uber Winfrey he pointed out Berrys dresser has this ontop of it: or the gargoyle statues: safe to say the rareware guys had an interesting sense of humor. ------------------------------------------ as for any tool, the closest thing to it would be Uber Winfrey's blender script. Most of my work has just been around documenting the structs/data, and while extracting some of the raw data is easy enough there is still a ton of stuff that needs to be figured out like for example Animation data is still WIP and would probably need to translate the shaders for the model to look right eg Fur, Cloth, Shine etc since it uses old VSH/PSH shaders instead of HLSL, they're pre compiled so they need to be decompiled from binary data, figuring out the shader params and what/how they're used for etc. these aren't unsolvable problems but its definitely outside of my skillset which means even if i find time for it its going to be slow.

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

i used retool to get the files out, here are the raw files and textures sample.rar

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.

if you've already got the pck files from beyondtools. Try dragging the pck files from the main folder to this python script. Though this only partially extracts the language voicelines but it does extract almost all the music and sound effect files pck_decrypt.py

Got a point cloud character and some normals, edit: got rid of them:

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

The script has been updated and is now output in Lua format whenever possible. format_hotfix_data.py

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

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

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.

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.

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.

I found the solution. Use the pak.py python script (i uploaded) in the same directory as the .data file This will extract the UE4 .pak file from the .data file Since the version is 4.27, use the QuickBMS 4.27 Unreal Engine Script to extract all data! Then you can use UModel to extract models/audio etc! # Unreal Engine 4 - Unreal Tournament 4 (*WindowsNoEditor.pak) (script 0.4.27e) # script for QuickBMS http://quickbms.aluigi.org math NO_TAIL_INFO = 0 # set it to 1 for archives with corrupt/missing tail information (extract without index) math VERSION = 3 # set it to 3 if NO_TAIL_INFO = 1 for most of modern games quickbmsver "0.12" callfunction QUICKBMS_4GB_CHECK 1 # set your AES_KEY here as umodel hex ("0x1122...") or C string ("\x11\x22...") # don't change AES_KEY_IS_SET, it will be handled automatically set AES_KEY binary "" math TOC_FILE = 0 math ALTERNATIVE_MODE = 0 math AES_KEY_IS_SET = 0 math BASE_PATH_INCLUDED = 1 math DIR_FLAG = 1 math NAME_FROM_ARRAY = 0 math SKIP_COUNT = 0 get ARCHIVE_NAME basename get ARCHIVE_PATH FILEPATH math CHUNK_OFFSET_ABSOLUTE = -1 # default, enabled # 1 = HIT math WORKAROUND = 0 if NO_TAIL_INFO != 0 get OFFSET asize math ALTERNATIVE_MODE = 1 else goto -0xcc # version 11 (4.26-4.27) savepos MAGIC_OFF get MAGIC long get VERSION long endian guess VERSION get OFFSET longlong get SIZE longlong getdstring HASH 20 xmath SIZE "MAGIC_OFF - OFFSET - 1" get FSIZE asize savepos CUR_POS if CUR_POS = FSIZE string COMP1 = "" else get CHECK byte if CHECK > 1 goto -1 0 SEEK_CUR endif getdstring COMP1 32 getdstring COMP2 32 string COMP1 l COMP1 string COMP2 l COMP2 endif if VERSION >= 3 goto MAGIC_OFF goto -1 0 SEEK_CUR get ENCRYPTED byte if ENCRYPTED != 0 callfunction SET_AES_KEY 1 log MEMORY_FILE5 OFFSET SIZE encryption "" "" else log MEMORY_FILE5 OFFSET SIZE endif math TOC_FILE5 = -5 endif goto 0 callfunction GET_BASE_PATH 1 endif get FILES long TOC_FILE5 getdstring DUMMY 12 TOC_FILE5 get HASHES_OFFSET longlong TOC_FILE5 math HASHES_OFFSET - OFFSET get HASHES_SIZE longlong TOC_FILE5 getdstring DUMMY 24 TOC_FILE5 get NAMES_OFFSET longlong TOC_FILE5 math NAMES_OFFSET - OFFSET get NAMES_SIZE longlong TOC_FILE5 getdstring DUMMY 24 TOC_FILE5 savepos BASE_INDEX_OFF TOC_FILE5 goto NAMES_OFFSET TOC_FILE5 math CHUNK_SIZE = 0x10000 # just in case... for i = 0 < FILES callfunction GET_NAME_AND_OFFSET 1 if NAME = "" continue NEXT0 endif savepos TMP_OFF TOC_FILE get OFFSET longlong TOC_FILE get ZSIZE longlong TOC_FILE get SIZE longlong TOC_FILE get ZIP long TOC_FILE getdstring HASH 20 TOC_FILE math CHUNKS = 0 math ENCRYPTED = 0 if VERSION >= 3 if ZIP != 0 get CHUNKS long TOC_FILE for x = 0 < CHUNKS get CHUNK_OFFSET longlong TOC_FILE get CHUNK_END_OFFSET longlong TOC_FILE putarray 0 x CHUNK_OFFSET putarray 1 x CHUNK_END_OFFSET next x endif get ENCRYPTED byte TOC_FILE get CHUNK_SIZE long TOC_FILE endif #if ALTERNATIVE_MODE != 0 savepos TMP_OFF TOC_FILE math OFFSET + TMP_OFF #endif #comtype copy callfunction COMPRESSION_TYPE 1 if CHUNKS > 0 log NAME 0 0 append math TMP_SIZE = SIZE if CHUNK_OFFSET_ABSOLUTE < 0 && OFFSET != 0 getarray CHUNK_OFFSET 0 0 if CHUNK_OFFSET u< OFFSET math CHUNK_OFFSET_ABSOLUTE = 0 else math CHUNK_OFFSET_ABSOLUTE = 1 endif endif for x = 0 < CHUNKS getarray CHUNK_OFFSET 0 x getarray CHUNK_END_OFFSET 1 x math CHUNK_ZSIZE = CHUNK_END_OFFSET math CHUNK_ZSIZE - CHUNK_OFFSET math CHUNK_XSIZE = CHUNK_ZSIZE if ENCRYPTED != 0 callfunction SET_AES_KEY 1 math CHUNK_XSIZE x 16 endif if TMP_SIZE u< CHUNK_SIZE math CHUNK_SIZE = TMP_SIZE endif math CHUNK_OFFSET = OFFSET if ZIP == 0 log NAME CHUNK_OFFSET CHUNK_SIZE 0 CHUNK_XSIZE else clog NAME CHUNK_OFFSET CHUNK_ZSIZE CHUNK_SIZE 0 CHUNK_XSIZE endif math TMP_SIZE - CHUNK_SIZE math OFFSET + CHUNK_XSIZE next x append else # the file offset points to an entry containing # the "same" OFFSET ZSIZE SIZE ZIP HASH ZERO fields, # just an additional backup... so let's skip them savepos BASE_OFF TOC_FILE math BASE_OFF - TMP_OFF math OFFSET + BASE_OFF math XSIZE = ZSIZE if ENCRYPTED != 0 callfunction SET_AES_KEY 1 math XSIZE x 16 endif if ZIP == 0 math BLOCK = 0x40000000 xmath FSIZE "OFFSET + ZSIZE" log NAME 0 0 append for OFFSET = OFFSET < FSIZE xmath DIFF "FSIZE - OFFSET" if DIFF < BLOCK math XSIZE = DIFF if ENCRYPTED != 0 math XSIZE x 16 endif log NAME OFFSET DIFF 0 XSIZE else log NAME OFFSET BLOCK endif math OFFSET + BLOCK next append else clog NAME OFFSET ZSIZE SIZE 0 XSIZE endif endif encryption "" "" if ALTERNATIVE_MODE != 0 if CHUNKS == 0 math OFFSET + XSIZE endif goto OFFSET get TMP1 longlong get CHECK byte if TMP1 == 0 && CHECK != 0 goto OFFSET continue NEXT1 else goto OFFSET endif xmath CHECK "0x800 - (OFFSET % 0x800)" if CHECK <= 16 padding 0x800 endif savepos OFFSET get TMP1 longlong get TMP2 longlong if TMP2 == 0 padding 0x800 else goto OFFSET endif label NEXT1 endif label NEXT0 next i print "\nEntries ignored: %SKIP_COUNT%" for i = 0 < SKIP_COUNT getarray NAME 7 i print "Ignored entry: %NAME%" next i startfunction SET_AES_KEY_ASK math AES_KEY_IS_SET = 1 print "The archive is encrypted, you need to provide the key" if AES_KEY == "" set KEY unknown "???" else set KEY binary AES_KEY endif if KEY == "" math AES_KEY_IS_SET = -1 set AES_KEY string "No key provided, encryption disabled" elif KEY strncmp "0x" string KEY << 2 string AES_KEY h KEY else set AES_KEY binary KEY endif print "KEY: %AES_KEY%" endfunction startfunction SET_AES_KEY if AES_KEY_IS_SET == 0 callfunction SET_AES_KEY_ASK 1 endif if AES_KEY_IS_SET > 0 encryption aes AES_KEY "" 0 32 endif endfunction startfunction GET_BASE_PATH get NAMESZ long TOC_FILE5 getdstring BASE_PATH NAMESZ TOC_FILE5 if NAMESZ != 0x0A && NAMESZ < 0xFF string BASE_PATH | "../../../" math BASE_PATH_INCLUDED = 0 endif endfunction startfunction CHECK_UNICODE if NAMESZ >= 0 getdstring RESULT NAMESZ TOC_FILE5 else math NAMESZ n NAMESZ math NAMESZ * 2 getdstring RESULT NAMESZ TOC_FILE5 set RESULT unicode RESULT endif endfunction startfunction GET_NAME_AND_OFFSET if NAME_FROM_ARRAY = 1 if CURR_NAME < DIR_FILES getarray NAME 5 CURR_NAME getarray OFFSET 6 CURR_NAME goto OFFSET math CURR_NAME + 1 if CURR_NAME = DIR_FILES math NAME_FROM_ARRAY = 0 endif endif else if DIR_FLAG = 1 get DIR_COUNT long TOC_FILE5 math DIR_FLAG = 0 endif if DIR_COUNT = 0 math DIR_FLAG = 1 callfunction GET_NAME_AND_OFFSET 1 else math DIR_COUNT - 1 get NAMESZ signed_long TOC_FILE5 callfunction CHECK_UNICODE 1 string DIR_NAME = RESULT get DIR_FILES long TOC_FILE5 if DIR_FILES = 0 callfunction GET_NAME_AND_OFFSET 1 else for y = 0 < DIR_FILES get NAMESZ signed_long TOC_FILE5 callfunction CHECK_UNICODE 1 string NAME = RESULT string NAME p "%s%s" DIR_NAME NAME if BASE_PATH_INCLUDED == 0 string NAME p "%s%s" BASE_PATH NAME endif putarray 5 y NAME get OFFSET long TOC_FILE5 savepos TMP_INDEX_OFF TOC_FILE5 if OFFSET != 0x80000000 && OFFSET != 0x7FFFFFFF xmath INDEX_OFF "BASE_INDEX_OFF + OFFSET" goto INDEX_OFF TOC_FILE5 get FLAGS long TOC_FILE5 xmath HAS_SIZE "FLAGS & 0x3F" xmath IS_64 "FLAGS >> 28" if HAS_SIZE = 0x3F get CHUNK_SIZE long TOC_FILE5 endif if IS_64 = 0xE get OFFSET long TOC_FILE5 else get OFFSET longlong TOC_FILE5 endif else putarray 7 SKIP_COUNT NAME math SKIP_COUNT + 1 string NAME = "" putarray 5 y NAME endif putarray 6 y OFFSET goto TMP_INDEX_OFF TOC_FILE5 next y math NAME_FROM_ARRAY = 1 math CURR_NAME = 0 callfunction GET_NAME_AND_OFFSET 1 endif endif endif endfunction startfunction COMPRESSION_TYPE if COMP1 = "" comtype zlib endif if ZIP = 1 && COMP1 = "zlib" comtype zlib elif ZIP = 1 && COMP1 = "zstd" comtype zstd elif ZIP = 1 && COMP1 = "oodle" comtype oodle elif ZIP = 1 && COMP1 = "lz4" comtype lz4 elif ZIP = 1 && COMP1 = "gzip" comtype gzip elif ZIP = 2 && COMP2 = "zlib" comtype zlib elif ZIP = 2 && COMP2 = "zstd" comtype zstd elif ZIP = 2 && COMP2 = "oodle" comtype oodle elif ZIP = 2 && COMP2 = "lz4" comtype lz4 elif ZIP = 2 && COMP2 = "gzip" comtype gzip elif ZIP = 3 || ZIP = 4 || ZIP = 0x10 # 3 - Faith of Danschant, 4 - Days Gone, 10 - Ashen comtype oodle if WORKAROUND == 2 comtype lz4 endif endif endfunction startfunction QUICKBMS_4GB_CHECK math TMP64 = 0x10000000 math TMP64 * 16 if TMP64 == 0 print "You must use quickbms_4gb_files.exe with this script!" cleanexit endif endfunction pak.py

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

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

Please use this updated script to repackage the data file. If you have any questions, please let me know so that other capable people or you can continue to process these .pxc files yourself # Update the decompression of pxc file（script 0.2） get FILE_SIZE asize xmath TOC_PTR "FILE_SIZE - 8" goto TOC_PTR get TOC_OFFSET long goto TOC_OFFSET get FILE_COUNT long for i = 0 < FILE_COUNT get OFFSET long get SIZE long get COMP_FLAG byte get NAME_LEN short getdstring NAME NAME_LEN get UNK long savepos TOC_ENTRY_POS if COMP_FLAG == 0 goto OFFSET getdstring MAGIC 4 if MAGIC == "PxZP" comtype zlib get UNCOMP_SIZE long get COMP_SIZE long savepos DATA_START clog NAME DATA_START COMP_SIZE UNCOMP_SIZE else log NAME OFFSET SIZE endif else goto OFFSET get MAGIC long get UNCOMP_SIZE long get COMP_SIZE long savepos COMP_START clog NAME COMP_START COMP_SIZE UNCOMP_SIZE endif goto TOC_ENTRY_POS next i pxc.zip

For this format it's not as hard as you may think of. It's just a matter of persistent search which some people lack of and leave it to guys like me... Be that as it may, here's a H2O example, copy the 6 lines into notepad, for example, and save as ch0001_01_whatever. Rename the .txt file to .H2O then and load the model and the H2O file into hex2obj. Press the 'mesh' button. 0x951408 11085 Vb1 32 99 0x8F8A68 5239 021010 0x0 255 ch0001_01 obj.bin seems to contain different meshes: And the start address of the concerning FI block is unknown: Being bored by this annoying FIs' start address search for each sub mesh I used meshlab again:

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

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.