Leaderboard

Warhammer 40,000 Space Marine - Anniversary Edition (2011) and Warhammer 40,000: Space Marine - Master Crafted Edition (2025) ucs.pc Export and Import python tool. Warhammer 40000 Space Marine .PC Tools.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.

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

I made a Noesis script to read all meshes from .RMD files but the meshes are in the center so we need the skeleton but I don't know how to do that, lol. I used the function "CreateTriList" from other PS2 script(made by leeao), it works fine. This function uses the last 4 bytes of vertices buffer as flag and pad: 12 bytes verts, 1 short flag, 1 short pad. Here is DBULL.RMD but like I said, we need the skeleton:

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

Railway Empire 2 translation tools and description. Railway Empire 2 Tools.zip

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

I have no idea where the holes come from. Use the exe from the zip here (needs dlls from previous zip) to get the rest of the body. For some unknown reason 47% of toko's sub mesh blocks don't have an uv block (the exe from the previous zip needs a correction because it misinterpretes normals as uvs). Still weird to join sub meshes manually (see shoe):

Alright, So I fired up @roocker666 ‘s Noesis script and the Console Texture Explorer. Sadly, just as expected, all RMD’s from CITYMAN1 to DCHAIR are completely identical. With the exception of DBULL.RMD they used the same model and textures as placeholders every time. So, no final boss and no City of the Dead residents. But not all is lost, the textures in question are not identical to the one’s featured in the final prototype. It seems that we have uncovered some Beta textures of the Demon Bull and Demon Man enemy. x1 As you can see: these textures lack some of the finer details when compared to their final iterations. While making everything look a bit more cartoonish, these beta textures are much more in line with the artstyle of the first two games. However, this discovery still begs the question where Unseen64 got these images of the City of The Dead residents from. We can’t tell for sure yet, but SEGA DREAMCAST INFO has stated on their website that there are other Fear Effect Inferno prototype builds out there. Maybe one of the earlier builds made use of these models, but that's just speculation on my behalf. Since we have uncovered the contents of these RMD and PS2 files, I’m perfectly happy with this discovery and declare the topic as solved for now. If anyone wants to take a shot at untangling these 3D models, feel free to do so. I have attached all of the converted models and textures down here: Big thanks to @roocker666 @shak-otay, I couldn’t have done any of this without you. If one of the earlier builds will ever see the light of day, I will be definitely be back for some more digging. Until then. See ya! RMD PS2.zip

I'm in the Sinnerclown translation group. We don't sell patches to anyone. This person and others like them really love to talk about things they know nothing about.

Ücretli yamalar satmıyoruz. Sitemizde bir destekçi bölümümüz var; insanlar bizi istedikleri gibi destekleyebilirler.

