Leaderboard

I forgot all about this thread, I have skin weights imported, and level support

Well so here's everything I know so far. Models are pain. Can't figure out monstrous table which has info about buffer id, vertex count, index count. I output only element buffers. I only know about vertex buffer. At cars they are mostly 8 bytes stride, int16 data type. Not sure what are others buffers. But they have type id. Textures on the other hand are simple. You can get pretty much all of them. I also looked into the sound files. Some are wav, but most of them are unexplored... need some time to research. Also those wav files are named by id which is described in track_table file which is also unexplored yet... So here's bms script. You can use it on any file from *.pack file which you can unpack with 7Zip. And here's Noesis for *.jtex files. from inc_noesis import * import noesis import rapi import os def registerNoesisTypes(): handle = noesis.register("Asphalt 9 Legends - Texture", ".jtex") noesis.setHandlerTypeCheck(handle, noepyCheckType) noesis.setHandlerLoadRGBA(handle, noepyLoadRGBA) noesis.logPopup() return 1 def noepyCheckType(data): bs = NoeBitStream(data) if len(data) < 20: return 0 return 1 def noepyLoadRGBA(data, texList): bs = NoeBitStream(data) baseName = rapi.getExtensionlessName(rapi.getLocalFileName(rapi.getInputName())) TextureWidth = bs.readUShort() TextureHeight = bs.readUShort() bs.read(1) PixelFormat = bs.readUByte() BufferSize = bs.readUInt() data = bs.readBytes(BufferSize) if PixelFormat == 34: print("Pixel Format > BC7 ", PixelFormat) elif PixelFormat == 35: print("Pixel Format > BC6H ", PixelFormat) elif PixelFormat == 36: print("Pixel Format > BC5 ", PixelFormat) elif PixelFormat == 5: print("Pixel Format > RGB8", PixelFormat) elif PixelFormat == 6: print("Pixel Format > RGBA8", PixelFormat) else: print("Unknown Pixel Format > ", PixelFormat) if PixelFormat == 34: data = rapi.imageDecodeDXT(data, TextureWidth, TextureHeight, noesis.FOURCC_BC7) texFmt = noesis.NOESISTEX_RGBA32 elif PixelFormat == 35: data = rapi.imageDecodeDXT(data, TextureWidth, TextureHeight, noesis.FOURCC_BC6H) texFmt = noesis.NOESISTEX_RGBA32 elif PixelFormat == 36: data = rapi.imageDecodeDXT(data, TextureWidth, TextureHeight, noesis.FOURCC_BC5) texFmt = noesis.NOESISTEX_RGBA32 elif PixelFormat == 5: texFmt = noesis.NOESISTEX_RGB24 elif PixelFormat == 6: texFmt = noesis.NOESISTEX_RGBA32 texList.append(NoeTexture(rapi.getInputName(), TextureWidth, TextureHeight, data, texFmt)) return 1

