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
Malte Langkabel
d2b1363f6d