Crafting Time Variance

[darrel04]

TL;DR

Crafting time variance

What ?

I'd like there to be a slider in the game settings to create and change the variance in crafting time for items so that crafting time will be a range rather than a defined duration. For example, if I set the crafting variance to 10%, the time taken to craft a splitter would vary between .9 to 1.1 seconds. I'd like this to affect everything, including drills, furnaces, automation machines etc.

Why ?

It would add another dynamic to the game, forcing players to take into account having some inventory to account for preceding items in the assembly line producing at slower or faster rates at times.

I got this idea from reading about real manufacturing plants and how variance causes issues and what they've done to resolve it. I thought it would be interesting to see for myself how much of an issue it is by simulating it here, but there was no mod available for this. Looking into it more, it appears that even the API does not allow for a mod to be made for this.

[MakeItGraphic]

https://mods.factorio.com/mod/zKenirasRandomRecipes

[darrel04]

https://mods.factorio.com/mod/zKenirasRandomRecipes

This isn't quite what I'm looking for. This randomizes the recipes and craft times for the entire duration of the play.

I'd like for each individual item being crafted to pull from a range each time an item is crafted. To build on my example of the splitter with a 10% crafting variance, the crafting time could be anywhere from .9 to 1.1 seconds every craft. The first time may be 9.5 seconds, the second time may be 1.3 seconds, the third...

This will force having inventory in certain locations where it previously wasn't needed. One example of this is having copper wire directly insert into green circuits. Since the crafting time is slightly unpredictable, you would need to have some sort of buffer between the two to accommodate this, else constrain green circuit production to the slowest variation of copper wire production.

[valneq]

I'd like there to be a slider in the game settings to create and change the variance in crafting time for items so that crafting time will be a range rather than a defined duration. For example, if I set the crafting variance to 10%, the time taken to craft a splitter would vary between .9 to 1.1 seconds. I'd like this to affect everything, including drills, furnaces, automation machines etc.

And this random crafting time should follow which distribution? Gamma, Normal, Uniform? This can make a big difference …

[eradicator]

I'd like there to be a slider in the game settings to create and change the variance in crafting time for items so that crafting time will be a range rather than a defined duration. For example, if I set the crafting variance to 10%, the time taken to craft a splitter would vary between .9 to 1.1 seconds. I'd like this to affect everything, including drills, furnaces, automation machines etc.

And this random crafting time should follow which distribution? Gamma, Normal, Uniform? This can make a big difference …

The engine won't ever support this, so there is no difference :p.

[capsizedpirate]

Maybe not for every single action, but there could be some static distribution of modifiers and then the entity would be assigned one on creation.
I would be happy if each machine had a distinct efficiency characteristic and this was static throughout the lifetime of the entity.

Lol you'd have to bin your machines for your production line.

it would be easy enough to do a cycles based randomization if they loosened the restrictions on recipes in the API.
Or you could instantiate a new recipe on the fly in Lua based on the machines active recipe, mod it with an adjusted energy_required using pseudo random function of choice, and then update the machine to use the runtime recipe.

I would love to see deprecation implemented....

[Deadlock989]

* rocks back and forth in corner of shower *

[Ranakastrasz]

Honestly, this wouldn't really even do anything. The law of large numbers smooths out those variences, and if factorio has anything, it has large numbers of craft events.

Past that, the existing buffers would largely hide the effect. It wouldn't even be asthetic. Belts, inserter stack size, and assembler inventory size. At best it would cause mild irregularities when you start up a new line, or cause overflows/belt balance issues, but nothing of consequence would happen.

[capsizedpirate]

That might be true late to end game when you're already scaled to the point where resource inefficiencies are irrelevant at the micro scale; especially if you've already had the foresight (or at least good practices) to build in balances and buffers to compensate.

But I think during early to mid game this would really help drive home the necessity to avoid taking on unjustified technical debt as it would especially punish those snakey-boi solutions we all love lol plus if there were some element of lifecycle mgmt involved in order to stop the weight of the factory's loss from toppling your economy this could just serve as a potential cost function for it.

IDK how masochistic the OP is but clearly my suffering is not enough....

[eradicator]

