Leaderboard

Progress Bar Direction: The prefix seen in front of the ProgressWindow property near the top of Lego.cfg states the direction the loading bar expands in. Valid values are: U p R ight D own L eft ProgressWindow L:142,450,353,9 ; loading to the left for a fresh new look You can also leave out the prefix (and the engine checks for that), but it'll end up placing the loading text in the top left corner. Map File Modifiers: This is the most bizarre find so far, and I can't think of any conceivable use for this, considering how strict many of the MAP file formats are. A handful of Map file properties defined in individual level blocks allow a numeric modifier postfix: "Map\file\path.map:2" (valid range is -128 to 127) When reading the respective map file, all block values (as can be checked in the RRU knowledge base), will have this modifier number subtracted from them. Positive numbers (which are subtracted) seem to be less useful, considering many maps will always contain block values with 0, forcing the value into an invalid range. MAP types with modifiers: PredugMap TerrainMap CryoreMap PathMap BlockPointersMap In practice (many crashes were had in finding good fits): PathMap Levels\GameLevels\Level23\Path_23.map:1 ; change the starting power paths into Rubble TerrainMap Levels\GameLevels\Level23\Surf_23.map:-1 ; Reduce the hardness level of all walls? (and other effects) CryoreMap Levels\GameLevels\Level23\Cror_23.map:-1 ; every block without spawns now produces 1 energy crystal (also ore and energy crystal spawns are swapped) PredugMap Levels\GameLevels\Level23\Dugg_23.map:-2 ; change undiscovered caverns into undiscovered Slimy Slug holes (this could break everything because I recall seeing a very low hard limit on number of holes) .

