Leaderboard

Hi guys, with the help of an AI agent, I decompiled the ea_madden_dump[] binary that is in ea_madden.c written by Aluigi Auriemma. The result is a functional decoder written in pure C for the NFL 07 game files. Here the link for the source: https://github.com/RayneDuarte/Madden-NFL-07-Decompressor

Tool supporting Alan Wake 2, Control, and FBC available: GitHubGitHub - Scobalula/Janitor: An asset extractor for Northl...An asset extractor for Northlight Engine games. Contribute to Scobalula/Janitor development by creating an account on GitHub.

The plugin itself is not against the rules. You can choose whether to purchase the software to run it or not.

This one was really tricky, but I've managed to do it Here's Blender plugin (tested on 5.0, probably works on latest): io_scene_tetsujin28.zip Files that can be imported: .hgm - model files (no references to used textures) .hgt - texture files .vob - objects (structures with embedded model, animations and reference to texture file, some objects contain additional references to models) .kkm - map files (mutiple embedded models as templates and many instances of these models forming one game level geometry) .kkt - exact same as .hgt, but used with .kkm of same name Plugin loads any reference resource if finds them (if you keep file structure straight from T28GOU.DAT everything should be fine)

Hello, I have managed to get the game files and uploaded to AssetStudio to view them, and I found Texture2Ds and Sprites but some of the assets are missing. For an example, there are literally no audio/voice files at all. Then, I noticed AssetStudio doesnt recognize the assets inside a folder called "ondemand" and there are about 2k assets there and I think they are encrypted/compressed. Here is one of the examples of the encrypted assets: Is there a way to decrypt/decompress this type of file? I think those are the remaining assets. If anyone can help me I would really apprecaite it. 5db8fd68-da55-9c4a-c71f-84af76d61103.7z

I found and squashed a bug that was present in the previous version and I have added support for a few more formats. Please give the new version a try and let me know the results. What are you trying to import and where? python .\gekishin_jpkg_v3.py "path\to\*.jpkg" "path\to\extraction\folder"gekishin_jpkg_v3.py

It's Android, so it uses ETC1, and also change your dimensions and offset. The 12-byte header includes dimensions and data size:

try it fmt_nx.py rendershape.bin.nx contains several different skeletons. I then analyzed the file structure in greater detail and discovered direct links: Shape → LOD → Surface → Skeleton In other words, each model in rendershape.bin.nx explicitly specifies the skeleton it requires.

Posted two scripts you can use to get models from this game. Filenames are not existing because they seem to have stripped them from the engine. It is easy enough to locate characters inside level files when sorting by size though.

This morning I added a new .dat loader module to my program, but I did not released it yet.

Sorry for the delay. Here is what I have so far for a Blender 4.2+ add-on. It supports multi-file import, but it can be a bit slow. I'm still working on importing the vertex normals and skin data. Also, note that I may not have covered all of the texture formats, and materials for them are not automatically created. If you get any errors or missing textures/meshes, click Window->Toggle System Console and paste the contents here. Warnings for the last few unimplemented tags are normal. io_tt_isle_of_man-0.1.0-linux_x64.zip io_tt_isle_of_man-0.1.0-macos_arm64.zip io_tt_isle_of_man-0.1.0-windows_x64.zip

