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
67 lines
2.4 KiB
C++
67 lines
2.4 KiB
C++
#pragma once
|
|
|
|
#include <string>
|
|
#include <vector>
|
|
|
|
// The kind of a single granted schematic within an unlock option.
|
|
enum class SchematicType
|
|
{
|
|
Ship,
|
|
Module,
|
|
Building,
|
|
Recipe
|
|
};
|
|
|
|
// One item granted by an unlock group (REQ-LOCK-EXPLICIT), shown in the
|
|
// schematic choice dialog's granted-items list.
|
|
struct GrantedSchematic
|
|
{
|
|
SchematicType type;
|
|
std::string id;
|
|
std::string displayName;
|
|
};
|
|
|
|
// One recipe shown in an option's preview, together with the output groups the player
|
|
// would be able to get out of it afterwards -- indices into the recipe's own
|
|
// `outputGroups`, in config order (REQ-DEF-SCHEMATIC-DROP). The indices are what the
|
|
// preview draws: which groups a recipe can yield is decided here, against the unlock
|
|
// state as it would stand after the award, and not by the dialog against the current one.
|
|
struct PreviewedRecipe
|
|
{
|
|
std::string recipeId;
|
|
std::vector<int> outputGroupIndices;
|
|
};
|
|
|
|
// One option presented to the player in the schematic choice dialog
|
|
// (REQ-DEF-SCHEMATIC-DROP). Built by the simulation when enemy stations are
|
|
// destroyed; the UI reads these to populate the dialog. A non-artifact option
|
|
// represents one unlock group; selecting it awards the whole group.
|
|
struct SchematicChoiceOption
|
|
{
|
|
bool isArtifact = false;
|
|
|
|
// Unlock group id (empty for the artifact option).
|
|
std::string unlockGroupId;
|
|
|
|
// Display name shown as the option's title: the unlock group's derived name,
|
|
// or "Artifact" for the artifact option.
|
|
std::string displayName;
|
|
|
|
// The ships, modules, buildings, and assembler recipes this group grants
|
|
// (empty for the artifact option).
|
|
std::vector<GrantedSchematic> grantedItems;
|
|
|
|
// What this option would add to the player's production options
|
|
// (REQ-DEF-SCHEMATIC-DROP), each sorted alphabetically by display name. The unit is
|
|
// usability rather than unlocking: a recipe is of no use while the building that
|
|
// runs it cannot be placed, so unlocking that building is as much a gain as
|
|
// unlocking the recipe was.
|
|
//
|
|
// Recipes the player could not use at all before and could after.
|
|
std::vector<PreviewedRecipe> newlyUsableRecipes;
|
|
// Recipes they could already use that would gain at least one further output group
|
|
// -- a plant that starts yielding voidsteel is a real gain, and one a list of recipe
|
|
// names alone cannot express.
|
|
std::vector<PreviewedRecipe> upgradedRecipes;
|
|
};
|