Factorio Forums

TL;DR

I think productivity modules = overpowered and should be rebalanced with a heavier speed penalty.

What ?

This is from something Fel said on the Steam forums. We're talking about using 4 Productivity 3 modules in a rocket silo vs. replacing one with a Speed 3.

The module effects are additive (together) so the small increase in speed can't cover the big decrease in productivity if you swap like that.

You go from 10.4 speed and 40% productivity to 11.05 speed and 30% productivity.
The amount of cycles required goes from 71.42857.. to 76.92307.. (so you consume a bit over 5 more cycles worth of items) and the time required for that goes from 20.604 to 20.884.

By swapping a productivity 3 fro a speed 3 you slightly increase the time it takes (nearly unnoticeable but still) and you need to spend more items.

The only thing that is winning with that is the power consumption but you wouldn't use that many modules if power was an issue anyway.

And from my reply:

That seems like a balancing flaw -- Productivity modules slow you down overall, so just taking one out and not putting anything in its place seems like it *should* increase the output-per-minute by a little (and the input-per-minute by a lot). Then adding the Speed mod should further increase both by the same %.

The only thing that is winning with that is the power consumption but you wouldn't use that many modules if power was an issue anyway.

Since you're using more inputs it would actually increase your overall power consumption by a LOT, so there's really no advantage at all to doing that.

What I would like to suggest is that the Productivity Module's speed penalty should be increased. 3 P + 1 S should be significantly faster than 4 P (otherwise why is it even called a "Speed Module" if using it is slower???)

Why ?

Well, because good balance is important. Factorio has a lot of different ways of doing the same thing, and each one should have its pros and cons. There shouldn't just be one "best" way of doing something. Yet when you ask just about any veteran player, the one thing they all agree on is "Put productivity modules in ALL THE THINGS!!!"

I don't agree (about the use nothing but productivity thing).

- Why even compare modules against each other? To me they're complimentary, unless you want to be single-minded.
- Why do none of these kinds of discussions factor in beacons?
- To trivialize power consumption, even when it's easy to access, discounts several other play-styles/objectives that at least I for one like to play.

*mentions example with 20 beacons with speed module 3s*

*complains that only productivity modules are ever used*

Yoyobuae wrote: ↑Mon Aug 10, 2020 9:05 pm *mentions example with 20 beacons with speed module 3s*

*complains that only productivity modules are ever used*

Haha, funny, but that's not really what I'm saying. What I'm saying is that it doesn't make sense that removing a (speed-reducing) productivity module and replacing it with a (speed-increasing) speed module shouldn't result in slower rocket production (even if there are 20 speed beacons in play).

jchardin64 wrote: ↑Mon Aug 10, 2020 9:37 pm

Yoyobuae wrote: ↑Mon Aug 10, 2020 9:05 pm *mentions example with 20 beacons with speed module 3s*

*complains that only productivity modules are ever used*

Haha, funny, but that's not really what I'm saying. What I'm saying is that it doesn't make sense that removing a (speed-reducing) productivity module and replacing it with a (speed-increasing) speed module shouldn't result in slower rocket production (even if there are 20 speed beacons in play).

Yeah, but you can't really easily alter that without fundamentally altering the mechanics. As long as the speed penalties and bonuses are additive and productivity modules give you extra outputs, it's going to work out that way.

My own preferred option would be for productivity modules to have no speed penalty whatsoever but to refund inputs instead of of outputs.

That would at a stroke align speed and productivity modules squarely into their niches: If you want more production from a given machine, you use speed, and if you want more production from a given amount of resources, you'd use productivity. And by blowing up the synergistic coupling between prod & speed you also increase the room for efficiency modules to operate in.

foamy wrote: ↑Mon Aug 10, 2020 11:39 pm Yeah, but you can't really easily alter that without fundamentally altering the mechanics. As long as the speed penalties and bonuses are additive and productivity modules give you extra outputs, it's going to work out that way.

