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