Yeah, but the problem is that the previous maybe positions I found had too many zero vectors. These ones look better - maybe the previous ones are the rotations? edit: yay, that seems to work (without rotations atm), save as cityman1.smd file: version 1 nodes 0 "jtroot" -1 1 "jtbody" 0 2 "jtwaist" 1 3 "jtchest" 2 4 "jtrshoulder" 3 5 "jtrarm" 4 6 "jtrelbow" 5 7 "jtrwrist" 6 8 "jtrpalm" 7 9 "jtlshoulder" 3 10 "jtlarm" 9 11 "jtlelbow" 10 12 "jtlwrist" 11 13 "jtlpalm" 12 14 "jtneck" 3 15 "jtmouth" 14 16 "jtlip" 15 17 "jtlleg" 1 18 "jtlknee" 17 19 "jtlankle" 18 20 "jtltoe" 19 21 "jtrleg" 1 22 "jtrknee" 21 23 "jtrankle" 22 24 "jtrtoe" 23 end skeleton time 0 0 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1 0.000000 3.300000 0.000000 0.000000 -0.000000 0.000000 2 0.000000 0.402560 -0.178039 0.000000 -0.000000 0.000000 3 0.000000 0.580854 0.078039 0.000000 -0.000000 0.000000 4 -0.400000 0.521687 0.100000 0.000000 -0.000000 0.000000 5 -0.354819 -0.119668 0.000002 0.000000 -0.000000 0.000000 6 -0.059615 -0.945793 0.041228 0.000000 -0.000000 0.000000 7 0.000000 -0.731849 -0.031247 0.000000 -0.000000 0.000000 8 -0.040038 -0.391559 -0.009981 0.000000 -0.000000 0.000000 9 0.400000 0.521687 0.100000 0.000000 -0.000000 0.000000 10 0.354819 -0.119668 -0.000000 0.000000 -0.000000 0.000000 11 0.059615 -0.945796 0.041228 0.000000 -0.000000 0.000000 12 0.000000 -0.731846 -0.031247 0.000000 -0.000000 0.000000 13 0.044455 -0.391561 -0.009981 0.000000 -0.000000 0.000000 14 0.000000 1.055681 0.036543 0.000000 -0.000000 0.000000 15 0.000000 0.060915 -0.159504 0.000000 -0.000000 0.000000 16 0.000000 -0.004216 -0.124180 0.000000 -0.000000 0.000000 17 0.300000 -0.398914 -0.076741 0.000000 -0.000000 0.000000 18 0.000000 -1.214391 -0.019746 0.000000 -0.000000 0.000000 19 -0.000000 -1.312631 0.048992 0.000000 -0.000000 0.000000 20 -0.000000 -0.374064 -0.777951 0.000000 -0.000000 0.000000 21 -0.300000 -0.398914 -0.076741 0.000000 -0.000000 0.000000 22 0.000000 -1.214391 -0.019746 0.000000 -0.000000 0.000000 23 0.000000 -1.312631 0.048992 0.000000 -0.000000 0.000000 24 0.000000 -0.374064 -0.777951 0.000000 -0.000000 0.000000 end

Here is the script if you want to test it. You need to press F4 or the red icon on bottom("Toggle face cull"). fmt_fear_effect_inferno_ps2_rmd.py

edit: seems instead of experimenting I'd try to get TGE's RMD maxscript, maybe from xentax backup archives edit 2; found Amiticia, but exporting the clump creates no file The bones with parent ids: 0 *jtroot* -1 1 *jtbody* 0 2 *jtwaist* 1 3 *jtchest* 2 4 *jtrshoulder* 3 5 *jtrarm* 4 6 *jtrelbow* 5 7 *jtrwrist* 6 8 *jtrpalm* 7 9 *jtlshoulder* 3 10 *jtlarm* 9 11 *jtlelbow* 10 12 *jtlwrist* 11 13 *jtlpalm* 12 14 *jtneck* 3 15 *jtmouth* 14 16 *jtlip* 15 17 *jtlleg* 1 18 *jtlknee* 17 19 *jtlankle* 18 20 *jtltoe* 19 21 *jtrleg* 1 22 *jtrknee* 21 23 *jtrankle* 22 24 *jtrtoe* 23 floats from the matrices (undefined values replaced by 0.0 0.0 0.0): 0.0 0.0 0.0 jtroot 0.413449 -0.995091 0.495473 0.357034 -0.674350 0.553032 0.982738 -0.695039 0.691009 0.253196 -0.269279 0.291826 0.216968 -0.236668 0.236830 0.0 0.0 0.0 jtrelbow 0.032668 -0.201254 0.164289 0.0 0.0 0.0 jtrpalm 0.253197 -0.269279 0.291826 0.216968 -0.228647 0.236830 -0.044276 -0.264800 0.184460 -0.039168 -0.199243 0.158531 0.0 0.0 0.0 jtlpalm 0.722860 -0.408135 0.387143 0.038753 -0.180144 -0.108344 0.0 0.0 0.0 jelelbow 0.016553 -0.456171 0.428642 -0.045874 -0.276716 0.403431 0.037943 -0.777463 0.348391 0.0 0.0 0.0 jtmouth 0.016552 -0.456171 0.428642 0.0 0.0 0.0 jtlleg 0.037943 -0.777463 0.348391 0.0 0.0 0.0 jtlankle edit: uvs are a little bit weird, as usual:

Those .PS2 files are textures, you can examine those with Console Texture Explorer. I found some info too like width and height, image data offset and palette offset. About .RMD files, these have a lot of submeshes but we need to find a way to collect all. I will try to check that later... Here is texture head0.PS2 from DCHAIR folder:

Hi all! I've been reverse engineering this engine on and off for a while now (specifically the engine for Spy vs Spy 2005). I'm assuming there wasn't major changes over the years, here is some potentially useful info. Custom File Format The game is actually fully programmed in the custom files described above (the engine itself doesn't have any game logic). Custom files are all serialized the same way, which is a series of versioned nested nodes that define objects/fields (in the 2005 engine, there's ~400 object types). The first reference to an object initialized it. These objects are everything from entities, meshes, textures, etc. The raw data often matches a standard format for the console (for xbox: textures are mostly mipmaps of A8/DXT images and audio is ADPCM). To put this in context, here is what you might have to do to go get a texture (assuming the first instance is being referenced by the script that fires when the map loads): .map file -> FileObject - field: object -> MapObject - field: onMapStart -> ScriptNode - field: children -> SpawnActionNode - field: entity -> Entity - field: materials -> Material - field: texture -> Texture - field: color_buffer TL; DR, it's quite hard to reverse engineer the custom file formats without deep understanding of the engine. My Research I made a GitHub org that has all my work: https://github.com/vicious-rebirth Currently, all the repos are private because I'm trying to figure out the best way to release without getting a cease and desist (I think Little Orbit still owns the engine and there's some algos that are patented by MS). This said, I'll try to release my web tool on GitHub page for extracting assets (mileage will vary). I can give read access to anyone interested. Useful Videos Vicious Engine Demo (a good summary of the features from the devs) Vicious Engine Tutorial (a partial series of tutorials of how to use the engine - useful to understand the various types of objects) Extract Model (a preview of a model I extracted for proof)

hi, i was able to extract older versions of idV and also load entire scenes and recover filenames.

I have made a Noesis script but it's basic. Just simple mesh export. No materials/ no bones/ no skin. Anyway this is mesh struct. Just basic. //------------------------------------------------ //--- 010 Editor v14.0 Binary Template // // File: // Authors: // Version: // Purpose: // Category: // File Mask: // ID Bytes: // History: //------------------------------------------------ LittleEndian();OutputPaneClear(); local uint32 i,j,k,l,TotalSize=FileSize(); string MeshName; uint32 Unknown_0; uint32 Unknown_1; float Unknown_2[27]; float Unknown_3[5]; uint32 TotalVertexCount; uint32 StrideType; if (StrideType == 19) { byte VertexBuffer[TotalVertexCount*24]; byte ColorBuffer[TotalVertexCount*4]; } else if (StrideType == 23) { byte VertexBuffer[TotalVertexCount*24]; byte UVBuffer[TotalVertexCount*8]; byte ColorBuffer[TotalVertexCount*4]; } uint32 TotalIndexCount; byte IndexBuffer[TotalIndexCount*6]; uint32 ShapeIndex; struct { string MaterialName; uint32 IndexCount; // *3 uint32 Unknown_0; uint32 VertexCount; uint32 Unknown_1; }ShapeInfo[ShapeIndex]<optimize=false>; FSeek(startof(VertexBuffer)); if (StrideType == 19) { struct { float VPosX,VPosY,VPosZ,VNPosX,VNPosY,VNPosZ; }Vertices[TotalVertexCount]<optimize=false>; } else if (StrideType == 23) { struct { float VPosX,VPosY,VPosZ,VNPosX,VNPosY,VNPosZ; }Vertices[TotalVertexCount]<optimize=false>; struct { float UVPosX,UVPosY; }UnitVector[TotalVertexCount]<optimize=false>; } FSeek(startof(IndexBuffer)); for (i=0; i < ShapeIndex; i++) { struct { uint16 F1,F2,F3; }Indices[ShapeInfo[i].IndexCount]<optimize=false>; }

//------------------------------------------------ //--- 010 Editor v14.0 Binary Template // // File: // Authors: // Version: // Purpose: // Category: // File Mask: // ID Bytes: // History: //------------------------------------------------ LittleEndian();OutputPaneClear(); local uint32 i,j,k,l,InfoOffset=FileSize(); FSeek(InfoOffset - 20); uint32 CheckSum<format=hex>; // Must be updated after edit > 32 bit LE checksum uint32 TableOffset; // Must be updated after edit uint32 TotalFileSize; // Must be updated after edit uint32 Flag; uint32 Unknown; // Not sure what is for... FSeek(TableOffset); ubyte ResourceCount; struct { ubyte StrLen; char ResourcePath[StrLen]; uint32 ResourceOffset; // Must be updated after edit uint32 ResourceSize; // Must be updated after edit uint32 Null; }ResourceInfo[ResourceCount]<optimize=false>;

Yes, I used VulkanRipper + ShadPS4.

i think its not armor, its uvs (skip z) i made plugin fmt_gb3.py *(parsing all blocks, if desired you can add parsing of materials, nodes, etc.)

Here's Noesis script for textures. from inc_noesis import * import noesis import rapi import os def registerNoesisTypes(): handle = noesis.register("Psi Ops - Texture", ".w32") 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())) bs.read(20) ResourceTableOffset = bs.readUInt() bs.read(12) StringTableOffset = bs.readUInt() bs.seek(ResourceTableOffset, NOESEEK_ABS) ResourceCount = bs.readUInt() for i in range(0, ResourceCount): Extension = bs.readUInt() Unknown_0 = bs.readUInt() ResourceSize = bs.readUInt() ResourceNameOffset = bs.readUInt() cPos_0 = bs.tell() bs.seek(StringTableOffset + ResourceNameOffset, NOESEEK_ABS) ResourceName = bs.readString() bs.seek(cPos_0, NOESEEK_ABS) ResourceOffset = bs.readUInt() Unknown_1 = bs.readUInt() cPos_1 = bs.tell() if Extension == 544761204: bs.seek(ResourceOffset, NOESEEK_ABS) TextureWidth = bs.readUInt() TextureHeight = bs.readUInt() RawDataSize = bs.readUInt() -20 Unknown_0 = bs.readUInt() BufferInfoOffset = bs.readUInt() Unknown_1 = bs.readUInt() MipMap = bs.readUInt() Unknown_2 = bs.readUInt() PixelFormat = bs.readUInt() Unknown_3 = bs.readUInt() RawDataOffset = bs.readUInt() bs.seek(RawDataOffset, NOESEEK_ABS) TextureBuffer = bs.read(RawDataSize) bs.seek(cPos_1, NOESEEK_ABS) if PixelFormat == 19: print("Pixel Format > R8") elif PixelFormat == 12: print("Pixel Format > DXT1") elif PixelFormat == 14: print("Pixel Format > DXT3") elif PixelFormat == 15: print("Pixel Format > DXT5") elif PixelFormat == 18: print("Pixel Format > RGBA8") else: print("Unknown Pixel Format > ",PixelFormat) if PixelFormat == 12: texFmt = noesis.NOESISTEX_DXT1 elif PixelFormat == 14: texFmt = noesis.NOESISTEX_DXT3 elif PixelFormat == 15: texFmt = noesis.NOESISTEX_DXT5 elif PixelFormat == 18: texFmt = noesis.NOESISTEX_RGBA32 elif PixelFormat == 19: TextureBuffer = rapi.imageDecodeRaw(TextureBuffer, TextureWidth, TextureHeight, "b0 g0 r8 a0") texFmt = noesis.NOESISTEX_RGBA32 texList.append(NoeTexture(ResourceName, TextureWidth, TextureHeight, TextureBuffer, texFmt)) return 1

becky GB3, 829 vertices, uvs unknown so far: edit: I've made a "smart UV projection", but the result is not how it should look like: Assumedly armor parts:

I've been chipping away at this for... Weeks now? I've been making improvements to the program called StudioCCS which is a model viewer/exporter for the .hack games. My primary focus is the original series' model animations. I have had some successes - characters largely now look a little bit off rather than twisted and deformed. I have, however, hit the limits of my understanding. An archived XenHax post indicates these use standard PS2 vif tags, and despite reading over the linked posts (through the wonders of the Wayback Machine), I still don't know what I can do. I've had some successes with fixing some of the rotation values so things don't look like garbage, and implemented a few things like exporting a current scene and exporting all animation data. A lot of what I've done is a little hacky, for now, and my code is a mess of commented out attempts and whatnot. My repo is here, and does include a built version in the bin/Debug folder (it's how what I forked from what doing, so I stuck with it): https://github.com/taarna23/StudioCCS I'm attaching 3 character models that the program will load. I hope someone will be able to help. ccs_chara_models.zip

