Leaderboard

This looks correct. The palette is RGB5551, but is swizzled with the same method as the image (not the standard PS2 palette shift). Patrick should be able to confirm if that can be added to ImageHeat as a palette swizzle option.

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

You'd be better using ImageHeat, as it has more options for swizzling, etc. For these, the image is PS2 swizzled, but I can't work out the palette. It doesn't seem to use any of the standard PS2 palette formats, maybe a different swizzling method. This is from "t_compact_rockangelz_closed_00000003":

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

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

https://github.com/bartlomiejduda/ImageHeat/releases/tag/nightly

Sometimes there's a 2nd uv channel. Do you mean that? (In another case one could also double special vertices to get the same amount like uvs but I forgot how to do that... iterate through faces, somehow. edit: found it, answer from Daniol Dan, ""thus each vertex has its own single UV coord"" Not sure whether this will apply to your problem, though.

Hello! Out of boredom, I decided to replace texture from a Godot game, in this case Slot or Not, by using Python but failing and failing over again exhausted me. My script has data and their MD5 hash code replacement, and data header change. I doubt that something doesn’t work or they are others data somewhere. I also think even if both WebP data from Godot and PIL are working, their data processing are different thus incompatible. Not even replacing them with PNG data works. I suspect there is a checksum for PCK somewhere. I compared its PCK file with Super Mario 127’s. Although the WebP data for CTEX and STEX are the same, the data pointers in SM127 are at the start of the file, after the header; SoN are at the bottom. The PCK for V1 is documented in Xentax wiki but not for V3. It may be small but this comparison shouldn’t be dismissed. What I need: If there is a checksum for PCK, where it is? The Bytes leading to the data header thus making the Python script adaptable If the WebP data is the issue, a better understanding of Godot’s WebP data Feel free to reply if you find anything! Slot or Not (PCK File V3) son PCK File.zip Godot Picture Replacer Script (Work in progress) Godot Pictures Replacer Script.py Note for the creator of Slot Or Not, you don’t have to turn it into an moddable game. The game need its own resource to be good game. I do this because why not and for research purpose. Knowledge GODOT PCK FILE FORMAT (Little Endian) (From Slot or Not) HEADER (112 Bytes) 4 Bytes = Signature ("GDPC") 4 Bytes = 03 00 00 00 (Engine Version) 4 Bytes = 04 00 00 00 (Major) 4 Bytes = 05 00 00 00 (Minor) 4 Bytes = 00 00 00 00 (Revision) 4 Bytes = 02 00 00 00 4 Bytes = 70 00 00 00 (First File Pointer) 4 Bytes = 00 00 00 00 4 Bytes = File Numbers 4 x 19 Bytes = 00s (Reserved) DATA HEADER (Found at the last part of the file) 4 Bytes = Length of Path, Including the 00s X Bytes = Path Name + 00s (If not divisible by 4) 8 Bytes = Data Pointer - 112 8 Bytes = File Size 16 Bytes = Data MD5 Checksum 4 Bytes = 00 00 00 00 GODOT CTEX FILE FORMAT (Little Endian) For WebP Format { 4 Bytes = String GTS2 4 Bytes = Use Alpha or Not (01 = Yes; 00 = No) 4 Bytes = Height 4 Bytes = Width 4 Bytes = 00 00 00 0D 4 Bytes = FF FF FF FF 4 x 3 Bytes = 00s (Reserved?) 4 Bytes = 02 00 00 00 2 Bytes = Height 2 Bytes = Width 4 Bytes = 00s 4 Bytes = 05 00 00 00 4 Bytes = Data Size after this Byte 4 Bytes = String RIFF 4 Bytes = WebP Data Size after this Byte 8 Bytes = WEBPVP8L / Tag for Loseless Encoded Image Data 4 Bytes = Data Size (or Data Size - 1 if WebP Chunk ends with 00) (Rest of the File) X Bytes = WEBP VP8L Chunk (On Python, the settings are Loseless = True, EXIF = False) 0-15 Bytes = 00 for Fill Up if the CTex Data Size isn't a divisible of 16 } [NOTE: You can get the WebP data by removing the GTS2 Header.] For PNG Format { X Bytes = PNG File Data 0-15 Bytes = 00 for Fill Up if the CTex Data Size isn't a divisible of 16 } X Bytes = String for [Remap], Settings, Path, Texture, Vram X Bytes = 00s (if the length the String isn’t a divisible of 16)

