Malte Langkabel
20789cb15c
An auto-recipe building adopted whatever recipe of its type consumed the material offered to it, without asking the unlock state. That was the last way a building could come to run a recipe the player could not have selected: the selection dialog hides those and the blueprint gate discards them, but a belt delivering the right material installed one regardless. Automatic selection now asks isRecipeUnlocked, the same question the dialog asks, plumbed in beside the isItemUnlocked the output pool already uses. Two callbacks, two questions, one unlock state -- rather than a second definition of "a recipe the player may run" written out inside the sim. A material whose only recipes are locked now selects nothing, and an unconfigured building has no input buffer, so that material is refused rather than swallowed: it stays on the belt and the line backs up behind an idle building. That is the intended failure -- a stalled belt is visible, a building quietly eating a material the player cannot use is not. Selection only. A recipe already set goes on producing under REQ-LOCK-OUTPUT-POOL, which deliberately never tests a single-group recipe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x