Leaderboard

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).