I figured out the format and have documented the compression here: Torus Games (Leapster) sprite decompression documentation Edit: Fixed the link

public static Byte[] iDecrypt(Byte[] lpBuffer, UInt32 dwKey = 0x6E6B7270) { UInt32 dwMagic = BitConverter.ToUInt32(lpBuffer, 0); if (dwMagic == 0x53524944) { UInt16 wFlag1 = BitConverter.ToUInt16(lpBuffer, 8); UInt16 wFlag2 = BitConverter.ToUInt16(lpBuffer, 10); if (wFlag1 == 1 && (wFlag2 & 1) != 0) { UInt16 wValue1 = BitConverter.ToUInt16(lpBuffer, 12); UInt16 wValue2 = BitConverter.ToUInt16(lpBuffer, 14); dwKey = (UInt32)(dwKey * (wValue1 ^ wValue2)); UInt32 dwSize = ((BitConverter.ToUInt32(lpBuffer, 4) + 3) >> 2) - 4; Boolean dwRemaning = ((BitConverter.ToUInt32(lpBuffer, 4) + 3) >> 2) == 4; if (!dwRemaning) { for (Int32 i = 16; i < dwSize * 4 + 16; i += 4) { UInt32 dwData = BitConverter.ToUInt32(lpBuffer, i); dwData ^= dwKey; dwKey = 5 * dwKey + 1; lpBuffer[i + 0] = (Byte)dwData; lpBuffer[i + 1] = (Byte)(dwData >> 8); lpBuffer[i + 2] = (Byte)(dwData >> 16); lpBuffer[i + 3] = (Byte)(dwData >> 24); } } } } return lpBuffer; } FS.DIR is encrypted, so the code above will help to decrypt it. if someone wants to check it and help to reverse structure i also attached the decrypted file. Looks like entry table is flipped... some examples Some correct paths FS_DECRYPTED.zip