Hello everyone. So very few people here from XenTax knew me for trying to rip models from Giana Sisters: Twisted Dreams. Well, I have the good news that I eventually figured out the model and skeleton format! I mainly use MeshFinder made by Durik256. It's a bit tricky as I had to do A LOT of fail & retry but the results were worth it. Long story short, the vertices data are 32 bytes long in half-float; 8 bytes for the position, 8 bytes for the normals and 8 bytes for the two UV maps (UV 1 is the first half and UV 2 is the second half). I still have no idea what the other 8 bytes are. Bone indices and weight are 4 bytes each, each bytes represent a bone which means a vertex can be affected by 4 weight groups. The skeleton is abit tricky for me to explain, so I hope the picture below can explain itself. With everything in place, the model can be exported with everything it needs. However, I've come to an issue with the tool regarding the bonemap. I always export it to the tool's format (.durik256) and use the Noesis script to convert as the tool doesn't let me use the other export options. but when doing so in Noesis, It always says "weight contains an out of range bone index", even though I double checked multiple times. I've come to the conclusion I might be doing something wrong with the bonemap. Or it could be the tool that can't understand that FF means 00 in the bone indices, and not data for a non-existing 256th bone. Here are the files below. The model can be found in giana_cute mesh.bin.nx and hold vertices, weight and face data. It used to be combined with all the models of the game, so I isolated it for convenience. rendershape.bin.nx holds the skeleton data and can be found at the address 1D0D0. I also added the template so you wouldn't have to insert everything on your own. If any here who is familiar with MeshFinder and can help would be appreciated, altough I highly doubt only Durik himself can help as he made the tool and Noesis script. giana_cute model data.zip

This is a blog of professional game developer to find aes key and its process.I just created new topic on it by thinking so further healthy discussion will continue in future. Links: https://blog.jamie.holdings/2019/03/23/reverse-engineering-aes-keys-from-unreal-engine-4-projects/

It's an old tutorial written by me 4 years ago: https://ikskoks.pl/tutorial-how-to-get-allegro-passwords/ But today I've updated it with a new frida script that can make getting password even easier than before 😉 https://github.com/bartlomiejduda/Tools/blob/master/NEW Tools/Allegro/allegro_DAT_frida_hook.js

Hi. I've posted a new tutorial on my blog https://ikskoks.pl/tutorial-hooking-android-bytecode-with-frida/

