Leaderboard

I didn't. I used Process Monitor, created several filters, then started carefully rerunning tests and startup multiple times to check what gets read and what doesn't on initial load, followed by testing what it grabs when loading up a map. Went through several passes, then did some manual removals etc. to see if the game would care or not and/or if anything looked broken. Was tedious and took me a week to fully do, but in the process found some fascinating items hidden in here/located assets that weren't even being called. I could have sworn I had removed those prior to uploading So this is one of the cases where the textures in question are in fact searched for and loaded by the game as they are mapped but are never actually assigned to a block/tile as they lack the hardcoded entries there. They're weirdly mapped/called by one function but not used elsewhere. Or at least that's the simplest way (I think) to explain some of what @trigger_segfault found with the biome loading. That's for another topic perhaps, but the TL;DR is these are ultimately unused. I'll address the second point first: doesn't seem to matter the game version but you can remove textures from biomes without the game caring much; the result of missing textures is the game will try to grab the regular ground tile as a default. Otherwise it will show as a white square (like in your test) if it can't find the ground texture. As for Soil, those bmps are grabbed and loaded, but are unused ultimately as the game just replaces instances of this wall type with Dirt (or at least that's what is implied to be happening based on surf map data). So the long and short of it is yes, these can be removed without the game throwing a fit and Soil textures are indeed unused. For the slug holes in ice and lava biomes: in vanilla they're most definitely unused. It's weird that DDI didn't use slug holes outside of rock levels, if you don't count the original intended setup for Lava Laughter (which I'm planning on making a topic for). The game won't crash if you remove the slug hole textures in any biome, as it will default to the ground texture (as mentioned above). Then there's LavaSplit\Lava45.bmp, the water texture for the lava biome. This is in fact used, and appears in the tutorial missions 1. Moving Rock Raiders and 4. Moving Rock Raider Vehicles. Sadly water doesn't show up in any of the actual lava missions, but this texture is still used nonetheless. Yeah, Failcrys.wav is defined but it's not actually used. IIRC the only way to get it to play currently is via a debug key? I haven't really looked into this particular failure line much, but there's an argument both ways for it being considered used and unused. Sounds\Streamed\InGame, is a bit of a convoluted rabbit hole. I think I failed to properly cover these because the game grabs all of them by virtue of being called by the Levels\GameLevels\Level##\##.txt files. As a result I left them alone initially; I have a separate folder I had been working on and had apparently forgotten about at the time of uploading the unused asset tree. A perfect example of these audio clips being actually called and seemingly hooked up in the NERPs is A Breath Of Fresh Air. Every piece of audio pertains to the air supply and the NERPs for the map indicates the messages were supposed to play when the air supply hit certain thresholds. Two possibilities: the script for the maps was done improperly (looking at the nrm raises a few questions), or Sparks notifications are overriding the NERPs messages. If the latter it doesn't explain why Chief fails to come on-screen anyway, which is why I lean on the side of the NERPs being a bit screwed up for the map. The 1002.wav is probably one of the most interesting of the lot as it means Erode Works was changed in some fashion from the original plot, which evidently involved locating a Granite Grinder. This clip is very clearly unused. That 1901.wav clip is yet another example. Note that 1501 and 1701 are seemingly for Ice Spy and yet are different clips, which again raises some questions whether 1701 was meant for another ice map where Lava Laughter now is, or if it was just an extra recording they tossed in. I'm going to recheck all these and update the unused asset tree accordingly. This was something I left out at the time pondering if I should include them or not, but yeah, you're right. These definitely count as unused. As for if those files remain in English no matter the version... I'll check tomorrow and edit this post. The main thing I did when I first built this archive was going off of things specifically not called, then recheck the assets that are loaded but are likely not used (such as Ice07.bmp). What I uploaded was the raw, undisputed unused assets, which I will be updating with what you've pointed out and what I've outlined in this post. I really appreciate you taking the time to go through these assets and kind of prodding me back into doing something with them again in the process. Thanks again for everything you pointed out.

I experienced a few crashes when restarting a custom mission, plus some already known problems written in the Readme (mostly random crashes), but other than that, it's fantastic. Also, I made an italian patch to use with it, it contains all the texts and voices, plus the United Lego.cfg with the italian strings copypasted in from my copy. Custom levels/enemies/etc. remain untouched. I used the latest english United patch as a base. Data ver.: https://drive.google.com/file/d/1Rg0I7sO-2WURa2KzTbpviCivtcmkBVoS/view?usp=sharing Cafeteria ver.: https://drive.google.com/file/d/1mBKXoOQqzN2fUEJ_w9bWF8gZhM0YvCou/view?usp=sharing

I can clarify a bit more on some of the loose ends like the CD priority, and expand on some information: File System Priorities: Data File Reading LegoRR9.WAD - LegoRR0.WAD Working Data folder (in current working directory, which should be your executable directory unless you want to have a bad time) CD-ROM Data folder (in first-located CD drive (`C-Z`) containing the file `CD:\Data\cd.key` (contents don't matter), this excludes Floppy-reserved drive letters `A,B`) Data File Streaming For AVI videos (needs more checking) and Streamed sounds (Sample properties defined with `@` path prefix). Working Data folder CD-ROM Data folder Data File Writing This is seen a few times in assembly, but I don't think any of it is reachable code. (There's some leftover code used to scan the Working Data directory and write a list of relative file names, which was likely used when preparing to build a WAD file) Working Data folder (only) Non-Game Data Priority Music, Saves, etc... TODO. Everything outside the data folder doesn't use LegoRR's built in File System manager, and technically streamed media doesn't either. (Rule of thumb is Working Data is checked before CD-ROM Data though) Misc CD-ROM drives will always be checked for on boot. As far as I can tell from the code, you can throw any data file in any different-numbered WAD file, as long as you're not relying on priority. Higher number WAD files can still be loaded even when lower numbered files don't exist. I have no clue about the machine-specific issue with the blaster though. WAD File Names: WAD file names are determined by the game executable name (without the extension). Renaming the executable to something else means it will no longer look for WAD files named `LegoRR#.wad`, but for `<exename>#.wad`. This is identical to how the root `Lego*` and `LegoRR` properties are handled in CFG-type files (Lego.cfg, *.ol, *.ptl, *.ae). Community Edition & Cafeteria LRR:CE supports WAD files just like the original, as long as they use the same executable name `LegoRRCE`. Cafeteria only outputs a WAD file named `LegoRR0.wad` when rebuilding mods, so this is why LRR:CE only functions when using the "Data method". WAD File Format: This info is entirely useless, but interesting none-the-less. There's one extra feature of WAD files that are never seen, but are supported by LegoRR (and LRR:CE). That being file compression. The WAD Entry metadata structure uint32 version -> flags // (1 = Store, 2 = Compressed) uint32 size -> packed_size // size in the WAD file uint32 size2 -> original_size // size of the file when decompressed uint32 offset In reality, version is a flags field, of which only the second bit (`0x2`) is ever checked. When set, the file is treated as RNC (Rob Northern Compression), not to be confused with the other RNC acronym: "Rob Northern Copylock". Following this, size is actually the packed_size (as present in the WAD file) while size2 is the unpacked original_size. When not compressed, these two sizes must be identical. Using the reversed tool rnc_propack, and creating WAD files with the output (while writing the appropriate metadata), the game still manages to read the game data files as expected... until it tries to read certain compressed .wav files and crashes mid-loading screen... All other file types seem to work fine, though. This means there's at least a few wav files that are read or used in unexpected ways... or the compression/decompression fails at some point. It's also not all wav files, since LegoRR1.WAD is fully converted and contains numerous interface SFX. I managed to get the 2 WAD file sizes down to nearly half their original size using compression. (74MB -> 40MB, and 3.6MB -> 1.9MB). And the game still loads a lot faster with compressed WAD data over using the Data directory method (which is the biggest benefit of WAD files: faster, more compact even without compression, and much less stress on the file system and Windows indexer).