Malte Langkabel
3c63205c6c
Deterministic recipes could have several outputs produced together; a probabilistic one could have several outputs of which exactly one happened. Two shapes meant two rules everywhere -- sizing a buffer, deciding whether a cycle fits, resolving what a cycle makes -- each written as a branch on whether the building was a reprocessing plant. New REQ-MAT-OUTPUT-GROUP merges them. A recipe has one or more output groups, each with a weight and a list of items; a cycle produces exactly one group, and the items within it together. One group is the ordinary recipe and is always chosen, so the old deterministic and probabilistic cases are the same shape with one group and with several -- and every rule downstream is written over groups, needing no branch at all. Config keeps outputs = [...] as the single-group form, so only the two reprocessing recipes change shape. It also lets an outcome yield several items, which was unrepresentable, and fixes a display bug on the way: the recipe summary drew all outputs as one combined yield, so a plant read as if a cycle made all four items. Groups are now separated by "/" and the items within one by "+". REQ-LOCK-REPROCESSING-POOL now restricts the choice between groups rather than the pool of output items, and says why that distinction is load-bearing: implicit unlocking is demand-derived, so an ordinary recipe's output can be producible while nothing yet calls for it. Testing eligibility there would not gate a drop, it would stop the building producing at all -- so a recipe with one group, having no choice to restrict, is never tested. A group is eligible only if all of its items are unlocked, since they are produced together. Requirements only; the implementation follows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x