Leaderboard

Over the years I have noticed many broken image links in older topics and they look like this (I took a working picture of mine and show you how it looked when it was broken): gallery_1586_213_7445.jpg And if you click on them you land on the RRU main site again. Well, how do you repair them then? Since this also affected my threads and posts I wanted to come up with a way to fix my own images at least. I don't know how I exactly came up with the solution, but at one point I have probably compared the working with the broken image links and noticed that you could turn this into a template. Here is the example from above, but in a form that actually works and the only reason why you don't see a picture is that I used the "Code" option in RRU's text editor to show you the actual link. https://www.rockraidersunited.com/uploads/gallery/album_213/gallery_1586_213_7445.jpg Basically the broken example is the URL end part for the new working example and here is an explanation, what those numbers actually mean (The numbers and file types obviously change from image to image): "1586" is the user number "213" is the album number "7445" is the image number "jpg" is the file type And to put this all together here is the template for working links: https://www.rockraidersunited.com/uploads/gallery/album_*album number*/gallery_*user number*_*album number*_*image number*.*file type* Now use the "Insert other media" option in the bottom right of the text editor, then click on "Insert image from URL" and insert the working image link: Hurray, a working picture! I have also reminded you of the "The (slightly disturbing) Running Man" thread again XD. Since the links go by the same pattern I wonder, if a script could be made to replace the broken ones with working ones in the entire forum. At least for the pictures hosted on RRU this could be a solution. If you repair image links in your own posts I recommend making a working image first and then delete the old broken one or otherwise you might delete your only hint to what image you have posted. You can also use the template to find out what images were used in posts besides your own ones by just putting it into an new browser tab and inserting the correct numbers.

The .blx and older .BLK map files are not an old .map format (as was originally speculated), but instead are a format that communicates between the level editor used by DDI and the output .map format used by the game. These files contain a set of 16x16 icons, and a pair of numbers that determine how the icons are grouped together in the level editor (such as separating CryOre Crystal/spawn counts from Ore/spawn counts.) None of these discoveries are particularly useful. But... Programmer art is beautiful! Extracted Icons All map type icon sets have been extracted into individual png 16x16 icons, and grids containing all icons (as shown above): The Slimy Slug predug icon is actually pretty great. It looks like a crossing sign.

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