I'm looking through the LegoRR.exe assembly for how exactly it reads Lego.cfg, and other cfg-like files (.ol Object Lists, .ptl Mission AI, etc.). The basic syntax already makes sense, but knowing the boundaries helps a lot with weird edge cases. There's already been some fun finds. Base CFG Syntax: Back to Extended Syntax Basics The most interesting aspect is that there seems to be almost no concept of lines. All whitespace characters (tabs, spaces, line feeds, carriage returns, and ';' comments) are treated the same, they all separate tokens (i.e. keys, values, block names, and block braces {}). There is one exception, and that is the newline character '\n', which is required to end ';' line comments. All properties (whether the beginning of a property block {}, or a property key value pair) consume exactly 2 tokens from the config file. A property block's "value" is actually the '{' character, while the '}' character is a special case that's consumed but not assigned anywhere. Because every property consumes 2 tokens, missing a property value/key/etc., or adding one too many can throw off the entire file. Double-slash `//` comments are NOT supported... yet they still appear in Lego.cfg if you search for `// ROCK FOG`. And look! This creates 3 tokens which would throw off the file... except it doesn't, because they appear in pairs every time when defining `FogColourRGB` and `HighFogColourRGB`. This essentially removes the `HighFogColourRGB` property, because the parser ends up treating it as a property value and not a key like so: { FogColourRGB = 110:110:155, // = ROCK, FOG = HighFogColourRGB, 155:155:110 = //, ROCK = FOG } Special Characters ';' - Comments, you see them everywhere. Not much more to add to this, other than the fact that these do not need to be separated by real whitespace. If a value has a ';' in it, it will immediately end (although this is never done in Lego.cfg). As an example, this would be 100% valid: `CreditsTextFile Credits.txt;comment`. '{' '}' - On the other hand, block open/close braces must be separated by whitespace, otherwise they will be considered part of the block name, property key, or property value. e.g. `BlockName{` will not count as an opening brace. A token can start with, end with, or have '{' '}' characters anywhere in the middle, as long as the token is at least 2 characters long, it will be treated like a name, and not as a block brace. '*' - The asterisk is used as a wildcard in block/property key names (at the root level only), and is used as a method for defining base information that can easily be overridden. Most notably, this is seen with the root `Lego* {}` block name. If you look at the bottom of Lego.cfg, you'll see the `LegoRR {}` block "; Settings for the final version", Rock Raiders uses the executable name (LegoRR.exe) -> `LegoRR::Block::Path::To::PropertyKey` when looking up configuration values. If you want to change the executable name, make sure the name starts with Lego, and then you can define custom config settings depending in the full name of the exe when launched. Which brings us to the next character(s): "::" - You'll see this syntax with Levels::LevelName, and Textures::Rock|Ice|Lava,. Internally, Lego Rock Raiders uses this to lookup any property or block key. It uses the same syntax as C++'s namespaces. I'm not quite sure how the usage of "::" is done with property keys, as is seen with `Stream_Objective_Levels::Level01 @Sounds\Streamed\Objectiv\MisObj01` and such, it's possible the handling for this is hardcoded. You cannot use double-quotes to include spaces in key names or values. Spaces can only be used for certain non-file-path text by inserting '_' underscore characters. Common Lego.cfg Syntaxes: Common Keywords and Literals Keywords: TRUE, FALSE, YES, NO, ON, OFF, NULL Integer: 25, -100, +32 Float: 0.1, -2.5, +1.0, 60.0f RGB: 255:0:13 (the `#.#f` float syntax is only seen with the 2 `PolyRange` properties. This is, again, a C/C++ syntax) Common Value Delimiters Very often, a single property key will require multiple points of information to fill in its value. There are 3 common characters used to separate this information, however these are only used for certain properties. Many will use multiple delimiters to signal different things. And many blocks will have comments stating how to format said property value. Delimiters: ':' ',' '|' Commen Key/Value Prefixes Three special prefix characters are seen on many property key and value names. These are as-always, used on a case-by-case basis: '@' (values) - Presumably specifies to stream a sound property value (rather than loading it in memory all at once). This prefix is also utilized in the ToolTips section to denote an image name instead of text (however this is never actually used in Lego.cfg, only commented on). '*' (values) - Seen on a handlful of Sounds\ path property values. Purpose is unknown. '!' (keys) - Seen on a handfull of SFX/SND/etc. property keys. Purpose isn't fully understood, but it seems this is used to denote that a property is an "expensive" resource, that can be ignored/excluded when using an appropriate `-reduceX` command line argument. Format Characters (sprintf) A few property values have dynamic information that needs to be replaced at runtime. These property values expect special "%_" format character patterns. More than anything else, messing up these property values can and will crash the game (immediately upon usage). This is because a program will pass in N values to replace N format characters, any difference in number will imbalance the program's execution stack, and immediately start causing all kinds of unexpected behavior until a crash is inevitable. See the printf reference for all existing format characters, however "%d" and "%%" are only ever seen in Lego.cfg. You can change up and replace "%d" with a different format specifier in-some-cases, but beware that it's a bit more complicated than just keeping the same number of format specifiers. "%%" - An escape to insert in a real '%' percent sign. This does not consume one of those N values passed by the program, it is simply the only way to specify a percent sign without causing formatting to occur. "%d" - Insert a signed integer (whole number that can be negative or positive). All Format Usages: Making Use of this Information: Syntax Highlighting for VSCode (WIP) This syntax highlighting is based on information that was only known before going into the assembly, a lot of the edge cases listed above aren't added in yet, but your average cfg file should be as readable as ever. The extension development is available on GitHub, (along with the rest of this research). It's not in any finished state, or on the VSCode Marketplace, but it can be installed by dropping the containing folder, vscode-lrr, into `C:\Users\<YOU>\.vscode\extensions\`. Fixing the ROCK FOG Comments Comparison of changing `HighFogColourRGB` to `255:0:0` without removing the `// ROCK FOG` comments, and with removing them: Changing the "LegoRR" Root Block Name As explained in the section describing '*' block name wildcard characters, the root namespace at the bottom of Lego.cfg is looked up based on the name of the game executable. When put into practice, here's an example of 3 game variations added to a single Lego.cfg file (ignore the fact that I created duplicate WAD files to match the exe names). The following executable-name-specific properties are defined: LegoRR::Main::PowerCrystalRGB 255:000:000 ; RED Energy Crystals for "LegoRR.exe" LegoSL::Main::PowerCrystalRGB 000:255:255 ; CYAN Energy Crystals for "LegoSL.exe" LegoSS::Main::PowerCrystalRGB 000:000:255 ; BLUE Energy Crystals for "LegoSS.exe"

