Malte Langkabel
7d0f3e6daf
Six things the player reported, five of them about where things sit and what is listed: - HP goes to the top of the runtime group, above everything else a card shows. Only the HQ had it elsewhere; the ship and station cards already led with it. - A construction site's progress moves out of the runtime group's place and directly under the header, so how far along the site is reads before what it is configured to become. - The production bar moves between the input and output buffers, so a producing building reads in the direction its materials flow: what goes in, what is being made of it, what has come out. BufferSection held both buffer sections and so could not be split around it; the two sections and the production section are now the card's own, in that order. - Locked items are left out of the buffers. An auto-recipe building's buffers are sized over every recipe of its type, so a Smelter carried an input for quartz -- which the player cannot mine yet -- and an output for the silicon it would smelt into. Both are dropped now, as everywhere else that hides what is not unlocked. - An idle auto-recipe building lists what it handles rather than nothing. It has no selected recipe to name, so a Reprocessing Plant between cycles showed no output buffer at all. Its sections now list the unlocked items of every recipe of its type -- the union its buffers were sized over -- without a per-cycle denominator, since no one recipe is in force. The sixth was the bars vanishing whenever the window lost focus, to a modal dialog or to another application. They were filled with the palette's current highlight, and the palette follows the window's focus: the inactive group's highlight sits close enough to the card's background to read as gone. They ask for the active group by name now. Measured on a freshly built Smelter, which is the case that showed three of these at once: INPUT BUFFERS 0 Copper Ore | 0 Iron Ore | 0 Scrap PRODUCTION idle OUTPUT BUFFER 0/2 Copper Ingot | 0/2 Iron Ingot Quartz and silicon filtered out, production between the buffers, and an idle building still saying what it handles. Requirements updated for the ordering, the locked-item rule and the idle auto-recipe listing (REQ-UI-SELECTION-CARD, REQ-UI-SINGLE-SELECTION, REQ-UI-PRODUCTION-PROGRESS, REQ-UI-HQ-PANEL). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
86 lines
3.4 KiB
C++
86 lines
3.4 KiB
C++
#pragma once
|
|
|
|
#include <map>
|
|
#include <string>
|
|
#include <vector>
|
|
|
|
#include "BuildingId.h"
|
|
#include "ItemChipRow.h"
|
|
#include "SelectionContent.h"
|
|
|
|
struct Building;
|
|
struct BuildingTarget;
|
|
class ProductionSection;
|
|
class RecipeSummaryRow;
|
|
class SectionBox;
|
|
|
|
// Shared body of the four cards that show one building with buffers -- the Miner and
|
|
// Assembler, the Smelter and Reprocessing Plant, the Shipyard, and the Salvage Bay
|
|
// (REQ-UI-SELECTION-CONTENT). All four show the same header status, recipe summary,
|
|
// buffer contents and production progress; they differ only in what one production cycle
|
|
// costs and how long it takes, which is what the subclass supplies.
|
|
//
|
|
// This is implementation sharing, not a catalog entry: every concrete subclass is one
|
|
// row of the content catalog.
|
|
class BufferedBuildingContent : public SelectionContent
|
|
{
|
|
Q_OBJECT
|
|
|
|
protected:
|
|
// What one production cycle of this building consumes, produces, and takes.
|
|
struct CycleInfo
|
|
{
|
|
std::map<std::string, int> perCycleInputs;
|
|
std::map<std::string, int> perCycleOutputs;
|
|
|
|
// Items the card lists whether or not they are currently in the buffers, for a
|
|
// building whose recipe is implicit and so has nothing to name while it sits
|
|
// between cycles (REQ-BLD-SMELTER, REQ-BLD-REPROCESSING). They carry no
|
|
// per-cycle denominator, since no one recipe is in force.
|
|
std::vector<std::string> handledInputs;
|
|
std::vector<std::string> handledOutputs;
|
|
|
|
// False when the building produces nothing at all (the Salvage Bay,
|
|
// REQ-BLD-SALVAGE-BAY) or has no recipe or schematic selected yet: the
|
|
// production section is then not shown (REQ-UI-PRODUCTION-PROGRESS).
|
|
bool runsProduction = false;
|
|
// 0 while an auto-recipe building sits between cycles, when no single recipe
|
|
// names a cycle time; the progress line then reads "idle".
|
|
double durationSeconds = 0.0;
|
|
};
|
|
|
|
BufferedBuildingContent(const SelectionContext& context, BuildingId id,
|
|
QWidget* parent);
|
|
|
|
// Called with a construction site's stored configuration too, so the summary of what
|
|
// the building will produce is shown before it is built (REQ-BLD-SITE-CONFIG).
|
|
virtual CycleInfo getCycleInfo(const BuildingTarget& target) const = 0;
|
|
|
|
// The subclass's own configuration controls. The identity, the recipe summary, the
|
|
// buffers and the production progress are handled here.
|
|
virtual void refreshControls(const BuildingTarget& /*target*/) {}
|
|
|
|
BuildingId getBuildingId() const { return m_id; }
|
|
|
|
private:
|
|
void refreshConfiguration() override;
|
|
void refreshRuntime() override;
|
|
|
|
std::vector<ItemChipRow::Entry> buildInputEntries(const Building& building,
|
|
const CycleInfo& cycle) const;
|
|
std::vector<ItemChipRow::Entry> buildOutputEntries(const Building& building,
|
|
const CycleInfo& cycle) const;
|
|
|
|
BuildingId m_id;
|
|
|
|
RecipeSummaryRow* m_recipeSummary;
|
|
|
|
// Input buffers, production progress, output buffer -- in that order, so the card
|
|
// reads the way the materials flow (REQ-UI-SINGLE-SELECTION).
|
|
SectionBox* m_inputSection;
|
|
ItemChipRow* m_inputChips;
|
|
ProductionSection* m_production;
|
|
SectionBox* m_outputSection;
|
|
ItemChipRow* m_outputChips;
|
|
};
|