Actually if the speed penalty from P. Modules was bumped back up to 20% (like it was early on) or even 17-18% it would correct the issue. A rocket silo is the only thing big enough to be covered by 20 beacons, so this is a unique case. As the math in my OP shows, the speed is *almost* the same, so just increasing the penalty a little would be enough.

foamy wrote: ↑Mon Aug 10, 2020 11:39 pm
My own preferred option would be for productivity modules to have no speed penalty whatsoever but to refund inputs instead of of outputs.

That would at a stroke align speed and productivity modules squarely into their niches: If you want more production from a given machine, you use speed, and if you want more production from a given amount of resources, you'd use productivity. And by blowing up the synergistic coupling between prod & speed you also increase the room for efficiency modules to operate in.

That's an interesting idea. Using P. Mods would then require some system for filtering out and recycling the extra inputs, right? (I'm assuming they are "produced" by the machine along with the product)

jchardin64 wrote: ↑Mon Aug 10, 2020 9:37 pm

Yoyobuae wrote: ↑Mon Aug 10, 2020 9:05 pm *mentions example with 20 beacons with speed module 3s*

*complains that only productivity modules are ever used*

Haha, funny, but that's not really what I'm saying. What I'm saying is that it doesn't make sense that removing a (speed-reducing) productivity module and replacing it with a (speed-increasing) speed module shouldn't result in slower rocket production (even if there are 20 speed beacons in play).

Productivity synergizes well with speed modules. The setup already has the equivalent of 20 speed modules. It seems logical that adding a 21st speed module is not better than having a fourth productivity module.

Yoyobuae wrote: ↑Tue Aug 11, 2020 12:07 amIt seems logical that adding a 21st speed module is not better than having a fourth productivity module.

I guess this is where we disagree. What seems logical to me is that if I want more speed, I should use a speed module. I use a productivity module if I want to make more stuff with fewer components, but it reduces the speed (of the output). That's what both modules say on the box... until you get into a beaconed rocket silo, when suddenly it becomes backwards day.

jchardin64 wrote: ↑Mon Aug 10, 2020 11:51 pm

foamy wrote: ↑Mon Aug 10, 2020 11:39 pm Yeah, but you can't really easily alter that without fundamentally altering the mechanics. As long as the speed penalties and bonuses are additive and productivity modules give you extra outputs, it's going to work out that way.

Actually if the speed penalty from P. Modules was bumped back up to 20% (like it was early on) or even 17-18% it would correct the issue. A rocket silo is the only thing big enough to be covered by 20 beacons, so this is a unique case. As the math in my OP shows, the speed is *almost* the same, so just increasing the penalty a little would be enough.

The problem is this: The productivity bonus applies multiplicatively with the crafting speed. You're correct that in the 4/0 case it doesn't require much to make 3/1 superior, but what about the 3/1 -> 2/2? All the same arguments would apply. Or 2/2 -> 0/4? All you're doing is adjusting the break-even point, not the underlying cause of the problem.

That's an interesting idea. Using P. Mods would then require some system for filtering out and recycling the extra inputs, right? (I'm assuming they are "produced" by the machine along with the product)

Maybe. I'd be more inclined to simply add the items to the assembler/whatever's input slots, though. Keeps things simple, and distinguishes p. mods from catalytic recipes.

foamy wrote: ↑Tue Aug 11, 2020 1:17 am

That's an interesting idea. Using P. Mods would then require some system for filtering out and recycling the extra inputs, right? (I'm assuming they are "produced" by the machine along with the product)

Maybe. I'd be more inclined to simply add the items to the assembler/whatever's input slots, though. Keeps things simple, and distinguishes p. mods from catalytic recipes.

What (if any) would be the speed penalty? (Also energy/pollution?)

Would it look something like this:
Base recipe:
200 iron -> 100 gears in 50 seconds
4 current P3's:
200 iron -> 140 gears in 80 seconds
4 foamy P3's:
120 iron (200 - 2 * 40) -> 100 gears in (?) seconds

This is effectively the same as 166.67% productivity instead of 140%. Seems a bit too much, but maybe you were thinking of reducing the %. Other than that it seems equivalent to the current system. "More output from the same input" and "The same output from less input" are effectively the same, just looked at from the other side of the equation.

