Leaderboard

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"

Since there have been enough new members thinking that they can mod something that is outside of LRR's limitations, I felt it was necessary to make a topic that logs what we know about modding this game. As I don't know everything about modding, please post what you know, what I missed, or what has yet to be confirmed here and I or another mod will add it to the below list. It might also be a good idea to list examples of modded content along with known stuff. What We Can Change and How Textures: All textures, except menu pictures, must be 256-color BMP files, with dimensions that are powers of 2. Such dimensions include 128x128, 16x16, 64x512, and so on. Interface images don't seem to care about what dimensions you use. Example: Armored Rock Raiders, Enhanced Biomes We can animate textures on any object with an animation. Example: Animated Textures on Models Models: All models must be in Lightwave 5 format, no exceptions. LWO6.5 or higher is incompatible. Models sometimes crash the game during the first loading screen if they have no texture or pseudotexture applied, and always crash if the game cannot find their textures. Example: High Poly Small Wheel, High Poly Cabin Animations: All animations must be in Lightwave 5 format, no exceptions. Anything other than LWS5.6 will crash the game when they are encountered in a level. Example: Extended Dynamite Countdown You can force an animation to use an object in the World\Shared folder by opening the LWS file in Notepad, finding the LWO, and changing the path of the LWO to look like "\\object.lwo" Sounds: All sounds must be uncompressed WAV files. Sample rate seems to have no effect on playback in-game. Needs more evidence. Raiders, Creatures, Buildings, and Vehicles: Many aspects of these objects can be altered, including their speed, size, damage values carrying capacities, and overall behaviors. We can also add more of all of these to the game, including multiple raider classes. More than 11 buildings can be added and used, but the game will crash without specific EXE hacks. Example: Rideable Slugs, Multiple Minifigure Classes, Inferno Monster Upgradeable Objects: We can add new objects that can be attached to vehicles or buildings when they are upgraded. There seems to be a limit of about 75 objects that can be defined as UpgradeTypes. Any more will crash the game when loading. Levels: We can edit and add new levels in all aspects. The design, goal, and specific AI behavior for each level is customizable, including adding level specific variables. Example: Regroup, The Algorithm Weapons: We can change how the handheld beams work to a small extent, such as damage and range. Increased fire rate requires an edited animation. We can also change the damage, range, fire rate, and energy drain of vehicle and building weapons. Dynamite damage values and range can also be changed. Custom movies: I have personally tested my own AVIs and WMVs. Specific settings don't seem to matter too much. For the sake of saving space, use WMV. Scenery: Things like foliage or structures can be added into levels to give a unique look, but they must be coded as a creature, vehicle, or building. Creatures work best for this. Example: Ice Pillar Adding Priorities and Properties: In the CFG file, we can mix and match different properties to change how objects and levels work, and even activate ones that are not used by the original game. Some are not interchangeable. Example: Add New Priorities Notifications and Messages: We can activate unused notifications (the little tabs on the left side) so you can be annoyed twice, or even thrice, as often. Example: Monster Class Messages Tiny Monsters doing stuff: Tiny monsters can do everything regular monsters can do but only if they're placed in the OL file. Tiny monsters spawned from a dying monster can do nothing but run away and enter walls. Pathfinding: We have limited control over how paths are drawn for units. In the unit's CFG entry, either comment out the RouteAvoidance line or set it to FALSE. The unit will attempt to follow the center of a tile instead of drawing a smooth curve. Some, if not all vehicles do not use smooth curves in their paths. More testing will need to be done to confirm how this affects other vehicles and monsters. Interface Elements: We can change the position of all of the main game's interface panels through the use of Cafeteria. What We Cannot Change and Why Materials: We cannot add more materials to the game and we cannot edit the existing materials' behaviour. Energy Crystals will always be used for power, and ore and bricks will always be used for building. More than one teleportable raider: There is nothing in the code that allows us to add another Teleport Rock Raider to Planet button. You are stuck with whichever raider comes first in the CFG. Changing the trained skills: Geologists will always scan, explosive experts will always kill themselves, and engineers will always try to repair buildings that are being eaten by lava. Vehicles that only cross land will always require drivers, vehicles that only cross water will always require sailors, vehicles that cross both land and water will always require pilots, and vehicles that cross lava will always require pilots. Tiny Monsters: Rock Monsters and Lava Monsters always turn into Tiny Rock Monsters, and Ice Monsters always turn into Tiny Ice Monsters. Slugs and custom monsters can never turn into tiny monsters. Pathfinding Algorithms: Though you can prevent raiders from taking shortcuts over lava, there's no way to change how the game handles pathfinding. Dynamic Lighting: The only light sources in the game are the cursor light and track object view light. We cannot add other lights. Priorities and Properties: We cannot add new, original entries of either of these since their functions are hardcoded into the game. We're limited to what already exists. NPL Scripting: We can't do anything with NPLs other than what's listed here: http://www.rockraide...=Nerpsreference Saving Progress During a Level: You can only save your game after you complete a level. If you need to go to the bathroom, pause the game. Adding Wall Types: We can't add more wall types. We're limited to what was programmed into the game, and even then, some wall types can't be used because of changes made to the surf and dugg maps during development. Speculations Some members are digging through the game's assembly code to find ways around the game's limitations. Implementations of many such discoveries require editing the game's EXE.