Malte Langkabel
f5001d9ea1
The unlock dialog drew each previewed recipe with every output group its config lists. Filtering those against the current unlock state would have been worse than not filtering: these recipes are previewed precisely because the award changes what they may yield, so the current state would have emptied the very lines the preview exists to show. So the preview stops being a recipe-id diff and becomes a usability diff. A recipe is usable when the player may run it, may place the building that runs it, and it has a group it could be handed; the option carries the difference between usable-now and usable-after, per recipe, down to which groups. The dialog then draws what it was handed instead of re-deriving eligibility against a state that is not the one being previewed. Two consequences fall out of the finer diff, both wanted: Unlocking a building is now a gain in its own right. A recipe unlocked long ago but useless for want of a plant belongs to the award that finally makes it usable, not to the one that unlocked it. A recipe that gains a group is a gain a list of names cannot express -- a plant that starts yielding voidsteel is the game's headline unlock. Those get their own list under "Upgrades recipes:", because a recipe the player already runs, listed as newly unlocked, reads as a bug. Each line is drawn whole, groups the player already had included; the caption carries the difference. toOutputGroups' unfiltered form has no callers left and is gone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x