A setting on recipes to only output 1 item.

[JamesFire]

I have several recipes that are intended to only output 1 item from the list of possible outputs. Currently, I have the outputs as % chances, which adds up to 100. On average, it will only output 1 item per cycle, but I'd like to be able to make it actually only output 1 per cycle.

More specifically, in this mod, I have implemented a "binning" process for electronic chip production. This process is supposed to be just checking the chips for their capability, so it should only take 1 chip in, and put one chip out. And, on average, it will do that, but having something more sure and specific would be nice.

[jodokus31]

I would also like to have a recipe, which outputs a secured fraction, not a chance

f.e:

50% would mean, that it outputs 1 every 2 cycles.

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 = 1.4 = 0.4 + 1 (yield)
3: 0.4 + 0.7 = 1.1 = 0.1 + 1 (yield)
4: 0.1 + 0.7 = 0.8
5: 0.8 + 0.7 = 1.5 = 0.5 + 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.

[curiosity]

I would also like to have a recipe, which outputs a secured fraction, not a chance

f.e:

50% would mean, that it outputs 1 every 2 cycles.

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 = 1.4 = 0.4 + 1 (yield)
3: 0.4 + 0.7 = 1.1 = 0.1 + 1 (yield)
4: 0.1 + 0.7 = 0.8
5: 0.8 + 0.7 = 1.5 = 0.5 + 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.

This seems like offtopic.

[jodokus31]

This seems like offtopic.

Both proposal are related, because they both want a more reliable mechanism for fractions of items instead of the quite random probability/chance mechanism.

The first proposal is a special case, that all fractions are add up to 100% with predictable yield (covered by my proposal) and that you want alternating results (not covered by my proposal).