Hello. I would like to share with you my private tutorial links collection. These are useful topics from Xentax, Zenhax and any other reverse engineering related sites that I was able to find in the Internet. I have put them into categories. You may encounter situation when one tutorial fits to few categories, but it is placed only in the category that it fits most. Also, you may encounter tutorials with "[PL]" mark, these are tuts in Polish language. If you don't understand this language, just skip them. Also be aware that I haven't read/watch some of these tutorials yet, so I can't recommend you which tutorial is the best choice, sometimes I'm still learning new things just like you and on this list you may find tuts that are not very useful for you, so don't blame me for that. 🙂 Just pick your favourite category and start learning. If you are complete newbie, I would recommend to start with tuts from category "Basic knowledge". If you have any other good source of knowledge, you can write a comment below and I will update this tutorials collection. Also remember that those links may be dead some day, so don't blame me for that and just make a copy for private use 🙂 So that's it. Enjoy. 😄 Links to tutorials: Basic knowledge (you should start with these if you are new to reverse engineering) - Definitive Guide To Exploring File Formats - Beginner Learning Materials on Reverse Engineering Video Games - What is a File Format? - Analyzing and Reverse Engineering a Game Archive - Key points to successful hex reading - Overview of game file formats and archives - REWiki - Reverse engineering hints - HOWTO-Reverse Engineering QuickBMS - [TUTORIAL] What is QuickBMS? How to export and import with QuickBMS? - QUICKBMS GUIDE - QUICKBMS GUIDE 2 ZLIB - QUICKBMS GUIDE 3 IF ELSE - Basic BMS Scripting - QuickBMS documentation - QuickBMS crc engine - QuickBMS - Reimporting files in the archives - QuickBMS - Scan all the supported compressions - Example of archive format reversing with QuickBMS (medium) - Practice with archives and quickbms scripts - [TUTORIAL] Making BMS Scripts MultiEx scripting - MultiEx Commander Manual - MultiEx Commander 4.5 YouTube tutorials - MexScript Documentation - Let's MultiEx Encryption tutorials - How to guess basic obfuscations: xor and sum/rot - Reverse simple decryption - Reversing AES Keys UE4 + AES Keys Collection - How To Get PAK RSA Key (Wolcen / CryEngine Games) - Retrieving ZIP passwords from games - the zero skills way - Retrieving ZIP passwords from games - the debugger way - Retrieving ZIP passwords from games using plain-text attack - Hacking Zip Passwords (C9) - Checksum / CRC scanning - Decrypt any vita game (no custom firmware needed) - How Unpack Themida 2.x.x or How Unpack Themida 2.x.x (WXP) - SM Hasher / Murmur3 hash + Wiki + Python implementation - LCG + sources + Cracking LCG + LCG in VC2 - Decrypt unity 3d files with Frida - [Tutorial] How to get Allegro passwords Hash tutorials - [Tutorial] How to restore hashed filenames from archives Compression tutorials - How to recognize the compression algorithms with your eyes - LZMA SDK (binaries + source code + specification) + LZMA Wiki - Bc7 and bc5 decompression and compression - Offzip - deflate/zlib scanning and extraction - ZSTD compression + documentation - Reverse Engineered old Compression Algorithm for Frogger - Oodle Data Compression + Oodle compressor + Oodle wiki page - RLE Compression explained + RLE Wiki + RLE in Python - LZ77 explained + LZ77 encoding + LZ77 decoding + LZ77 in Python - LZSS Compression + LZSS explained - LZ Compression + Open-source LZ Compressors Debugging / Decompilation / Disassembling - Lenas Reversing for Newbies - Reversing Spider-Man 2000 - Real World Decompilation with IDA Pro - IDAPython conditional breakpoints - The Beginner's Guide to IDAPython - Using IDAPython to Make Your Life Easier Part1 + Part 2 + Part 3 - Reverse Engineering with Ghidra - How to Reverse Engineer with IDA Pro Disassembler - How to reverse engineer functions - Debugging “Dust: A Tale of the Wired West” - Reverse Engineering Dust: Uncovering Game Scripts - Reverse Engineering an Xbox360 Game - Reverse engineering C programs - bin 0x10 - Memory Hacking — External Signature/Pattern Scanning Tutorial - Remote Debugging with IDA Pro (Windows) + Connecting host with VirtualBox - Remote Debugging with IDA Pro (Linux) - Basic IDA Python Scripting Hooking / DLL Injection - Simple C++ DLL Injector Source Code Tutorial - Quick and EZ - Dll Injection Explained (how it works + source code) - Manual Mapping DLL Injection Tutorial - Blizzhackers DLL Injection - API Hooking and DLL Injection on Windows - [PL]ReverseCraft #7 - Inline hooks, DLL injection - [PL]DLL INjection by Maciej Pakulski (PDF) - C++ Detour / Hooking Function Tutorial - [Tutorial] The different ways of hooking - API Hooking with MS Detours + MS Detours 4.0.1 description + source - Hooking tutorials - Inline hooking in Windows - C++ Internal Trampoline Hook Tutorial - OpenGL Hook - MinHook - The Minimalistic x86/x64 API Hooking Library + source on github - DLL Hijacking - [Tutorial] Simplest function hooking with IDA, Detours & C++ - [Tutorial] DetourFunction __thiscall - How to Hook Functions - Code Detouring Guide - Resources About Hooking - [Tutorial] Hooking Java Functions - [TUTORIAL] Hooking Android bytecode with Frida Console Tutorials - PS2 Texture Swizzling - PS1 LibCrypt tutorial + LibCrypt Sectors Mappings + LibCrypt Bible - Gears: A look Inside the Final Fantasy VII Game Engine - Convert Ps3 to Debug 4.21 - Extract Samples and MIDI files from Square PS2 Games - Extracting Xbox 360 game files - Reverse Engineering Xbox360 SaveGame (Dead Space) - Extract + Decrypt 3ds Roms - [HOW-TO] Assembling 3DS Homebrew for Gateway - [Tutorial] How to Decrypt, Extract & Rebuild 3DS|CIA|CXI Files - PS2 Hidden files + this + this + this + IsoBuster + Ratchet and Clank PS2 discoveries + Ratchet and Clank Hidden files extractor + this - PS2 Modding Tutorials + PS2 Modding Tools + PS2 AIO Project - [TUTORIAL] [PS2DEV] An Introduction to PS2DEV and it's History - Racing Lagoon Hacking Deep Dive (Translating PS1 games - tutorial) DOS Tutorials - DOS games reverse engineering guide - DOS file formats / encryptions / compressions etc. - DOS game "Nomad" (1993) documentation and tools Audio - The basics of VGM ripping + VGM Ripping Tools - Common Sound Formats - How to scan audio codecs with ffmpeg - Tutorial on vg-resource - Extract Binary Domain's Music/Sound (CRI .cpk bgm) - Batman Arkham Knight - Extract Soundtrack - Multimedia Wiki (Audio, Video, Codecs) - TXTH files documentation Graphics - Finding graphics - Graphics/Texture finders and viewers - Xentax Wiki - Image file formats - Tutorial : How to edit EA's FIFA PS2 TEXTURE Source code + documentation - PS1 BRender Engine (Harry Potter 1, Harry Potter 2 etc.) - PS1 BuggyBunny (Bugs Bunny) - Python Tools Collection - KAO2_PAK + documentation - J2ME game Stalker - Soul Calibur 3 Reversing Books - Reverse Engineering for Beginners + Reverse Engineering challenges + Compiler Explorer - Game Hacking: Developing Autonomous Bots for Online Games - Reversing: Secrets of Reverse Engineering - The IDA Pro Book, 2nd Edition: The Unofficial Guide to the World's Most Popular Disassembler - Mastering Reverse Engineering - Practical Reverse Engineering - [PL]Gynvael Coldwind Praktyczna inżynieria wsteczna - [PL]Asembler. Sztuka programowania 3D Models - Approaches of Parsing Bone Representations - Noesis tutorial Basic Model - Video tutorials on model formats reversing - Make_obj (C source) - Extracting simple models - Analyzing and Extracting a Game Model - [Tutorial] How to extract bones from any games with Noesis - Sanae3D - 3D format converter - Background Knowledge of Bone Stuffs - Extract 3D models from binary files - Writing an Obj Convertor in C - [crash course] How to get multiple submeshes using Make_H2O - Very Basic model format conversion (Shaiya). - INTEL GPA mesh ripper tutorial + tool (x32,x64,DX9,10,11) - 3ds Ram Dump - [Tutorial] Exploring model formats: 9 Dragon - Noesis tutorial Zlib - Video tutorial on full model format reversing (Planetside) krystalgamer's Lair - Marvel Avengers - Writing a server emulator - Spider-Man 2000 - Save file protection - Spider-Man 2000 - Re-enabling a cheat code - Spider-Man 2000 - Save file content exploration - Spider-Man 2000 - PKR Format - Spider-Man 2000 - Custom File Loader - Spider-Man 2000 - Apple to the Rescue! Mobile (Android, iOS, J2ME) - OWASP guide - OWASP guide crackmes source code (Warning! Big spoilers!) - Beginners Guide to Reverse Engineering Android Apps - [Android] Decrypt unity 3d files with Frida - Mobile Game Asset Download - [PL]Reverse engineering mobile app (Niebezpiecznik) - J2ME Reverse Engineering Capture The Flag - Solving CTF Challenges Part1 and Part 2 - [PL]Capture the flag Tutorials playlist Other - The Ultimate Game Hacking Resource - Low-Level Programming University - 1024bar tutorial - [PL]ReverseCraft blog and ReverseCraft playlist - [PL/ENG]Modding tutorials - UE4 games texture replace - nullsecurity.org - crackmes.one - RCE Tools Library - GHB1 - Start Here Beginner Guide to Game Hacking - Ripping Tutorials - Searching text strings using Total Commander