UModel is mis-parsing the package, usually because the game’s UE2 fork / package format doesn’t match what UModel expects with the current settings. Umodel to my knowledge works with this game. Your settings are not correct. I will elaborate using your error. FArray::Empty: -116 x 12 UModel tried to allocate an array with -116 elements of 12 bytes each. A negative element count is impossible, so the size overflows to a negative number (-1392) and appMalloc blows up. UModel is reading the wrong structure at that position (e.g., thinks this field is “NumVerts” but it’s actually some other 32-bit value), because the package layout / engine profile doesn’t match what UModel expects for “game=ue2” in this case. The rest of the stack confirms it dies while trying to load a skeletal mesh from that .ukx, not on textures or trivial data. In easy to understand terms. "wrong assumptions about how this game’s .ukx stores its skeletal meshes". Umodel should have a selection on the side for where you can pick game targets. If the game isn't there then you might be out of luck. However, I think this game shares a target with another game. Just trial and error to see if any of them work. Also, if this is not a "PC" version of the game you need to change the "Auto" on the bottom right of the gui to the specific platform. I know the topic says PC. People do make mistakes. Unreal Engine 2 games are rare and few in between. Not many people cared to work with any of them. Even the Wheels of Time game didn't get much investment. Also, turn off all forms of textures/material when first trying with unreal engine 2 games to speed up the process especially with whack a mole trial and error. The only people that would even bother adding support to this game which is extremely unlikely are on Gildor's forum. Again, very few people would ever care for an Unreal Engine 2 or 1 game. I am sorry if this wasn't helpful.

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.

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

I am uploading all animations for the character gar here. I should have done that in the previous post but it slipped my mind. So now you have a complete set of animations for one character. gar.rws.dec_be_-15_extracted.rar

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

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

Drag and drop .resources files into the script this will extract all of it's content from there. (Developed for the Reloaded exe version, no errors there) Next Steps: BMD6MODEL/BMODEL - https://reshax.com/topic/18566-wolfenstein-the-new-order-wolfenstein-the-old-blood-bmd6modelbmodel-files/#comment-101213 BIMAGE - https://reshax.com/topic/18567-wolfenstein-the-new-order-wolfenstein-the-old-blood-bimage-files/#comment-101214 STREAMED.RESOURCES - https://reshax.com/topic/18568-wolfenstein-the-new-order-wolfenstein-the-old-blood-streamedresources/#comment-101215 VIRTUALTEXTURES - https://reshax.com/topic/18569-wolfenstein-the-new-order-wolfenstein-the-old-blood-pages-virtualtextures/#comment-101216 wolfesntein_resources.py wolfesntein_resources.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

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

