Jump to content
Cyrem

CE: Roadmap

Recommended Posts

Cyrem

LRR:CE Roadmap

 

There are many features/updates planned for Community Edition, a number of big updated have already been experimented with to prove plausibility. The goal of CE is to update LRR whilst being respectful to it's original formula and game experience, so there is no features planned to make it something that it is not. This is a list of planned features/updates or other changes that are planned for the future.

 

Ideas and suggestions for updates are most welcome. Keep in mind small changes such as extra CFG options or removal of hardcode can most of the time be added reasonably quickly whereas larger changes may need to be established somewhere on the roadmap and worked towards. If you do submit an idea, please do so in this topic preferably with the answers to these questions:

 

Quote

1. Describe the feature or change
2. What are the benefits of this change/feature?
3. Show or describe examples of this feature or how it might be implemented.

 

 

Roadmap

Legend

Completed Tasks

In-Progress Tasks

Delayed Tasks

 

v1.0.0.0

  1. This is the original LRR Masterpiece (Released 1999).

 

v1.0.X.X - Debug Milestone

  1. Initial work to start CE
  2. Features to enhance the ability to debug modding issues.
  3. Misc updates/fixes

 

v1.1.X.X - Resolutions Milestone

  1. Run LRR in resolutions up to 2k.
  2. Misc updates/fixes

 

v1.2.X.X - Multi-Minifigures

  1. New menu for teleporting different minifigures.
  2. Misc updates/fixes

 

v1.3.X.X - Nerps Extended Script (NEXS)

  1. New level scripting system.
  2. Misc updates/fixes

 

v1.4.X.X - Text/Font Update

  1. Update to text drawing functions to optimizes and add font features.
  2. Misc updates/fixes

 

v1.5.X.X - 32Bit Colour Support

  1. Support for running LRR in 32Bit colour.
  2. Misc updates/fixes

 

 

Community Ideas/Suggestions

These ideas have been suggested and accepted into the roadmap. They will be added into the roadmap above as they are completed.
 

  • Turn lava smoke on/off per level
  • Set lava smoke colour per level
  • Set crystal ui icon bmp per level
  • Extend tutorial block limit to 255
  • (Milestone) level load/save

Share this post


Link to post
Share on other sites
aidenpons

IT'S HAPPENING! :)CE is happening! :light1:Rejoice, all ye RRUsers! :light2:

 

 

 

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

Edited by aidenpons

Share this post


Link to post
Share on other sites
Cyrem

Thank you for all the requests! I'll comment on each one below.


Mid-level saving and loading

Something I do want to achieve in the future. This is definitely going to be a milestone and probably be achieved slowly with more and more data added to save files.

 

Extension of tutorial block limit

This will probably be done soon rather than later, I've already located the things I need to update. So look for this soon.

 

NERPS command: ForceSetTutorialBlockIsGround X

I'll definitely look into this one.

 

Vehicles to have an ore and stud cost
Another good idea worth looking into.

 

Extend the UpgradeTypes limit

Thanks I didn't imagine people would go beyond this limit, but that doesn't look to be the case :D I'll check it out.

Share this post


Link to post
Share on other sites
Slimy Slug

myturn.wav from Time Raiders plays

 

Description:

LavaSmoke MiscObject cfg property.

LavaSmoke RGB property configurable on a level by level and biome by biome basis.

DisplayLavaSmoke TRUE/FALSE configurable in same manner as RGB.

 

Benefits:

The texture path for the lava smoke miscobj is hardcoded, as is the presence of the smoke, and the rgb applied to the textures.  Removing these limits allows for a new type of erosion liquid replacement for lava - such as acid - without the potential disparity with smoke and/or color.

 

Examples:

An acid biome with... acid in place of lava could utilize different smoke rgb.  A hacky solution for water erosion (hint hint :old_wink:) would be to disable lava smoke and replace the lava and erosion textures.

 

 

 

Description:

Interface elements on a level by level or biome by biome basis.