Yeah, I got things working to extract the files. Just checking some of the other mesh files, seems like some work and some don't. But here's another one I could get something from. I'll have a look at the textures to see if I can do anything with them, although they seem like an unknown format at the moment. Looks like BC1 maybe with some swizzling/tiling.

I checked jmox files but mesh needs transformation... Here's quick sum up content of *.pack archives. main = ? > mixed mdc = jmox > models cars mde = jmox > models environment so = xvs > sounds lm = jtex > textures prb = jtex > textures gin = jtex > textures

Here's 010 editor template for jtex files. I will write bms for decompress + noesis for preview later... LittleEndian();OutputPaneClear(); local uint32 i,j,k,l,m,n,TotalFileSize=FileSize(); local string FileName=GetFileName(),FilePath=FileNameGetPath(FileName,true),BaseName=FileNameGetBase(FileName,false); struct { ubyte Version; char JTEXSign[4]; uint32 Unknown_0; uint32 Unknown_1; }Header; struct { uint32 TextureTableSize; uint32 TextureInfoSize; uint32 Unknown_0; uint16 Unknown_1; struct { uint16 TextureWidth; uint16 TextureHeight; ubyte Unknown_0; ubyte PixelFormat; ubyte Unknown_1; ubyte Unknown_2; uint16 Unknown_3; ubyte Unknown_4; ubyte MipMap; uint32 Unknown_5; float Unknown_6; float Unknown_7; uint16 TextureWidth_t; uint16 TextureHeight_t; struct { uint32 MipMapTableSize; uint32 MipMapInfoSize; uint32 Unknown_0; uint16 Unknown_1; struct { uint32 MipMapBlockSize; uint32 CompressedSize; // - 8 uint32 DecompressedSize; ubyte CompFlag; ubyte Unknown_1; uint32 Unknown_2; float Unknown_3; if (CompFlag == 0) byte Buffer[DecompressedSize]; else byte ZSDTBuffer[CompressedSize - 8]; }MipMapInfo[MipMap]<optimize=false>; }MipMapTable; }TextureInfo; }TextureTable;

