[0.15.10] Uranium processing ratio incorrect (100% U-238)

[malventano]

Understood that the ratio reporting has been updated to show 0.7% and 99% for U-238 and U-235, however, the 99% is currently incorrect. Whenever a centrifuge completes a cycle, it appears you *always* get a 238, and ~0.7% of the time, you *also* get a U-235. This means that U-238 is actually 100%. I do like the idea of getting a 238 *or* a U-235 on a given cycle, but that does not appear to currently be the case as implemented.

Recommend either shift the output to an actual ~0.7% toggle to a single unit of U-235 (no 238) or relabel the U-238 in the recipe as 100% (or better yet, simply '1').

[Arch666Angel]

The recipes always read as an "and", so the recipe is telling you that you have a 99% chance to get u-238 per run and a 0.7% chance to get a u-235 per run, they are completely independent from each other.
It would be cool to have a chance based "or" recipe but that would be a feature request, not a bug report

[malventano]

Huh, on the test runs I was doing I was getting the same number of 238 across all centrifuges, with none missing. Perhaps I didn't let it run long enough.

So you're telling me that some cycles yield no items at all? That seems almost as odd as the centrifuges spitting out two items for something that's written as a 0.7/99(.3) ratio.

[Rseding91]

There's a 99.3% chance you get 238 out and a 0.7% chance you get 235 back per recipe craft. You can look at the recipe definitions in the lua files if you like

[malventano]

There's a 99.3% chance you get 238 out and a 0.7% chance you get 235 back per recipe craft. You can look at the recipe definitions in the lua files if you like

Oh, I believe you for sure, and I witnessed it happen since I let the experiment run long enough to get a 'no yield' cycle.

It still seems wrong though. 10 uranium ore should always give you *something* after a cycle, wouldn't you think? Especially since both sides of the percentages total to 100%.

Here's an example to clarify my point:
Bob likes Nascar. Bob has a 1%/99% probability of turning right/left each time he reaches a fork in the road. As this 'chance' is currently implemented, sometimes Bob doesn't turn and drives straight through the wall, and sometimes he simultaneously turns both directions.

Simpler example:
A '50/50 chance' generally does not include neither or both answers simultaneously.

[Rseding91]

The way recipe products work each product is calculated separately so you could have 20 different items each with 99% chance to produce and get nothing. Now that's extremely unlikely but it could still happen.

[Arch666Angel]

Could we turn this into a feature request then for a probability based "or" ?

[malventano]

Could we turn this into a feature request then for a probability based "or" ?

From a standpoint of flexibility and consistency in gameplay items using this mechanic (where recipe percentages total to 100%), it really should be implemented as an 'or'. If the player wants to create a circuit network item that inserts 10 uranium ore and is triggered by the previous cycle completing, that can not currently be done consistently, as some cycles result in 0 items and some cycles result in two. As it is currently, it screws up any attempt at accounting/summing inputs and outputs, as many of those methods would use output count as a means of determining if the cycle has completed. An 'or' mechanic here would eliminate that problem while keeping the chance/probability identical.

[TruePikachu]

The way recipe products work each product is calculated separately so you could have 20 different items each with 99% chance to produce and get nothing. Now that's extremely unlikely but it could still happen.

So they don't act as weights, in other words? If I define a recipe with 0.5 and 0.5, then 25% of the time I'd get both products and 25% of the time neither?

[malventano]

The way recipe products work each product is calculated separately so you could have 20 different items each with 99% chance to produce and get nothing. Now that's extremely unlikely but it could still happen.

I was looking for the correct term and finally found it. The type of mechanic that would apply to something like uranium processing is actually a 'discrete probability distribution'. That is how you get one thing or the other thing some percent of the time, but never get zero or all things. That's really how this sort of thing should work.

[TruePikachu]

The way recipe products work each product is calculated separately so you could have 20 different items each with 99% chance to produce and get nothing. Now that's extremely unlikely but it could still happen.

I was looking for the correct term and finally found it. The type of mechanic that would apply to something like uranium processing is actually a 'discrete probability distribution'. That is how you get one thing or the other thing some percent of the time, but never get zero or all things. That's really how this sort of thing should work.

Strictly speaking, it should work how the devs intend it to work. In the grand scheme of things, the expected return from processing 10,000 uranium ore is 993 U-238 and 7 U-235; only in small sample sizes do doubled/nullified products play any sort of significant part. The current system does allow for some useful additional functionality, though; if one specifies that some recipe outputs a `foo` 100% of the time, and a `bar` 10% of the time, it means that you'll always get a `foo`, and sometimes also get a `bar`. With 0.14 functionality, this could only be implemented by multiplying the recipe cost by 10 (increasing the required investment to actually run the recipe), and going by the current definition of the prototypes' syntax, one wouldn't be able to define the recipe to either give a `foo` or a `foo`+`bar`, since the probabilities (currently) apply strictly to the output items, not combinations of output items.

[malventano]

only in small sample sizes do doubled/nullified products play any sort of significant part.

Yes, but if you are attempting to use the count of output items for anything, it won't necessarily be equal to 1/10th of the count of ore that was processed. If the probability ratio was meant to be a dice roll, then it should actually be a dice roll (and it should be since processing 10 ore should always net you *some* result). You can't get zero / multiple simultaneous results when you roll dice - you get *one* answer.

[undarl]

Yes, but if you are attempting to use the count of output items for anything, it won't necessarily be equal to 1/10th of the count of ore that was processed. If the probability ratio was meant to be a dice roll, then it should actually be a dice roll (and it should be since processing 10 ore should always net you *some* result). You can't get zero / multiple simultaneous results when you roll dice - you get *one* answer.

Depends on how many times you're rolling the dice.

I agree that the system you're arguing for -- take a set of probabilities that total 100%, make one roll, choose and return one output from the set -- has its uses, and that it would be a better fit for the uranium processing recipe as written.

However, I think there is also a place for the current multiple-roll system. I like having the ability to say "this recipe always returns one of item A, but it also has a 50% chance to return one of item B, and a separate 10% chance to return one of item C".