30kB unit, using hex2obj: 184 kB unit: 2nd mesh of 881kB unit:

EA Games used the same endianess structure as the Nintendo Wii... Just insert it as if it were a Nintendo Wii game. You're welcome.

thanks franco

What do you mean by code? What's so funny @Indra881?

Hi. Try this script: https://github.com/bartlomiejduda/Tools/blob/master/NEW Tools/Super Mario Sunshine/Super_Mario_Sunshine_HAR_HIX_script.bms Here's the tutorial for the script (just in case): https://ikskoks.pl/tutorial-what-is-quickbms-how-to-export-and-import-with-quickbms/ And file format specification: https://rewiki.miraheze.org/wiki/Super_Mario_Sunshine_HAR_HIX

It worked! Thank you very much!!!

Wrote a unpacker for JAM files with the magic key of JAM2 and FSTA, both are used for Codename Kids next door, JAM2 version is under DATAPSX2/UI directory, FSTA is under DATAPSX2/JAMFILES. If you have python installed you can just drop the .jam file onto the script and it will unpack. I have not made a repacker for it. Unpack 2.0.py

you mean this txt? https://github.com/zbirow/Monster-Jam-Unpack/blob/main/chunk_00000.txt

Thanks! Good to know!

Hi I need to find my extractor I have written it a while ago, meanwhile you can just use the resources in the google drive link I gave earlier

Uvs are there just have to bind the right texture!

Never played the game, there was one guy on a discord server that asked for help for this specific game and i decided to help him out Id like to once again credit REDxEYE for his blender addon

UniLoader.zip it was just a matter of unzipping the file renaming the folder within to "UniLoader" and zipping it. Now to install the addon you must compress that .py file in order to be installed

0xc4b4, UVB size 8