That said, I do thematically like the idea of "it doesn't use as much" better than "it sometimes magically produces an extra one".

jchardin64 wrote: ↑Tue Aug 11, 2020 3:16 am

foamy wrote: ↑Tue Aug 11, 2020 1:17 am

That's an interesting idea. Using P. Mods would then require some system for filtering out and recycling the extra inputs, right? (I'm assuming they are "produced" by the machine along with the product)

Maybe. I'd be more inclined to simply add the items to the assembler/whatever's input slots, though. Keeps things simple, and distinguishes p. mods from catalytic recipes.

What (if any) would be the speed penalty? (Also energy/pollution?)

Would it look something like this:
Base recipe:
200 iron -> 100 gears in 50 seconds
4 current P3's:
200 iron -> 140 gears in 80 seconds
4 foamy P3's:
120 iron (200 - 2 * 40) -> 100 gears in (?) seconds

This is effectively the same as 166.67% productivity instead of 140%. Seems a bit too much, but maybe you were thinking of reducing the %. Other than that it seems equivalent to the current system. "More output from the same input" and "The same output from less input" are effectively the same, just looked at from the other side of the equation.

That said, I do thematically like the idea of "it doesn't use as much" better than "it sometimes magically produces an extra one".

I'd have no speed penalty at all. The speed penalty is a hack to try and bring some kind of balance to the module system, and in this conception I don't think it's necessary.

If you can't supply enough raw materials, yeah, it would act as a production increase, but that's basically the desired result in any case -- you get more out of the same amount. But the distinction is that, assuming you have the materials, to increase production you need either more machines or more speed beacons.

So, for example, say we're working with gears. Two belts of iron in, 1.4 belts of gears out in either scenario. But: To get those 1.4 belts, with the current productivity setup, you need 22.5 crafting speed (aggregated among the assemblers). To get it with my proposed change, you'd need 40% more -- 31.5. So you'd need 40% more assemblers to do the same throughput. Removing the speed penalty would significantly improve non-beaconed uses of productivity modules, as well.

foamy wrote: ↑Tue Aug 11, 2020 4:08 am So, for example, say we're working with gears. Two belts of iron in, 1.4 belts of gears out in either scenario. But: To get those 1.4 belts, with the current productivity setup, you need 22.5 crafting speed (aggregated among the assemblers). To get it with my proposed change, you'd need 40% more -- 31.5. So you'd need 40% more assemblers to do the same throughput. Removing the speed penalty would significantly improve non-beaconed uses of productivity modules, as well.

This is effectively the same as what I'm proposing, just looked at differently. You still have the 1:1.4 ratio of items in:out, you've just "slowed it down" differently (by removing the bonus output and making it use fewer inputs, instead of having a speed penalty). But overall you've done the same thing as I'm proposing, requiring more machines or speed beacons to get the same throughput.

jchardin64 wrote: ↑Tue Aug 11, 2020 4:58 pm

foamy wrote: ↑Tue Aug 11, 2020 4:08 am So, for example, say we're working with gears. Two belts of iron in, 1.4 belts of gears out in either scenario. But: To get those 1.4 belts, with the current productivity setup, you need 22.5 crafting speed (aggregated among the assemblers). To get it with my proposed change, you'd need 40% more -- 31.5. So you'd need 40% more assemblers to do the same throughput. Removing the speed penalty would significantly improve non-beaconed uses of productivity modules, as well.

This is effectively the same as what I'm proposing, just looked at differently. You still have the 1:1.4 ratio of items in:out, you've just "slowed it down" differently (by removing the bonus output and making it use fewer inputs, instead of having a speed penalty). But overall you've done the same thing as I'm proposing, requiring more machines or speed beacons to get the same throughput.