And it's compressed... I see multiple chunks. Chunk table > uint16 compressed size, But not sure where is offset Compression is deflate. Offzip should dump it into one file. After decompression I get this textures

Not sure if is there any tool which supports this pixel formats like CI4/8. Most of them are CI4/8. I tried ImageHeat but result was not pleasing. Anyway here is one texture from file 1495.model.bin And as you can see I already have made 010 editor template by the documentation. So I know what is what. Pixel Format > 1 = CI4. Size of buffer is callculated by (width * height / 2) which results in 2048 bytes data. Next is 32 bytes Palette. As described in documentation. Untitled1.7z EDiT: Well I think I got something. Not sure if it's supposed to look like this... Well Palette Format is > xbgr1555. I noticed it on this texture. Here are textures. You can test it. 1495_textures.7z

The script works better now. Strangely it's the "Senran Kagura" one. (Need to check the differences...)

Mercury Engine has been developed by MercurySteam First title running this tech was Lords of Shadow 2 The engine has been also used in Spacelords (previously: Raiders of the Broken Planet), there might be other titles as well. A brief info about the engine All resources are stored inside packed archive. Resources are combination of INI text files and custom binary formats. Engine uses lua language and lua scripts are compiled to binary. Mercurio Mercurio can extract and convert scene and cinematic formats (as of initial release). Mercurio can be found at: https://github.com/PredatorCZ/Mercurio Small gallery

Such unspecified requests usually lead to nothing. There isn't even clear which game is meant. There's two different versions, one from 2017, Telltale Series (where RandomTalkingBush made a tool for on Xentax) and the newer GotG, 2021, using the Dawn engine.

Next time it will be removed!

The tool you mentioned does not work with single-line JSON files. I wrote this tool for you, so give it a try. Let me know if you encounter any problems. Single Line Dialogue Editor.rar

