Changing module concept

[Engimage]

TL;DR

1. Add cap to speed modules to prevent snowball stacking
2. Improve Productivity module design to make it work clearly + added cap to prevent snowballs
3. Removed downsides from all modules
4. Split pollution from energy consumption for balancing purposes



After some discussion on modules in this thread I understood that this system in its current state may not be clear or optimal.
So I decided to take some time and think on a decent concept that may be much more clear.

PROBLEMS THAT I SEE

1. Currently modules effect pollution only through indirect means. The effect on pollution should be more clear.
2. All recipes have same pollution and energy consumption
3. Speed modules have too strong downsides
4. Productivity modules just make things out of thin air.
5. No cap on crafting speed and productivity lead to rediculous snowballs with multiple beacons.

MY IDEAS ON HOW TO FIX

Many parameters should become the part of recipe as opposed to assembler (or other unit). Its obvious that some processes require more energy and others result in much pollution or both. These parameters may be displayed "per production cycle" and "per second" so it could be clear that increasing production speed will increase both energy consumption and pollution.

In the current state Speed modules increase energy consumption more than they increase speed. Generally this might be useful when you are really limited with resource nodes (such as Oil) and in most other cases building just another building is more effective than using speed modules. And now the main usage of them is stacking tons of beacons around depleted nodes which is pretty rediculous.
I would propose only to increase production speed (up to a cap of 100% which should clearly be required) and it should be clear that power consumption per cycle (as well as pollution) stays the same (or gets a bit lower due to this module actually optimizing stuff to increase speed) and power per second increases. You should be able to see this paramaters change in the unit interface right as you insert those modules.
Most reasonable values in this case would be 25% increase for level 1 modules, 35% at level 2 and 50% at level 3 so if would take 4 level 1 modules to reach the cap, 3 level 2s and 2 level 3 modules.
With this change Speed modules can really make more use as you get your compactness without extra downsides. And having a cap will help mitigating abuse of overlaping beacons.


About current "Productivity module" concept. Currently this idea makes things come "out of thin air" with no clear way of how it is done.
I propose the following idea of how to handle and explain it.
We can add "wasted resources" part to a recipe. Below I will give the idea in an example on transport belts. However I will add some inflation on numbers to make this work more viable.

Transport belt
2x Iron Plate
2x Iron Gear
Wasted resources
2x Iron Plate
2x Iron Gear
Here we can see that there is a part of a recipe that goes to waste due to initially sub-optimal crafting process. And without optimizations this recipe will consume a total amount of 4 Iron Plates and 4 Gears.

Fast Transport Belt
1x Transport Belt
5x Iron Gear
Wasted Resources
5x Iron Gear

Obviously there are some parts (like Transport Belt in Fast belt recipe) that can't be optimized as you do upgrade 1 unit to a better version and obviously nothing can be wasted here. And obviously there can be recipes which can't waste anything using any optimization process is totally not viable there.

So now it makes more sense to add an Effeciency Module which will decrease the amount of wasted resources by up to 50% per module (at level 3)so it makes no sense going for more than 2 modules anyways.
The reasonable values for modules are 25% at level 1, 35% at level 2 and 50% at level 3. This will require 4 level 1 modules for the full effect, 3 level 2 modules or 2 level 3 modules.

I do not see why this process should require any type of a downside like increased energy consumption. However if you would consider one then decreasing production speed is a thing to consider. As more thorough process will most likely require more time. Also I did name this modules Efficiency not by mistake. Actually using materials in more efficient way preventing waste is actually called effeciency related to production.

You can also use this kind of modules with the buildings that consume fuel for decreased fuel consumption. It this case you can say that say 40% fuel is initially wasted and you can decrease the waste resulting in lower fuel consumption.

Yet again, having a clear explanation and cap will lead to predictable results as well as clarity around the matter.


Now coming to current Efficiency module concept. It is nice to have a module which will decrease energy consumption and pollution as there are no other modules allowing it. The only thing to consider are values per level and the name of the module. It can surely stay the same (if previous remain productivity) or go as Eco modules or whatever.
Values per level can go as: 20% for level 1, 30% for level 2 and 40% for level 3 so that the cap (80%) is reached by 4 level 1 modules, 3 level 2 or 2 level 3 modules just like with other modules.

I would like to point out that in this scenario all 3 types of modules do effect their own stats and do not interfere with each other leading to a some kind of energy and pollution snowball effect like it was with speed + production modules in its current state.

WHAT WE GET
1. Prevented insane snowballing with beackons like speed in Pumpjacks.
2. Made Green modules level 3 actually useful
3. The configuration with assemblers with 4 modules + 1 beacon resulting in 6 effective modules reaches all paramaters cap making beacons really effective in many configurations
4. Made balancing easier by splitting pollution from energy consumption
5. Made balancing easier by moving parameters to a recipe from the building
6. Opened possibility to use ex-productivity Efficiency modules in buildings with fuel consumption for decreased fuel usage (no current use but may be useful in future)
7. Made modules have much clearer usage.

[ssilk]

Sorry, speaking as moderartor that want to help you with thus suggestion I need to say, this is a wall of text.
To improve it you can you provide
- a TL;DR
- what you want to change (I couldn't read it simply out of the text - make it short, users don't want to read numbers)
- and especially why you want to change it.

[Engimage]

Fixed a bit. Hope that is more structured and readable. However TL;DR makes no sense here.

[mattj256]

What is your suggestion here?
One or two sentences please.
If you took that much time to write that post this must be important to you, and I'm not understanding what you're trying to communicate.

[Engimage]

What is your suggestion here?
One or two sentences please.
If you took that much time to write that post this must be important to you, and I'm not understanding what you're trying to communicate.

Added TL;DR section to the post

TL;DR

1. Add cap to speed modules to prevent snowball stacking
2. Improve Productivity module design to make it work clearly + added cap to prevent snowballs
3. Removed downsides from all modules
4. Split pollution from energy consumption for balancing purposes

[ssilk]

Now it can be understood. Moved the TL;DR to the top.

I think those changes are too big to built it in into vanilla, cause nobody can oversee the implications to the game-play.

I think it should be made as mod first, but this is currently also not possible (not for all). But I think most things could be tested as mod first or the devs can add more modding for modules, that makes this possible.

[mattj256]

Thanks PacifyerGrey. Now I have a better understanding of what you want.

For what it's worth I think modules are fine as they are now.
I like the snowballing and I like the negative effects.
If anyone else thinks the module system should be changed please chime in...