D:\88>py mot_rotation_extractor.py CHARA_POSE_SVT_0088_S01.mot arm_r 0 4.889439125475239e-10 0.5407554599817733 1.4406841468094752e-05 0.8411798453911885 1 -6.857191399194769e-10 -0.6332053752420114 -1.7710689242085512e-05 0.7739838192436295 2 9.680781275471423e-10 0.7419904178008506 2.197732230619127e-05 0.6704104857538526 3 1.168805020248789e-09 0.7357420612946057 2.3368850020973145e-05 0.6772618538614599 4 1.949070875265381e-09 0.9986487356304239 3.447117855729147e-05 -0.05196827527918962 5 1.8955871688974175e-09 0.7756976401807586 2.9743424602522006e-05 0.6311047220020868 6 2.5455886772310853e-09 0.878827057772032 3.542967924363111e-05 0.4771404418748128 7 3.226245697914568e-09 0.9417279975589877 3.9870071014519985e-05 -0.3363753513917405 8 4.099035407402478e-09 0.999881701599271 4.486528620122835e-05 -0.015381183116150696 9 4.475697367806648e-10 0.09022508301908228 4.352295069325249e-06 0.9959213996974146 10 -9.900496580111543e-11 -0.016108207506788277 -8.63153966278132e-07 0.9998702544081274 11 6.059799266392733e-09 0.8019628892165832 4.840268748269343e-05 0.597373854446753 12 -5.033915462308732e-09 -0.550395433826452 -3.5755896897761944e-05 0.8349041053585182 13 5.053784333516648e-09 0.4450858715305767 3.1563178794486055e-05 0.8954878926974015 14 8.419066313234432e-09 0.5885535705971041 4.6467524984686766e-05 0.8084582193151163 15 8.90557735051792e-09 0.48400980850508935 4.3647539557974e-05 0.8750625711146369 16 1.705888293133057e-08 0.739653758245311 7.467434392777951e-05 0.6729876019194776 17 5.1572109382203555e-09 0.18538461353349664 2.0212396550665652e-05 0.9826660392302642 18 -2.328339814495478e-08 -0.6828563164678986 -8.178477919607272e-05 0.7305526978741114 19 -3.913764879296982e-08 -0.916708464375864 -0.0001236022330290307 -0.39955672446366336 20 -5.154739810461322e-08 -0.9363174368121112 -0.0001465770889527342 0.35115471808983634 21 1.9941416689432306e-08 0.30514574357555446 5.101391250695028e-05 0.9523056613164191 22 7.665103345684452e-08 0.9660344250734825 0.00017489193652521154 -0.2584133490858223 23 7.134766782413641e-08 0.7025958983240921 0.0001410635188906553 0.7115890553959081 24 -3.6214565545341617e-08 -0.27067645581828326 -6.240843221417008e-05 0.9626703757625655 25 5.1790279998520676e-08 0.31343069120738587 8.093030035361684e-05 0.9496110757881587 26 9.76471751687859e-08 0.48348140665826506 0.00013865182460356674 0.8753546196778808 27 2.4320931108231546e-07 0.9660679133066328 0.00031516943800675713 -0.2582879934250419 28 -5.760116220776852e-09 -0.01787397162264415 -6.858465480027745e-06 -0.9998402477853122 29 -3.6387090286711984e-07 -0.9183475143749914 -0.0003981115505918134 -0.39577478993530635 30 8.160074093917339e-08 0.1715509171534115 8.22720490679595e-05 -0.9851752514426693 31 5.819853717302611e-07 0.9980718776550587 0.0005416464023315233 -0.06206636490839266 32 2.1510279639614338e-07 0.29228983646104745 0.00018557380336221306 0.9563297637655598 33 7.59445645377239e-07 0.8474814676856007 0.0006068034885069383 0.5308246355609446 34 3.5690964072418125e-07 0.33639013436576054 0.0002642112401393917 0.9417226808852375 35 -4.091057811462368e-07 -0.3193635112840012 -0.0002813906752493844 0.94763224326712 36 -7.546453676244599e-07 -0.47343991028694626 -0.0004824099506598264 0.8808259865759857 37 -1.8906289688167591e-06 -0.982952229475143 -0.0011231856476135507 0.183857697745491 38 -2.1105062508406607e-06 -0.9390839443880565 -0.0011623317184248968 0.3436858949289188 39 -2.5853066957476077e-06 -0.9646240712325369 -0.0013513238739472448 0.2636258240686401 40 -2.548795549486021e-06 -0.7758524791739349 -0.0012792661159138326 0.6309130637666075 41 -3.1615860075804858e-06 -0.8029301935402714 -0.0015291192910664463 -0.5960711082459713 42 -4.322600984749709e-06 -0.953658460734394 -0.0020134870391519846 -0.3008845062826679 43 -5.25241455552712e-06 -0.988412035710498 -0.002360985304159304 0.15177639270794138 44 -4.161603802056902e-06 -0.6521624127905219 -0.001807772378551133 0.7580771196157773 45 -6.4076487092003816e-06 -0.8348013728080191 -0.0026990522530703945 0.5505446240167313 46 -7.580466976304793e-06 -0.8733343844600407 -0.003096347434863975 -0.4871113481483479 47 -9.462704350659117e-07 -0.09508303543407069 -0.00037510524919442804 -0.9954692740952882 48 8.425608187935311e-06 0.7236249853299245 0.0032503281231428655 -0.690185711169369 49 1.3974775863233788e-05 0.9967865728728194 0.005250760229253485 0.0799309543429847 50 1.0252517924129751e-05 0.6522193732200672 0.003760479792529784 0.7580209415860742 51 7.079466725136183e-06 0.4028542154397706 0.002540938285457269 0.9152606321070067 52 3.595970832695169e-06 0.18027461327948976 0.001262493988347378 0.9836155091817782 53 9.582308647070628e-07 0.04164757493191193 0.00032967767325522203 0.9991323089631344 54 3.0435151035103606e-06 0.11275994047819692 0.0010266722975638299 0.9936217297131157 55 2.9213899144023735e-05 0.9943722786079471 0.009681902328738926 -0.10549896421237603 56 4.16363697258811e-06 0.12927425161304473 0.0013598656852372205 0.9916079460239664 57 -3.495453234750954e-05 -0.9799068872688088 -0.0112615781923993 0.1991373092063645 58 -1.19122282820623e-05 -0.2979602519629299 -0.003812380482884125 -0.9545706646777596 59 4.098904589922595e-05 0.8996510312258749 0.013230551163297976 -0.436409180529046 60 4.5509829644210436e-05 0.9224974013820024 0.014836853340391197 0.38571804489194406 61 2.5386896899756216e-05 0.4819785870349148 0.008372019390152027 0.8761429964832588 62 -7.74043605304678e-06 -0.13710430629077341 -0.0025848694109572466 0.9905532431862206 63 -4.197002811754517e-05 -0.6905692943694501 -0.014249406220070262 0.7231258551144275 64 -6.446179774219989e-05 -0.9784274441560907 -0.022294390233699647 0.20538425580108186 65 -6.738314184076315e-05 -0.9344167343406218 -0.02371722618609395 -0.3553911299199207 66 -5.318598254396075e-05 -0.6860462826797571 -0.019139229784659265 -0.727306115109579 67 -3.8073695903130686e-05 -0.4746078275031473 -0.01399468271587061 -0.8800861079910411 68 -2.0410335231135395e-05 -0.2460513518917346 -0.007675809464634084 -0.9692263996428959 69 -1.2414483692513633e-06 -0.014420071326659416 -0.0004768556868665043 -0.999895911657832 70 1.8390372862545596e-05 0.20651283622780844 0.0072618292052958125 -0.9784169428068659 71 3.720258570931797e-05 0.40298122945248555 0.015066659318015195 -0.9150842163986469 72 5.4747583197640296e-05 0.5694511849406998 0.02265236859910118 -0.8217129761475023 73 7.145976821520378e-05 0.7041115041467583 0.0298058800041412 -0.7094635960631596 74 8.65754632068576e-05 0.8079792090272402 0.036359064406225806 -0.5880880960535662 75 0.00010014190563846156 0.8858057159534748 0.042406154240265545 -0.4621146412291018 76 0.00010775037244367866 0.9231688063963739 0.04585370721855432 -0.381650076406211 77 0.0001119465641689991 0.9431990123522885 0.047940303828193226 -0.3287511792138469 78 0.00011522374207694951 0.9580387962502455 0.049692902280489296 -0.28229818820851793 79 0.00011812670846677753 0.9687373316043265 0.05115606062490537 -0.24275713349673386 80 0.00012029059110273124 0.9757962307228829 0.05223183248698172 -0.2123523894667537 81 0.00012149859992430558 0.9800959610243474 0.0529662230739378 -0.19132817783884565 82 0.000122493452797258 0.982595143704861 0.053448177709211446 -0.17790463980049037 83 0.00012276327248308762 0.9836103161533365 0.05364896424336061 -0.1721409873374937 84 -5.960464477538421e-07 -5.364418029784578e-07 -5.9604644775384206e-08 -0.9999999999996767 85 -4.172325134277023e-07 -5.364418029784743e-07 -0.0 -0.9999999999997691 86 -0.498829392620764 -0.09178566173618598 -0.860177822755763 -0.05327985169278694 87 -0.7640124337551579 -1.0923536302676896e-08 -0.0 -0.6452015197343542 88 -1.6689300537085817e-06 -0.0 -2.3841857910122597e-06 -0.9999999999957652 89 -0.0 -3.09944152831535e-06 -0.0 -0.9999999999951967 90 -3.814697265602702e-06 -0.0 -4.529953002903208e-06 -0.9999999999824638 91 -0.0 -5.2452087402103235e-06 -0.0 -0.9999999999862439 92 -5.960464477503769e-06 -0.0 -0.0 -0.9999999999822364 93 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 94 0.1485628140697129 1.683760545851179e-05 6.091795376621932e-13 -0.988902972991882 95 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 96 0.3462483126415183 4.290287474297634e-06 -2.1494426223936043e-09 -0.9381429027469615 97 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 98 0.36087411019359966 -0.00038851728707961855 -6.715246250684779e-09 -0.9326144571291479 99 -5.960464477539059e-08 -0.0 -0.0 -0.9999999999999982 100 0.0 0.9540857816096563 2.1230699129955274e-07 -0.29953350618961844

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

My first try on this .lwo format.

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

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

here you go : 0x09D01B34E843AC6BE08BD854B3CEDA0C4CA52281C08B02BF827F3ADA77173BCA

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

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)

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.

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

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

You need to decompress them first. Only then you can succeed... Here's jersey-color after decompression. PS4 format. But there's problem with switch format. ImageHeat doesn't support swizzle format. But RawTex can handle this.

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

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

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

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

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)

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