RecipePrototype, add ProductPrototype functionality to IngredientPrototype

[AutoChaos]

TL;DR

Make the Ingredients prototype come with:
probability - Chance of item consumption directly
consumption_on_craft - How many will get consumed on probability triggering.

Not crucial, but will allow for more interesting recipes.
spoilage_on_craft - How much the items will spoil on craft.

What?

I suggest adding internal functionality to make true catalysts and make these recipes allow more complicated functionality than usual Ring Around the Rosie.
For example, we can make some item so that it can "spoil" while being used as a catalyst. Or can get consumed before spoiling, or more.

For example, currently Space Exploration has recipies that use Cation or Ion exchange beads. Those are supposed to work as catalysts and currently use the ProductPrototype probability to drop. They also ignore productivity because it could be duplicated like this.
Then we have an extra step of taking out the same bead, placing it on the belt, and putting it back into the machine.
The same exact thing happens with all other recipes that have a sort of catalyst used in them.

Example image of current recipes. Space-Exploration/k2 biomass

01-10-2026, 23-11-33.png (1.07 MiB) Viewed 91 times

Suggesting currently. No return chances, just directly chance of consumption in the machine input slot.

01-10-2026, 23-19-18.png (178.12 KiB) Viewed 91 times

Why?

Cleaner production of the recipes, fewer ring-around-the-roses recipes that could have just been a true catalyst.
With extended functionality could also work to add realistic catalysts that can go bad/get used, then require a specific process to return them. Now, even if you have such a system its working based on the chances of outputing specific item, rather than being a catalyst.
Imagine you want a specific recipe that can use a specific catalyst 10 times before it spoils. Currently its impossible unless you x10 your recipe and add the catalyst with the output of spoiled catalyst.

The spoilage mechanic can be ignored if it's impossible to implement with the current game logic. Actually, if the item spoils in the input slot, you will have to get it out like normal. So there isnt even a need to make it to be spat out or anything.

[boskid]

Sorry but this is not going to happen due to ill-formed interface request, there are not even any example use cases provided that would allow refining this request.

What would "probabiliy" mean? If a probability roll would fail, would that mean the ingredient is not consumed? That would require extra handling for cases when recipe is changed and ingredients are refunded to avoid cases where ingredient would be returned when it was not consumed.

What would "percent_spoiled" mean? If an item is more spoiled than provided value it would not be accepted? Or would it cause spoilage of ingredient to be assumed to be decreased by that amount when computing average spoilage for products?

What would "reset_freshess_on_craft" mean? This flag is defined for cases when item is produced, not when it is consumed, that makes absolutely no sense.

What is "main_ingredient" and what would be its impact on the recipe handling?

Why do you need "is_catalyst"? This is currently doable by means of ignored_by_stats in ingredient, and ignored_by_stats+ignored_by_productivity pair on the product side.

[AutoChaos]

Probability - of consumption of the ingredient.
percent_spoiled - item below X spoilage not accepted.
main_ingredient - kinda makes no sense now I think about it. Game doesnt care about what to consume.

Even adding % consumption to the ingredient will already be enough for most. The rest will allow for more extensive management of the catalyst.

[boskid]

percent_spoiled - item below X spoilage not accepted.

If an item is inserted into ingredient inventory and then time progresses, based on that rule it would become not acceptable while being in the ingredient inventory. That would require some piece of logic to detect incorrect ingredient and move it to the trash slots. If this was required to happen as soon as item goes below specified freshness value, then we would have to rewrite the entire spoiling mechanic because right now we do not keep track of freshness values themselves - they can be queried but this is a value deduced from current game tick, computed spoil tick stored on the item and spoil duration from the prototype. Having this checked by the assembler would mean the assembler would be unable to sleep because it would have to be checking freshness of ingredients every tick wasting ups, and if it would be allowed to only happen when assembler looks at the ingredients inventory then we will get bug reports due to assembling machine througput being slow because removal of the item exactly when ingredients were checked would mean now assembler must stop due to lack of proper ingredients and input inserters will only start working to grab new items that will be available some amount of ticks later. Given the complexity of this suggestion combined with lack of use cases i think this becomes a wont implement.

[AutoChaos]

I have reworked the idea a bit. Is it feasible now?

At least the basic %consumption chance idea it started from.
Let's just say, I didn't expect a reply at all. So my first draft of the idea was not that great.