Malte Langkabel
d2b1363f6d
isRecipeUnlocked only ever meant anything for miner and assembler recipes: the traversal inserted those two and nothing else. So every caller carried the same branch -- ask the unlock state for a miner or an assembler, ask something else otherwise -- in the blueprint gate, the selection dialog, and the item tooltip's producer list, three copies of one exception. Recipe unlocking moves out of the item traversal into a pass of its own, run once the item set has settled: a recipe is unlocked when it is not a gated assembler recipe still awaiting its group, and it has an output group it could actually yield. Smelter and reprocessing recipes are judged by that too, so the question is now meaningful for all of them and the three branches collapse to one call. The two conditions stay independent on purpose. Explicit gating is about permission and outlives a wanted output -- a drop-only recipe whose output is useful anyway stays locked until it is awarded. Reprocessing still takes no part in the item traversal (REQ-BLD-REPROCESSING): it is asked in the new pass whether it can yield anything, without its yields feeding what counts as unlocked. Judging a group whole rather than per item (REQ-LOCK-OUTPUT-POOL) is what keeps a group's locked companion item from letting the whole group through. Recorded replays from before this change will not reproduce: unlocked recipe ids feed the state checksum, and smelter and reprocessing ids now join them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x