[...]especially if you've already had the foresight (or at least good practices) to build in balances and buffers
[...]it would especially punish those snakey-boi solutions

Belts are buffers. Spaghetti factories have lots of belts. So the opposite of that would happen.

[capsizedpirate]

Belts are buffers. Spaghetti factories have lots of belts. So the opposite of that would happen.

But that's under the assumption that their performance characteristics are static; could be compounding over time leading to disparities between upper tier recipe input availability.
Just because your machine has a higher crafting speed, it's still only receiving materials at the same linear rate from the belt so this isn't a direct cancellation of reduced crafting speed which will always impact the output; especially in sparse belts with high resource density ingredients.

When you're playing on death world or in a sea block type of scenario, conversion efficiency is king when you're min-maxing these lines because you don't have the space to just put down extra belts or mine an extra patch of resources.
Obviously in peaceful mode where there are no production/time constraints this wouldn't have much value add....

Probably why OP wanted an optional toggle for it, i just want it to not be read only so I can update it at runtime every n cycles or something.

[eradicator]

When you're playing on death world or in a sea block type of scenario

IDK how masochistic the OP is but clearly my suffering is not enough....

If you just want someone to punch you into the face you can get the same effect by giving every recipe a chance to fail completely. Which is actually something that the engine can do right now. I.e. copper wires recipe with half cost but only 50% chance to produce.

[capsizedpirate]

If you just want someone to punch you into the face you can get the same effect by giving every recipe a chance to fail completely. Which is actually something that the engine can do right now. I.e. copper wires recipe with half cost but only 50% chance to produce.

Please tell me more... my face is ready.

But if there was a failed recipe, then I would expect some sort of waste management of the unsuccessful attempt and then there'd have to be the necessary deviation tracking...
If the machines were just crawling I could pretend this wasn't happening

[eradicator]

Half/Half doesn't work out statistically after i thinking about it. But - and this works best on recipies with a short crafting time - you could change a recipe that produces 100% of the output 100% of the time into a recipe that produces 0%~200% each cycle (or 50%~150%, or 75%~125% or whatever). Thus generating a statistical variance in crafting time without requiring new engine features. Sure you can get unlucky, but i'm talking about "things the engine can actually do" vs "things the engine will never be able to do" here.

[capsizedpirate]

Half/Half doesn't work out statistically after i thinking about it.

Agreed, I was running some simulations in excel using the logistic curve and you can clamp the distribution and use a bias (ie. [-0.1+bias, 0.1+bias]) to steer the effect in a positive/negative way.
After 20 iterations, even with a very small bias (.01), you can see pretty decent impact on throughput rates

you could change a recipe that produces 100% of the output 100% of the time into a recipe that produces 0%~200% each cycle (or 50%~150%, or 75%~125% or whatever).

What this doesn't impact is power consumed, since it would still pull a full recipe's worth of power.
From my understanding consumption is static with two states rates (active, idle) and I would have to model if this would be a negligible difference being on longer per recipe vs firing blanks in a distribution (analog vs PWM).

but i'm talking about "things the engine can actually do" vs "things the engine will never be able to do" here.

If I understood how beacons operate better, it almost seems like the functionality is already there in the backend for beacons.
If you had a large number of custom speed modules incrementally defined to emulate the distribution and then assigned a custom beacon with a 1x1 range to each machine with a randomly chosen module applying the speed effect.

[eradicator]

but i'm talking about "things the engine can actually do" vs "things the engine will never be able to do" here.

If I understood how beacons operate better, it almost seems like the functionality is already there in the backend for beacons.
If you had a large number of custom speed modules incrementally defined to emulate the distribution and then assigned a custom beacon with a 1x1 range to each machine with a randomly chosen module applying the speed effect.

A static (negative) speed bonus per-assembler is possible of course but would imho just force the player to micro-optimize. I.e. rebuild the assembler several times until they get a good "dice roll" with permanent bonus speed. You could use the assembler position as a random seed to make that more difficult, but there'd still effecively be good and bad "spots" to build things. Regularly swapping the modules in the hidden beacon to completely prevent this would ofc be possible but a) is intransparent to the player who just sees that a belt is randomly compressed or not without knowing why and b) have a somewhat high cpu cost.