Jump to content


Popular Content

Showing content with the highest reputation since 05/19/2021 in all areas

  1. 4 points

    In-depth Look at the CFG Syntax

    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"
  2. 3 points
    Maxim Ivanov

    Lego Racers Unity remastered.

    Little video.
  3. 2 points

    Question: Chaning the max amount of rock raiders

    Welcome to RRU. I believe changing the OxygenCoef for the rock raider will do it. Here's the relevant section in the CFG. Change -1.0 to -0.66 and you should be able to bring 15 raiders per Support Station. Pilot { Levels 4 RouteSpeed 01.500:01.650:01.850:02.000 SoilDrillTime 08.000:07.000:06.000:05.000 LooseDrillTime 08.000:07.000:06.000:05.000 MedDrillTime 12.000:11.000:10.000:09.000 HardDrillTime 00.000:00.000:00.000:00.000 SeamDrillTime 15.000:14.000:13.000:12.000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OxygenCoef -1.0 CanStrafe TRUE EnterToolStore TRUE ShowHealthBar TRUE } Someone else can double check me.
  4. 2 points
    lol username

    How The Legend of Mata Nui Was Found

    A few months ago, there was some discussion in the comments of this video about who found Bionicle: The Legend of Mata Nui. The thing is, Bennet/mcdude451 isn't technically wrong, but the full story of how it all played out is long, messy, and kind of hilariously dumb. I definitely don't blame Liam Robertson for not knowing it. Since I'm pretty much the only person who both saw the actual start to all this, and has also been significantly involved in it to the current day, I feel like I'm probably in the best position to tell this story. Buckle up. 2001 - 2017: ROADS TO NOWHERE People had been curious about LoMN pretty much ever since it was canceled. This would eventually turn into people outright trying to hunt it down. In May 2004, an anonymous person only known as "Deep Brick" sent screenshots and other information about the game to Mask of Destiny. Deep Brick's copy of the game was the from the very end of development, and would be the closest look at the game we would have for years. In 2010, Deep Brick recorded footage of the game (as far into it as they could get, before running into a softlock), and again passed it to the Mask of Destiny admin Mark/RedQuark for posting on YouTube. They also sent some small sample files from the game, but were afraid of sharing the entire game, should LEGO object to it. This was a wealth of new information, and the first time we'd seen the game in motion. People had wanted the game before, but now they really wanted it. There were a lot of persistent rumors about the game. Common myths included there being 8 beta discs, sometimes said to be packaged in with sets, etc - none of which were true. Occasionally someone would claim to have the game, or otherwise fabricate some information about it, to get attention or just for the sake of trolling. People tried contacting developers or other people who potentially had the game, but this usually led nowhere. Fans all-too-eager to get their hands on the game turned away people who actually may have had it. MID-LATE 2017: LOL TROLLS AMIRITE For a good chunk of 2017, this forum was offline for maintenance, but had a shoutbox on the main page so people could keep in touch in the meantime. This shoutbox wasn't backed up or archived as far as I'm aware, but I have some screenshots. July 17, 2017: July 20, 2017: Darvell had also previously replied to someone on BZPower (though his name wasn't given), among many other people who'd approached him privately. However, his own copy - from October 10th, 2001 (the date the cancellation officially happened and many people were laid off) - remains lost to this day. We'll get to that later. Months later, on September 22, 2017, Bennett again entered the shoutbox, this time claiming he had the game. Unfortunately I can't find full logs/screenshots of this, but I do have some reactions to it from a Discord server: The gist of it was Bennett was claiming to have the game, but when asked for any shred of proof (I recall asking at some point if he could even just screenshot the disc contents and/or installation directory), he refused to give it. That, plus how many times this sort of thing had happened before, led everybody to dismiss it as just another person lying to get attention. On October 5th, 2017, Bennett entered the shoutbox again, but it went the same way as last time - people asked for any kind of proof, he refused to give it, and so he was dismissed as a troll. Again, I can't find any direct logs of this, but there was discussion of it in a Discord server: At this point, someone who was in Bennett's own Discord server posted some logs from it, before getting kicked. I'll post some snippets from them, since they give some more insight on the timing of things: However, I don't think most people actually bothered even reading those logs at the time - I know I didn't. Maybe if they had, they would've given it second thought, but then again, everybody was so turned off by how Bennett/mcdude451 was acting in the shoutbox that they dismissed it and moved on with their day. And for a long while, that was the end of Bennett's involvement, as far as everyone knew. 2018: OH BOY HERE WE GO In late January 2018, a completely separate chain of events was kicked off. It's a story in and of itself, but not one I imagine some people would like me telling, so I'll cut to one of the things it resulted in: in early February, the BioMediaProject was anonymously emailed a link to a build of LoMN, Alpha 0.006, from July 24, 2001. It's unknown who it was that actually provided this build of the game, but at long last, it'd happened. It was a much earlier build of the game than the final build Deep Brick had shown, but this turned out to be a positive - much content had been cut or redesigned between the two builds, and if it were not for us getting this alpha build, we likely never would have known it existed. Interest then turned to fixing bugs and crashes in this build, to make it as playable as possible. While I initially wasn't involved in this, I eventually started poking at it around late Febuary-ish, and started making fixes myself. A team organically formed, and we kept hammering out dents in the game. At some point, we got into talks with Liam Robertson, who decided to make a video about the game - the one linked at the top of this post. As part of his research on it, he started talking to some of its developers, including Darvell... Who, in April 2018, sent him the final build, from October 23d, 2001. Liam R then sent this final build to us. Talking with Liam R, the decision was made to release this final build at the same time as Liam's video - it wouldn't take long, we could make some patches to make it more playable in the meantime, and it'd be a cool surprise. As it turns out, life happened, and Liam's video ended up taking about a month to create - which meant a month of us working on patching the final build in secret. It was all hands on deck, and a lot of fun, though we were all itching to release it to the world. (An aside - during the wait, some folks on the team took it upon themselves to create a weird meme-y ARG teasing it - which I thought was a mostly bad idea, and it did indeed almost blow up in our faces once or twice, but it also gave me a chance to do this, so whatever lol) Then on April 28th, 2018, 2 weeks before Liam R's video would end up being posted, Bennett/mcdude451 showed up in the public Discord channel. Remember, nobody outside the team knew we had the final/October 23rd build at this point. All of these screenshots are from now-public channels in a large Discord server, so I'll leave usernames intact this time. Now, here's what was happening in the (then-private) team channel... TL;DR Bennett/mcdude451 got a physical disc of the final October 23rd build in the mail from an anonymous developer, in October 2017. He bragged about it on RRU, refused to show any proof, and got dismissed as a troll. He did, however, send a cue/bin disc image of the game to Darvell - one of its programmers, who'd lost his own copy. The alpha build from July 2001 made its way to the internet in February 2018 through an entirely unrelated series of events. If Bennett had posted his October 23rd build online right when he got it, this wouldn't have happened, since people would've stopped looking for the game. Liam Robertson later talked to Darvell in April 2018, and was sent the cue/bin of the final October 23rd build that he'd gotten from Bennett. Bennett showed up again shortly before the final build was about to be released, finally showed proof of him having it, and we all died laughing as we realized what'd happened. So, the chain is: Anonymous developer -> Bennett -> Darvell -> Liam R -> Us/the BioMediaProject -> The open internet. Bennett still owns the original, physical disc. Most websites and articles, like the IGN article, simply say Darvell gave Liam R the build. Liam probably didn't know the full history of what had happened - even Darvell probably didn't. Darvell said he doesn't know much about all the players in this saga to get the game; that he'd been contacted by many people in various ways, and always tried to help them and tell them what he knew. Darvell's own copy from October 10th - the day the project was officially canceled, and he left - remains lost. This is, strangely, another stroke of luck - if he had it, he likely would have posted it online far sooner than any of this. Not only would we have missed the alpha from July, we also would have missed the true final build from October 23rd - which had some extra work done "on the side" past the official cancelation, was burned to discs, and passed around to its developers (supposedly without clearance from Saffire management), so they would have something to remember it by. As far as I know, Deep Brick hasn't ever responded to the game finally making it out to the internet. As far as we can tell, their copy is identical to what we have - one of the final October 23rd builds handed out to the devs. I don't think Bennett is a bad dude or anything, he's just some LEGO fan who was excited to get the holy grail of Bionicle, and didn't really know what to do from there. I guess if Darvell ever happens to find that October 10th build in his garage, we'll have 3, lol.
  5. 2 points
    lol username

    How The Legend of Mata Nui Was Found

    Update - Darvell found his copy, though it turns out it's actually the final October 22nd/23rd build as well: The disc's contents are indeed an exact match for the previously uploaded final build, so in that sense it's nothing new, but it's cool to see the disc label, and for the mystery of his copy to be solved.
  6. 1 point

    In-depth Look at the CFG Syntax

    Impressively found! I had no idea that // didn't work as a comment and instead caused the next line to break In particular, I've always been curious about what the ! , @ , and * operators all do. You see the former two in sounds occasionally and the * once as a weird case. I've also always been marginally curious why indents were always used in the .cfg yet seemed to never be necessary. I wonder if the // comment style is a leftover from the mission scripting with .nrn and .nrm files compiling into .npl , where // is used as a comment. As a side note, one of the original devs said a long time ago (source somewhere buried in here) that their original .cfg editor was Notepad - which explains why you can open and edit it in Notepad so easily.
  7. 1 point

    Cafeteria Patch Documentation

    Note that script.txt needs to be formatted using CRLF ("\r\n") newlines. Otherwise it seems that everything will be treated as a single line, (which I think was executing successfully because the first line was a comment). Some editors like VSCode may not use this format by default.
  8. 1 point

    Cafeteria Patch Documentation

    PATCH DOCUMENTATION FOR CAFETERIA If you do not have Cafeteria or don't know what it is, go to the Cafeteria Topic first. WADP Files A WADP file is a standard WAD file with the same format as LEGO Rock Raiders' WAD files. The extra "P" means "Patch". It's used to bundle all the necessary files for a patch into a single file for easy distribution. A WADP file has two necessary files for it to be identified by Cafeteria as a patch it can execute. These two required files will be covered in the next section. WADP Anatomy A WADP file must have 2 files in the root directory. These files must be called info.xml & script.txt (lowercase) so they are correctly identified. info.xml This file provides information about the patch for the patching system. Inside it contains information about the patch such as its name, author, version and more. It also contains information to help the patching system to prioritize your patch and IDs to check for any patches that may be incompatible with each other. script.txt This file is the script that Cafeteria will run in order to apply your patch. The contents contains commands, one per line similar and it will tell Cafeteria what to modify in the CFG and WAD. The format is similar to standard command line. Info.xml The required contents of an info.xml file (for version 1 of the patch system) are as follows. All these elements are REQUIRED. It is however best to create this file using the Developer Tools in Cafeteria itself, rather than writing your own. If this file cannot be found or if it is invalid, it will not appear in the Mod Manager of Cafeteria. Standard Format: <?xml version='1.0'?> <patch system="1"> <name>My Patch Name</name> <author>Username</author> <version>1.0</version> <description>This is a little info about my patch.</description> <uid>rru.lrr.username.mypatchname</uid> <priority>1</priority> <dependency>rru.lrr.username.myotherpatch,rru.lrr.username.someotherpatch </dependency> <incompatible>rru.lrr.username.badpatch</incompatible> </patch> System: This defines the patch system to use to apply this patch. In the future, changes to the system will occur and this number will increase, you should always use the latest version. Name: This is the human readable name of your patch. Do not include a version number here. Author: This should be your username. Version: This is a human readable version number of your patch. Description: This is information about what your patch does. UID: This is a unique identifier for you patch, it is used to internally identify your patch when processing. This is required to be in the format: rru.lrr.[username].[patchname] . This should be in lowercase and contain no spaces. You should never re-use across different patches, this is to say if you make a patch that changes textures and another patch that adds models, these should have different UIDs. Priority: By default this should always be 1. (This property is depreciated since Cafeteria 1.0 BETA 1). Dependency: This is a comma separated (no spaces) list of UIDs of other patches that a user needs for this patch. If a user does not have the patches in this list, your patch will not be applied. Incompatible: This is a comma separated (no spaces) list of UIDs of other patches that this patch cannot be installed with. If an incompatible patch has been installed before your patch, your patch will not be applied. Script.txt CFG Commands CFG:AddProperty - Adds a property to a block. CFG:AddProperty <block path> <property name> <property value> CFG:SetProperty - Changes the value of a property. CFG:SetProperty <property path> <value> CFG:RemoveProperty - Removes a property from a block. CFG:RemoveProperty <property path> CFG:RenameProperty - Changes the name of a property. CFG:RenameProperty <property path> <new name> CFG:AddBlock - Adds a new block { } CFG:AddBlock <parent block path> <block name> CFG:ClearBlock - Clears properties from a block and/or removes child blocks. This will not remove the block itself that you are clearing. CFG:ClearBlock <block path> <remove children TRUE/FALSE> CFG:RenameBlock - Renames a block CFG:RenameBlock <block path> <new name> CFG:InsertCFG - Inserts the contents of a CFG file from the Patch WAD into a block. CFG:InsertCFG <parent block path> <patch file path> WAD Commands WAD:AddFile - Adds a file from the Patch WAD to a directory. WAD:AddFile <patch file path> <wad file path> WAD:AddFilesFromDirectory - Adds a directory of files from the Patch WAD to a directory. WAD:AddFilesFromDirectory <patch directory path> <wad directory path> WAD:RemoveFile - Removes a file from a directory. WAD:RemoveFile <wad file path> WAD:RenameFile - Renames a files in a directory. WAD:RenameFile <wad file path> <new name> WAD:InsertReplaceFile - Replaces a file with another file or adds it as a new file if it doesn't exist. WAD:InsertReplaceFile <wad file path> <patch file path> WAD:ReplaceFileData - Replaces the data of a file in a directory with the data of a file in the Patch WAD. (No file names are changed) WAD:ReplaceFileData <wad file path> <patch file path> WAD:CopyDirectory - Makes a copy of a directory. WAD:CopyDirectory <wad directory path> <wad directory path of copy> WAD:RemoveDirectory - Removes a directory and all it's files. WAD:RemoveDirectory <wad directory path> WAD:MoveDirectory - Moves a directory to a new path. WAD:MoveDirectory <wad directory path> <new wad directory path> Block & Directory Paths These paths are formatted the same, and must finish with a final backslash. Block Path: Lego*\Main\ Directory Path: Interface\RightPanel\ Property & File Paths Again these are the same, however they do not feature a final backslash. File paths must include a file extension. Property Path: Lego*\Main\LoadingText File Path: Interface\RightPanel\CrystalSideBar.bmp If a parameter in your scripts contains a space, for example in a directory path, enclose the parameter in quotes e.g "This Folder Has A Space" Comments You can put comments in scripts. Comments should begin with a double forward slash. // This is a comment
  9. 1 point

    Bits N' Bricks Podcast

    I understand most people are well-aware about this series (especially those of you on the RRU Discord), but for the sake of future reference/preservation, here's a topic dedicated to the official LEGO Games "Bits N' Bricks" podcast. [Side-note to any avid listeners of the podcast: feel free to correct me if I get any information about this podcast incorrect. I'll try to fix any errors post-haste] [ The full playlist of the "Bits N' Bricks" podcast, hosted on the official LEGO Gaming Youtube channel ] What IS the Bits N' Bricks podcast? Bits N' Bricks - Season 2 Full Episode List Episodes of the "Bits N' Bricks" podcast release every Wednesday, at roughly 12 noon [GMT]. The series is available on: - Apple Podcast - Spotify - Stitcher - Youtube - Google Podcast - ...and RSS Full transcripts of every episode are available on LEGO's website. More information about the series, as well as info on the 25th anniversary of LEGO video games, can be found on LEGO's website here: https://www.lego.com/en-gb/legogames-25
  10. 1 point

    Thoughs on Lego Builder Journey

    Huh, well that was a surprise for me. I am really curious about the puzzle aspect about it, so that is my angle. I like aesthetics however I need a bit more meat to my games than looks. I'm also happy that we were are getting something new from Lego, hopefully this is a trend that will keep on going.
  11. 1 point

    TUN/PCM Converter

    Turns out that FFmpeg does support conversion of LEGO Racers tun and pcm audio, as of these releases: (I cut out the rest of the highlights) According to the FFmpeg source code, we have this person to thank: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/adpcm.c https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/alp.c
  12. 1 point

    LEGO Awesomeness

    Sorry for the double post (something I cannot avoid, considering this thread hasn't received any new posts since my last one), but here's another case of "LEGO Fan redesigns old sets" which might be interesting to some individuals: ArtStation user "Gunn Illustration" made a thread of 3D renders where he overhauled a bunch of "Time Cruisers" and "Time Twisters" sets, reimagining them in the slicker design-style of modern LEGO sets, while preserving the whimsical "LEGO System mash-up" look and design that both themes are distinct for: (The full collection of renders (featuring more sets than the three shown here), can be found at https://www.artstation.com/artwork/g2BAwx) I was initially planning to post just his Time Cruisers/Time Twisters stuff, but I decided to dig through his ArtStation account and discovered that he's done a few other theme reimaginings - specifically Studios and all 4 stages/versions of Adventurers - and even some cool custom digital MOCs: It's genuinely awesome work, and his account is well worth a looksie: https://www.artstation.com/robtoonz44
  13. 1 point

    Broken "Contact Us" Form

    Recently I discovered that the Contact Us form on this site was not working as expected. There were some server issues (mostly fixed), but my email provider started blocking messages sent from that form (not sure how to fix). We've figured out a temporary solution, so please send your messages again if you have sent any since the beginning of the year. Alternatively, you may contact me on Discord at Cirevam (number symbol) 1894 until the form is fully functional. Please only contact me this way if you are having account issues or issues with the site.
  14. 1 point
    Maxim Ivanov

    Lego Racers Unity remastered.

    I love AI, that improves pictures quality
  15. 1 point
    Maxim Ivanov

    Lego Racers Unity remastered.

    I love how new map preview pics. Admiral and Forestman are looks not great. They all will be just a pics, maybe they will gеt animation in the future.
  16. 1 point

    My LEGOs, including RR :)

    Here is the "complete" family of Lego Stunt Rally ! And now a new family : Yes, it's Lego RACERS ! Some pieces aren't with the good color, some pieces are still missing, some stickers too AND some characters are not exactly the same (too expensive...), but I'm so happy about the results !
  17. 1 point

    Rock Raiders has hotkeys, apparently

    In the Lego.cfg file there has always been a very confusing reference to keys. They did not appear to do anything. The only game-interaction hotkeys ever appearing were in Rock Raiders' debug mode. Recently, a document was unearthed about Rock Raiders hotkeys. To make a long story short: 1. To use hotkeys you have to hold F2 and click the selected hotkey 2. Hotkeys are rebindable in the Lego.cfg file in the "InterfaceImages" section. The last entry of each row refers to a key. search "KEY_M" for an example. Now that's a 20-year old secret hiding in plain sight! Edit: Also worth mentioning that in Eye View, Z and X makes your character strafe, which I learned fairly recently myself
  18. 1 point

    CE: Roadmap

    IT'S HAPPENING! CE is happening! Rejoice, all ye RRUsers! I have some requests! Description: Allow specifying starting levels via ObjectList via a new Levels parameter. Benefits: Building levels can be painfully specified via NERPs (yet to look into this fully) for the start of a level, but there's no way to start vehicles with upgrades. You can also specify Health, suggesting that the functionality of the .ol should be straightforward to extend. Examples: - A level in which you must get the lost Chrome Crusher back to base. It would feel much more like an extended mining operation if it was fully upgraded. - With Upgraded Hover Scouts and other vehicles, their upgrade level determines their functionality. Starting with a Hover Scout that was able to drill could make, say, Run the Gauntlet play quite differently. Description: Recharge Seams do not count as a wall for the purposes of landsliding Benefits: LRR already has a lovely random landslide generator that you can couple with Fall.map to cause extra landslides where you want them. The random generator can surprise you, like landsliding walls behind walls (otherwise fiddly to do), and just generally adding a bit of hazard fun that you can get rid of with reinforcements. However, this isn't usable in a level with Recharge Seams, which cannot be reinforced, and thus landslide endlessly, causing all sorts of annoying stupidity. Examples: This allows the random landslider to be used on levels which would benefit from not having to paint landslides by hand. Note: Recharge Seams can also act as monster emerge points. If the easiest way to prevent them from landsliding is to also disable monster emerging, that's fine. Description: Mid-level saving and loading Benefits LegoRR.exe has stopped working... By allowing saving, if we aren't able to find the cause of the crashes, we can at least save every so often on large maps so they don't explode as much. Examples: Perhaps this could be implemented by effectively writing everything into a map file: Surf.map, Dugg.map, Cror.map, ObjectList.ol, InitialCrystals, InitialOre, etcetera and then re-loading this in a special dedicated "Continue Last Game" level slot. However this would not record object levels, behave poorly with constructions in progress, and severely stuff up the task queue. Nevertheless, it would be a save functionality which could allow the player to recover from a crash: not having the above is merely a minor concern. As for the effect on level progression - once this saved level is won, the player can enable debug keys, load the original level, hit Ctrl+S to insta-win, save on the scoreboard, and then continue with the next level. Note: NERPs and record objects record everything in the .ol so it is highly possible that levels using the above idea would play up. However these levels are few and far between - the only one truly needing it in vanilla is Explosive Action. The map creator may need to write a disclaimer of sorts, saying "Do not use with saving and loading" Description: Extension of tutorial block limit beyond 56, preferably up to the limit of the .map file, 255. Benefits The Tuto.map is still relatively unexplored but hits a cap for no discernible reason at 56. While vanilla maps rarely use numbers beyond 5 (a notable exception being Don't Panic), it should be straightforward and useful to extend this limit. Examples Implementing this should be simply changing the number 56 to 255. However I have almost no knowledge on the underlying framework. Nevertheless, its inherent simplicity is why it is suggested here. Uses include: - Triggering monster invasions requires at least one tile for you to point out where the monsters emerge; the easiest trigger is another tile for a raider to walk on. Furthermore, being able to spend a list of tutorial blocks (eg 1-10) allows you to put short timing delays in between triggering an emerge at each different tutorial block, making it seem less scripted and more natural - Hidden caverns can be marked with a tutorial block to essentially check progress through the level - By marking every wall with a block, you can count the number of blocks destroyed & send measures (erosion, monsters) accordingly, to prevent strip-mining (experiments of this were where I first discovered a phantom limit) - Paving over Slug Holes requires 5 tutorial blocks per slug hole - more wacko ideas including Maze, Minesweeper, or an orbital laser used to demolish tiles, ideas both stymied by the 56 block limit (even a 10x10 grid would require 100 blocks) Description: New NERPS command: ForceSetTutorialBlockIsGround X. Regardless of the current tile state this would forcibly set the tile(s) marked X to ground. Benefits: There is no way to remove erosion. Neither is there a way to delete water. This command would enable this to become possible. (The tile may re-erode again: I don't mind if this happens or does not happen). Examples: Using this command and use of GetRecordObjectAtTutorial with regards to a LargeHeli present on level start, it would be possible to have the Tunnel Transport pick up water from a lake and dump it on lava, creating a ground tile. The converse would also become possible: deleting water with lava. Imagine Fire and Water, but instead of sailing over you make yourself a land bridge. SetTutorialBlockIsGround and SetTutorialBlockIsPath will demolish walls and remove rubble respectively, but they will not remove lava nor water. This would also allow for proper paving over slug holes: in the current implementation the hole is still there, but it merely has a power path over it. (But wait Aiden, isn't this hilariously technical in scriptomancy? Most of us aren't script wizards! - to which I say I can write up a template you'll be able to use, as well as what tutorial blocks to paint where. Should be straightforward enough!) Description: Allow vehicles to have an ore and stud cost which is returned when the vehicle is teleported up. Benefits: Currently, while CrystalCost works for vehicles, StudCost and OreCost in Lego.cfg do nothing. It would be possible to force the player to upgrade their vehicle to have its functionality (eg: no carrying until upgraded), but this wastes an upgrade slot that could be used for something more interesting. Examples: This would force the player to not only have crystals to spare, but also stockpile ore. This could make lategame vehicles more meaningful, as now not only do you need 5 Energy Crystals to teleport down the Chrome Crusher, you need to have stockpiled 150 ore. Furthermore, ore spent on upgrades is not returned when teleported up: so while I can make the Chrome Crusher cost 1000 ore on its drill upgrade, if a monster stunlocks it that's 1000 ore down the drain you won't see again. Note: Currently in the game a quiet distinction between Ore and Studs exists. Say I have 80 ore stockpiled from before I built an Ore Refinery, and then have collected 10 studs (=> 50 ore's worth). The game displays 80+50 = 130 ore. However, if there is a vehicle upgrade that costs 100 ore | 20 studs, it will not be available to click, because I neither meet the stud requirement nor the ore requirement. I am happy for this functionality to continue if it means vehicles can at least have an ore and stud cost! Description: Extend the UpgradeTypes limit beyond whatever it currently is (80-ish? Will experiment to see if I can find a number) Benefits: The game is known to crash when the UpgradeTypes { in Lego.cfg reaches about 80. This, as one can see, is immediately problematic for upgrading vehicles (eg: my [unreleased] Hover Scout Upgraded model requires basically ten UpgradeTypes due to the way its front piece works). One can be efficient but the LRR devs can hardly be called this and it would be significantly easier to have this overhead limit increased as to not worry about it. Examples: As above, the Upgraded Hover Scout has about seven front pieces alone, plus a change for the laser upgrade, plus defining the mini laser itself, plus some other stuff I probably forgot about when writing this post. I have leeway for this, but no more: were I to add another vehicle with extensive upgrades I wouldn't be able to do so. Looking forward to whatever comes out of this
  19. 1 point

    Need help finding Lego racers 1 Mods

    None knows. If you want to mess around with modding tools in the meantime however, those can still be accessed. It may not be the same thing as getting pre-made mods, but at least you'll be seeing some changes. Edit: I've got a few powerup layout mods in my history. Brickless tracks: https://app.box.com/s/t6d84fn3murl7xzuq630 Green-brickless: http://www.mediafire.com/file/vov0g87q1ybqus7/Green_Brickless_LR_Tracks.zip
  20. 1 point

    Request: LRR Sound Effect/Voice Clip Downloads?

    Appreciated - thanks for dealing with my n00bish forum decorum, and regardless of the Racers sfx, you are the BEST for showing me the link to the LRR sound I wanted. Sorry to have nitpicked, but, I can at least give you the knowledge that getting this sound file has made my day, and brought a dumb ear-to-ear grin to my face. While you did say I don't have to, now that I got the LRR files I wanted, would it better for me to edit out the Racers parts of this topic and reinsert them into a new topic on the proper forum, (where perhaps it will garner the attention of those more able to fulfill the request,)* or, would that be a waste of the sites' server space? Basically, how likely is it that the sorts of Racers fans from the game's forums here will see my request given that it's within the LRR forum... under a topic that... doesn't... mention... Racers... Um, never mind, I think I answered my own question. lol Thanks again! * Addendum: While making the Racers forum topic, I realized that the last part of my message there applied equally to the Rock Raiders & Alpha Team communities here. I was always fondest of LRR, so I thought I ought to share my thoughts as inspiration to the creators and supporters of this community - especially both the makers of the debugging/overhauling mods and to any/all of those who may yet still be fighting the good fight to release the game's rights. (If that's still a thing? I think it is?) Anyhoo, I'll stop blabbing. Here's what I said: * "Thanks so much for being awesome, and for keeping these games alive. I can only hope that I can still find your efforts here once I finally can play these games again. I dearly want for have these games - Rock Raiders, Racers, & Alpha Team - to become parent-child memories for my own kids that are just as happy for them as the ones me & my dad have from when we played them together as I sat on his lap."
  21. 1 point

    Things We Know About Modding LRR

    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.
  22. 1 point
    lol username

    Lego should make more Creator Games

    Minifigures isn't even remotely similar to Universe. It's actually quite unique, as far as LEGO games go - I wouldn't even call it similar to Chima Online. Regarding LU - the game was focused on a demographic/age group that, by and large, neither had the skill to do much with properties or the patience to deal with finite bricks/running across the whole darn universe to buy that one piece from a vendor. From what I saw, most AFOLs who would have liked the interactive building/sandbox were turned away by it being tied to a game and having a subscription requirement. Add in the fact that LU properties were glitchy as hell (breathing on a property too harshly could lead to losing work or even corrupting the whole thing and making the property unusable, and even basic things like rotating hinges ended up not working at points)... Yeah, it's not a big mystery as to why it didn't catch on with much of the LEGO community. There's a lot more I could talk about on the subject, but I >already have.
  23. 1 point
    Oboe Shoes

    Lego should make more Creator Games

    Honestly, I'd be content if LDD had even a small, basic play around mode like LC1 did. I can get my fix of building random things in Digital Designer, seeing as it's essentially an improved Creator build mode with nearly all bricks, but I really miss the charm of watching those creations run around and do things. While I'd welcome a Creator 2, I like LDD's build mode so much, I kind of wish it would just be an add-on to that, even if it was just the basic features ported over from creator, such as moving minifigures and Drivable/Flyable vehicles. While I'd be more than happy with just that, part of me would really like to see a full-blown sequel that takes advantage of what is possible to do now. More detailed environments of a larger variety, weather, boats, spaceships and other misc. vehicles... It'd be great fun.
  24. 1 point

    Launch Rock Raiders Directly Into A Level

    LEGO Rock Raiders has an inbuilt executable parameter to launch the game directly into a game level. This function would have been used to debug levels when the game was in development. If you want to start the game into a level without having to navigate the menu, this tutorial will show you. Disable the front end You will first need to disable the game's front end. Firstly open the file 'Lego.cfg' located in LegoRR1. In the 'Main' block at the start of the file, scroll down till you find the setting called "FrontEnd" and change its value from "TRUE" to "FALSE". Save the file then re-build LegoRR1.wad if you need to. Shortcut In order for this to work you must create a shortcut to 'LegoRR.exe' which is located in the Rock Raiders install directory. Once you have created it, right click on it and go to Properties. In the 'Target' text field add this to the end after the closing quote. -startlevel Levels::Level01 "Level01" in the above code is the level you want to start. You can change this to "Level02", "Level03" etc... to start different levels. Batch File With the shortcut above, you may find it annoying to have to change it for each level. There is a better way to do it using batch files which will allow a user to enter the level number. Firstly create a new file in the Rock Raiders install directory, call it 'StartLevel.bat'. Make sure the file extension is '.bat' or this will not work. Open the file in notepad and paste this code: set /p level= Enter the level you wish to start: LegoRR.exe -startlevel Levels::Level%level%[/code] Save the file and that's it! Note that if the level number is below 10 you must put a 0 in front of the number for the batch file to work.
  • Newsletter

    Want to keep up to date with all our latest news and information?
    Sign Up
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.