CrystalRGB on a biome by biome basis (maybe redundant?)

 

Benefits:

Allows for potentially having buildings, vehicles, crystal colors, etc. show up on certain levels only.  The interface elements for them at least.

 

 

Examples:

If I have the default crystal color as blue, but I have green and red crystals on several other levels respectively, I can have blue interface elements set as normal, but override them either on a level by level or biome by biome basis. 

Share this post


Link to post
Share on other sites
Cyrem

Thanks Slimey Slug

 

8 hours ago, Slimy Slug said:

LavaSmoke RGB property configurable on a level by level and biome by biome basis.

DisplayLavaSmoke TRUE/FALSE

 

I'll note these as two separate features. As we've discussed these shouldn't be too hard todo. Gas causing acid liquid would work nicely with level Toxicity.

 

8 hours ago, Slimy Slug said:

Interface elements on a level by level or biome by biome basis.

CrystalRGB on a biome by biome basis (

 

CrystalRGB for levels is already added, however not the ui bmp, so thats an idea. This could be fleshed out a little with a CrystalTypes property block where you can set the rgb colours with level ui icon etc.

Share this post


Link to post
Share on other sites
Ben24x7

Okay, admittedly this feature request/submission is very, very low priority (to the point where it has no impact on the game itself) and is... kind-of nit-picky, but...:

 

 

 

Description:

Ability to easily disable custom "LRR:CE" icon.

 

Benefits:

While it's a nice touch to replace the default LRR icons with an up-to-date "Community Edition"-branded logo, a few people (like myself) might prefer to keep the original LRR logo for the sake of nostalgia.

 

Examples:

Perhaps during the LRR:CE installation process, give users the choice of whether they want the icon to be replaced or to keep the original.

Either that, or don't overwrite the original LRR icon and keep the original file intact (unless you have to overwrite the original file in order to change the shortcut icons, in which case, provide a copy of the original logo - possibly with a different filename - alongside the new, custom icon, so users can replace the game's icon manually if they want to).

...

Or possibly make the custom icon an optional "Mod" for the game.

Admittedly, all of these solutions depend on how LRR:CE installs the new icon in the first place.

 

 

 

Again, this is an incredibly minor nit-pick, and I assume no-one else would care if the custom icon was optional instead of mandatory, but I would be happy to see this implemented in a future build.

...

...unless it already exists in the currently released build, or there's a simple work-around, in which case sorry to waste your time.

 

 

Nonetheless, I think what you're making here is incredible, Cyrem. Thank you soo much for creating LRR:CE, and I'll definitely be keeping an eye out for future updates!

Share this post


Link to post
Share on other sites
Cyrem
13 hours ago, Ben24x7 said:

Ability to easily disable custom "LRR:CE" icon.

 

I could probably remove it, though there were two reasons for giving the game a new icon:

1 - To visually tell the difference between the original and CE when you have both exe's in the same folder.

2 - 32px icons look terrible on Windows Vista and above.

 

I'd be interested in other peoples take on this as well?

Share this post


Link to post
Share on other sites
aidenpons
Quote

I'd be interested in other peoples take on this as well?

I feel like a new icon reflects the new changes.

Original LRR didn't have all these cool features, and I feel that adding more functionality deserves a new look. While CE at the moment is not drastically different from LRR, things like multiple minifigures, greater resolutions, and the 32-bit color (all on the roadmap!) will really change the way not only LRR plays but also how it looks.

 

On 10/2/2019 at 9:08 AM, Ben24x7 said:

a few people (like myself) might prefer to keep the original LRR logo for the sake of nostalgia.

But at the same time, if you want to be playing the original game, you can still do so - Community Edition won't make it run on Win10, but it just adds some new stuff to play with.

 

At the same time, if this isn't technically difficult to do (you're doing magic I don't understand Cyrem :P ), why not?

 

 

Aaaaand another batch of requests :P.

 

 

Description:

Increase building and vehicle limit (currently the panel crashes if you try to add a building, and there's only 7 vehicle slots or suchlike IIRC. Haven't investigated this in too much detail, and probably should)

 

