Factorio Forums

As proposed in a different thread (viewtopic.php?p=560573#p560573), I would like to have to possibility to remove the randomness of probabilities for fractional outputs.
For example:
Seablock has a recipe, which takes 200 fluid input and outputs 2x0.55 product1 and 1x0.7 product2
If you let this recipe run 100 times, you usually don't end up with exactly 110 p1 and 70 p1 of each product, but sometimes significant difference like 118p1 and 65p2 or 100p1 and 76p2.
If you'd run it 1000 or 10000 times, it gets closer to that desired ratio, but in seablock the first cycles matters most in overall progression.


You could scale up that recipe to the lowest common denominator:
input 2000 -> output 11 p1 and 7 p2 (if i'm not mistaken)
this is very different, because you end up waiting 10 regular cycles to get the products all at once.

or you take a approximation, with slightly different ratio. f.e.:
input 560 -> 3.08p1 and 1.96p2 simplified to
input 560 -> 3 p1 and 2 p2
this could be done, but its just a different ratio.

This is not very satisfying and it's at least a real life example, and I imagine there would be other use cases.
RNG can be nice component, but it can be disturbing, if you are forced to use it. I'm not a big fan of randomness in factorio.

My proposal is the following:
The recipe virtually outputs the given fractions of each product each cycle, which is getting summed up.
Once it reaches 1 or higher, it outputs it:

50% would mean, that it outputs 1 every 2 cycles.
1: 0.5
2: 0.5 + 0.5 = 0 + 1 (yield)
3: 0 + 0.5 = 0.5
4: 0.5 + 0.5 = 0 + 1 (yield)
etc.

70% would mean, that it outputs as soon, as it reaches at least 1 and the remainder is taken over:
1: 0.7 = 0.7
2: 0.7 + 0.7 = 0.4 + 1 (yield)
3: 0.4 + 0.7 = 0.1 + 1 (yield)
4: 0.1 + 0.7 = 0.8
5: 0.8 + 0.7 = 0.5 + 1 (yield)
6: 0.5 + 0.7 = 0.2 + 1 (yield)
etc.

160%
1: 1.6 = 0.6 + 1 (yield)
2: 0.6 + 1.6 = 0.2 + 2 (yield)
3: 0.2 + 1.6 = 0.8 + 1 (yield)
etc.

EDIT:
In order to reduce memory consumption and also increase usefulness I would propose, that the fractions of each recipe are shared with all machines executing this recipe. This also would help to don't loose cycles, if you change the machine's recipe.

jodokus31 wrote: Fri Jan 28, 2022 1:15 pm In order to reduce memory consumption and also increase usefulness I would propose, that the fractions of each recipe are shared with all machines executing this recipe. This also would help to don't loose cycles, if you change the machine's recipe.

Doing this on the global level would eg. for the 50% case inevitably lead to the situation that half the assemblers would output on every cycle and half would never output if there's an even number of (active, ie. not blocked due to missing ingredients or output full) assemblers because in a steady state situation the assemblers would always finish their individual recipe cycles in the same order and thus it's always the same assemblers that would fall on the outputting "slots". With 25% and the number of assemblers divisible by four one quarter would always output and three quarters never. In your example with 0.7 if the number of assemblers is divisible by ten then 70% would always output and 30% never. You get the picture, for every fraction there's always an assembler count where they would fall into such a lock-step situation (to be precise it happens when product fraction times assembler count results in an integer).

blahfasel2000 wrote: Sat Mar 05, 2022 10:29 am

jodokus31 wrote: Fri Jan 28, 2022 1:15 pm In order to reduce memory consumption and also increase usefulness I would propose, that the fractions of each recipe are shared with all machines executing this recipe. This also would help to don't loose cycles, if you change the machine's recipe.

Doing this on the global level would eg. for the 50% case inevitably lead to the situation that half the assemblers would output on every cycle and half would never output if there's an even number of (active, ie. not blocked due to missing ingredients or output full) assemblers because in a steady state situation the assemblers would always finish their individual recipe cycles in the same order and thus it's always the same assemblers that would fall on the outputting "slots". With 25% and the number of assemblers divisible by four one quarter would always output and three quarters never. In your example with 0.7 if the number of assemblers is divisible by ten then 70% would always output and 30% never. You get the picture, for every fraction there's always an assembler count where they would fall into such a lock-step situation (to be precise it happens when product fraction times assembler count results in an integer).

I see. Hmm...need to contemplate on this.

EDIT:
I think, you would have to save the fraction per machine then (which eliminates my memory saving approach).
But when an assembler is removed, the fraction should be passed on to an other assembler (or saved until a new assembler gets activated)

But when an assembler is removed, the fraction should be passed on to an other assembler (or saved until a new assembler gets activated)

You lose productivity bonus (and I think normal assembly progress) already when you change recipe. It's kind of silly to think a factory has a partially made item go in an invisible warehouse until production is resumed with no losses. We already have an unrealistic level of input efficiency.

robot256 wrote: Sat Mar 05, 2022 12:54 pm

But when an assembler is removed, the fraction should be passed on to an other assembler (or saved until a new assembler gets activated)

You lose productivity bonus (and I think normal assembly progress) already when you change recipe. It's kind of silly to think a factory has a partially made item go in an invisible warehouse until production is resumed with no losses. We already have an unrealistic level of input efficiency.

I have those garden recipes from angels in mind, which work for 300 seconds and produce with 5% probability. So you would need to run full 20 cycles to get an output and must not disturb it ever.
But ok, it's nice to have. (The current mechanism with random outputs could still be used for those type recipes.)