Hello, I've got some examples of some game engine files from the proprietary game engine used to make the BIT.TRIP games, a series Wiiware games made in the early 2010's. Almost all files contained in the attached file have file types that start with ".ae", followed up by a couple extra letters for each file type. There seem to be three notable exceptions to this. Firstly, all sound files are stored as .OGG's, and can be opened normally. These files contain everything from sound effects, cutscene audio, and the soundtracks used in game. Another file type that breaks the ".ae" convention are the .collision files. One of these files exist for each level, and each one varies greatly in size. Despite the odd file type, the contents can be viewed normally through a basic text editor. Each file contains a series of decimal values, each one being separated by a comma. An observation that gives insight as to what these files do is that levels 1 and 2, 3 and 4, and 5 and 6 each have similar sized .collision files (i.e, levels 1 and 2 have collision file sizes of 22KB and 18KB, whereas levels 3 and 4 have collision file sizes of 9KB and 4KB). Each pair of levels share a similar theme, and each theme has varying levels of obstacles that cannot be fired through. Levels 3 and 4 both lack obstacles for the most part, whereas the other four levels all have numerous obstacles throughout. Therefore, it's likely that these decimal values each map to the hitbox of the obstacles placed throughout the levels. the final deviation from convention is the .vs folder under the FATE/Hell/Layouts file path. this contains various json files along with other file types that I haven't seen before (what on earth is the file at the bottom of the FATE/Hell/Layouts/.vs/Layouts/FileContentIndex?) The remainder of these file types, as stated prior, are files made by the proprietary game engine used to make this game. Viewing and modifying these files are restricted to bitwise modifications via hex editors, and are much harder to modify without breaking things. That being said, the names of each .ae file betray their probable purposes. .aetex files store 2D texture information. most of these files are under the "Textures2D" folder. .aescn files store a variety of 2D and 3D objects. these files are stored throughout the whole game. These are used for the cutscenes, level backgrounds, player 2D models and animations, and all of the 3D models in the game. .aemenu files store information about the game menus, including those that display the final score for a level, the level select menu, and the startup menu. Interestingly, the GAME OVER screen is stored as an .aescn file, and not an .aemenu file, which explains how the player isn't booted back to the menu upon defeat in game, but instead is sent back to the start of the level. the .aeefx file type only appears one time under the Effects directory. the file "General.aeefx" doesn't have any obvious hints as to what it might contain (beyond the obvious "it contains game effects" observation). An interesting thing to notice is that the games files are split between two directories, a "General" directory and a directory called "Hell". The BIT.TRIP series released six games on wii ware, each of them having multiple instances of shared assets throughout. the "General" directory contains those reused assets, whereas "Hell" contains the assets from this particular BIT.TRIP title. Underneath the "General" directory is another file type labeled as .aeshader, which contains (you guessed it) shaders. Though these files are stored under the "Shaders" directory, the names attached to the .aeshader files makes it difficult to gauge what each file governs exactly. Lastly, the fonts used for this game are stored in .aefnt files. three of these files exist, with the difference between the three being unclear. I've attached some examples of the game engine files for those that wanna mess around with them, have fun and make friends! AtrophyGameEngineFileTypes.zip

Hello,i have done some resherch about the flie and written a noesis plugin to export it. But i have some problems with reading vertex and face,using rapi. The vertecies are stored by each model,but the faces are stored by the matial. So,i use rapi reading all vertex then read the face tristrips individually. When consturct model,it can`t get the right weight(For example:char3d_ta.MUA). May be the rapi ignore the vertecies that are not active in context. I upload a simple model file,a model with problem and noesis plugin. Seeking for some help,thanks. MUA.7z

I don't think so. cityman1 is just clumped and the parts need their offsets being applied. Maybe later.

x_h_nicky2.STAG is missing some faces.

https://github.com/Ekey/BW.WPK.Tool

Done. Copy the executable file to the folder with the DIR and BIN File and run it. DWDS.Unpacker-bin-src.zip

Bumping this again since more updates need to happen. Honestly surprised it's been nearly 1 year since I had started this thread in January a couple days after the start of this year.

As per your issue here... https://github.com/wattostudios/GameExtractor/issues/34 ... we believe the archive is extracting correctly (we weren't able to find any missing files), however when we extracted the LVL files, we were able to open those and find SGP2/SGPX files within them - perhaps that is what you're looking for? Please work with us via the GitHub issue, so we can try to resolve this for you.