Looking to see if anyone is interested in this, 3D models/geometry isn't exactly my strongest skillset (which I'm sure you will soon notice). I was originally inspired by an old thread on Xentax for other Rareware games (primarily Grabbed by the Ghoulies) however Live and Reloaded seemed to get skipped over since no one could figure out the compression the game was using. Fast forward a few years and i learned that Xemu had a debugging feature with support for IDA which is a tool I'm fairly familiar with, using this i was able to extract the x86 assembly instructions the game uses to decompress the game assets and write a wrapper for it allowing me to unpack the files to a state similar to what's used in other Rareware titles. You can check out that tool here: https://github.com/birdytsc/clr_unpack I'm currently in the process of reversing the games model format but my limited experience with 3d models/formats is hindering my progress. While some of the data is pretty straightforward to obtain some are packed away in pushbuffer instructions, one example is the tri's/faces data: This makes it a little more annoying to tell what set of vertexes they belong to but they are (so far) stored in order that you will find any vertex data one problem i am having is im not sure whether im extracting the data properly, example: the first part for conkers main model is broken into 3 sets of triangles all sharing a single set of vertexes, uv's etc. the model only looks correct if i separate the 3 sets of tri's into there own mesh, keeping them together creates artifacts: Another issue im having is Texture alignment, the game stores the textures as raw DXT data (usually DXT1 or DXT5) even in simpler models that only consist of a single set of triangles im still having alignment issues, for example: Perhaps this is a sign that there is indeed an issue with how im extracting the Tri's? If anyone wants to play around with this stuff ive included some files in the zip: aid_bfdmodel_characters_conker.py - a script for ModelResearcherPro that will load the verts/tris for the main conker model retail_aid_zpackage_general_singleplayer.rbm.listfile.csv - list of file names (if they havnt been stripped from the asset packer) and offsets retail_aid_zpackage_general_singleplayer.rbm.unpacked - just the decompressed version of the file found in the retail game retail_aid_zpackage_general_singleplayer.rbm.unpacked.mapped - same file as above but after its had a bunch of pointers mapped, useful for diffing against the original to find pointers. retail_aid_zpackage_general_singleplayer.rbm.unpacked.mapped.hexpat - imhex pattern file for the previous file. conker_stuff.zip

This seems to indicate that it's a matter of how the triangle strips are generated automatically. Speaking for me only I never saw this issue. Holes, yes, but bigger ones, not these "one-face-holes". There should exist scripts to fix this. (I'll check meshlab for such a feature when I'm back to office.) edit: well, the feature Filters > Remeshing, Simplification and Reconstruction > Close Holes does increase the holes. So it not meant to be used with one-face-holes, seems. Blender, Non-Manifold operator Works with v2.79 (disadvantage see pictures) That's too less. For character models there must be other indicators (material IDs, vertex groups, whatever) to group vertex blocks together.

Hi, it was brought to my attention that the Beta xbox version has additional outfits that the PC version does not have. The models are in a different format, namely .xgg - Which is slightly similar to the pc version. The ps2 version is also in a different format .pgg - However I won't be looking at this at the moment. I created a script for the character models, it probably won't work for terrain or objects. At this stage I am not going to expand on it further or create a new thread as it is the same game. XGG_convert.py

you give me hope man. i just collected 4 screenshots for you with the ingame debug camera. i can also provide the .obj from my ripping attempt, if that helps. submeshes are split by materials though. LVL_Backyard.zip

That's bacause obj file use "," instead of "." Change all , to .

Partially. Some if not most of them are compressed. No one reversed them yet.

Is this something that could get me into trouble?

And this is "odd": an FVFsize of 27. edit: another tree 0xC5EE0 11976 Vb1 28 16 0xCBC70 2786 020100 0x0 255 staffs, whatever 0xE8EC0 3368 Vb1 27 16 0xEA920 2798 020100 0x0 255 0x2AF590 3180 Vb1 27 16 0x2B0E70 2546 020100 0x0 255

For XBOX and PS3 check this. (You'll need to do a detailed search for yourself.) Maps (Here's some fruitless discussion.)

Well, meanwhile I don't have the time for teaching from scratch, sorry. You'll need to use what exists so far as there is a general short tutorial hex2obj (check 'tut' button) or threads where hex2obj has been used. edit: for the mdl files here you can search for 47585000 to give them some structure. Interestingly there's 12 occurences in both files, the small and the big one. Quicker results can be obtained when searching for 000001000200 (start of face indices' blocks) but there's a lot of them in st00b_ground.mdl (FVFsize is 28 bytes for this sub mesh) edit: bigger one edit 2: UVs are half floats at UV pos 16 fences: H2O file for trees 0x772C0 7173 Vb1 28 16 0x7AAD0 1607 020100 0x0 255