Finally found the usages for the key and value prefixes (at least for sounds) Key Prefixes: Reduce Prefix: '!' This tells the game that the sound (and presumably any other resource) will be removed with `-reduce____` command-line arguments. This has been tested on sound effects using `-reducesamples`. This will eliminate a large number of tooltip and interface sounds we all known and love. !SurfaceSFX_Medium Sounds\Voices\Surfaces\looserock !SurfaceSFX_Rubble Sounds\Voices\Surfaces\rubble Other spotted uses of this prefix: Probably for `-reduceflics`: Flics { !Score Avi\Capt.flh|121|153|234|327 } Probably for `-reduceanimation`: !MenuWipe Interface\FrontEnd\Rock_Wipe\RockWipe Value Prefixes: I've only researched usages of this for sound at the moment. Though again, the config file states other areas where this should be supported. Multiple Instance Prefix: '*' States a sound can have multiple instances playing at once. If this prefix is not present, and a new sound needs to play, it will cut off any currently playing instance of the sound and start a new one. SFX_Drill *Sounds\drtdrillc Streamed Prefix: '@' Sound is streamed (and it will sound a bit louder). Cannot be used with '*' to play multiple instances at once. When this prefix is not specified. The sound file will be fully loaded in memory, supposedly on boot. Stream_Objective_Levels::Level01 @Sounds\Streamed\Objectiv\MisObj01 BUG: When defining a Sound Group (with ','), the Streamed flag will be applied to all future sounds in a group after the first-listed sound with '@'. (Note: It hasn't exactly been tested if Streaming functionality is even supported with Sound Groups) Reduce Volume Prefix: '#' Reduces the volume of a sound. This one follows a format: #number# Where number should be a whole number between -10000 and 0 (anything else is set to 0). The lowest number will make it silent, while the highest (0), will keep it at the original volume. (this prefix is never used) !SurfaceSFX_Immovable #-100#Sounds\Voices\Surfaces\solidrock Combinations with '#' This prefix can be combined with '*' or '@', however note that the order is important: The Multiple Instance prefix must come before the Reduced Volume prefix: !SurfaceSFX_Immovable *#-100#Sounds\Voices\Surfaces\solidrock Meanwhile the Steamed prefix must come *after* the Reduced Volume prefix: !SurfaceSFX_Immovable #-100#@Sounds\Voices\Surfaces\solidrock POSSIBLE BUG (technical): When parsing the this prefix, it seems the program doesn't properly terminate the number string, which can potentially allow for garbage data to be included in the number. Worst-case-scenario is the volume would be quieter, but it entirely depends on what data was previously in this location. Miscellaneous: Sound Group: ',' This is used a lot in the samples Block to define multiple sound effects that can randomly be selected from a single type of sound: !SFX_Drip Sounds\drip1,Sounds\drip2,Sounds\drip3,Sounds\dripsA,Sounds\dripsB,Sounds\dripsC Different Value Prefixes listed above should supposedly work with each individual sound (the prefixes are parsed individually for each sound in a group). LIMITATION: The game engine only has room for 200 total extra sounds defined in groups. (1 slot is used for each sound defined after the first comma ','). BUG: When defining a second sound (turning it into a group), the first sound's information is overwritten with that of the second sound (which also makes the second sound twice-as-likely to play when more than 2 sounds are listed. You may notice a lot of first-listed sounds that you've never heard before in-game. Listen to groan1.wav or slip1.wav for good examples: !SND_Slipup Sounds\Minifigure\slip1,Sounds\Minifigure\slip2 SND_Groan Sounds\Minifigure\groan1,Sounds\Minifigure\groan2