If you view a recipe with probability on the outputs, it does not show this at all

I'm not sure if this is a bug introduced into the game .. or a game change that means you have to change the mod somehow. But the mod works properly in 0.17.45 and does not work in 17.46 thru 17.50.

Just to add to this, there was a small change to how recipe prototypes are handles by the game, and the way to calculate probabilities changed a bit. It affected pretty much any mod that does this (Helmod, What is it really used for?, FNEI, etc). I wrote up a small gist that explains how you should calculate the actual amount that a recipe produces for every product here: https://gist.github.com/ClaudeMetz/df2b085814d4de51425938e8ee55eb82

@Therenas
You state that this is needed:
1. local produced_amount = nil
2. if product.amount_max ~= nil and product.amount_min ~= nil then
3. produced_amount = ((product.amount_max + product.amount_min) / 2) * product.probability
4. elseif product.probability ~= nil then
5. produced_amount = product.amount * product.probability
6. else
7. produced_amount = product.amount
8. end

If product.probability equals nil, then line 3 fails and you have a bug(?)

Pretty sure that if you have a max and min amount, you also need to have a probability. I use this algo in my mod for a week or so, and haven't run into any problem.

Why not just add the extra check so you don't have to wonder whether this will ever break?

Well, if my assumption becomes wrong in a future update, the calculations would be incorrect anyway, so I'd rather it crash the game, so I can fix it. But you're free to add it in your own implementation.

Why? If you do the test then when product.probability equals nil you would have the produced_amount = product.amount. Which is correct in all cases.
Anyway, do what you want. I'm just used to developing important/critical C++ software where this kind of loose end is not allowed.

It is not correct. When min and max amounts are set, you can't just ignore those. You might want to take the approach that you rather have it be wrong than have it crash, but I don't for this kind of non-critical type of code.

Yes, you are correct. That is another thing where this code would break.
Really, no matter how important it is you should always handle all situations. Normally for something like this I would create a table to determine which flow decisions I need to make to have all paths both handled and correct.

Anyway, thanks for your contributions.

@Sander_Bouwhuis , not sure this situation is really worth a table detailing flow-cases... ;)

local produced_amount = nil, safe_probability = product.probability
if safe_probability == nil then safe_probability = 1 end
if product.amount_max ~= nil and product.amount_min ~= nil then
produced_amount = ((product.amount_max + product.amount_min) / 2) * safe_probability
else
produced_amount = product.amount * safe_probability
end

... or even:

local produced_amount = product.amount, safe_probability = product.probability
if safe_probability == nil then safe_probability = 1 end
if product.amount_max ~= nil and product.amount_min ~= nil then
produced_amount = (product.amount_max + product.amount_min) / 2
end
produced_amount = produced_amount * safe_probability