Today I am gonna discuss on how we can reverse engineer the extraction of the game archives, sit back because this is where it starts to get interesting... +==== TUTORIAL SECTION ====+ But how do those files store game assets like 3D Models, Textures, Sounds, Videos and etc... Well, the anwser is simple, they usually bundle them, they pack them close together in their eighter compressed or even encrypted form (Rarely). To understand let's first quickly move into the basics, into how the Computer stores any file at all. DATA TYPES Those are the most frequent Data types: Byte/Character = 1 Byte, so 8 Bits Word/Short = 2 Bytes, so 16 Bits Dword/Int = 4 Bytes, so 32 Bits ULONG32/Long = 4 Bytes, so 32 Bits ULONG64/Long Long = 8 Bytes, so 64 Bits Float = 4 Byte, so 32 bits Double = 8 Bytes, so 64 Bits String = A sequence of 1 Byte Characters terminated with null ("00") Where Bit is literally one of the smallest Data that we can present, it's eighter 0 or 1 but combining those 8 Bits together (Example: 0 1 1 1 0 0 1 1) so we get a whole byte. So, all files literally look like this: Addres: HEX: ASCII: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 0x00000040 2a 2a 20 2a 2f 0a 09 54 61 62 6c 65 20 77 69 74 ** */..Table wit 0x00000050 68 20 54 41 42 73 20 28 30 39 29 0a 09 31 09 09 h TABs (09)..1.. 0x00000060 32 09 09 33 0a 09 33 2e 31 34 09 36 2e 32 38 09 2..3..3.14.6.28. 0x00000070 39 2e 34 32 0a 9.42. This is called a Hex dump, it's essentially a mkore human readable code of binary file that aside the actual Binary data in HEX shows us the Adresses and the ASCII representation for each 0x..0 to 0x..F line. The packed file usually contains compressed data and a small separator/padding between them, hover it doesn't tell us the name and the path of the file we want to com press, whch is a problem. Heck, we don't even know which compression method was used and which "flavour/version" and how the decompressed file should look like... That's where QuckBMS comes to help. QuickBMS QuickBMS has one very specific function I wanna talk about, it's "comptype unzip_dynamic" it supports millions methods and their "flavours/versions". It has also a very fast perfomance and is good for extracting the multiple files out of the package at once. There are also already lots of QuckBMS scripts out there for extracting specific archives, but I'll talk about that later. Compression types As said previously, the block separators/markers are very usefull to identify but turns out most of the compression methods have their own headers and magic numbers, here are few of them: Magic numbers: ZLIB: 78 01 (NoComp) 78 5E (Fastest) 78 9C (Default) 78 DA (Maximum) LZ4: [No Magic Numbers] LZ4 Frame: 04 22 4D 18 (Default) LZW: [No Magic Numbers] LZO: [No Magic Numbers] BZIP/BZIP2: 42 5A 68 GZIP: 1F 8B 08 Practical steps Below is the example of how average QuickBMS Archive extractor looks like, it's also one of my first favourites and the first one, it's designed for extraction of assets from Wolfenstein: The New Order & Wolfenstein: The Old Blood: wolfenstein.bms: open FDDE index 0 open FDDE resources 1 comtype unzip_dynamic endian big goto 0x24 get files long get unk long math TMP = files math TMP - 1 for i = 0 < files endian little get FNsize1 long getdstring FN1 FNsize1 get FNsize2 long getdstring FN2 FNsize2 get namesize long getdstring name namesize endian big get offset long get size long get zsize long get unksize long math unksize * 0x18 math unksize + 5 getdstring unkdata unksize if size = zsize log name offset size 1 else clog name offset zsize size 1 endif if i != TMP get filenumber long endif next i Script summary: Open index + data files Read file count For each file: Read filename Read offset and sizes Skip metadata Extract raw or compressed data Compression logic ConditionAction | size == zsizeRaw copy | | size != zsizeZlib decompress | In ID Tech 5, games have all assets packed inside the .resources files and all of the metadata like name, path, extension, compressed size, decompressed size are in the .index files that means is that we open both files in this way: 1. Setup open FDDE index 0 open FDDE resources 1 open = tells QuickBMS to open files. FDDE = the format ID (arbitrary, just a label). index -> is opened as file 0 resources -> is opened as file 1 comtype unzip_dynamic 2. Loop This sets compression to Zlib dynamic (handles soo many decompressions). endian big This sets reading data in Big-Endian. goto 0x24 Jumps to 0x24 to skip archive header get files long get unk long files -> total number of files in the archive unk -> unknown value (probably versioning or flags) math TMP = files math TMP - 1 TMP = holds files - 1 (Used later to avoid reading an extra value after the last entry). for i = 0 < files The script now iterates once per file entry. endian little The filename block is little-endian, even though the rest of the archive is big-endian. get FNsize1 long getdstring FN1 FNsize1 Reads length of string Reads string data get FNsize2 long getdstring FN2 FNsize2 Another string component get namesize long getdstring name namesize This is the real filename name is used later by log / clog This determines the extracted file name on disk endian big Switch back to big-endian. get offset long get size long get zsize long offset = Where the file data is located in resources size = Uncompressed size zsize = Compressed size get unksize long math unksize * 0x18 math unksize + 5 getdstring unkdata unksize Reads a count (unksize) Multiplies it by 0x18 (24 bytes per entry) Adds 5 extra bytes Skips a block of unknown metadata This is not used for extraction, only skipped to reach the next file entry. 3. Extract the files if size = zsize log name offset size 1 If compressed size equals uncompressed size: File is stored raw log copies data directly from file 1 (resources) else clog name offset zsize size 1 endif clog means compressed log Reads zsize bytes Decompresses using unzip_dynamic Writes size bytes to disk if i != TMP get filenumber long endif Between entries, there is an extra long Probably an ID or index value Not present after the last entry This prevents reading past the table next i Repeats until all files are extracted

So, with the Unreal Port, what exactly is the end goal? Porting the game over to it or just playing with some of the stuff in another engine? It's been a hot minute since i've looked at this thread. Thanks to you, I've also been slowly working on remaking some of the models from the multiplayer and the campaign. I may be overdoing it a tad on using subdivision modifier, but I use the frame for basis, remake the mesh and with re-topologize in mind. They aren't perfect, I need to get back into making textures for this kind of stuff, but all placeholders and AO for now using node setups. I got a few others, but one thing at a time and good luck still to your endeavors in regards to this.

