Factorio Forums

I realize the probability calculation is currently implemented intentionally this way and that there is no effective effect on outcome for the vanilla uranium mining recipe since the probabilities are so uneven. However, I think there is a strong case to be made that the current calculation leads to unwanted outcomes for mod authors that are trying to leverage this feature in recipes using higher percentages, as the overlap means that inputs are effectively created or destroyed. It also means that any circuit network calculations that relies on traceable calculations from inputs to outputs cannot be implemented.

For example, I am trying to create a mod that incorporates a scrap/recycling mechanism for complex products, like robots or engines. The new probability recipes seem perfect for this - in theory, I can create a recipe that will create a broken part 10% of the time (and have research to unlock a more efficient recipe). I can then have a recycling path that can try to rework the broken part into a working part or to recycle it for materials. However, when I try to create a production area for these recipes that tries to use the circuit network to control the delivery of inputs and map it to scrap and outputs, it isn't possible to get it working because the independent nature of the probability calculations make it a common occurrence for a single recipe cycle to produce either both a real item and scrap item or to produce nothing. Although this is fine at a macro level, since the effect on overall production will average out over time, at a micro level using circuit networks, the numbers of inputs to outputs almost never line up at any given time. In other words, out of input resources for 10 items, it is quite likely to find that I've produced 10 working items and 1 scrap item or 8 working items and 1 scrap item. The numbers simply do not add up.

This effect is more pronounced as the probability of producing items is increased. It's not noticeable at the vanilla level for uranium mining - no one is going to notice the 0.6951% chance (actual number) of not producing U-235 or U-238 for a recipe cycle. But, it is very noticeable when the probabilities are higher (5%, 10%, 50%) and makes it impossible to do any circuit network calculations that expect recipe inputs and outputs to sum to a consistent value.

It could be possible to keep the current behavior as an opt-in by adding a flag to the recipe, but I think the common expectation is that a recipe will choose a single outcome from among its possible outcomes when the probabilities sum to 1 and that producing nothing should only be a possibility when the probabilities sum to less than 1.

Given the above, I respectfully submit that the current implementation - to treat recipe probabilities as independent events rather than dependent events (i.e., only one can occur for any given recipe cycle) - is a design and implementation bug.

Fishling wrote: Given the above, I respectfully submit that the current implementation - to treat recipe probabilities as independent events rather than dependent events (i.e., only one can occur for any given recipe cycle) - is a design and implementation bug.

Unfortunately its not a bug, so i will move this to ideas and suggestions

For modding purposes it would make sense to have access to both independent and dependent product probabilities. I can imagine uses for both.
Surely the latter is easy to code though. n=rand(1:1000), IF n</= 7, THEN give u-235, ELSE give U-238.

This gives me ideas, breaking down say a robot you might want a cascade effect.

So the robot is made of 2 items so there's a 50:50 choice over which is broken to get into the object then if the circuit board is the broken one the flying robot frame has an 80% chance of being intact 20% broken. and vice versa if the robot frame is broken then the circuit board has a 80% chance of being intact 20% broken (since the robot frame is a more solid unit it might be harder to accidentally break but as you're recycling I'm assuming you have to break something to get the components out)

This could internally cascade so without having broken parts you have to further process. It would just continue to recylce until all components are accounted for and either returned, broken into more components or lost entirely. So the robot might have then a broken frame, a robot frame is made from 4 components, given it's broken 1 of them must have broken, 25% each to work out which one was lost entirely, and then give the remaining 3 an even split for breaking the rest apart, the remaining 2 out of the 4 each get a 90% survival chance 10% broken chance. Rather only breaking 1 component (not totally losing 1) and 20% chance of losing the remaining when breaking an intact item, and internally that continues until it hits raw materials some being intact in the same way as components might survive and some getting broken or completely lost (iron or steel plates (and broken they could be iron sticks), wire (lost when broken) or copper (broken into wire), plastic (lost when broken))

Which then uses the same mechanic but repeated as turning ore into Uranium because each time with the process you should always get 1 output but there's a choice about each one with the 99.3%:0.7% breakdown rather than the simplified 50:50 80:20 and 90:10 ratios I've used above.

Aye, I would like to have some ore that has a recipe like this.
My expected (aka desired) result would be that it always outputs an iron plate and either 1 or 2 copper plates into a special furnace that has result_inventory_size=2.

But, what I am experiencing is that slot 1 gets 1 iron plate, slot 2 sometimes gets 1 and slot 3 (I put that in there to verify), sometimes get 2, but sometimes I only get 1 iron plate....sometimes all 3 slots get an updated value.

Also, this points out that result outputs aren't grouped by type, but rather by recipe slot. I think that should be changed too...

hmm, just figured out that what I should be using is amount_min and amount_max...but that only works for an equal % chance of the values

this wouldn't work with amount_min/max