The alternating results could be realized, that each different product starts later with adding up. (I'll draw an example later...)

[SoShootMe]

More specifically, in this mod, I have implemented a "binning" process for electronic chip production. This process is supposed to be just checking the chips for their capability, so it should only take 1 chip in, and put one chip out. And, on average, it will do that, but having something more sure and specific would be nice.

Your requirements seem to match those of Uranium processing, except with more than two possible results. So I think everything ought to be fine provided the probabilities add up to 1...

Both proposal are related, because they both want a more reliable mechanism for fractions of items instead of the quite random probability/chance mechanism.

I can see why you think that but as I read it, the relevant part is ensuring it is always "take 1 chip in, and put one chip out". Not related to "fractions of items". Perhaps the OP could clarify.

[curiosity]

Both proposal are related, because they both want a more reliable mechanism for fractions of items instead of the quite random probability/chance mechanism.

The first proposal is a special case, that all fractions are add up to 100% with predictable yield (covered by my proposal) and that you want alternating results (not covered by my proposal).

The alternating results could be realized, that each different product starts later with adding up. (I'll draw an example later...)

As has been pointed out above, the proposal is for a random choice result, not at all related to what you propose. Speaking of which, it is easily done by just scaling up the recipe. The same may not always be possible (although in OP's particular case it seems to be) for the cases where you want a choice (see, for example, arcosphere recipes from Space Exploration).

[jodokus31]

Both proposal are related, because they both want a more reliable mechanism for fractions of items instead of the quite random probability/chance mechanism.

The first proposal is a special case, that all fractions are add up to 100% with predictable yield (covered by my proposal) and that you want alternating results (not covered by my proposal).

The alternating results could be realized, that each different product starts later with adding up. (I'll draw an example later...)

As has been pointed out above, the proposal is for a random choice result, not at all related to what you propose. Speaking of which, it is easily done by just scaling up the recipe. The same may not always be possible (although in OP's particular case it seems to be) for the cases where you want a choice (see, for example, arcosphere recipes from Space Exploration).

Ah, OP WANTS the random result, but just one at max. Got it. That's what I didn't get.

My proposal can be done by scaling up the recipe, but it's not the same. f.e.: Seablock has a recipe, which outputs 2x 0.55 and 1x0.7. If you try to scale that, you have a lot in/output for each cycle to get full numbers. That's not desired. But if you keep the probabilities, you end up having much or little for each components based on randomness.
But, I guess I have to put it separately.

[curiosity]

Your requirements seem to match those of Uranium processing, except with more than two possible results. So I think everything ought to be fine provided the probabilities add up to 1...

BTW, fun fact: you can get both U-235 and U-238 at the same time from the uranium processing recipe.

[SoShootMe]

Your requirements seem to match those of Uranium processing, except with more than two possible results. So I think everything ought to be fine provided the probabilities add up to 1...

BTW, fun fact: you can get both U-235 and U-238 at the same time from the uranium processing recipe.

Yeah... after a little experimentation I see the problem and take back my statement above. But I think it is more than a modding interface request, it needs an extra layer (say "result sets") with the probabilities attached to them instead of the results.

[JamesFire]

Your requirements seem to match those of Uranium processing, except with more than two possible results. So I think everything ought to be fine provided the probabilities add up to 1...

BTW, fun fact: you can get both U-235 and U-238 at the same time from the uranium processing recipe.

Yeah... after a little experimentation I see the problem and take back my statement above. But I think it is more than a modding interface request, it needs an extra layer (say "result sets") with the probabilities attached to them instead of the results.

Yes, that would work nicely.

[Silari]

I feel like ideally we'd be able to set a ProductPrototype in a recipe's results property to a new type like 'group' (instead of 'item' or 'fluid' ) which then has a table of ItemProductPrototypes with the probability property required. A check on startup can ensure the sum of probabilities is equal to 1 (or possibly allow less than 1 for the remainder to be considered no resulting item).

Doing it that way would mean it wouldn't break any existing recipes and is pretty similar to how several other prototype properties are done.

Would need a way in the recipe tool tip, item tool tip (if it has rocket_launch_products using a group), and any CraftingMachine GUI to show the group.

[curiosity]

A check on startup can ensure the sum of probabilities is equal to 1 (or possibly allow less than 1 for the remainder to be considered no resulting item).

A problem that can be conveniently avoided by bypassing the concept of probability altogether in favor of distribution weight, especially considering how fickle floating-point fractions can be.

[SWeini]

+1 for better control over probability-based recipes

If you create systems containing closed loops on these probabilistic items, that need to be primed, the current situation is really bad and you need large buffers. The fact is, if you run a coin toss simulation for infinite time, you will reach an infinite large difference between head and tail, in both directions. Similarly, if you run those closed loop systems for long enough time, they will stop because of unbalanced random results.

To illustrate this issue let's assume a system with following imaginary recipes:
- mousetrap + cheese => 50% mousetrap with trapped mouse + 50% mousetrap (the mouse escaped)
- mousetrap with trapped mouse => mousetrap + dead mouse

In theory you could provide 10 mousetraps and the system can catch mice forever. But because the first recipe can return nothing there is a chance that there are no more mousetraps at some time. It can also happen that the system breaks because there are too many mousetraps. You can provide a steel chest half full of mousetraps to mitigate the issue (let's hope they are not too expensive), but if you let it run long enough it will still stop at some point.

This issue restricts mod authors in designing their recipe chains.

One possible way to define this without breaking existing functionality is this:

ItemProductType.probability can be either a double, working as before or a table containing ranges for a random roll.

Code: Select all

recipe.results = {
  { type = "item", name = "item1", probability = { from = 0.0, to = 0.5  } },
  { type = "item", name = "item2", probability = { from = 0.5, to = 0.6  } },
  { type = "fluid", name = "fluid3", probability = { from = 0.6, to = 1.0  } }
}

This would result in 50% item1, 10% item2 and 40% fluid3, with always exactly one of those results. Nothing needs to add up to exactly 1. It's up to the mod author to define exactly what would happen on that shared random number.

Every product using the double probability uses a separate random number, while every product using the table probability uses a single shared random number.

[ChefOfRamen]

Bumping to add my +1 to this. I've been playing Ultracube, and it's really weird how you can sometimes get 6 speed modules from only 5 casings.

Especially since I'm pretty sure this is already done with quality.