It looks like the geometry data and models are mostly in the .str files as well. So .str seems to contain not just sound, but also bitmaps, models and any other data. Not sure how to unpack them at the moment though. .SCB are the image files - so for example, Global\bitmaps\bitmaps.pak has over 1000 images in there.

You can extract the pak files with this QuickBMS script. The .str files look like audio data. Models are probably in another archive. pak.zip

Using hex2obj, first sub mesh st14a:

The previous posts have all expired, and I can't find any keys on other forums.

It will work for TASM1 on PS3 and 360. If you want to decompress the PC files, you need to replace endian big with endian little It outputs .pak because it's a decompressed format of .pkz Yeah, that's me! Thanks, glad to be here

On a quick glance, 1495-model, big endian shorts, edit: indices don't make much sense to me. Maybe take the odd ones only? But then there will be sequences like 82 82 82, 114 114 144 etc. address 0x8020: 7 2 6 48 288 300 2451 0 0 1 1 11 12 13 25 13 38 11 49 1 50 0 50 8 58 8 66 8 74 8 82 0 82 0 82 8 90 8 98 8 106 8 114 0 114 0 114 8 122 8 130 8 138 8 146 0 146 0 146 10 156 12 168 11 edit: wrong start of indices? Correct one looks like so: address 0x84b0: 18 16 19 0 0 256 14 15 16 0 0 256 14 16 18 0 0 256 18 16 19 0 0 256 60 61 62 0 0 256 63 61 60 0 0 256 61 64 62 0 0 256 62 64 65 0 0 256 296 295 292 0 0 256 297 295 296 0 0 256 298 297 296 0 0 256 299 297 298 0 0 256 10 11 13 0 0 256 13 15 14 0 0 256 14 15 16 0 0 256 14 16 18 0 0 256 48 49 50 0 0 256 60 61 62 0 0 256 63 61 60 0 0 256 88 63 89 0 0 256 89 63 60 0 0 256 298 297

I did it ! never mind thank you so much ! everything is extracting

Tool to extract files. Just enter archive name as an argument StolenBCBTool.rar

Good to know. Meanwhile you could trick around with Donovan, apply textures, for example. (Joining sub meshes is not the best idea, btw.) edit: the state of the project is unclear - I found an unused function CreateDatFile() which can create a .dat file for each obj file. The contence is like so dividing by the scale 262.0 you can find 1.935866 81.411710 -15.432590 matching the first vertex in # donovan_nxg v 0.007389 0.310732 -0.058903 As usual it doesn't make much sense to dig into other author's code (for offsetP, offsetN here) because you're usually faster (but not fast enough) doing own research. There's offsets logged to the console but I can't make much sense of them atm, guess "Offset vertices" needs to be added to iPos. edit 2: the FIs were not the problem, I simply had the wrong FVFsize for the half float vertices: edit 3: this part doesn't use tri strips: I moved it manually:

Who said? It's uncommented source. Usually it takes ages to understand other author's code. Plus, it's decompiled source so unsure whether recompile will work. Without knowing the ghg file structure chances are low. Best would be to ask sluicer on Rock Raiders United, imho. (If he's still active.) edit: surprisingly it compiles (usually 50% chance with C#/Net/NuGet for me) but then this error with hardcoded path by AlunJ: File C:\Users\alunj\source\repos\LEGO TOOLS\ExtractNgxMESH\obj\Debug\net20\HAT_I NDY_REDDISHBROWN_NXG.GSC does not exist! edit: ok, replacing the path/filename with a current one did the trick. Cool.

Mesh vertex format for the first sub mesh appears to be simple, Donovan: edit: half float uvs look a little bit strange, imho: edit 2: rest of sub meshes is not a fun. Small chunks which I don't know how to collect them in an easy manner... But uvs look better.

hey guys i need anyone help to help me find the lewis dbl file from the meet the robisons game i cant find it on the robinsons game files please find it and post it to mega and mediafire and google drive please everyone

hi i have reversed most of the game files, including 3d models files. these are my findings on 3df and map files: 3DF file field size in bytes note header magic 2 must be = 1 vertex list vertex_count 2 number of vertices vertex 12*vertex_count 3 floats face repeated until face_vertices = 0 face_vertices 2 number of vertices per face (3 or 4) unknown 2 vertices_index 2*face_vertices indices on the vertex list MAP file field size in bytes note MAGIC 2 0x8001 (01 80) unknown 510 all zeroes face block 128*faces in 3DF see face block format face block format UV per face 2 number of UV coords per face when < 3 no UV, color is provided color 2 RGB555 unknown 124 when 3 unknown 32 U1 4 integers 0..255 U2 4 U3 4 dummy 4 V1 4 V2 4 V3 4 dummy 4 unknown 62 when 4 unknown 32 U1 4 integers 0..255 U2 4 U3 4 U4 4 V1 4 V2 4 V3 4 V4 4 unknown 62 I've also dumped SKL and ROT files entirely, presumably skeleton and poses, but I don't have enough experience to know what to do with these. I am attaching some dumper tools you can use on the game demo in the first post; i might have misnamed or misinterpreted some values; if anyone wants to give some hints it would be appreciated. rot_dumper.py skldumper.py

Looks like encrypted to me with variable key. Maybe that keys are in exe.

Yes, model is good, but textures is a mess. i used id-daemon's map tools for frostbite 2 (https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=4864, you will see instructions how to use it here) and converted level's EBX files into gmf using another tool (https://github.com/XeNTaXTools/XeNTaXTools-Legacy/blob/main/archive/xntx_8557_frostbite_maps_dmf.7z). Levels has 15-20 root files that contain the whole level if you import them in blender, so i did: https://www.mediafire.com/file/61zjmz3f9f31ngx/independence.blend

First: wrong sub forum! That's not a graphic's format problem. 2nd: So this is Durik's script which you seem to have patched wrongly? (Since Durik's script usually work like a charm...) --------------------------------- To get rid of this annoying "RuntimeError: Invalid type provided for bone matrix" I made these changes (without knowing what I did exactly): elif ntype == 10: bs.seek(80, NOESEEK_REL); trfm = NoeMat44.fromBytes(bs.readBytes(0x40)).toMat43() #trfm = NoeMat44.fromBytes(bs.readBytes(64)) bs.seek(80, NOESEEK_REL) print("trfm:", trfm) #bone = NoeBone(pidx, trfm, bonename) bone = NoeBone(len(bones), bonename, trfm, "dummy", -1) bones.append(bone) (Be sure to replace the string "dummy" by a parent bonename variable, btw.) Result:

Knife + Rifle

Got a working importer up and running with a package list to click from, so far the models are working, I already have working bone import and such, once I can find the scaleing I'll work on rigging

Have you tried other files, I'm running it normally I used the same file as you. If the file format has been updated, maybe a new version of the file can be provided, because this post has been a long time, I'm not sure if they have changed.

https://web.archive.org/web/20231014011449/https://forum.xentax.com/viewtopic.php?t=22088&start=105 Scroll down to speakers60's reply. The only differences are the global.ucas in the same folder as the tool, and the end map file generated in dmf format

Good news. Issues with missing objects and incorrect normals were fixed. Now tool is really close to release.

Hi I hope this helps, please use it in conjunction with the script if anything is unclear in either. I got lazy in some parts of the script. Documentation for WGG files: Header - 88 Bytes (All pointers and offsets always starts after the header) 8 Bytes - Magic(HVSIWGG) 4 Bytes - Version1, Always 2 4 Bytes - Version2, Always 13 4 Bytes - EndOffset, also Filesize 8 Bytes - Object Separator, used to separate objects in file 4 Bytes - Last Chunk Pointer 4 Bytes - Unknown, usually 0 4 Bytes - Amount of Tables 4 Bytes - Size of object list 4 Bytes - Number of Vertex Chunks 4 Bytes - Pointer to start of vertex information 4 Bytes - Number of Face Chunks 4 Bytes - Pointer to start of face information 4 Bytes - Number of vertex chunks with no face information, called "Positional Chunk" herein 4 Bytes - Face EndOffset 4 Bytes - Size of Last chunk to EndOffset 4 Bytes - Unknown, might be pointer to start of object list, always 0 4 Bytes - Size of "Unique Face data" 4 Bytes - Size of "Unique Face data" and "Unique Transformation Data" 4 Bytes - Size of unlisted chunk, mostly unused 4 Bytes - Size of Last chunk(Duplicate) Object List:(For each 16 bytes in "Size of object list") 8 Bytes - Object Name 8 Bytes - Object Separator Tables:(For each "Amount of Tables") Table Header: (24 Bytes) 4 Bytes - Number of entries in table 4 Bytes - Size of "Unique Face data" in objects 4 Bytes - Number of objects 8 Bytes - Name of table 4 Bytes - Size of "Unique Transformation Data" in objects Table Data:(40 Bytes - For each "Number of entries in table") 4 Bytes - Number of the Vertex chunk containing data 4 Bytes - Number of the Face chunk containing data 4 Bytes - Number of the Positional chunk containing data 4 Bytes - Number of vertices to skip in vertex chunk 4 Bytes - Number of faces to skip in face chunk 4 Bytes - Size of faces in object 2 Bytes - Unknown 2 Bytes - Number of vertices in object 2 Bytes - Unknown 2 Bytes - Which object from object list does this table belong to 2 Bytes - Number of faces in object 2 Bytes - Unknown 2 Bytes - Unknown 2 Bytes - Unknown Vertex Chunk:(For each "Number of Vertex Chunks") Header:(60 Bytes) 4 Bytes - Type of Vertex Chunk, 0 Normal, 4 Split, or 8 Transformational 4 Bytes - Count of vertex entries 4 Bytes - Flags, 80 = only vertices, A0 = Vertices and UV's, A8 = Vertices, normals and UV's 4 Bytes - Unknown 2 Bytes - Unknown 2 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 2 Bytes - Unknown 2 Bytes - Unknown 4 Bytes - Unknown Float 4 Bytes - Unknown Float 4 Bytes - Unknown Float 2 Bytes - Unknown 2 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Size of vertex entries Data:(For length of "Size of vertex entries*Count of vertex entries" either 12,16,20,24,32,36, or 40) 12 Bytes (3 Floats)= Contains only vertices * Count of vertex entries 16 Bytes (4 Floats)= Contains vertices and extra unknown float * Count of vertex entries 20 Bytes (5 Floats)= Contains vertices and UVs * Count of vertex entries 24 Bytes (6 Floats)= Contains vertices and extra unknown float and UVs * Count of vertex entries 32 Bytes (8 Floats)= Contains vertices and normals and UVs * Count of vertex entries 36 Bytes (9 Floats)= Contains vertices and extra unknown float and normals and UVs * Count of vertex entries 40 Bytes (10 Floats)= Contains vertices and two extra unknown floats and normals and UVs * Count of vertex entries Face Chunk:(For each "Number of Face Chunks") Header:(8 Bytes) 4 Bytes - unknown 4 Bytes - Size of face information Data:(For length of "Size of face information") 6 Bytes - face 1, 2 and 3 each 2 Bytes * ("Size of face information"/3) Positional Chunk:(For each "Number of Positional Chunks") - Unlike other chunks, all headers are together, no data is between them. Header:(72 Bytes) 4 Bytes - Count of entries 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Size of entries 4 Bytes - Unknown Data:(Size = "Size of entries*Count of entries" Always starts at "Last Chunk Pointer") 12 Bytes (3 Floats)= Contains only vertices * Count of entries If the vertex chunk has a 4 or 8 in first 4 Bytes then a large portion of the file is dedicated to "strange" face and transformational data, called "Unique" herein, there is never more than 1. Sometimes with 4 you can extract the data from the usuall route through the tables, but 8 never has table data accompanying the header. If the "Unique Face data" or "Unique Transformation Data" has a value other than 0 then it is referring to this chunks data. The data starts at "Last Chunk Pointer", for the length of "Size of "Unique Face data"", what is odd is that it contains duplicates. Face Data(Count = "Size of "Unique Face data"/16): 4 Bytes - Face 1 4 Bytes - Face 2 4 Bytes - Face 3 2 Bytes - Unknown(Seemed like a index number from object list, but that is untrue for some/most files, unless some weird logix applys) 1 Bytes - Unknown 1 Bytes - Unknown After the face data is "Unique Transformation Data", it is used for normal data in the script, but this is wrong as some of the chunks that start with 4 have normal data in the vertex chunk. Transformation Data: 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Unknown float 4 Bytes - Index number for face data 4 Bytes - Unknown 4 Bytes - Index number for other transformation data or 0xFFFFFFFF 4 Bytes - Index number for next transformation data or 0xFFFFFFFF Filling in any unknown data would be awesome, and very much appreciated, though I am pretty much finished with this project. I am attaching all the files I have hereto. WGG Sample.zip WGG_convert - Final.py