## FNEI

by npo6ka

FNEI mod. All recipes for items and usage for them.

1 year, 1 month ago
0.15 - 1.1
862320

## bProbability no longer displayed correctly 2 years ago

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. 2 years ago

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 2 years ago

@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(?) 2 years ago

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. 2 years ago

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

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. 2 years ago

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. 2 years ago

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. 2 years ago

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. 2 years ago
(updated 2 years ago)

@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