Leaderboard
Popular Content
Showing content with the highest reputation since 11/15/2025 in Posts
-
5 points
-
4 points
-
3 points
-
There is the tool PS2JunjouUnpacker-decompressor.zip2 points
-
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 file2 points
-
2 points
-
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_utils2 points
-
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.zip2 points
-
1 point
-
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… haha1 point
-
1 point
-
Drag and drop .resources files into the script this will extract all of it's content from 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.zip1 point
-
Yeah if you are fan of defining almost 800 resource types then go for it. I have faith in you...1 point
-
1 point
-
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??1 point
-
Today I am gonna show you, how to reverse eningeer any Binary 3D Models, turns out this is not that hard and actually one of the cooolest things in reverse enigneering! (Uncompressed and un-encrypted models obviously). +====TUTORIAL SECTION=====+ INTRODUCTION But how do all those models store their 3D Data? Well, the answer is simple, there is no magic here, All 3D Models are just made up of *Vertecies*, *Faces*, *Vertex UV Coordinates* and *Vertex Normal Coordinates* They are definatelly *must* somewhere there in your file (this place is called buffer) and there is absolutelly no extra magic in here. This is how the Vertecies look like: v 1.0 4.0 3.0 <= X, Y, Z matrix coordinates (usually from 0.01 to 1000) v 2.0 3.0 4.0 <= Point values so are usually floats v 6.0 2.0 3.0 <= Usually stable, values don't varry to much in max and min values This is how faces looks like: f 1 2 3 <= Takes all those previous vertecies and makes a triangle out of them This is how UV Vertex coords look lke: vt 0.2 0.3 <= 2D coordinate of the first vertex (usually from 0.1 to 1.0) vt 0.5 0.2 <= Point values so are usually floats vt 0.3 0.1 <= Usually stable, values don't warry to much in max and min values This is how Vertex normals look like: [not so important actually] vn 0.745 0.845 0.360 <= X, Y, Z matriz coordinates (usually from 0.01 to 1) vn 0.320 0.625 0.270 <= Point values so are usually floats, so "v2 x, y, z" vn 0.430 0.320 0.390 <= Usually stable, values don't warry much in max and min values The result is a simple triangle that has it's own UV Map too. This is how the simplest 3D Model format OBJ stores their 3D Model data, hovewer we can say that all of the binary models store their 3D Data in OBJ file format there is just one more thing to it. Binary formats have only two ways of storing their 3D Data (Aside faces) in a Separate way and Structured way, here is how it looks like: Separate way: vertex_buffer = [ v1 1.0 4.0 3.0 <= X, Y, Z matrix coordinates (usually from 0.01 to 1000) v2 2.0 3.0 4.0 <= Point values so are usually floats, so "v2 x, y, x" v3 6.0 2.0 3.0 <= Usually stable, values don't varry to much in max and min values ... ] face_buffer = [ f1 1 2 3 <= Takes all those previous vertecies and makes triangle out of them, so "f1 v1, v2, v3" ... ] uv_coords_buffer = [ vt1 0.2 0.3 <= 2D coordinate of the first vertex (usually from 0.1 to 1.0) vt2 0.5 0.2 <= Point values so are usually floats, so "vt2 u, v" vt3 0.3 0.1 <= Usually stable, values don't warry to nuch in max and min values ... ] vertex_normals_buffer = { vn1 0.745 0.845 0.360 <= X, Y, X matrix coordinates (usually from 0.01 to 1) vn2 0.320 0.625 0.270 <= Point values so are usually floats, so "v2, x, y, z" vn3 0.450 0.310 0.390 <= Usually stable, values don't warry much in max and min values ... } Structured way: buffer = [ {v1 1.0 4.0 3.0, vt1 0.2 0.3, vn1 0.745 0.845 0.360} {v2 2.0 3.0 4.0, vt2 0.5 0.2, vn2 0.320 0.625 0.270} {v3 6.0 2.0 3.0, vt3 0.3 0.1, vn3 0.450 0.310 0.390} ... ] BINARY DATA The data in each file can be viewed as binary no matter if it was readable or unreadable or even empty before, viewing it in binary will spoil immediatelly everything. And while binary files are all the same, the way we read it changes drastically everything! To view your binary file yiou must dump HEX from it or load it into HEX Viewer: Example file: Addres: HEX Bytes: ASCII: 0012BFC0 48 53 68 61 70 65 5F 31 37 00 00 00 00 00 01 00 HShape_17....... <= First line contains ASCII strings 0012BFD0 00 00 0A 00 00 00 22 00 00 10 00 00 00 00 0C 00 ......"......... <= Second line does not contain ASCII strings 0012BFE0 00 00 61 32 76 2E 6F 62 6A 43 6F 6F 72 64 01 00 ..a2v.objCoord.. <= Third line contains ASCII strings 0012BFF0 00 00 FF FF FF FF 02 00 00 00 47 04 00 00 82 56 ..........G....V <= Fourth line contains interesting "00 00 FF FF FF FF" buffer mark 0012C000 F9 40 39 94 59 43 76 26 13 41 BB 61 FB 40 5A A4 [email protected]&.A.a.@Z. <= Fifth line starts containg the actual float Vertex coordinates! But looks random in ASCII strings! 0012C010 5B 43 95 B7 00 41 8F 70 CB 40 C1 4A 5B 43 31 08 [[email protected][C1. <= Sixth line contains actual float Vertex coordinates! But looks random in ASCII strings! 0012C020 12 41 8A 8E C9 40 E7 5B 59 43 E8 82 1D 41 90 A0 .A...@.[YC...A.. <= Seventh line contains actual flaot Vertex coordinates! But looks still random in ASCII strings! 0012C030 62 40 21 90 58 43 05 DD 1C 41 BC B3 78 40 D7 63 b@[email protected] <= Eight line contains actual float Vertex coordinates! But looks again random in ASCII strings! But what are those floats, shorts and ASCII? The Bits are the smallest units of computer data they are either 0 or 1 and comma. The Bytes hgovewer is a combined 8 Bits that can actually start representing some data. Those are Bits ranging from 0 to 255, where 0 is also precieved as an important value (So 256 combinations), (I represented them in HEX, 0-F values, so a 256 combinations) Here is one Byte for example: 10110111 (32 16 8 4 2 1 = 256 bits as sum), combining Bytes together we can make multiple data types. This are all of the data types: Byte/Char => 1 Byte, unsigned/signed (8 Bits) |Example: 48 <= H | ASCII Word/Short => 2 bytes, unsigned/signed (16 Bits) |Example: 48 53 <= HS | ASCII Dword/Int => 4 bytes, unsigned/signed (32 Bits) |Example: 48 53 68 61 <= HShap | ASCII ULONG32/Long => 4 Byte, unsigned/signed (32 Bits) |Example: 48 53 68 61 <= HShap | ASCII ULONG64/Long Long => 8 Byte, unsigned/signed (64 Bits) |Example: 48 53 68 61 70 65 5F 31 <= HShape_17 | ASCII float => 4 bytes, for represnting floating point values (32 Bits) |Example: 48 53 68 61 <= HShap | ASCII double => 8 bytes, for representing more precise floating point values (64 Bits) |Example: 48 53 68 61 70 65 5F 31 <= HShape_17 | ASCII String/Char => A Sequence/Array of Characters terminated by the nulll character |Example: 48 53 68 61 70 65 5F 31 <= HShape_17 | ASCII Big-Endin vs Little-Endian: Reading in Big-Endian for example a float byte will read it normally, left-to-right 48 53 68 61 "HShap", where's Little-endin reads byte in reverse order, right-to-left 61 68 53 48 "paSH". Big-Endians were mainly used in PS3, Xbox360 and Wii platforms where Little-Endians are mainly in Windows, PS4, Xbox One, Nintendo Switch. TRYING TO REVERSE THE BINARY 3D FORMAT But how do we actually apply this info into reverse engineering the binary 3D file format structure and even converting it into an OBJ Model. Assuming that you have the actual decompressed/uncompressed and decrypted/unencrypted binary 3D model file, you can actually visualize the 3D Data geometry while analyzing the HEX from it in realtime! ModelResearcherUltimate is the program that will enable this opportunities. First of, Level 1: Start with vertecies count 500, type: float, carefully try different offsets while printing the values and render it too, until you see a countinous very stable output without insanelly big or small values. (from 0.001 to 1000). If nothing works try with different Endianess, then try a different type (unlikely). If the mesh appears but random vertecies appear too that means that the Data structure is sctructured and you need to try different Padding or even Pad inters sometimes. Second of, Level 2: Start with vertex UV coordinates count [exactly how many vertecies], type: float, carefully try different offsets while printing the values and rendering it too, until you see a countinous stable output without insanelyy big or small values (from 0.0001 to 1.) If nothing works try different type, since you already know the Endianes and Structure. Third of, Level 3: Start with faces, they are actually very carefully linked with vertecies, so the errors will constantly appear, carefully try different offsets while printing the values, don't render it, it will often just throw the errors. You will need see the full values without floating points that are very stable in output without big and small values, if nothing works try different type or even the format. Fourth of, Level 4: [To be honest I didn't know what to write here, normals are pretty useless though, you can just flip them and calculate, very easily in programs like Blender in just a few clicks, so it's not worth your brainstorming!] Practical steps: Here is how BAD Data will look like: [random, disoriented pattern, extreamly low and extreamly big values occur] v -0.0000 -0.0000 -184538016.0000 v -0.0000 15.7924 -158665664.0000 v -0.0000 90990377942005974930976407552.0000 -17551224.0000 v -0.0000 -3386287.2500 -115467744.0000 v -0.0000 15397417210601645679040601784320.0000 -22963316.0000 v -0.0000 15397417210601645679040601784320.0000 -22963316.0000 vt 0.0000 1785889664.0000 vt 0.0000 140283808776479363868647227392.0000 vt 0.0000 10997215558668704718782464.0000 vt 0.0000 -516472.2188 vt 0.0000 -0.0000 vt 0.0000 0.0000 f 57856 10240 3073 f 3073 64769 57856 f 31744 64768 3072 f 57857 64768 58112 f 57856 58112 58368 f 58112 59136 58368 Here is how GOOD data looks like: [strong countinous repating pattern, values are pretty much very similiar] v -0.0733 0.0012 1.6030 v -0.0735 -0.0118 1.6023 v -0.0776 -0.0146 1.5900 v -0.0718 -0.0247 1.6005 v -0.0784 0.0009 1.5913 v -0.0784 0.0009 1.5913 vt 0.0008 0.6221 vt 0.0316 0.6229 vt 0.0344 0.6543 vt 0.0628 0.6246 vt 0.0008 0.6539 vt 0.9978 0.6533 f 226 296 268 f 268 253 226 f 124 253 268 f 226 253 227 f 226 227 228 f 227 231 228 Changing Offfset (oftenly) or Endianess or Type will instanly give the different results including BAd data drastically turning into a GOOD data so keep that in mind and play with those offsets. There is just one small but very important step left, most of the time those binary files leave also values like Vertex count (UV Coords and Vertex Normals count is the same as Vertex always), Face count, buffer mark and even Vertex stride! (Vertex Stride = Vertex Padding + 12, UV Coords stride = UV Coords stride + 8). They are essentially at the begginning of the mesh buffer and are pretty easy to find and are always placed in the same way hovewer, this time I personally recommend finding them using the dedicated HEX viewer, my recommendadions are IM Hex, truly the open-sourse king in terms of ease of use.1 point
-
*.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.1 point
-
=== Available bones in motion file === 2: waist - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 3: chest - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 6: eye_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=68] 7: eye_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=62] 8: shoulder_r_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=67] 9: arm_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=101] 10: forearm_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=34] 11: wrist_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=101] 12: pinky_r_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=89] 14: pinky_b_r - Other[type=0x01, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 15: pinky_c_r - Other[type=0x01, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1] 16: ring_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=84] 20: middle_a_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=96] 21: middle_b_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=89] 22: middle_c_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 23: index_a_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 24: index_b_r - Other[type=0x01, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 25: index_c_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 26: thumb_r_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=90] 28: thumb_b_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=92] 29: shoulder_l_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=78] 30: arm_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 31: forearm_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 32: wrist_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 33: pinky_l_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 35: pinky_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 36: pinky_c_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 37: ring_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=52] 41: middle_a_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=92] 42: middle_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] 43: middle_c_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 44: index_a_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=84] 45: index_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=84] 46: index_c_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 47: thumb_l_jo - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 49: thumb_b_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=76] 51: thigh_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=101] 52: leg_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 53: foot_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=68] 54: toe_r - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=1(StaticValue), frames=1] 55: thigh_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=77] 56: leg_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=38] 57: foot_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=1(StaticValue), frames=1], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1], Rotation[type=0x11, keyType=6(QuatSlerp), frames=72] 58: toe_l - Other[type=0x01, keyType=1(StaticValue), frames=1], Other[type=0x02, keyType=0(Static0), frames=0], Other[type=0x00, keyType=0(Static0), frames=0], Other[type=0x06, keyType=1(StaticValue), frames=1], Other[type=0x07, keyType=1(StaticValue), frames=1], Other[type=0x08, keyType=1(StaticValue), frames=1] === Bones in skeleton but not in motion (static) === 0: root 1: upperbody_jo 4: neck 5: head 13: pinky_a_r_jo 17: ring_a_r 18: ring_b_r 19: ring_c_r 27: thumb_a_r_jo 34: pinky_a_l_jo 38: ring_a_l 39: ring_b_l 40: ring_c_l 48: thumb_a_l_jo 50: lowerbody_jo1 point
-
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. 😉1 point
-
1 point
-
1 point
-
You could check the MakeH2O_log.txt. If you find a structure like 12 4 4 4 4 4 (for example) the last "4 bytes block" might be alpha uvs (just a wild guess). edit: it's 16 8 8 4 4 here Try using 82ea3, 4 for uvs. Looks promising.1 point
-
1 point
-
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).1 point
-
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.rar1 point
-
The script has been updated and is now output in Lua format whenever possible. format_hotfix_data.py1 point
-
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.1 point
-
So here's pixel format for ps4. PF_DXT5 = 7 PF_DXT1 = 13 PF_BC7U = 22 PF_UNKNOWN = 2 not sure but can be RGBA1 point
-
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.py1 point
-
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.zip1 point
-
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 i1 point
-
I don’t know if this has any effect. https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=35471 point
-
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.1 point
-
1 point
-
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.1 point
-
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.1 point
-
1 point
-
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.1 point
-
tool.py Here a working script that will output json file with { hash: text, ... }1 point
-
I made a blender addon to import models, textures and animations for dolphin wave and other games that used the same engine. it can import lzs and lza files as is. You don't need to decrypt or decompress the files https://github.com/Al-Hydra/blenderBUM1 point
-
1 point
-
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.1 point
-
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.py1 point
-
When i get home, i will compile the decompressor/compressor unpack and pck tool, is one all tool. std::vector<uint8_t> compressLZSSBlock(const std::vector<uint8_t>& input) { const int MIN_MATCH = 3; // comprimento mínimo para virar par const int MAX_MATCH = 17; // (0xF + 2) const int DICT_SIZE = 4096; const size_t n = input.size(); // Dicionário igual ao do descompressor std::vector<uint8_t> dict_buf(DICT_SIZE, 0); size_t dict_index = 1; // mesmo índice inicial do descompressor size_t producedBytes = 0; // quantos bytes já foram "gerados" (saída lógica) std::vector<uint32_t> flagWords; uint32_t curFlag = 0; int bitsUsed = 0; auto pushFlagBit = [&](bool isLiteral) { if (bitsUsed == 32) { flagWords.push_back(curFlag); curFlag = 0; bitsUsed = 0; } if (isLiteral) { // bit 1 = literal (mesmo significado do descompressor) curFlag |= (1u << (31 - bitsUsed)); } ++bitsUsed; }; std::vector<uint8_t> literals; std::vector<uint8_t> pairs; literals.reserve(n); pairs.reserve(n / 2 + 16); size_t pos = 0; while (pos < n) { size_t bestLen = 0; uint16_t bestOffset = 0; if (producedBytes > 0) { // tamanho máximo possível para este match (não pode passar do fim do input) const size_t maxMatchGlobal = std::min(static_cast<size_t>(MAX_MATCH), n - pos); // percorre todos os offsets possíveis do dicionário for (int off = 1; off < DICT_SIZE; ++off) { if (dict_buf[off] != input[pos]) continue; // --- SIMULAÇÃO DINÂMICA DO DESCOMPRESSOR PARA ESTE OFFSET --- uint8_t candidateBytes[MAX_MATCH]; size_t candidateLen = 0; for (size_t l = 0; l < maxMatchGlobal; ++l) { const int src_index = (off + static_cast<int>(l)) & 0x0FFF; // valor em src_index, levando em conta que o próprio bloco // pode sobrescrever posições do dicionário (overlap) uint8_t b = dict_buf[src_index]; // Se src_index for igual a algum índice de escrita deste MESMO par // (dict_index + j), usamos o byte já "gerado" candidateBytes[j] for (size_t j = 0; j < l; ++j) { const int dest_index = (static_cast<int>(dict_index) + static_cast<int>(j)) & 0x0FFF; if (dest_index == src_index) { b = candidateBytes[j]; break; } } if (b != input[pos + l]) { // não bate com o input, para por aqui break; } candidateBytes[l] = b; ++candidateLen; } if (candidateLen >= static_cast<size_t>(MIN_MATCH) && candidateLen > bestLen) { bestLen = candidateLen; bestOffset = static_cast<uint16_t>(off); if (bestLen == static_cast<size_t>(MAX_MATCH)) break; // não tem como melhorar } } } if (bestLen >= static_cast<size_t>(MIN_MATCH)) { // --- CODIFICA COMO PAR (offset, length) --- pushFlagBit(false); // 0 = par uint16_t lengthField = static_cast<uint16_t>(bestLen - 2); // 1..15 uint16_t pairVal = static_cast<uint16_t>((bestOffset << 4) | (lengthField & 0x0F)); pairs.push_back(static_cast<uint8_t>(pairVal & 0xFF)); pairs.push_back(static_cast<uint8_t>((pairVal >> 8) & 0xFF)); // Atualiza o dicionário exatamente como o DESCOMPRESSOR: // for (i = 0; i < length; ++i) { // b = dict[(offset + i) & 0xFFF]; // out.push_back(b); // dict[dict_index] = b; // dict_index = (dict_index + 1) & 0xFFF; // } for (size_t i = 0; i < bestLen; ++i) { int src_index = (bestOffset + static_cast<uint16_t>(i)) & 0x0FFF; uint8_t b = dict_buf[src_index]; dict_buf[dict_index] = b; dict_index = (dict_index + 1) & 0x0FFF; } pos += bestLen; producedBytes += bestLen; } else { // --- LITERAL SIMPLES --- pushFlagBit(true); // 1 = literal uint8_t literal = input[pos]; literals.push_back(literal); dict_buf[dict_index] = literal; dict_index = (dict_index + 1) & 0x0FFF; ++pos; ++producedBytes; } } // Par terminador (offset == 0) pushFlagBit(false); pairs.push_back(0); pairs.push_back(0); // Flush do último flagWord if (bitsUsed > 0) { flagWords.push_back(curFlag); } // Monta o bloco final: [u32 off_literals][u32 off_pairs][flags...][literais...][pares...] const size_t off_literals = 8 + flagWords.size() * 4; const size_t off_pairs = off_literals + literals.size(); const size_t totalSize = off_pairs + pairs.size(); std::vector<uint8_t> block(totalSize); auto write_u32_le = [&](size_t pos, uint32_t v) { block[pos + 0] = static_cast<uint8_t>(v & 0xFF); block[pos + 1] = static_cast<uint8_t>((v >> 8) & 0xFF); block[pos + 2] = static_cast<uint8_t>((v >> 16) & 0xFF); block[pos + 3] = static_cast<uint8_t>((v >> 24) & 0xFF); }; write_u32_le(0, static_cast<uint32_t>(off_literals)); write_u32_le(4, static_cast<uint32_t>(off_pairs)); size_t p = 8; for (uint32_t w : flagWords) { block[p + 0] = static_cast<uint8_t>(w & 0xFF); block[p + 1] = static_cast<uint8_t>((w >> 8) & 0xFF); block[p + 2] = static_cast<uint8_t>((w >> 16) & 0xFF); block[p + 3] = static_cast<uint8_t>((w >> 24) & 0xFF); p += 4; } std::copy(literals.begin(), literals.end(), block.begin() + off_literals); std::copy(pairs.begin(), pairs.end(), block.begin() + off_pairs); return block; } @morrigan my compressor, try it, and let me know the results.1 point
-
In the ..var01.st2 csv data is contained: edit: and xml data: <!-- ______________________________________________________________________________ Copyright 2004 The Collective, Inc. DISMEMBERMENT DEFINITION Character: Clone Trooper Author: Baback Elmieh Date: 01/07/2004 ______________________________________________________________________________ --> <!-- HEAD --> <DismemberablePart Name="Head" Hitpoints="25"> <!-- The Materials section is a list of materials in the original mesh that are to be turned off when the part is dismembered --> <!-- <Materials> <Material Name="headSG"/> </Materials> --> <!-- ReactionProcessing defines the chunks and particles to be spawned when a reaction dismemberment is processed for the character the definition requires a Bone from which a chunk should be spawned and the name of the chunkmesh. The ChunkMesh definition in turn can have several values set such as GravityScale and UseGinFile. GravityScale greater than 1.0 pulls a chunk down faster, UseGinFile will look for a bounding box with the same name as the chunkmesh in the damage mesh's gin file, if the bound is found, it is used instead of the default rendering bound which can help artists orientate chunks so that they land on their correct side --> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="neck_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <!-- <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="neck_g"> <Param Name="ChunkMesh" Value="head"/> <Param Name="GravityScale" Value="1.4"/> <Param Name="RandomVelocityScale" Value="0.2"/> </Param> </Chunk> --> </ReactionProcessing> <!-- The Capsules section provides a list of capsules that should affect the hitpoint of the part and should be disabled once the chunk has been dismembered --> <Capsules> <Capsule Name="Dneck_g"/> </Capsules> </DismemberablePart> <!-- LEFT SHOULDER --> <DismemberablePart Name="Left Shoulder" Hitpoints="25"> <Materials> <Material Name="Shoulder_LSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_L_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_L_g"> <Param Name="ChunkMesh" Value="Shoulder_L"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_L_g"/> </Capsules> </DismemberablePart> <!-- RIGHT ELBOW --> <DismemberablePart Name="Right Shoulder" Hitpoints="25"> <Materials> <Material Name="Elbow_RSG"/> </Materials> <ReactionProcessing> <!-- particles --> <Particles> <!-- spark particle from the joint --> <Param Name="BoneEmission" Value="shoulder_R_g"> <Param Name="ParticleID" Value="IDS_FX_LIGHTSABER_BODY_IMPACT"/> </Param> </Particles> <!-- chunks --> <Chunk Typename="TSingleChunk"> <Param Name="Bone" Value="shoulder_R_g"> <Param Name="ChunkMesh" Value="Elbow_R"/> <Param Name="GravityScale" Value="1.8"/> <Param Name="RandomVelocityScale" Value="0.1"/> </Param> </Chunk> </ReactionProcessing> <Capsules> <Capsule Name="Dshoulder_R_g"/> </Capsules> </DismemberablePart> </DismembermentDefinition>1 point
-
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.1 point
-
rename it to .awb files then use the lastest vgmstream, works well1 point
-
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 files1 point
-
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.py1 point
ResHax.com: Empowering Curious Minds in the World of Reverse Engineering
Delving into the Art of Code Unraveling: ResHax.com - Your Gateway to the Thrilling World of Reverse Engineering, Where Curiosity Meets Innovation!