So the info is in rendershape.bin as I suspected. I got first glimps... I'll take a look once i got some time. After work.

Any new progress? Just curious!

Work in progress

this looks like palette data yup they do contain image data

try it updated Project-G1M. New g1t files has zlib 64kb compressed data https://github.com/hearhellacopters/Project-G1M/releases/tag/v1.9.2.4

I'm not seeing TO_BE_DC.PS2 in the sample file? Is that texture 8-bit palettized? Try gray8 first just to vet whether the wrap width is right, and then look for 4-byte palette entries likely near/before/after the image data (often with 80h's in the alpha channel, which actually represents full opacity).

I'm glad you're enjoying them! Regarding the JAM tools, I figured out the format myself, although your work was an important reference. The main changes are in the repacker: it now recalculates the index folder pointers and can add new resources. You can link my versions in your JAM thread; I'd really appreciate it. And yes, please, I'd love to see your PS2 script! The vertex encoding is exactly where I got stuck (they're clearly not simple floats), so I'd be happy to help with the missing part, or compare notes with what I've found so far.

Thank you for sharing the scripts again, much appreciated, going to have fun going through it. It was a throwback seeing the JAM unpacker and repacker😅, was it based on the one I wrote? I see some similarities but you changed the repacker quite a bit, it is much better now. If you don't mind, can I link your versions to the post here on reshax, or would you like to post it? https://reshax.com/topic/1034-leisure-suit-larry-magna-cum-laude-jam-files/ The pc and xbox versions, wgg and xgg respectively, are very similar in structure, the ps2 one changes quite a bit because of the ps2 EE. I already have most of it mapped out, just need to actually write the vertices to file. Let me know if you want the script I have.

Thanks a lot for confirming that about the collision data, and for the original documentation back when this started — it was the base everything else was built on. Here's a Drive link with the tools since the forum won't let people download attachments directly: https://drive.google.com/file/d/1UykXweD2U7mPXy4AArbecsIEP6ywoX7y/view?usp=sharing Included in the folder: unpack_jam.py repack_jam_v2.py dds_to_png.py png_to_dds.py wgg_to_obj.py obj_to_wgg.py I've never looked into the PS2 side of things, but I'll try to take a look when I get the chance and let you know if I find anything useful. @MOGILYOVVV @loonatic here you go too, hope it's useful for your research.

I've taken a look at the game decomp which luckily has all the symbols, the topology of .vu0 is all done via GIFTags, check StandardModelOutVu0_PreInit(SKIN_MODEL_CONTEXT) and https://ps2dev.github.io/ps2sdk/gif__tags_8h.html. My noesis script is below. fmt_VU0.py

Here's the manifest :P AsphaltLegendsManifest.7z

I couldn't find a working solution for this specific problem on the forum, so I decided to investigate it myself. After experimenting with the file structure and using AI assistance during the development process, I managed to put together a small Python-based extraction workflow that allows Metin2 .EPK / .EIX files to be extracted. I'm sharing it here in case it is useful to anyone else working with Metin2 assets or encountering the same problem. RequirementsWindows Python installed Metin2 .EPK and .EIX files UsageFirst, extract the provided ZIP archive. After extracting it, copy the Metin2 .EPK and .EIX files you want to work with into the same directory as: epk_extractor.py 1. Generate the extraction commandsRun: EPK List Tool.bat The batch file will scan the directory for .EIX / .EPK pairs and generate a file called: list.txt This file contains the Python commands required to extract each archive. 2. Run the generated commandsOpen the folder containing epk_extractor.py. Hold Shift and right-click an empty area inside the folder, then select: Open PowerShell window here On newer versions of Windows, this may appear as: Open in Terminal Open list.txt, copy its contents, paste them into PowerShell and press Enter. The commands will be executed sequentially and the corresponding EPK files will be extracted. 3. Extracted filesDepending on the contents of the archive, the extraction may produce files such as: .GR2 — Granny 3D model files .DDS — Texture files Other files contained within the archive The files are organized into their corresponding output directories. WorkflowMetin2 .EIX + .EPK │ ▼ EPK List Tool.bat │ ▼ list.txt │ ▼ Copy generated commands │ ▼ PowerShell │ ▼ epk_extractor.py │ ▼ Extracted GR2 / DDS / other files NotesThis is simply the workflow I ended up using successfully after not finding a suitable existing solution for my particular case. I am not claiming that this is the only or best way to handle the Metin2 archive format. I am posting it mainly as a practical solution and as a starting point for anyone interested in investigating the format further. If anyone has additional information about the Metin2 EPK/EIX format, encryption/compression, or a more complete way of handling these files, feel free to share it. Hopefully this is useful to someone. epk_extractor.zip

Hey, These appear to be NovaLogic RESOURCE1 archives and quite some research has been invested into them already. The filenames are XOR'd with repeating bytes: 0xAD, 0xDE, 0xED, and 0xAC. Attached you will find two files: AF2_RES_Unpacker.py | This script will extract .RES files Place AF2_RES_Unpacker.py inside the same directory where the .RES files are and let it rip. AF2_LZP1_PNG.py | This script decompresses LZP1 and convert PCX to PNG. Place AF2_LZP1_PNG.py inside the same directory where the .PCX files are and let it rip. Below you will find the research / projects I briefly mentioned before. Source 1: Comanche 3 and Armored Fist 2 Notes Source 2: LZP1 Decompressor + PCX To PNG Converter AF2_RES_Unpacker.py AF2_LZP1_PNG.py

Would you mind sharing that script where you view the animation data?

New Version of TASM 1+2 Tools Audio is now sorted/named Also sorted into languages.

@DKDave's file doesn't work anymore (i can't download it)

Hello I am trying to view the models for FOTNS LP and it extracts normally but gmd uses a different thing since no other Dragon Engine GMD importer doesn't load it samples https://drive.google.com/drive/folders/1HjstmsXSn1O-sE2Cr6EdZ7vpDV1mpJed?usp=sharing https://drive.google.com/drive/folders/1V3VoUwkhsk9qXPgl9MBkibirDif3e2bK?usp=sharing Update! Blender 4.1 loaded it thankfully!

Modding tools in progress (details in discord, forum thread will be created later). The first ever custom model in DS2. Extracted from the game, modified, and put back into it.

i have too low space i can't unistall anything because i have nothing more than gmod ,lego hp 5-7 and hp dh pt2 and the file of the gmod server are draining me so much space and how i can direct message you?

I've had a quick look at the first archive. I don't know the exact format of the file tables and how they relate filenames to the actual files, but I can see that it uses LZ4 compression, so the raw files can be easily extracted without names. Here's an example image extracted manually as a test. If I can work out the filename/file relationship, a script should be easy enough.

So I looked into this again and I'm still stumped. I managed to get a decrypted lib from the iOS version of the game via ArmConverter. I did find a few more hints but nothing I can make sense of. First, the devs refer to the pack files as "pegasus packs". Not sure if they were used in other Jet engine games. The file you're referring to is likely an encrypted SoundbanksInfo.xml file. Also the file names look like Murmur hashes by the const but the function has a that weird 0x61C88647 value use in a way that it is here. . I also have no idea what that string format they are using. Looks like Python but letters in the brackets don't make sense to me. Anyways. here is the lib if you want to play around and spend more time on it. You might get lucky but that's all I got in this sitting. https://drive.google.com/file/d/1Lzuinw7cys6_xgkOiu6Wkc0i8BhRe4Ft/view?usp=drive_link Next steps would be to find a way to attach a debugger to the game but that can be easier said then done.

hi there! yeah, the music is in pack_sd, maybe they changed it in the newest updates? lemme check rq edit: yep it's all still in there! you're using DKDave's quickBMS script, right? the one in this post here: that'll get you all the music! i think i might have gotten lost a bit here, how are you able to see compression flags with that quickbms script? (sorry i'm new to all this! xD) also, where'd you nab that pack5 file from? all of the pack5 files i've seen so far have had filesizes in the hundreds of megabytes, but this one's tiny! edit: did some research, i see that these BT files are templates for 010 hex editor. never knew you could do that before. neat! might play around with this myself, though i barely know what i'm looking at, so you'll probably not get too much useful info from me ahahaha ^^;

Original poster great aluigi A real example/tutorial about a not-so-simple archive format. I think this is a bit advanced for beginners but I wanted to do something based on a recent file format I analyzed. The sample is attached: talk_Vat_00.zip Tools: QuickBMS http://quickbms.aluigi.org Hex editor if you don't have idea of what to take, try XVI32 Read hex, speak hex, eat hex: forget the decimal notation and think only to 0xNUMBER, it's what will help you during reversing... so 10 is 0xa. Things to notice: Do we have a magic number? It's a string/signature or number that is usually used to identify a file format, for example ZIP archives have "PK". In this case we have a 0x00 "CAP" which looks just like a magic. What is the endianess? The endianess is the direction of the numbers stored in the archives. Big endian of 0x11223344 is 11 22 33 44 Little endian of 0x11223344 is 44 33 22 11 The secret is watching the data as blocks of 4 bytes (32bit) so in this case after " CAP" we have: 00 00 00 00 00 00 00 0c That second field looks just a 0xc, so a big endian. Doesn't have sense to be 0x0c000000 in little endian We don't know yet what is this 0xc, let's check it later. Then we have another 00 00 00 00, skip the fields set to zero. And now 00 00 00 e0, so 0xe0. We are at the beginning of the format so it may be an offset, or the size of a section or the number of files or maybe nothing important. Go in your hex editor and press CTRL-G, select hexadecimal and type e0: The data at that offset looks just like a DDS image, take it in your notes. We can notice that it's a non-compressed file because there are many zeroes and the file is easily identified. The next field is 00 4e db 38, so 0x4edb38. Repeat the same operation as before and at that offset you will see a sequence of complete filenames (path + name): Now go back to the beginning of the file because there are still a lot of fields between that DDS image and the current position: 00 43 41 50 00 00 00 00 00 00 00 0c 00 00 00 00 .CAP............ 00 00 00 e0 00 3e db 38 00 00 00 00 00 00 00 00 .....>.8........ 00 00 00 00 00 10 00 80 00 00 00 00 00 00 00 2f .............../ 00 10 00 80 00 10 00 80 00 00 00 30 00 00 00 24 ...........0...$ 00 20 01 00 00 01 cc a8 00 00 00 58 00 00 00 1c . .........X.... 00 21 cd a8 00 00 6a 5f 00 00 00 78 00 00 00 1c .!....j_...x.... 00 22 38 08 00 02 a9 11 00 00 00 98 00 00 00 1c ."8............. 00 24 e1 1c 00 04 13 83 00 00 00 b8 00 00 00 1c .$.............. 00 28 f4 a0 00 04 70 93 00 00 00 d8 00 00 00 1c .(....p......... 00 2d 65 34 00 03 85 79 00 00 00 f8 00 00 00 1c .-e4...y........ 00 30 ea b0 00 04 e2 dc 00 00 01 18 00 00 00 1c .0.............. 00 35 cd 8c 00 01 8b 5a 00 00 01 38 00 00 00 1c .5.....Z...8.... 00 37 58 e8 00 07 7a 40 00 00 01 58 00 00 00 14 [email protected].... 00 3e d3 28 00 00 07 2f 00 00 01 70 00 00 00 2b .>.(.../...p...+ 44 44 53 20 7c 00 00 00 07 10 00 00 00 04 00 00 DDS |........... If you watch carefully you can notice a certain "pattern", from offset 0x20. Basically a sequence of fields that gets repeated, like 4 32bit numbers, 4 numbers, 4 numbers... So let's try to identify this pattern splitting the fields in our mind: Now it's time to make some math operations. We have the number 0xc at the beginning of the file that is also the number of these patterns composed by 4 fields each one, so probably that 0xc is the number of files. The first field is zero so if it's an offset it's for sure a relative offset: OFFSET + 0xe0 = file offset. The second field seems related to the first one. For example: OFFSET 0x00 and second field 0x100080 OFFSET 0x100080 (previous offset + previous size) and second field 0x100080 OFFSET 0x200100 (previous offset + previous size) and second field 0x1cca8 and so on. So let's say it's a SIZE. When we work with archives we need at least 3 parameters: OFFSET SIZE NAME The missing one is NAME and considering the ascendant number (0, 0x30, 0x58, 0x78) it may be a relative offset for the names table we have seen at the beginning of the analysis at offset 0x3edb38. Check it: 0x3edb38 + 0x30 = "BattleRes/talk/st_bg/screen_bg02.dds" 0x3edb38 + 0x58 = "se/talk/07Vat/Vat00_0001.msf" 0x3edb38 + 0x78 = "se/talk/07Vat/Vat00_0002.msf" Ok we have the NAME relative offset And what may be the last one? It's not important, but if you check it you will notice that it's related to the incremental name offset, it's the name size. The reversing of the file format is finished, we can extract all the files with their original filenames Let's check the relative script: http://aluigi.org/papers/bms/others/uniel.bms And in the next post we will see how to write the script from scratch with these parameters.

understood all good! This has been an incredible help so far. Thank you so much for everything. do you have any tips and best practices for quickly identifying/organizing files? Any tools that that you like to use or workflows that help the process go by faster? edit: found an app called Eagle that shows tons of metadata and lets you build a database with tags, folders/subfolders, and most importantly lets you playback/scrub through simply by highlighting a file's thumbnail (which is a generated waveform). really incredible for previewing and basic tagging. it isn't perfect but it's really nice and i'm making it work!

update: i did a mass rename to add .wav to all of the files, then ran them through vgmstream-cli.exe, and they all seem to have been converted successfully! this is an absolute treasure trove. here are my remaining questions: any faster way to identify these files? is there an index or metadata we can use to identify what each file is without playing it back? what about the ones that won't convert? there's about ~160 files that won't open. any ideas on how we can identify and get into 'em? how likely will game updates affect the integrity of these files and their names? i'm planning on indexing these in a database. but to do that, each file needs a static identifier. right now, that's the file name. how likely is the name to be preserved across updates in a frequently-patched live service game? i'm sure the answer differs from engine to engine, and since Jet Engine is proprietary, we probably don't have much insight into how exactly it works. but i'm hoping that these stay pretty fixed. i know some databases and indexes will muck around with file names while using a constantly-updated manifest to keep them identified... (if that's the case maybe i'll just use a hash instead lol) will you still be adapting your quickBMS script now that we've gotten this far? i know it's still useful to do just so we can skip the rename and vgmstream steps on future runs, but do you think it's possible it might help with any of the outstanding problems i mentioned above? edit: actually, yeah, the quickBMS script might come in handy, this has a LOT of files but it seems far from comprehensive. i can only guess that the rest of the sounds are spread out throughout the rest of the .pack files.

You can start with games made using popular engines like Unity or Unreal Engine. Here is the list of modding tools for Unreal Engine https://github.com/Buckminsterfullerene02/UE-Modding-Tools Try also search Xentax Wiki for game file formats that are already known. Each article should have a list of programs attached at the end. https://reshax.com/topic/110-xentax-wiki/#comment-2169

i would start in here from tutorial section. it will grow a lot in time..

Great, many people will find your tutorial useful.