Benefits:

This allows lots of new buildings and new vehicles to be added. While the functionality of vehicles is already nailed down in LRR, and new vehicles wouldn't drastically change the way the game plays, it would still be fun to be able to add stuff like Treasures from the Lair, and have more fun toys to play with.

 

Examples:

I know you did the building limit in the previous batch of CE :P and I have some interesting ideas for the Air Filter myself: the Support Station is moved to a very lategame building and the Air Filter requires only ore to build, but only offsets the oxygen by 1 or so. (It's nearly two years since it was teased :( )

 

 

 

Description:

Debug Key Z when in first person currently triggers Activity_Eat. If this were to be changed to Activity_FireLaser, one would have first person shooting. See this. For an animation that has the camera nulls, I quickly put this together. (If you want to see how this looks and are not Cyrem, open Pilot.ae and point Activity_Eat to Shoot)

 

Benefits:

F I R S T  P E R S O N  S H O O T I N G

 

Examples:

F I R S T  P E R S O N  S H O O T I N G

 

 

 

Description:

Scanners show resources in walls and contents of hidden cavern (lava, water, potentially monsters)

 

Benefits:

Other than plonking down energy crystal seams on the radar, there's no simple way as a map creator for you to indicate where the resources are and aren't - and also no way for you as a player to determine where crystals are and where you concentrate your mining efforts.

Additionally, there's nothing worse than opening up that cavern in Air Raiders and seeing erosion come your way.

 

Examples:

This could also be used to indicate where large quantities of monsters would emerge could be by placing monsters in a cavern. When you enter that cavern, a bunch of monsters come out.

 

 

 

 

 

 

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. 

 

 

 

Share this post


Link to post
Share on other sites
Slimy Slug

A few more ideas

 

Description:

Custom monster information notifications (very low priority I would think)

 

Benefits:

Allows for creating custom monster notifications for things such as Jessietail's Seam Monster.  

 

Examples:

As is, there are info notifications hardcoded for the ice, lava, and rock monster.  There is also a generic notification (literally Info_GenericMonster), but this does not allow for custom bmps for each monster type.  Allowing the user to specify a monster at the end of a property such as Info_CreatureSEAMMONSTER would allow someone to add a green-eyed bmp in so the notif matches the monster's.  An added bonus is the possibility of spider and scorpion notifs if this is done this way.

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Description:

Custom building/vehicle/raider damage from monsters on a monster by monster and upgrade level by upgrade level basis.

 

Benefits:

Allows for certain buildings/vehicles/raiders to be weaker or stronger to attacks from varying monsters, much like how the boulders operate in the WeaponTypes {} section of the cfg.

 

 

Examples:

In theory I could set up the Rock Monster to deal 20 damage to the tool store on level 0 of its upgrade, then only 15 on level 1, then 10 on level 2.  I could also set the Ice Monster to deliver 50 damage to the Tool Store on level 0, 35 on level 1, and 20 on level 2 as an example.  Furthermore the Lava Monster could inflict 30 damage onto an unupgraded Raider, and so forth and so on.  Same for vehicles. 

Implementation I am not sure on here though.  A multiplier of some sort could work but then again this smells of WeaponTypes {} shenanigans and may be best suited in a format like the boulder.

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Description:

Fix the ridiculous multiplier used by the RockFallIn {} section within WeaponTypes {} in the cfg.

 

Benefits:

Allows for more precise damage values being applied to objects.

 

 

Examples:

Currently the values specified in the RockFallIn {} section use some strange multiplier value.  In other words, using a value of 1.0 will result in a unit sustaining 52 damage.  Further testing showed the value was slightly lower than 52 but higher than 51.8.  Why DDI used this number is the main question but if it doesn't have any ill effects then this should be changed to 50 at least.   

NOTE: I may try poking around with this one since if it's a static value it shouldn't be too hard to find.

 

 

That's all I got for now as far as new ideas go.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • 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.