Well.... again, not quite. Mechanically the problem with just increasing the speed penalty is that you still get the synergistic effects. In fact you make adding beacons and speed modules even more necessary to make prod modules worthwhile. And while you don't get the absolute increase on silos going from 3/1 to 4/0 any more, you still have the same issue with 0/4 -> 2/2 or similar, and the effectiveness of your fix varies with the number of speed beacons you can surround a machine with.

Whereas killing the output bonus, removing the speed penalty, and refunding inputs will work uniformly on everything and guarantee that if you want more production from a given set of machines (assuming sufficient inputs) you always need to use speed modules. And if you want more production total (again, assuming sufficient inputs), you need more machines. It kills the emergent synergy and clearly deliniates the roles modules play.

foamy wrote: ↑Tue Aug 11, 2020 5:48 pm Well.... again, not quite. Mechanically the problem with just increasing the speed penalty is that you still get the synergistic effects. In fact you make adding beacons and speed modules even more necessary to make prod modules worthwhile. And while you don't get the absolute increase on silos going from 3/1 to 4/0 any more, you still have the same issue with 0/4 -> 2/2 or similar, and the effectiveness of your fix varies with the number of speed beacons you can surround a machine with.

Whereas killing the output bonus, removing the speed penalty, and refunding inputs will work uniformly on everything and guarantee that if you want more production from a given set of machines (assuming sufficient inputs) you always need to use speed modules. And if you want more production total (again, assuming sufficient inputs), you need more machines. It kills the emergent synergy and clearly deliniates the roles modules play.

Ah, I see what you mean now. I agree, this is a good way to handle it.

I think this is an imaginary problem.

jchardin64 wrote: ↑Tue Aug 11, 2020 6:00 pm

foamy wrote: ↑Tue Aug 11, 2020 5:48 pm Well.... again, not quite. Mechanically the problem with just increasing the speed penalty is that you still get the synergistic effects. In fact you make adding beacons and speed modules even more necessary to make prod modules worthwhile. And while you don't get the absolute increase on silos going from 3/1 to 4/0 any more, you still have the same issue with 0/4 -> 2/2 or similar, and the effectiveness of your fix varies with the number of speed beacons you can surround a machine with.

Whereas killing the output bonus, removing the speed penalty, and refunding inputs will work uniformly on everything and guarantee that if you want more production from a given set of machines (assuming sufficient inputs) you always need to use speed modules. And if you want more production total (again, assuming sufficient inputs), you need more machines. It kills the emergent synergy and clearly deliniates the roles modules play.

Ah, I see what you mean now. I agree, this is a good way to handle it.

I think that it’s too late to change. The devs aren’t (I hope) going to kill everyone’s blueprints with 1.0

AmericanPatriot wrote: ↑Thu Aug 13, 2020 12:31 am
I think that it’s too late to change. The devs aren’t (I hope) going to kill everyone’s blueprints with 1.0

I don't see a reason why it would kill BP's. Machines with blueprinted modules in them would still have those modules, they would just operate a bit differently when turned on (getting refunded inputs instead of extra outputs).

Unless you're talking about changing the ratios those BP's were based on... but they haven't worried too much about things like that in the past. (referring to oil processing changes, the blue science recipe, etc.)

jchardin64 wrote: ↑Thu Aug 13, 2020 1:26 am

AmericanPatriot wrote: ↑Thu Aug 13, 2020 12:31 am
I think that it’s too late to change. The devs aren’t (I hope) going to kill everyone’s blueprints with 1.0

I don't see a reason why it would kill BP's. Machines with blueprinted modules in them would still have those modules, they would just operate a bit differently when turned on (getting refunded inputs instead of extra outputs).

Unless you're talking about changing the ratios those BP's were based on... but they haven't worried too much about things like that in the past. (referring to oil processing changes, the blue science recipe, etc.)

many moduled ratios/number of machines needed/rates would get messed up.

AmericanPatriot wrote: ↑Thu Aug 13, 2020 2:01 am
many moduled ratios/number of machines needed/rates would get messed up.

Well, that's... kind of the point of making a change? I'm sorry that people would have to redesign BP's for maximum efficiency, but like I said they've made recipe changes requiring BP redesigns in just about every update in the past.