33 Commits

Author SHA1 Message Date
ade15c19d5 carry a tooltip along with the element it explains
Scrolling the world under an open tooltip left it stranded beside where
its button used to be. It now holds the place it was given in relation to
its element instead of the place it was given on the screen, so the
element takes it along -- out from under the pointer, and off the screen
if that is where the element goes, which is what then hides it.

Followed on a timer rather than on move events: a move event reaches only
the widget whose own position changed, never a label carried along by the
button around it, which is exactly the case here. The timer already ran
while a tooltip was up; it now ticks once a frame so the tooltip keeps up
with the ground it stands on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 23:08:23 +02:00
abe8c8f448 stand the expansion button on the ground it buys
The button leaves the header bar for the world, centered on the columns
the next purchase unlocks and panning with them until it leaves the view.
Those columns now take a lighter tint than the locked ground behind them,
so the boundary between the two says how far one purchase reaches.

Nothing in the code reported a scroll: the camera knew it had moved and
told only the hover. A ViewScrolledEvent says it now, which is what a
widget keeping a place in the world rather than on the screen needs. The
panels want none of it -- they are placed against the screen and stay put
as the world moves under them -- so the button is placed after their pass
and never joins the rectangles they step around.

Its face is two lines, "Expand" over the cost. That makes the cost a
display of its own, so it carries the building-block tooltip the way every
other item value does, on hover alone since the click buys the expansion.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 22:55:06 +02:00
8292bc6134 stand the expansion button on the ground it buys
The button leaves the header bar and floats over the world, centered on
the columns the next purchase unlocks. Being a place in the world rather
than on the screen, it pans away with those tiles; nothing needs to bring
it back, since the leftmost pan centers the buildable edge and the
columns lie just left of it.

Those columns now take a tint of their own, more transparent than the
locked ground behind them, so the boundary between the two says how far
one purchase reaches. The tinted area itself went undocumented until now,
and it has no left edge: expansions are unbounded, so the tint runs as far
left as the view can see, which is what made "the middle of the greyed
region" answerable only for the next expansion's slice.

The button's face becomes two lines, "Expand" over the cost. That makes
the cost a display of its own, so it carries the item tooltip the way
every other item value does instead of the whole button standing in for
it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 22:34:21 +02:00
b51a9c5c77 give the keyboard back when a modal closes
Hiding the layer takes the focus off whatever stood on it and leaves the
window with no focus widget at all, so the world view answered no keys
afterwards: Escape opened the menu once, closed it, and then did nothing.
Each modal now notes what held the keyboard when it opened and gives it
back on the way out -- the world view for the first of a stack, the modal
beneath for one above it, which was dead the same way.

The window's own focus guard now also catches the focus going nowhere,
rather than only landing on the wrong widget.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 22:11:04 +02:00
b7fe5cfcf2 put the caret in the name prompt's line edit
The layer asked the modal's focusWidget() what to focus, but hosting a
modal reparents it into a scroll area and a reparent clears the focus its
constructor set, so the answer was always nothing and the dialog itself
took the keyboard. Modals now name their initial focus widget outright,
which survives the hosting.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 22:05:28 +02:00
1ffacae2fb put the modal up in the same frame as the dim behind it
The layer was shown and painted before the modal it hosts was placed, so
opening one -- the layout dialog from the shipyard panel, say -- painted a
frame of bare dim over the world before the dialog appeared, which reads
as a black flash. The modal is now placed and shown while the layer is
still hidden, and showing the layer paints both at once.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 21:57:47 +02:00
44ec3c51f1 explain an item wherever the UI names one
Every display naming an item now shows that item's production tooltip, not
only the selection panel's chips: the header block stock, the total cost of
a building multi-selection, the remaining scrap of a debris selection, the
icons of every recipe summary, and a blueprint card's cost.

ItemTooltip moves out of the selection panel and takes an
ItemTooltipContext of its own -- an item is named all over the UI, and the
panel's context carries visuals and a debug flag no tooltip reads. A
recipe line wraps each icon with its amount so the pair can be pointed at
as one statement, and attaches tooltips only where asked: a module button
and the item tooltip itself draw the same line and stay silent.

Hover only wherever the display sits on something the player clicks, whose
click is not free to explain. Note that a recipe line on an option button
can no longer be transparent to the mouse -- Qt never looks inside a
transparent widget for the cursor -- so it relies on press propagation to
keep picking the option.

The header block stock loses world.building_blocks_tooltip, showing what
every other block icon shows instead. The Expand button keeps no tooltip:
its cost is painted into its face with nowhere to hang one, and the button
is due to be removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 21:41:34 +02:00
dcc801f017 explain an item wherever the UI names one
An item icon names an item, so the player can ask what it is wherever it
is drawn: a chip, a value stated as an amount plus a bare inline icon, or
an icon in a recipe summary. All three now show the item production
tooltip, with the amount beside the icon as part of the target.

An icon says nothing only where its display already carries a tooltip of
its own, since a display can only show one -- the build buttons, and the
module selection buttons, which are described controls whether or not a
given module fills its description in. On a clickable host the tooltip is
hover-only: the click belongs to the control.

The header bar's block stock loses its configured description in favour
of the production tooltip every other block icon shows, so
world.building_blocks_tooltip goes with REQ-UI-BLOCKS-TOOLTIP. It was the
only place stating what blocks are spent on, which no producer list says.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 17:26:23 +02:00
099d614395 show a tooltip on click, and keep it up until the pointer leaves
One tooltip mechanism for the whole UI: a Tooltip popup plus a
TooltipTrigger event filter, replacing every setToolTip call. Qt's own
tooltip cannot do what REQ-UI-TOOLTIP-TRIGGER and REQ-UI-TOOLTIP-DISMISS
ask for -- it times out, hides on the first mouse move, cannot be hovered
and cannot be brought up by a click.

A tooltip now appears the moment an element with no click action of its
own is clicked, and it is placed with its top-left corner on the pointer,
so the pointer can move onto the tooltip and hold it open. The pointer is
polled while a tooltip is up rather than tracked through enter and leave
events, whose order depends on which widget the pointer crosses first.

The item chip's children become transparent to the mouse. They were
taking the chip's enter and leave events, so its tooltip only ever
appeared when the pointer rested on the chip's padding.

The modal header's close button loses its "Close" tooltip: a close button
in a header says that by being one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 14:52:02 +02:00
1554d99739 show an icon's tooltip the moment it is clicked
An icon that displays a value and does nothing when clicked is free to use
the click for "tell me what this is", which beats waiting out the hover
delay and is the obvious thing to try. Buttons whose click already acts
keep hover only, so one gesture never both acts and explains.

Tooltips also stop timing out and become hoverable themselves, so a
tooltip listing several recipe lines can be read at any pace.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 14:05:23 +02:00
0e64f45a5e forward-declare GameConfig as the struct it is
Command.h announced it as a class while GameConfig.h defines a struct, which
MSVC reports as C4099 in every translation unit that sees both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 12:31:10 +02:00
fb65cbabf4 close a dialog when the player clicks beside it
REQ-UI-DIALOG-DISMISS asks that a dialog be put away by clicking away from
it, the gesture that already puts the selection panel away. The layer is
the widget those clicks land on, so this is where it belongs -- and the
three dialogs that take the gesture already say so through isDismissible(),
which Q has been using since the base class arrived.

A left press and a left release must both land beyond the open modal's
rectangle. Where the click landed is what decides, never that the layer
received it: a click on an inert part of a dialog -- a label, the gap
between two controls -- propagates up from the widget that ignored it and
arrives here with a position inside the modal, which is not a dismissal. A
drag begun inside the dialog never reaches the layer at all, the widget it
began on keeping the release, so no gesture ends by discarding the dialog it
was made in.

Every click on the layer is consumed either way, dismissing or not: the
window behind a modal takes no input, and closing the modal does not turn
that click into one for whatever lies under it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 12:16:57 +02:00
9b88deff69 give the escape menu and the name prompts the game's own frame
The last dialogs wearing system chrome were the three QMessageBoxes -- the
escape menu, the game-over and win screens -- and the two QInputDialogs that
name a blueprint. They are the ones the player meets at the sharpest moments
of a run, and they looked like alerts from the operating system.

MessageDialog and NameInputDialog replace them on the layer. The message
dialog names its buttons by the index addButton hands back and reports which
was clicked, with Escape standing for a button the caller nominates rather
than for a dismissal of its own -- Continue in the escape menu, as it was
explicitly set to before, and Quit on the two state screens, which is where
the reject role sent it. Neither dialog takes Q or a click outside: every
button is a decision, and a half-typed name is work in progress
(REQ-UI-DIALOG-DISMISS).

Two things the layer needed for the nested case: it now tracks the scroll
area each modal is shown in, so a modal opened with no anchor centers on the
one it was opened from rather than on the window -- which is where the
Create Blueprint prompt belongs (REQ-UI-PANEL-MODAL) -- and findFor() walks
a widget's parents to the layer, so the blueprint panel buried in the layout
dialog can open a modal without every widget in between carrying a pointer.

The three error boxes stay system dialogs on purpose: config load, config
reload, and blueprint file load all report a failure that may leave nothing
to draw on (REQ-UI-MODAL-CHROME).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 12:14:31 +02:00
f03003194f host the modals in the window instead of in windows of their own
Every dialog was an OS window with a dim widget behind it in the game
window. That is why a click beside one could not reach it: Qt drops mouse
events for a window a modal blocks, so the dim -- a child of the blocked
window -- never saw the press.

ModalLayer is that dim grown up: still a child of the main window covering
its rect, but it now hosts the open modal, places it, and runs its event
loop, so it is the widget the clicks beside a modal land on. It keeps a
stack, paints one dim however many modals are open, and a hold keeps it up
while one modal hands over to the next. ModalDimOverlay and ModalDimScope
are gone; ModalLayerHold replaces the scope at the sites that still open a
system message box.

ModalDialog is what a dialog inherits in place of the window it lost: the
panel background, the drawn header with its optional close button, and the
dismissal gestures. isDismissible() governs Q and, next, the click outside
-- one predicate because both gestures reach the same dialogs. Its default
refuses, so a dialog opts in. requestDismiss() is what a gesture asks for,
and ShipLayoutDialog overrides it with the one-step ladder its Q handler
used to spell out, which is now reached by both. DialogDismiss.h folded into
the base.

The four dialogs the player meets keep their contents unchanged and lose
their title bars: the recipe/schematic selection, blueprint selection, ship
layout, and schematic choice dialogs. Placement moved with them --
placeOnSelectionPanel became getSelectionPanelAnchor, and the layer centers
on that rectangle in window coordinates, with no global mapping and no
frame height to guess at.

Two things followed from dropping OS modality: the focus guard that hands
focus back to the game world now also asks the layer whether a modal is
open, and closeEvent refuses to close the window while one is, since its
nested loop runs over widgets the window owns.

The escape menu, the game-over and win screens, and the two name dialogs are
still system dialogs; they are dimmed by a layer hold until they are
converted next.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 12:07:25 +02:00
7327343b2a draw every modal the player meets while playing
The dialogs were OS windows with a dim widget behind them, which is why a
click beside one could not reach them: Qt drops mouse events for a window a
modal blocks, so the dim -- a child of the game window -- never sees the
press that REQ-UI-DIALOG-DISMISS now asks it to act on.

REQ-UI-MODAL-CHROME states the rule the fix follows: a modal is drawn by the
game on the dim, with no title bar, no window border, no window-manager
close, and no way for the player to move it, resize it, or drag it off the
window. Each draws its own header, as the blueprint selection dialog already
does; content too large for the window scrolls inside the modal instead of
hanging past the edge. The exception is failure reporting -- a config or
blueprint file that will not load is still a system message box, since it
must reach the player when there is nothing left to draw on.

The requirements that described the old chrome follow: the blueprint dialog
loses its window-manager close, the escape menu, game-over and win screens
and both name dialogs say they are drawn, and REQ-UI-MODAL-DIM says the dim
is the surface a modal sits on rather than a layer kept in step with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 11:54:54 +02:00
da3f417464 let a click outside a dialog dismiss it
A dialog was left by Q, Escape, or its own Cancel; a click beside it did
nothing, though that is exactly the gesture that already puts the selection
panel away. REQ-UI-DIALOG-DISMISS now covers both ways out, for the same
three dialogs and to the same effect, and the layout configuration dialog
backs out one step at a time under the click as it does under Q -- so a
mis-aimed click during module placement costs a re-click, not the session.

Three things the bare "clicks outside" left open are settled: the press and
the release must both land outside, so a drag begun in the dialog cannot end
by discarding it; the click is spent on the dismissal and does not reach what
it landed on; and the name-entry dialogs refuse it as they refuse Q, a
half-typed name being work in progress.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-18 09:29:02 +02:00
01aa1a08b0 stop the layout dialog opening for a shipyard with no schematic
Clearing a shipyard with "(None)" opened the layout configuration dialog on a
grid of no cells. The auto-open guard asked only whether the chosen id differs
from the current one, and the "(None)" option carries the empty id, which
differs from every schematic; ShipLayoutDialog then found no ship def and
derived a 0x0 grid. Predates this branch -- 698dd4d, 2026-07-13.

The question all three sites were answering by hand is now one:
findLayoutShipDef() returns the ship to configure a layout against, or nullptr
when no schematic is set, the id names no ship, or the ship defines no grid.
The auto-open path and the LayoutDialogRequestedEvent handler now ask it
before opening, and ShipyardContent asks it instead of spelling the same test
out for the preview and the Configure button.

The event handler was reachable only through a button ShipyardContent already
disables, so guarding it changes nothing today; it is guarded because the
dialog's precondition belongs to the dialog's entry, not to the widget that
happens to be the only caller.

REQ-MOD-UI-AUTO-DIALOG said "differs" and left clearing implicit, which is the
reading the code took. It now says clearing opens nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 22:50:14 +02:00
5968e5f40a dismiss a dialog with Q, and refuse to dismiss the drop dialog
Three dialogs take Q as a second way out beside Escape: the recipe/schematic
selection dialog and the blueprint selection dialog close outright, and the
layout configuration dialog steps out one level per press -- the module being
placed, then remove mode, then the session. Both of those mode exits now go
through the handler the Remove button uses, extracted from a lambda into
onRemoveButtonClicked(), so the key and the button cannot leave different
state behind.

The schematic choice dialog goes the other way and declines reject(). It had
no close button but Escape still closed it, and the caller then applied
choiceIndex 0 -- awarding whichever option happened to be first. Refusing
reject() covers Escape, Alt+F4, and the window manager together, since all
three funnel through it. It is also the only dialog whose dismissal would
strand state: the poll that opened it does not reopen it while the choices
stay pending, so a drop dismissed is a drop lost.

The key itself is spelled once in DialogDismiss.h rather than in three key
handlers. It stays out of the ControlAction table on purpose: that table
answers what an input does in the player's current situation, and a dialog
has none -- it holds focus and takes the key whatever the world is doing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 22:31:59 +02:00
1e24b87640 let Q dismiss a dialog, and stop the drop dialog being dismissed at all
Q backs the player out in the game world, so it backs them out of a dialog
too: the recipe/schematic selection dialog, the blueprint selection dialog,
and the layout configuration dialog, where it is Cancel. In that last one it
steps out one level at a time as it does in the world -- a selected module,
then remove mode, then the session -- so one press never both leaves a mode
and discards the changes.

The schematic choice dialog goes the other way: it is now stated to be
undismissable, which it was already built to be (no close button) but was not
written down. Escape currently closes it and the handler then applies the
default choiceIndex of 0, awarding the first option the player never picked;
saying no way out exists but choosing is what closes that.

Q stays an ordinary character in the two dialogs that take a typed name. The
Escape bullet named only the blueprint dialog and was narrower than what
Escape has always done, so it now covers dismissible dialogs generally.

Requirements only; no code yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 22:22:05 +02:00
b0fa0da813 clear the selection with Q, and drop it on entering a build mode
Implements the requirements committed in 731b887.

Q becomes a three-way branch in the action table, which is the layer that owns
what an input does: ExitMode while a mode is active, the new ClearSelection
while something is selected, EnterDeconstruct otherwise. The three partition
the situations between them, so resolution stays first-match-wins over
available actions and the handler never re-derives the precedence -- which is
why ClearSelection gets its own event rather than joining ModeCancel on Q.

GameWorldView clears the selection at each of the three events that enter a
mode; those are the only ways in, whichever button or key the player used. No
clear is needed where ModeCancel falls through to deconstruct mode: Q resolves
to ClearSelection while anything is selected, so there is nothing left by then.

The Selection context's Q row reads "Clear selection", sits last as the row
that hands the context back does everywhere, and carries the exit badge
styling -- one key that backs out should look the same wherever it appears.
Requirements follow that last point in REQ-UI-CONTROLS-CARD and
REQ-UI-CONTROLS-CONTENT.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 21:49:33 +02:00
731b8874c9 let Q clear the selection, and keep selection and build mode apart
Q backed out of a build mode or toggled deconstruct mode; it now clears the
selection as its middle case. That needed a rule for a selection held while a
build mode is active, a state the code allows today: clearAll() is called only
by a click or drag that hit nothing, so a selection survives into builder,
blueprint, and deconstruct mode.

Make the two mutually exclusive instead, matching what the controls panel
already shows: entering any build mode clears the selection. The blueprint
gestures read the selection before the mode entry clears it, so C and Ctrl+C
lose nothing.

Drops the accuracy carve-out that had C / Ctrl+C merely omitted from the build
contexts on the strength of a surviving selection -- with no selection there,
they are unavailable rather than omitted, and the list is the three cases its
intro claims.

Requirements only; no code yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 21:31:35 +02:00
392a2b8d00 keep the selection panel half a tile off what it describes
The panel had one distance for the view edges, the widgets it steps around,
and the selection alike, so it stood eight pixels from a building and touched
it outright along the top. The gap from the selection is now its own value,
half a tile, and it is horizontal only -- the top edges stay level.

It is sampled where the tile size is known, in the same moment as the anchor
rectangle, and travels with it: a rectangle frozen in one moment has no
meaningful distance to a tile size measured in another. chooseSide now takes
the gap in place of the margin, the band having already taken the margin off.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 16:24:14 +02:00
abaccc45b5 give the selection panel its own gap from what it describes
The panel kept one distance for everything: the view edges, the widgets it
steps around, and the selection itself. Beside a building that read as
touching it -- eight pixels to the side and nothing at all above, the top
edges flush. Split the two apart: an edge margin as before, and a selection
gap of half a tile, horizontal only, frozen with the anchor rectangle it is
measured from.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 15:53:30 +02:00
b2148f00ac stop hovering when the cursor points at no tile
A cursor resting on a panel or outside the window kept whatever it last
pointed at: the ghost, the tunnel preview, the deconstruct tint all stayed
put, because "not hovering" was not a state the build mode could hold. Make
both ghost tiles optional, clear the hover with them, and re-derive it when
the cursor comes back or a mode is entered.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 15:19:22 +02:00
9490a96e12 let the hover follow a view that scrolls under a still cursor
Only the selection box was refreshed while the camera panned, so the ghost,
its validity, the resolved tunnel end and the deconstruct hover all kept the
tile of the last mouse move. Give the whole hover update one entry point and
run it from the pan step as well, for a cursor that is over the world.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 14:54:34 +02:00
fd0c246bc0 show the tunnel end the click would actually place
The controls panel header read the type builder mode was entered with, so
tunnel mode always said Tunnel Entry even where the ghost had resolved to an
exit. Feed the header the same effective type the ghost and placement already
use.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 13:26:50 +02:00
9c275e283c give every recipe one shape: a list of output groups
Implements REQ-MAT-OUTPUT-GROUP. A recipe had two shapes -- outputs produced
together, or outputs of which exactly one happened -- and every rule over them
was written twice, selected by `building == ReprocessingPlant`: sizing a
buffer, deciding whether a cycle fits, resolving what a cycle makes, costing an
item. RecipeDef now holds output groups, each a weight and a list of items, and
a cycle yields exactly one group. One group is the ordinary recipe, so the old
two cases are the same shape with one and with several, and all four rules
collapse to one expression apiece with no building-type test left.

rollReprocessingOutput becomes rollOutputGroup, where a single group returns
without drawing or testing eligibility. That early-out is load-bearing twice
over. Drawing there would consume entropy for every ordinary recipe and shift
every later random outcome; and eligibility must not apply either, since
implicit unlocking is demand-derived, so an ordinary recipe's output can be
producible while nothing yet calls for it -- testing it would stop the building
producing rather than gate a drop. Past the early-out a group is eligible only
when all of its items are unlocked, being produced whole.

Threat follows the recipe's shape rather than the building, and the per-unit
value now divides by the group's amount as well as its odds. That moves no
number today: every item resolved through this path has amount 1, which is why
the threat expectations are untouched.

Config keeps `outputs = [...]` as the single-group form, so only the two
reprocessing recipes change shape. The recipe summary gains "/" between groups
and keeps "+" within one, which also fixes the plant reading as though a cycle
produced all of its items at once.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 12:47:09 +02:00
41c45d73ce cut the reprocessing plant entry back to what is still its own
Everything it used to specify moved out as the output-group merge generalised
it: the pick is REQ-MAT-OUTPUT-GROUP, the all-outcomes gate REQ-MAT-CYCLE, the
buffers REQ-MAT-OUTPUT-BUFFER, the eligible set REQ-LOCK-OUTPUT-POOL, the
recipe control REQ-BLD-AUTO-RECIPE. Restating them here only invited the two
to drift apart.

What is left is what config cannot say: why the building exists -- the
value-preserving counterpart to smelting scrap down, and the only path to
voidsteel -- plus the one rule that really is specific to it, that reprocessing
recipes take no part in the implicit unlock traversal, which until now was only
implied by REQ-LOCK-IMPLICIT naming the other three building types.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 10:51:54 +02:00
f39e4f3506 name the output pool restriction for what it restricts
It is no longer about reprocessing: any recipe with several output groups is
subject to it, and the plant is only the building that happens to have one
(REQ-MAT-OUTPUT-GROUP). REQ-LOCK-REPROCESSING-POOL becomes REQ-LOCK-OUTPUT-POOL.
Four citations, all in docs -- no code cites it.

Also corrects a line REQ-LOCK-IMPLICIT still carried from before smelters had a
recipe control: their recipes are not "never shown in any UI dropdown" any more,
they are simply never gated, so the dialog offers all of them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 10:32:30 +02:00
3c63205c6c make every recipe one shape: a list of output groups
Deterministic recipes could have several outputs produced together; a
probabilistic one could have several outputs of which exactly one happened.
Two shapes meant two rules everywhere -- sizing a buffer, deciding whether a
cycle fits, resolving what a cycle makes -- each written as a branch on
whether the building was a reprocessing plant.

New REQ-MAT-OUTPUT-GROUP merges them. A recipe has one or more output groups,
each with a weight and a list of items; a cycle produces exactly one group,
and the items within it together. One group is the ordinary recipe and is
always chosen, so the old deterministic and probabilistic cases are the same
shape with one group and with several -- and every rule downstream is written
over groups, needing no branch at all. Config keeps outputs = [...] as the
single-group form, so only the two reprocessing recipes change shape.

It also lets an outcome yield several items, which was unrepresentable, and
fixes a display bug on the way: the recipe summary drew all outputs as one
combined yield, so a plant read as if a cycle made all four items. Groups are
now separated by "/" and the items within one by "+".

REQ-LOCK-REPROCESSING-POOL now restricts the choice between groups rather
than the pool of output items, and says why that distinction is load-bearing:
implicit unlocking is demand-derived, so an ordinary recipe's output can be
producible while nothing yet calls for it. Testing eligibility there would not
gate a drop, it would stop the building producing at all -- so a recipe with
one group, having no choice to restrict, is never tested. A group is eligible
only if all of its items are unlocked, since they are produced together.

Requirements only; the implementation follows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
2026-08-17 09:46:31 +02:00
a1c567715e make selection box sub-tile aware 2026-08-14 22:51:05 +02:00
1cf7c264c1 draw selection rect only if mouse has moved 2026-08-14 22:20:35 +02:00
d36e59fd26 make selection box use the selection or deconstruct color to indicate the mode 2026-08-14 21:49:55 +02:00
111 changed files with 3599 additions and 1288 deletions

View File

@@ -99,25 +99,21 @@ building = "reprocessing_plant"
inputs = [{item = "scrap", amount = 4}]
duration_seconds = 4.0
[[recipe.outputs]]
item = "iron_ingot"
amount = 1
[[recipe.output_group]]
probability = 0.3
items = [{item = "iron_ingot", amount = 1}]
[[recipe.outputs]]
item = "copper_ingot"
amount = 1
[[recipe.output_group]]
probability = 0.3
items = [{item = "copper_ingot", amount = 1}]
[[recipe.outputs]]
item = "silicon"
amount = 1
[[recipe.output_group]]
probability = 0.2
items = [{item = "silicon", amount = 1}]
[[recipe.outputs]]
item = "voidsteel"
amount = 1
[[recipe.output_group]]
probability = 0.2
items = [{item = "voidsteel", amount = 1}]
# -----------------------------------------------------------------------------
# Tier 2 — early intermediates (clean ratios, ~2:3)

View File

@@ -344,12 +344,15 @@ width_px = 2
[overlays]
ghost_valid = "#ffffff44" # builder-mode ghost, placement allowed (REQ-BLD-GHOST)
ghost_invalid = "#ff000044" # builder-mode ghost, placement invalid (REQ-BLD-PLACE-VALID)
deconstruct_tint = "#ff000033" # deconstruct-mode hover tint
selection_rect = "#00ff00" # box-drag selection rectangle (REQ-UI-MULTI-SELECT)
deconstruct_tint = "#ff000033" # deconstruct-mode hover tint; its RGB also draws the
# box-drag rectangle in deconstruct mode, opaque
# (REQ-UI-MULTI-SELECT, REQ-BLD-DECONSTRUCT-BOX)
tile_highlight = "#ffffff22" # tile under cursor
selected_outline = "#ffff00" # outline drawn around currently-selected building(s)
selected_outline = "#ffff00" # outline around currently-selected building(s), and the
# box-drag selection rectangle (REQ-UI-MULTI-SELECT)
config_transfer = "#33ccff66" # blueprint ghost over a configuration-transfer target (REQ-UI-BLUEPRINT-TRANSFER)
locked_asteroid = "#0000007f" # tint over the asteroid left of the buildable edge (not yet unlocked by expansion)
next_expansion = "#00000040" # lighter tint over the columns the next expansion unlocks (REQ-UI-LOCKED-ASTEROID)
modal_dim = "#00000099" # semi-transparent black dim behind modal dialogs/menus (REQ-UI-MODAL-DIM)
tunnel_preview = "#00ff0055" # tunnel connection preview: matched end + tiles between (REQ-BLD-TUNNEL-MODE)

View File

@@ -11,7 +11,6 @@ tunnel_max_distance_tiles = 10
departure_interval_seconds = 20
orbit_factor = 0.8
rally_orbit_radius_tiles = 5.0
building_blocks_tooltip = "Building blocks are the currency for construction. Spend them to place buildings and to expand the asteroid. Produce building blocks in your assemblers and deliver them to the HQ on a belt to grow your stock."
artifact_tooltip = "Artifacts are the key to victory. Earn one by choosing the artifact reward when you destroy a set of enemy defence stations. Collect enough of them to win the game."
[regions]

View File

@@ -75,20 +75,17 @@ building = "reprocessing_plant"
inputs = [{item = "scrap", amount = 5}]
duration_seconds = 3.0
[[recipe.outputs]]
item = "iron_ingot"
amount = 2
[[recipe.output_group]]
probability = 0.6
items = [{item = "iron_ingot", amount = 2}]
[[recipe.outputs]]
item = "circuit_board"
amount = 1
[[recipe.output_group]]
probability = 0.3
items = [{item = "circuit_board", amount = 1}]
[[recipe.outputs]]
item = "advanced_alloy"
amount = 1
[[recipe.output_group]]
probability = 0.1
items = [{item = "advanced_alloy", amount = 1}]
# -------------------------------------------------------------------
# Extra recipes for ThreatCostCalculator unit tests (fixes 6-9)

View File

@@ -11,7 +11,6 @@ tunnel_max_distance_tiles = 10
departure_interval_seconds = 20
orbit_factor = 0.8
rally_orbit_radius_tiles = 5.0
building_blocks_tooltip = "Spend building blocks to build; deliver them to the HQ to gain more."
artifact_tooltip = "Choose the artifact reward when destroying enemy stations; collect enough to win."
[regions]

View File

@@ -427,7 +427,7 @@ width_px = 2
ghost_valid = "#ffffff44"
ghost_invalid = "#ff000044"
deconstruct_tint = "#ff000033"
selection_rect = "#00ff00"
selected_outline = "#ffff00"
[toast]
bg = "#000000cc"

View File

@@ -230,8 +230,8 @@ supporting different fleet doctrines feel structurally different to build.
**smelting** (same basic materials as ore — the safe, boring option) and
**reprocessing** (probabilistic higher intermediates, including the
late-game input — the gamble that eventually becomes mandatory).
- The reprocessing output pool renormalizes over implicitly unlocked items
(REQ-LOCK-REPROCESSING-POOL), so its output quality improves
- The reprocessing output pool renormalizes over the output groups whose items
are implicitly unlocked (REQ-LOCK-OUTPUT-POOL), so its output quality improves
automatically as the run progresses. **Rule:** weights are authored for
the *fully unlocked* pool state; early-game behavior falls out of
renormalization for free and needs no separate staging.

View File

@@ -4,9 +4,9 @@
Config files use the TOML format. The following config files drive game parameters:
- **world.toml** — world dimensions, region widths, expansion amounts, building refund percentage, building deconstruction time, wave timing, boss wave timing, belt speed, starting building blocks, departure interval, ship orbit factor, rally orbit radius, scrap-per-threat conversion, combat target-selection parameters (target score formula, overclaim penalty formula, target hysteresis), artifact chance formula, artifact win count, view pan speeds (slow and fast horizontal pan speed and pan ramp band width), an optional building blocks tooltip string (shown as the header bar's building blocks stock hover tooltip, REQ-UI-BLOCKS-TOOLTIP; omitted when unset), and an optional artifact tooltip string (shown as the header bar's artifact count hover tooltip, REQ-UI-ARTIFACTS-TOOLTIP; omitted when unset).
- **world.toml** — world dimensions, region widths, expansion amounts, building refund percentage, building deconstruction time, wave timing, boss wave timing, belt speed, starting building blocks, departure interval, ship orbit factor, rally orbit radius, scrap-per-threat conversion, combat target-selection parameters (target score formula, overclaim penalty formula, target hysteresis), artifact chance formula, artifact win count, view pan speeds (slow and fast horizontal pan speed and pan ramp band width), and an optional artifact tooltip string (shown as the header bar's artifact count tooltip, REQ-UI-ARTIFACTS-TOOLTIP; omitted when unset).
- **buildings.toml** — building block cost and construction time per building type, plus an optional tooltip description string per building type (shown as the build button's hover tooltip, REQ-UI-BUILD-TOOLTIP; omitted when unset). Whether a building type is available from game start or must be unlocked during play is not defined here but in **unlocks.toml** (REQ-LOCK-EXPLICIT): a building type granted by an unlock group starts locked and is hidden from the build menu until its group is awarded (REQ-LOCK-BUILDING).
- **recipes.toml** — crafting recipes: inputs, outputs, quantities, durations, and reprocessing plant probabilities. Assembler recipe entries may optionally define `unlocked_at_start` (boolean, default false): when true the recipe is available from game start regardless of the implicit item graph — used for base recipes that no schematic's materials reach (such as building blocks; see REQ-LOCK-IMPLICIT). Which assembler recipes must instead be awarded during play (explicitly gated) is defined in **unlocks.toml**, not here (REQ-LOCK-EXPLICIT); every remaining assembler recipe is implicitly unlocked through the item graph (REQ-LOCK-IMPLICIT).- **ships.toml** — per schematic: a human-readable display name (used in the UI), hull stats (HP, max linear speed, sensor range, main acceleration, maneuvering acceleration, angular acceleration, max rotation speed) as plain values, required build materials, a layout grid defining the ship's module slots, and a `default_modules` list used for enemy wave ships (see REQ-WAV-DEFAULT-MODULES). Whether a ship schematic is available from game start or must be unlocked during play is defined in **unlocks.toml** (REQ-LOCK-EXPLICIT), not here.
- **recipes.toml** — crafting recipes: inputs, output groups with their quantities and probability weights, and durations (REQ-MAT-OUTPUT-GROUP). Assembler recipe entries may optionally define `unlocked_at_start` (boolean, default false): when true the recipe is available from game start regardless of the implicit item graph — used for base recipes that no schematic's materials reach (such as building blocks; see REQ-LOCK-IMPLICIT). Which assembler recipes must instead be awarded during play (explicitly gated) is defined in **unlocks.toml**, not here (REQ-LOCK-EXPLICIT); every remaining assembler recipe is implicitly unlocked through the item graph (REQ-LOCK-IMPLICIT).- **ships.toml** — per schematic: a human-readable display name (used in the UI), hull stats (HP, max linear speed, sensor range, main acceleration, maneuvering acceleration, angular acceleration, max rotation speed) as plain values, required build materials, a layout grid defining the ship's module slots, and a `default_modules` list used for enemy wave ships (see REQ-WAV-DEFAULT-MODULES). Whether a ship schematic is available from game start or must be unlocked during play is defined in **unlocks.toml** (REQ-LOCK-EXPLICIT), not here.
- **modules.toml** — per module type: id, surface mask, materials list, production time, fill color, glyph, an optional tooltip description string (shown as the module selection button's hover tooltip, REQ-MOD-UI-MODULE-TOOLTIP; omitted when unset), and an optional capability section and/or stat modifier formulas. Whether a module schematic is available from game start or must be unlocked during play is defined in **unlocks.toml** (REQ-LOCK-EXPLICIT), not here. A module with a capability section (`[module.weapon]`, `[module.salvage]`, or `[module.repair]`) containing base stat formulas is a **capability module** that grants the ship a weapon, salvage bay, or repair tool per instance (see REQ-MOD-CONFIG for the full list of formulas per capability type). A module with only `added_*`/`multiplied_*` formulas is a **passive module** that modifies stats on the ship or on capability module instances (see REQ-MOD-STAT-CALC).
- **unlocks.toml** — unlock groups: each `[[unlock]]` entry names a group of ship schematics, module schematics, building types, and/or assembler recipes that are awarded together from a single defence station drop (see Unlock Group Format, REQ-LOCK-EXPLICIT, REQ-DEF-SCHEMATIC-DROP). Anything not granted by any unlock group is available from game start.
- **stations.toml** — HP, damage, range, fire rate, and scrap drop for player and enemy defence stations, defined as formulas of station level.
@@ -101,7 +101,7 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- **Enemy buffer zone** — space between the enemy's defence stations and the enemy spawn boundary (`enemy_buffer_width`).
- REQ-GW-SCROLL-LIMIT: The player can scroll the view horizontally from the asteroid's left edge to the current set of enemy defence stations (the enemy buffer zone is not visible).
- REQ-GW-PUSH-EXPAND: When the player destroys a set of enemy defence stations, the scrollable area is extended by `world.toml [push].push_expand_columns` tiles. A new enemy buffer zone of `world.toml [regions].enemy_buffer_width` tiles is added beyond the new enemy defence stations.
- REQ-GW-ASTEROID-EXPAND: When the player unlocks an asteroid expansion, `world.toml [expansion].columns_per_expansion` tile columns are added to the left of the asteroid.
- REQ-GW-ASTEROID-EXPAND: When the player unlocks an asteroid expansion, `world.toml [expansion].columns_per_expansion` tile columns are added to the left of the asteroid. Those are the columns drawn as locked ground before the purchase (REQ-UI-LOCKED-ASTEROID) and the ones the expansion button stands on (REQ-UI-EXPAND-BUTTON).
## HQ & Game Over
@@ -109,7 +109,7 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- REQ-HQ-BELT-INPUT: The HQ has a belt input port. Building blocks delivered to it are added to the global building blocks stock.
- REQ-HQ-STATS: HQ stats (HP) are read from `stations.toml [hq]`.
- REQ-HQ-STARTING-BLOCKS: At game start, the global building blocks stock is initialized to `world.toml [world].starting_building_blocks` (default 100).
- REQ-HQ-GAME-OVER: If the HQ is destroyed, the game ends. A game-over screen shows the final survival time and offers "Restart" and "Quit" buttons.
- REQ-HQ-GAME-OVER: If the HQ is destroyed, the game ends. A game-over screen, drawn by the game as every modal is (REQ-UI-MODAL-CHROME), shows the final survival time and offers "Restart" and "Quit" buttons.
- REQ-HQ-INVULNERABLE: Factory buildings (other than the HQ) are never targeted or destroyed by enemies.
## Win Condition
@@ -122,8 +122,8 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- REQ-BLD-COST: The player places buildings from a build menu. Placement costs building blocks from the global stock. The cost per building type is read from `buildings.toml [[building]].cost`.
- REQ-BLD-QUEUE: Placed buildings enter a construction queue and are built one at a time. Each building takes a duration defined in `buildings.toml [[building]].construction_time_seconds` to construct.
- REQ-BLD-ASTEROID-ONLY: Buildings can only be placed on asteroid tiles (per surface_mask; tiles marked `S` may extend into space).
- REQ-BLD-BUILDER-MODE: Clicking a build button activates builder mode for that building type. Builder mode is exited by right-clicking in the game world or clicking the same build button again. (Exception: while a belt drag placement is in progress, right-clicking cancels that drag instead of exiting, and builder mode stays active — REQ-BLD-BELT-DRAG.)
- REQ-BLD-GHOST: While in builder mode, a ghost of the building is rendered at the tile under the cursor, showing where it would be placed. The ghost is drawn semi-transparently in the building type's own visuals — its `fill` and `outline` colors and `glyph` from `visuals.toml` — so that different building types are visually distinguishable in builder mode rather than all looking alike. When the current cursor position is invalid, the ghost instead uses the distinct "invalid" color (REQ-BLD-PLACE-VALID), which overrides the per-building coloring.
- REQ-BLD-BUILDER-MODE: Clicking a build button activates builder mode for that building type, clearing the selection as entering any build mode does (REQ-UI-SELECTION-EXCLUSIVE). Builder mode is exited by right-clicking in the game world or clicking the same build button again. (Exception: while a belt drag placement is in progress, right-clicking cancels that drag instead of exiting, and builder mode stays active — REQ-BLD-BELT-DRAG.)
- REQ-BLD-GHOST: While in builder mode, a ghost of the building is rendered at the tile under the cursor, showing where it would be placed. The ghost follows the tile the cursor points at, which includes the view scrolling (REQ-UI-SCROLL) under a cursor that has not moved: the ghost then moves across the world with the scroll rather than sticking to the tile it was last placed on by a mouse move, exactly as a running selection box does (REQ-UI-MULTI-SELECT). The same holds for everything else the hovered position determines — placement validity (REQ-BLD-PLACE-VALID), the tunnel end being placed (REQ-BLD-TUNNEL-MODE), a belt drag's path (REQ-BLD-BELT-DRAG), the blueprint ghost (REQ-UI-BLUEPRINT-MODE), and the deconstruct hover (REQ-UI-DECONSTRUCT-BUTTON). A cursor that is not over the game world — resting on one of the floating panels (REQ-UI-CONTROLS-PANEL, REQ-UI-BUILD-BAR, REQ-UI-SELECTION-PANEL), or outside the window — points at no tile and therefore hovers nothing: no builder ghost and no blueprint ghost is drawn, no tunnel connection is previewed, and no building is tinted as the deconstruct hover, until the cursor returns to the world. The mode itself is unaffected — the player is still building, just not over anything — and the position the ghost had is not remembered: it is re-derived from wherever the cursor comes back. This applies whenever the cursor points elsewhere, including at the moment a mode is entered, so a mode entered from a build button (REQ-UI-BUILD-BAR) shows its ghost only once the cursor is over the world, while one entered by hotkey (REQ-UI-HOTKEYS) under a cursor already there shows it at once. The one exception is a gesture that holds the mouse button — a belt drag (REQ-BLD-BELT-DRAG) or a selection or deconstruct box (REQ-UI-MULTI-SELECT, REQ-BLD-DECONSTRUCT-BOX) — which goes on following the cursor across the panels and beyond the window until the button is released. The ghost is drawn semi-transparently in the building type's own visuals — its `fill` and `outline` colors and `glyph` from `visuals.toml` — so that different building types are visually distinguishable in builder mode rather than all looking alike. When the current cursor position is invalid, the ghost instead uses the distinct "invalid" color (REQ-BLD-PLACE-VALID), which overrides the per-building coloring.
- REQ-BLD-ROTATE: While in builder mode, pressing Shift+R rotates the ghost 90° clockwise and R rotates it 90° counter-clockwise. Rotation affects the direction of the output port.
- REQ-BLD-PLACE: Clicking a valid tile in builder mode places a construction site and adds it to the build queue, consuming building blocks from the global stock. (For belts, placement is instead deferred to a drag gesture and happens on mouse release — REQ-BLD-BELT-DRAG.)
- REQ-BLD-PLACE-VALID: A placement position is valid only if (a) every footprint cell in the rotated `surface_mask` is satisfied by the underlying terrain — `A` cells coincide with asteroid tiles, `S` cells coincide with space tiles — (b) no footprint cell overlaps an existing placed building or construction site, except as allowed by REQ-BLD-ROTATE-IN-PLACE (builder mode) or REQ-UI-BLUEPRINT-OVERLAP and REQ-UI-BLUEPRINT-TRANSFER (blueprint placement mode), and (c) the player has enough building blocks to afford the building. The ghost (REQ-BLD-GHOST) is rendered in a distinct "invalid" color — overriding its per-building coloring (REQ-BLD-GHOST) — when the current cursor position fails any of these conditions.
@@ -144,15 +144,15 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- REQ-BLD-DECONSTRUCT: The player can deconstruct a placed factory building. Deconstructing a **fully-built** factory building does not remove it instantly: it is added to the deconstruction queue (REQ-BLD-DECON-QUEUE) and, once its deconstruction completes, `world.toml [world].refund_percentage` percent of the original building block cost (default 75%) is returned to the global stock. Exception: if the building is still in the construction queue (not yet fully built, including the one currently being constructed), it is **not** queued for deconstruction but removed instantly from the construction queue, and the **full** building block cost is refunded immediately. The HQ and player defence stations cannot be deconstructed.
- REQ-BLD-DECON-QUEUE: Fully-built factory buildings marked for demolition (REQ-BLD-DECONSTRUCT) enter a **deconstruction queue** that is processed one building at a time and runs in parallel with the construction queue (REQ-BLD-QUEUE) — the two queues advance independently and simultaneously. Each building takes `world.toml [world].deconstruction_time_seconds` (default 0.1) to deconstruct, the same duration for every building type. When a building's deconstruction completes it is removed from the world and its refund is credited (REQ-BLD-DECONSTRUCT). A building **stops operating the moment it enters the queue**: it runs no production and transports no items, and no longer participates as a live building (its tunnel pairing is re-evaluated as if it were gone, REQ-BLD-TUNNEL-PAIR), but it still physically occupies its tiles until removed, so those tiles stay blocked for placement. A queued building can be taken back out of the deconstruction queue before it is removed (REQ-BLD-DECONSTRUCT-CLICK, REQ-BLD-DECONSTRUCT-BOX) — including the one currently being deconstructed; doing so discards any deconstruction progress, credits no refund, and the building resumes operating (and re-pairs, REQ-BLD-TUNNEL-PAIR). Construction sites never enter the deconstruction queue (REQ-BLD-DECONSTRUCT). Every building in the deconstruction queue is rendered with the deconstruct tint — the `visuals.toml [overlays].deconstruct_tint` color, the same tint applied to a building hovered in deconstruct mode (REQ-UI-DECONSTRUCT-BORDER) — so queued buildings are visually distinct.
- REQ-BLD-DECONSTRUCT-CLICK: While in deconstruct mode (REQ-UI-HOTKEYS, REQ-UI-DECONSTRUCT-BUTTON), left-clicking a placed factory building or construction site in the game world marks it for demolition, following the rules of REQ-BLD-DECONSTRUCT: a fully-built building is added to the deconstruction queue (REQ-BLD-DECON-QUEUE), and a construction site is removed instantly with the full refund. Left-clicking a fully-built building that is **already in the deconstruction queue** instead removes it from the queue (un-queues it, REQ-BLD-DECON-QUEUE), with no refund; repeated clicks on the same building therefore alternate between queueing and un-queueing it. Clicking a building that cannot be deconstructed (the HQ or a player defence station, per REQ-BLD-DECONSTRUCT), or clicking empty world space, has no effect. Deconstruct mode stays active after each action so the player can continue without re-entering the mode; it is exited via the Q toggle (REQ-UI-HOTKEYS) or the Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON).
- REQ-BLD-DECONSTRUCT-BOX: While in deconstruct mode (REQ-UI-HOTKEYS, REQ-UI-DECONSTRUCT-BUTTON), the player can click and drag a selection box in the game world. A selection rectangle is drawn while dragging, using the same box-drag gesture and coverage semantics as the multi-select box (REQ-UI-MULTI-SELECT). On mouse up, following the rules of REQ-BLD-DECONSTRUCT: every construction site covered by the box is removed instantly with the full refund; and among the fully-built deconstructible buildings covered by the box, if **all** of them are already in the deconstruction queue they are all removed from it (un-queued, REQ-BLD-DECON-QUEUE), otherwise every covered building not yet in the queue is added to the deconstruction queue (already-queued ones stay). Buildings that cannot be deconstructed (the HQ and player defence stations, per REQ-BLD-DECONSTRUCT) are excluded from the box demolition; ships and defence stations are never affected.
- REQ-BLD-DECONSTRUCT-BOX: While in deconstruct mode (REQ-UI-HOTKEYS, REQ-UI-DECONSTRUCT-BUTTON), the player can click and drag a selection box in the game world. A selection rectangle is drawn while dragging, using the same box-drag gesture and coverage semantics as the multi-select box (REQ-UI-MULTI-SELECT), but drawn in the deconstruct color rather than the ordinary selection color (REQ-UI-MULTI-SELECT, Rectangle color). On mouse up, following the rules of REQ-BLD-DECONSTRUCT: every construction site covered by the box is removed instantly with the full refund; and among the fully-built deconstructible buildings covered by the box, if **all** of them are already in the deconstruction queue they are all removed from it (un-queued, REQ-BLD-DECON-QUEUE), otherwise every covered building not yet in the queue is added to the deconstruction queue (already-queued ones stay). Buildings that cannot be deconstructed (the HQ and player defence stations, per REQ-BLD-DECONSTRUCT) are excluded from the box demolition; ships and defence stations are never affected.
- REQ-BLD-SITE-CONFIG: A construction site — a building that has been placed but is still queued or under construction (REQ-BLD-QUEUE) — can be selected and configured exactly like the equivalent operational building, before it finishes building. Whatever configuration the building type supports is available on the site: the recipe for a Miner, Assembler, Smelter or Reprocessing Plant (REQ-UI-SELECT-BUTTON, REQ-BLD-AUTO-RECIPE), the produced-ship schematic and its module layout for a Shipyard (REQ-UI-SELECT-BUTTON, REQ-MOD-UI-PREVIEW, REQ-MOD-UI-DIALOG), and the output filters for a Splitter (REQ-BLD-SPLITTER) — all set through the same selection panel controls (REQ-UI-CONFIG-INLINE). Only currently unlocked recipes and schematics are offered, exactly as for operational buildings (REQ-LOCK-UI-RECIPE, REQ-LOCK-UI-SCHEMATIC, REQ-LOCK-UI-SPLITTER). The configuration is stored on the construction site and carries over unchanged when construction completes, so the building becomes operational already configured. A construction site has no input/output buffers and runs no production cycle, so the buffer and production-progress portions of the panel (REQ-UI-SINGLE-SELECTION, REQ-UI-PRODUCTION-PROGRESS) are not shown for it; only its construction progress (REQ-UI-CONSTRUCTION-PROGRESS) and its configuration controls appear. (Blueprint placement already applies a stored recipe or schematic to a construction site on placement per REQ-UI-BLUEPRINT-PLACE; this requirement additionally lets the player set or change that configuration directly on an existing site.)
## Building Types
- REQ-BLD-MINER: **Miner** (2×2): The player selects which ore type it extracts. Each ore type corresponds to a `recipes.toml [[recipe]]` entry with `building = "miner"`, defining the output item and `duration_seconds`. Every asteroid tile is equivalent for mining — any miner can produce any ore type based solely on its selected recipe. Ore never depletes. Only implicitly unlocked ore-type recipes are available for selection (REQ-LOCK-UI-RECIPE).
- REQ-BLD-SMELTER: **Smelter** (2×2): Converts ore or scrap into basic materials. Its recipe is selected as any other building's is, except that it also picks one for itself from the first material it is offered (REQ-BLD-AUTO-RECIPE). Inputs, outputs, and rates are defined in `recipes.toml [[recipe]]` entries with `building = "smelter"`.
- REQ-BLD-ASSEMBLER: **Assembler** (3×3): The player selects a recipe from the config-defined crafting tree. Produces the selected output item at the rate defined in the corresponding `recipes.toml [[recipe]]` entry with `building = "assembler"`. Only implicitly unlocked recipes are available for selection (REQ-LOCK-UI-RECIPE).
- REQ-BLD-REPROCESSING: **Reprocessing Plant** (3×3): Consumes scrap per cycle and produces exactly one **kind** of higher-level intermediate product per cycle via weighted random pick, in that output's configured amount (which may be more than one item). The input quantity, possible output items, per-output weights, and amounts are defined in `recipes.toml [[recipe]]` entries with `building = "reprocessing_plant"` (`inputs`, `outputs[].item`, `outputs[].amount`, `outputs[].weight`). Weights are normalized at load time; their sum does not need to equal 1. The output is rolled at cycle start (see REQ-MAT-CYCLE); the pool of eligible outputs is restricted to implicitly unlocked item types (REQ-LOCK-REPROCESSING-POOL). Its output side follows the general rules with no exception: one buffer per possible output item (REQ-MAT-OUTPUT-BUFFER), and a cycle starts only when every possible roll would fit (REQ-MAT-CYCLE) — which is also what denies the player a reroll by stalling the output belt. Like the Smelter it picks its recipe from the first material it is offered while none is set (REQ-BLD-AUTO-RECIPE).
- REQ-BLD-ASSEMBLER: **Assembler** (3×3): The player selects a recipe from the config-defined crafting tree. Produces what that recipe produces (REQ-MAT-OUTPUT-GROUP) at the rate defined in the corresponding `recipes.toml [[recipe]]` entry with `building = "assembler"`. Only implicitly unlocked recipes are available for selection (REQ-LOCK-UI-RECIPE).
- REQ-BLD-REPROCESSING: **Reprocessing Plant** (3×3): Consumes scrap and returns a higher-tier material chosen by chance, as the value-preserving counterpart to smelting scrap down (REQ-BLD-SMELTER) and the only source of voidsteel. Its inputs, output groups and weights are ordinary recipe config (REQ-MAT-OUTPUT-GROUP) with `building = "reprocessing_plant"`; nothing about its behaviour is specific to the building. Reprocessing recipes take no part in the implicit unlock traversal (REQ-LOCK-IMPLICIT), so what it can yield is governed by REQ-LOCK-OUTPUT-POOL alone.
- REQ-BLD-AUTO-RECIPE: **Automatic recipe selection.** The Smelter and the Reprocessing Plant (REQ-BLD-SMELTER, REQ-BLD-REPROCESSING) are *auto-recipe buildings*. They carry a selected recipe and are configured exactly as a Miner or Assembler is — the same selection button and dialog (REQ-UI-SELECT-BUTTON), buffers sized for that one recipe alone (REQ-MAT-INPUT-BUFFER, REQ-MAT-OUTPUT-BUFFER), and the same pre-configuration on a construction site (REQ-BLD-SITE-CONFIG). They differ in one respect only:
- **Selection while none is set.** When such a building has no recipe, the first material offered at any of its input ports that some recipe of its type consumes selects that recipe; the material is then accepted as normal. This holds for every intake path — a belt, splitter or tunnel exit at an input port, and a directly coupled producer (REQ-MAT-DIRECT-COUPLE) — because a building that accepts nothing would otherwise leave a coupled producer stuck at its port forever. The choice is deterministic: input ports are examined in order, and where several recipes of the type consume the offered material the first in config order wins.
- **No further switching.** Once a recipe is set the building keeps it. It does not switch when its buffers run empty, nor when a material belonging to another of its recipes arrives — that material is simply not an accepted input, exactly as for any other building.
@@ -202,8 +202,13 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- REQ-MAT-ACCEPT-DIR: A transport tile (belt, splitter, tunnel entry, or tunnel exit) accepts an incoming item only through a non-output edge; an item that would enter through one of the tile's output edges is refused. For a belt or a tunnel entry/exit the sole output edge is the one in its facing direction; for a splitter either of its two output directions is an output edge. This applies both to items pushed from an adjacent transport tile and to items deposited by a building's output port (REQ-MAT-OUTPUT-PORT).
- REQ-MAT-INPUT-BUFFER: Each building has one input buffer per required input material. Each per-material buffer holds up to twice that material's per-cycle requirement. When the player selects a new recipe or schematic, all items in all input buffers are cleared.
- **Setting a configuration to the value it already holds is a no-op.** Selecting the recipe or schematic already set, or applying a ship layout identical to the one already configured, changes nothing: buffers are not cleared, an in-progress production cycle is not cancelled (REQ-BLD-SHIPYARD), and a construction site's progress and stored settings are untouched. This holds however the setting is applied — through the selection dialog (REQ-UI-SELECT-BUTTON), the layout configuration dialog (REQ-MOD-UI-DIALOG), a blueprint placement (REQ-UI-BLUEPRINT-PLACE), or a blueprint configuration transfer (REQ-UI-BLUEPRINT-TRANSFER). Only a setting that genuinely differs has effects.
- REQ-MAT-OUTPUT-BUFFER: Each building has **one output buffer per item its recipe can produce** — each output of a deterministic recipe, and every possible roll of a probabilistic one (REQ-BLD-REPROCESSING). Each per-material buffer holds up to twice that item's per-cycle amount, mirroring the input side (REQ-MAT-INPUT-BUFFER); a buffer's contents never occupy another item's capacity. An emerging item still occupies its buffer for the whole animation (REQ-MAT-OUTPUT-EMERGE). Whether a buffer without room stops production is decided by REQ-MAT-CYCLE. When the player selects a new recipe or schematic, all items in all output buffers are cleared (relevant when the adjacent belt is jammed and items have accumulated). Re-applying a setting the building already has clears nothing, per REQ-MAT-INPUT-BUFFER. Two buildings stand outside this rule: the Shipyard has no output buffer at all, since it spawns a ship rather than producing items (REQ-BLD-SHIPYARD), and the Salvage Bay has no recipe, so its single scrap buffer is sized by config instead (REQ-BLD-SALVAGE-BAY).
- REQ-MAT-CYCLE: Production cycle lifecycle. When a building is idle, it attempts to start a new cycle: (a) all required inputs must be present in the per-material input buffers, and (b) **every** output the cycle could produce must fit in that item's own output buffer (REQ-MAT-OUTPUT-BUFFER). For a deterministic recipe (b) is simply its own outputs. The Reprocessing Plant rolls its output at cycle start (weighted pick, REQ-BLD-REPROCESSING), so every possible roll must fit: the roll is committed the moment the cycle begins, and a cycle whose result could not be stored must not be started at all. Testing every possibility rather than the rolled one is what keeps a stalled output belt from biasing the distribution — with one item type's buffer full the plant stops entirely instead of going on producing only the others. On cycle start, inputs are consumed immediately and the production timer begins. On cycle completion, the (already-decided) output is deposited into its output buffer and the building returns to idle.
- REQ-MAT-OUTPUT-GROUP: **What a recipe produces.** A recipe's output is defined as one or more **output groups**, each carrying a probability weight and a list of item/amount pairs. One cycle produces the items of exactly **one** group, decided at cycle start (REQ-MAT-CYCLE); the items within that group are all produced together.
- A recipe with a **single group** always produces it. There is nothing to choose, so no weight is consulted, no randomness is involved, and no eligibility is tested (REQ-LOCK-OUTPUT-POOL). This is the ordinary recipe, and the shape of all but the reprocessing ones.
- A recipe with **several groups** picks one by weight at cycle start. Weights are normalized at load time; their sum does not need to equal 1.
- There is no separate deterministic and probabilistic kind of recipe: the two are one shape with one group and with several. Every rule about outputs is written over groups, so none of them needs to distinguish the two cases — or which building runs the recipe.
- **Config shape.** A group is a `[[recipe.output_group]]` entry with `probability` and `items = [{item, amount}, ...]`. The single-group case may instead be written as `outputs = [{item, amount}, ...]`, which means exactly one group holding those items. A recipe uses one form or the other; both present fails config load.
- REQ-MAT-OUTPUT-BUFFER: Each building has **one output buffer per item its recipe can produce** — every item of every one of its output groups (REQ-MAT-OUTPUT-GROUP). Each per-material buffer holds up to twice that item's per-cycle amount, meaning the largest total any single group produces of it, mirroring the input side (REQ-MAT-INPUT-BUFFER); a buffer's contents never occupy another item's capacity. An emerging item still occupies its buffer for the whole animation (REQ-MAT-OUTPUT-EMERGE). Whether a buffer without room stops production is decided by REQ-MAT-CYCLE. When the player selects a new recipe or schematic, all items in all output buffers are cleared (relevant when the adjacent belt is jammed and items have accumulated). Re-applying a setting the building already has clears nothing, per REQ-MAT-INPUT-BUFFER. Two buildings stand outside this rule: the Shipyard has no output buffer at all, since it spawns a ship rather than producing items (REQ-BLD-SHIPYARD), and the Salvage Bay has no recipe, so its single scrap buffer is sized by config instead (REQ-BLD-SALVAGE-BAY).
- REQ-MAT-CYCLE: Production cycle lifecycle. When a building is idle, it attempts to start a new cycle: (a) all required inputs must be present in the per-material input buffers, and (b) **every one** of the recipe's output groups must fit — for each group, the items it would produce must fit in their own output buffers (REQ-MAT-OUTPUT-GROUP, REQ-MAT-OUTPUT-BUFFER). With a single group (b) is simply that group. With several it means every possible outcome, tested **before** one is picked: the pick is committed the moment the cycle begins, and a cycle whose result could not be stored must not be started at all. Testing every outcome rather than the picked one is what keeps a stalled output belt from biasing the distribution — with one item type's buffer full the building stops entirely instead of going on producing only the others. On cycle start the group is picked (by weight where there is more than one, REQ-MAT-OUTPUT-GROUP), inputs are consumed immediately, and the production timer begins. On cycle completion the (already-decided) items are deposited into their output buffers and the building returns to idle.
- REQ-MAT-GLOBAL-STOCK: The building blocks stock is the only global inventory. All other materials exist only in building buffers or on belt tiles.
## Resources
@@ -268,9 +273,9 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
### Module Placement
- REQ-MOD-PLACEMENT: In the layout configuration dialog (REQ-MOD-UI-DIALOG), the player places modules onto the ship's layout grid. Clicking a module button in the module selection grid enters module placement mode for that module type. While in placement mode, a ghost of the module's surface mask is rendered at the cell under the cursor. Clicking a valid position places one instance of the module. A position is valid if every `O` cell in the module's (rotated) surface mask coincides with an unoccupied buildable cell of the ship's layout. The player may place unlimited instances of the same module type.
- REQ-MOD-PLACEMENT: In the layout configuration dialog (REQ-MOD-UI-DIALOG), the player places modules onto the ship's layout grid. Clicking a module button in the module selection grid enters module placement mode for that module type. While in placement mode, a ghost of the module's surface mask is rendered at the cell under the cursor. Clicking a valid position places one instance of the module. A position is valid if every `O` cell in the module's (rotated) surface mask coincides with an unoccupied buildable cell of the ship's layout. The player may place unlimited instances of the same module type. Placement mode is left by pressing Q or clicking outside the dialog, either of which clears the selected module before it reaches the dialog itself (REQ-UI-DIALOG-DISMISS), and by the existing gestures: clicking the same module button again, picking another module, or entering remove mode (REQ-MOD-REMOVE).
- REQ-MOD-ROTATION: While in module placement mode, pressing R rotates the module ghost 90° counter-clockwise and Shift+R rotates it 90° clockwise. Rotation transforms the surface mask grid identically to building rotation (REQ-BLD-ROTATE).
- REQ-MOD-REMOVE: The module selection grid includes a "Remove" button. Clicking it enters remove mode. In remove mode, clicking on a cell occupied by a placed module removes that entire module instance from the layout. Remove mode is exited by clicking the Remove button again or by selecting a module for placement.
- REQ-MOD-REMOVE: The module selection grid includes a "Remove" button. Clicking it enters remove mode. In remove mode, clicking on a cell occupied by a placed module removes that entire module instance from the layout. Remove mode is exited by clicking the Remove button again, by selecting a module for placement, or by pressing Q or clicking outside the dialog, either of which leaves the mode before it reaches the dialog itself (REQ-UI-DIALOG-DISMISS).
### Module Effects
@@ -285,7 +290,7 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- **Miner recipe**: `duration_seconds / output_amount`, where `output_amount` is the number of units produced per cycle.
- **Smelter recipe**: `(duration_seconds + Σ (input_threat × input_amount)) / output_amount`, where the sum is over all inputs.
- **Assembler recipe**: `(duration_seconds + Σ (input_threat × input_amount)) / output_amount`, where the sum is over all inputs.
- **Reprocessing-only item** (an item type that has no miner, smelter, or assembler recipe producing it, and is only obtainable via reprocessing): `(scrap_threat × scrap_per_cycle + duration_seconds) / probability`, where `scrap_threat` is the threat value of scrap (see REQ-THREAT-SCRAP), `scrap_per_cycle` is the number of scrap consumed per reprocessing cycle, `duration_seconds` is the reprocessing cycle time, and `probability` is the normalized weight of that item in the reprocessing output pool. (Reprocessing output amounts are 1 in practice, so per-unit division is already implicit in the formula.)
- **Item from a recipe that picks between output groups** (an item type produced by no single-group recipe, and so obtainable only where a cycle picks one outcome of several — REQ-MAT-OUTPUT-GROUP): `(scrap_threat × scrap_per_cycle + duration_seconds) / probability / output_amount`, where `scrap_threat` is the threat value of scrap (see REQ-THREAT-SCRAP), `scrap_per_cycle` is the scrap consumed per cycle, `duration_seconds` is the cycle time, `probability` is the group's normalized weight, and `output_amount` is how many units of the item that group yields. The cycle's cost is divided by the odds of getting the group at all, and then by how many units it yields, so the value is per unit as everywhere else in this requirement.
- **Multiple recipes**: if an item type can be produced by more than one non-reprocessing recipe (miner, smelter, or assembler), its threat value is the **maximum** across **all** such eligible recipes, and the threat is committed only once every eligible recipe is computable (so a shallow shortcut recipe that resolves earlier than a deeper base recipe cannot lower the item's threat). The reprocessing path is only used when no other recipe exists. If recipe cycles prevent full resolution, the max over the currently computable subset is used as a fallback.
- **Scrap-consuming recipe fallback**: a non-reprocessing recipe that takes `scrap` as an input participates in an item's threat computation only if no scrap-free recipe (miner, smelter, or assembler) produces that item. This mirrors the reprocessing fallback rule and prevents the scrap-to-ingot smelter recipe from inflating basic material threats via the max rule.
@@ -316,13 +321,13 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- **Left** (below the grid): The ship stats panel (see REQ-MOD-UI-STATS-PANEL), and beneath it the layout's **build cost**, so the price of a configuration is visible while it is being assembled rather than only once it has been confirmed: the total materials required for the ship — the union of the schematic's base materials and those of every placed module, summed per item type (REQ-MOD-MATERIALS) — drawn as item icons on their colored squares with their amounts (REQ-UI-ITEM-ICON), and beside them the total production time (REQ-MOD-PRODUCTION-TIME). Both update in real time as modules are placed and removed. The cost sits beside the stats panel rather than within it because a build cost belongs to a ship being configured: the same panel serves an existing ship (REQ-UI-SHIP-STATS-PANEL) and the balancing tool, neither of which costs anything.
- **Center** (below the grid): A grid of module selection buttons (one per **unlocked** module type; see REQ-DEF-SCHEMATIC-DROP) plus a "Remove" button. A module button shows the module's name — its `id` under the usual display convention — on its first line, and beneath it what the module costs: the icons of its `materials` items on their colored squares with their amounts (REQ-UI-ITEM-ICON) and the production time it adds, as `+<n> s` (REQ-MOD-MATERIALS, REQ-MOD-PRODUCTION-TIME). This is the same form a recipe option button uses to state what it makes (REQ-UI-SELECT-OPTIONS), and it puts the price of a module in front of the player before it is placed. The "Remove" button costs nothing and shows its caption alone.
- **Right** (below the grid): The layout blueprint panel (see REQ-MOD-UI-BLUEPRINT-PANEL through REQ-MOD-UI-BLUEPRINT-FILE-LOAD).
- **Bottom**: A "Confirm" button and a "Cancel" button. Cancel discards all changes made in this dialog session and closes the dialog. Confirm applies the changes: the shipyard's configured layout is updated, the required materials and cycle time displayed in the selection panel are recalculated, and the ship layout preview is refreshed.
- **Bottom**: A "Confirm" button and a "Cancel" button. Cancel discards all changes made in this dialog session and closes the dialog; Q and a click outside the dialog are two further ways to reach it, each once nothing is left to back out of within the dialog (REQ-UI-DIALOG-DISMISS). Confirm applies the changes: the shipyard's configured layout is updated, the required materials and cycle time displayed in the selection panel are recalculated, and the ship layout preview is refreshed.
- REQ-MOD-UI-EMPTY-PULSE: While a module is selected for placement in the layout configuration dialog (REQ-MOD-UI-DIALOG), the empty buildable cells of the layout grid pulse smoothly around their normal fill shade, oscillating between a slightly darker and a slightly brighter shade at approximately 1 Hz (one full cycle per second), to draw the player's attention to where the module can be placed. All empty buildable cells pulse in phase. When no module is selected for placement (including remove mode), empty buildable cells render at their normal static shade. Non-buildable cells and cells occupied by a placed module do not pulse.
- REQ-MOD-UI-AUTO-DIALOG: When the player selects a schematic for a shipyard (operational building or construction site) through the schematic selection dialog (REQ-UI-SELECT-BUTTON), and the chosen schematic **differs** from the shipyard's current schematic, the layout configuration dialog (REQ-MOD-UI-DIALOG) opens automatically and immediately once the selection dialog closes — exactly as if the player had then clicked "Configure". Re-selecting the schematic already set does not reopen the dialog. This auto-open applies only to the manual schematic selection dialog; a schematic applied by blueprint placement (REQ-UI-BLUEPRINT-PLACE) does **not** auto-open the dialog. The player may still cancel the auto-opened dialog (REQ-MOD-UI-DIALOG), which leaves the newly selected schematic in place with its default empty layout; the "Configure" button (REQ-MOD-UI-PREVIEW) remains available to open the dialog again later.
- REQ-MOD-UI-AUTO-DIALOG: When the player selects a schematic for a shipyard (operational building or construction site) through the schematic selection dialog (REQ-UI-SELECT-BUTTON), and the chosen schematic **differs** from the shipyard's current schematic, the layout configuration dialog (REQ-MOD-UI-DIALOG) opens automatically and immediately once the selection dialog closes — exactly as if the player had then clicked "Configure". Re-selecting the schematic already set does not reopen the dialog. Neither does **clearing** the shipyard: the `(None)` option (REQ-UI-SELECT-OPTIONS) differs from whatever was set, but it names no schematic and leaves nothing to configure, so no dialog opens — the same condition under which the "Configure" button is disabled (REQ-MOD-UI-PREVIEW). This auto-open applies only to the manual schematic selection dialog; a schematic applied by blueprint placement (REQ-UI-BLUEPRINT-PLACE) does **not** auto-open the dialog. The player may still cancel the auto-opened dialog (REQ-MOD-UI-DIALOG), which leaves the newly selected schematic in place with its default empty layout; the "Configure" button (REQ-MOD-UI-PREVIEW) remains available to open the dialog again later.
- REQ-MOD-UI-MODULE-TOOLTIP: Each module selection button in the layout configuration dialog (REQ-MOD-UI-DIALOG) shows a hover tooltip with the descriptive text defined for that module type in `modules.toml` (the optional per-module tooltip field). If a module type defines no tooltip text, its button shows no tooltip. The "Remove" button is not a module type and has no config-defined tooltip.
- REQ-MOD-UI-MODULE-TOOLTIP: Each module selection button in the layout configuration dialog (REQ-MOD-UI-DIALOG) shows a hover tooltip — hover only, its click selecting the module instead (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS) — with the descriptive text defined for that module type in `modules.toml` (the optional per-module tooltip field). If a module type defines no tooltip text, its button shows no tooltip. The material icons on the button face carry none of their own either way (REQ-UI-ITEM-VALUE-TOOLTIP): the button is a described control, and a module whose description happens to be unset must not read differently from the one beside it. The "Remove" button is not a module type and has no config-defined tooltip.
- REQ-MOD-UI-STATS-PANEL: The **ship stats panel** in the layout configuration dialog shows the stats of the currently configured ship layout as they would be computed, incorporating all passive module modifiers per REQ-MOD-STAT-CALC. The panel updates in real time whenever modules are placed or removed in the layout grid.
@@ -351,7 +356,7 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- REQ-MOD-UI-BLUEPRINT-PANEL: The right column of the layout configuration dialog is the layout blueprint panel. It shows only blueprints whose `ship_type` matches the schematic of the shipyard for which the dialog was opened. The panel contains, from top to bottom: a "Create Blueprint" button, followed by a scrollable list of blueprint entries (one per matching blueprint, in creation order).
- REQ-MOD-UI-BLUEPRINT-CREATE: Clicking "Create Blueprint" opens a modal dialog prompting for a name. The dialog has Confirm and Cancel buttons. Clicking Cancel closes the dialog with no effect. Clicking Confirm with a non-empty name creates a blueprint from the module layout currently shown in the left-side layout grid (the in-progress state of the dialog, not the previously confirmed shipyard layout) and appends it to the blueprint list.
- REQ-MOD-UI-BLUEPRINT-CREATE: Clicking "Create Blueprint" opens a modal dialog prompting for a name, drawn by the game like every other modal (REQ-UI-MODAL-CHROME) and, like the other name dialog, dismissed by neither Q nor a click outside it (REQ-UI-DIALOG-DISMISS). The dialog has Confirm and Cancel buttons. Clicking Cancel closes the dialog with no effect. Clicking Confirm with a non-empty name creates a blueprint from the module layout currently shown in the left-side layout grid (the in-progress state of the dialog, not the previously confirmed shipyard layout) and appends it to the blueprint list.
- REQ-MOD-UI-BLUEPRINT-ENTRY: Each blueprint entry shows the blueprint name and a delete icon ("×") to the right of the name. Clicking the entry (name area) loads that blueprint's module list into the left-side layout grid, replacing all currently placed modules. Module instances that are invalid for the current ship layout (unknown module type, locked module type, position outside the grid, position on a non-buildable cell, or overlapping another module in the same blueprint) are silently skipped; the remaining valid instances are placed. Clicking the delete icon ("×") removes that blueprint entry from the list immediately.
@@ -376,7 +381,9 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
Each option additionally displays a vertical list of recipe lines labeled "Unlocks recipes:", showing which miner and assembler recipes would newly become implicitly unlocked (REQ-LOCK-IMPLICIT) if this option were selected — specifically, the miner recipes and implicitly-gated assembler recipes that are not currently implicitly unlocked but would become so after applying this option's effect. To compute this, all `materials` of the group's granted ship and module schematics are added to the base set per REQ-LOCK-IMPLICIT step 1a, and the output items of the group's granted assembler recipes are added per step 1b, before recomputation.
Each recipe is shown as a **recipe line** of the same two-row card the item production tooltip uses (REQ-UI-ITEM-TOOLTIP): the icon of the building that runs it (REQ-UI-BUILD-ICON) and the recipe's name — by its `id`, using the same display convention as the assembler recipe-selection dialog — on the first row, and the recipe drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) on the second. The lines are sorted alphabetically by recipe name. The line says everything there is to say about the recipe, so nothing in this list carries a tooltip, as in the selection dialog (REQ-UI-SELECT-OPTIONS). If no recipes would be newly unlocked, the list shows "None".
Each recipe is shown as a **recipe line** of the same two-row card the item production tooltip uses (REQ-UI-ITEM-TOOLTIP): the icon of the building that runs it (REQ-UI-BUILD-ICON) and the recipe's name — by its `id`, using the same display convention as the assembler recipe-selection dialog — on the first row, and the recipe drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) on the second. The lines are sorted alphabetically by recipe name. The line says everything there is to say about the recipe, so nothing in this list carries a tooltip describing it, as in the selection dialog (REQ-UI-SELECT-OPTIONS); the items the line names do explain themselves, on hover or click: the card is not itself clicked, the option being taken with the button beneath it (REQ-UI-ITEM-VALUE-TOOLTIP). If no recipes would be newly unlocked, the list shows "None".
**The dialog cannot be dismissed.** Clicking an option is the only thing that closes it: it has no close button, no Cancel, neither Escape nor Q dismisses it, and a click outside it does nothing (REQ-UI-DIALOG-DISMISS). The drop is a reward the player has earned by destroying the station set, and every way out of the dialog would have to either forfeit it or pick an option the player did not — so there is no way out but choosing. The dialog is modal and the game is paused meanwhile, so nothing is waiting on the decision.
The player selects one option by clicking it. If the player selects the artifact option, the player's artifact count is incremented by 1 (REQ-WIN-ARTIFACT-COUNT) and the dialog closes; no unlock is applied. Otherwise the selected unlock group is awarded and the dialog closes: every ship, module, building, and assembler recipe the group grants becomes unlocked at once — ship schematics unlock the corresponding shipyard selection; module schematics unlock the module type for placement in the layout configuration dialog (REQ-MOD-UI-DIALOG); building types become available in the build menu (REQ-LOCK-BUILDING); assembler recipes become available in the assembler recipe-selection dialog (subject to REQ-LOCK-UI-RECIPE). The unlock group is removed from the pool permanently (REQ-LOCK-EXPLICIT), and the implicit unlock set is recomputed (REQ-LOCK-IMPLICIT).
@@ -387,12 +394,14 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
- REQ-LOCK-PREREQ: An unlock group may optionally define `requires` — a list of prerequisite **unlock-group ids** that must already have been awarded before this group may enter the drop pool. A prerequisite is **satisfied** only when the unlock group it names has been awarded (REQ-LOCK-EXPLICIT). This check is applied in addition to the conditions in REQ-DEF-SCHEMATIC-DROP: a group enters the eligible pool only when its `station_level` condition is met, it has not yet been awarded, and every id in its `requires` is satisfied. `requires` defaults to empty (no prerequisites). The check is re-evaluated against the current set of awarded unlock groups every time a drop pool is built (after each REQ-DEF-SCHEMATIC-DROP and on Restart per REQ-CFG-RELOAD), so a gated group becomes eligible in the first drop after its last prerequisite is awarded. Every id listed in any `requires` must resolve to an unlock group defined in `unlocks.toml`; an id that names no such group is a configuration error that fails config load with a descriptive message (config is loaded at startup and reloaded on Restart, REQ-CFG-RELOAD). An unlock group that lists itself, or a cycle of mutually dependent prerequisites, is not a load error but can never become eligible, since no group in the cycle can be the first to be awarded.
- REQ-LOCK-IMPLICIT: Item types and miner/assembler recipes are **implicitly** unlocked or locked based on the current set of unlocked ship, module, and assembler recipe schematics. The implicit unlock set is recomputed whenever any schematic changes lock state (on Restart or after REQ-DEF-SCHEMATIC-DROP). Computation:
1. Start with the union of: (a) all item types listed in `materials` across all currently unlocked ship schematics and all currently unlocked module schematics, and (b) the output item type of every assembler recipe that is currently **explicitly available** — that is, either flagged `unlocked_at_start` in `recipes.toml`, or granted by an unlock group that has been awarded (REQ-LOCK-EXPLICIT).
1. Start with the union of: (a) all item types listed in `materials` across all currently unlocked ship schematics and all currently unlocked module schematics, and (b) the output item types of every assembler recipe that is currently **explicitly available** — that is, either flagged `unlocked_at_start` in `recipes.toml`, or granted by an unlock group that has been awarded (REQ-LOCK-EXPLICIT).
2. For each item type in the current set: for every recipe (miner, smelter, or assembler) that produces it — skipping any assembler recipe that is granted by an unlock group whose group has not yet been awarded — add each of that recipe's input item types to the set. If the recipe is a miner recipe, or an assembler recipe that is not granted by any unlock group, mark it as implicitly unlocked. Assembler recipes that are explicitly available (flagged `unlocked_at_start`, or granted by an awarded unlock group) are available in the assembler recipe-selection dialog by virtue of REQ-LOCK-EXPLICIT; their inputs are also added to the implicit set in this step.
3. Repeat step 2 until no new item types are added.
Item types and miner/assembler recipes not reached by this process (and not explicitly unlocked) are locked. Smelter recipes participate in the traversal to propagate unlocking to their inputs but are never themselves shown in any UI dropdown.
Item types and miner/assembler recipes not reached by this process (and not explicitly unlocked) are locked. Smelter recipes participate in the traversal to propagate unlocking to their inputs but are never themselves gated by it: they are not granted by unlock groups either (REQ-LOCK-EXPLICIT), so a Smelter's dialog offers all of them once the building is unlocked (REQ-LOCK-UI-RECIPE, REQ-BLD-AUTO-RECIPE).
- REQ-LOCK-REPROCESSING-POOL: The pool of possible outputs for a Reprocessing Plant cycle (REQ-BLD-REPROCESSING) is restricted to item types that are currently implicitly unlocked (REQ-LOCK-IMPLICIT). Weights are renormalized over the eligible outputs. If no eligible outputs remain, the Reprocessing Plant cannot start a production cycle.
- REQ-LOCK-OUTPUT-POOL: **The choice between output groups is restricted to what the player can use.** Where a recipe has several output groups (REQ-MAT-OUTPUT-GROUP), only groups whose items are **all** currently implicitly unlocked (REQ-LOCK-IMPLICIT) are eligible; a group holding any locked item is dropped whole, since its items are produced together and taking it would hand the player a locked one. Weights are renormalized over the eligible groups, and if none remains the cycle cannot start.
The restriction is on the **choice**, not on production: a recipe with a single group has no choice to restrict and is never tested for eligibility. This distinction is load-bearing rather than an optimization. Implicit unlocking is derived from demand — an item becomes unlocked because something the player can build needs it (REQ-LOCK-IMPLICIT) — so an ordinary recipe's output can be perfectly producible while nothing yet calls for it. Testing eligibility there would not gate a drop, it would stop the building producing at all. In practice this governs the Reprocessing Plant, the only building whose recipes have several groups (REQ-BLD-REPROCESSING).
- REQ-LOCK-UI-RECIPE: Locked miner ore-type recipes and assembler recipes are not shown in their respective recipe-selection dialogs (REQ-UI-SELECT-BUTTON). Smelter and Reprocessing Plant recipes are never granted by an unlock group (REQ-LOCK-EXPLICIT restricts `recipes` grants to assembler recipes), so they are available from the start and their dialogs list them all; what gates them in practice is whether the building itself is unlocked (REQ-LOCK-BUILDING).
@@ -428,9 +437,27 @@ Any ship, module, building, or assembler recipe id that appears in no unlock gro
## UI
### Tooltips
Several UI elements carry a tooltip: the header bar's artifact count (REQ-UI-ARTIFACTS-TOOLTIP), every display that names an item — item chips, inline item values, and recipe summary icons, the header bar's building blocks stock among them (REQ-UI-ITEM-TOOLTIP, REQ-UI-ITEM-VALUE-TOOLTIP), the build button bar's building-type buttons (REQ-UI-BUILD-TOOLTIP) and Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON), the layout configuration dialog's module selection buttons (REQ-MOD-UI-MODULE-TOOLTIP), and the blueprint card's delete icon (REQ-UI-BLUEPRINT-DELETE). Each of those requirements defines what its tooltip says; the first two requirements here define how every one of them is shown and hidden, and the third says which displays carry an item's tooltip without being an item chip. An element not named there describes itself or says nothing: the modal header's close button (REQ-UI-MODAL-CHROME) says what it does by being a close button, and the selection dialog's option buttons describe themselves on their own faces (REQ-UI-SELECT-OPTIONS) — carrying no tooltip of their own, though the items they name still explain themselves (REQ-UI-ITEM-VALUE-TOOLTIP).
- REQ-UI-TOOLTIP-TRIGGER: A tooltip is shown by **hovering** the element it belongs to, after the usual short hover delay. On an element that has **no click action of its own** it is in addition shown **immediately on left click**, without waiting the delay out. That covers the header bar's building blocks stock display and artifact count and the selection panel's item chips: these display a value and do nothing when clicked, so a click on them is free to mean "tell me what this is", which is quicker than waiting on a hover and is the obvious thing to try. It does not cover elements whose click already does something — the building-type buttons, the Deconstruct button, and the module selection buttons — whose tooltips are reached by hovering alone, so that one gesture never both acts and explains. Nor does it cover an item named on such a control (REQ-UI-ITEM-VALUE-TOOLTIP): the click there belongs to the control, whatever the pointer is resting on. Only the left mouse button shows a tooltip; the right and middle buttons never do. Clicking an element whose tooltip is already up leaves it up.
- REQ-UI-TOOLTIP-DISMISS: A tooltip stays visible until the pointer leaves **both the tooltip and the element it belongs to**, however it was triggered. It does **not time out**: there is no display duration after which it vanishes on its own, so a tooltip listing several recipe lines (REQ-UI-ITEM-TOOLTIP) can be read at whatever pace the player needs. The tooltip is itself part of the area that keeps it open — moving the pointer off the element and onto the tooltip does not hide it — which is what fixes where it is placed: its **top-left corner sits at the pointer**, at the position the pointer had the moment the tooltip was triggered. The pointer therefore starts on the tooltip's own corner and reaches the rest of it without crossing a gap. A tooltip that would run off the screen is pushed back onto it, which only moves it further over the pointer. **A tooltip whose element moves goes with it**, holding the place it was given in relation to that element rather than the place it was given on the screen: the expansion button rides the scrolling world (REQ-UI-EXPAND-BUTTON), and a tooltip left standing where the button used to be reads as belonging to nothing. Moving with it is also what ends it, without any rule of its own — the element travels out from under the pointer and takes the tooltip along, and once the pointer is on neither, the tooltip hides. Nothing else dismisses it, and nothing else needs to: a click elsewhere is a click the pointer has already travelled to, so the tooltip is gone before it lands.
- REQ-UI-ITEM-VALUE-TOOLTIP: **Wherever the UI names an item, that spot explains the item.** An item is named by its icon, and it is named in three forms (REQ-UI-ITEM-ICON): as an **item chip**, as a **value** — a number followed by the bare inline icon standing in for the item's name — and as an **icon on its colored square within a recipe summary** (REQ-UI-RECIPE-SUMMARY), each with its per-cycle amount. All three show that item's production tooltip (REQ-UI-ITEM-TOOLTIP). The player can therefore ask what an item is wherever it is named, rather than only where it happens to be drawn as a chip.
The **whole value carries the tooltip** — the amount and the icon together, in every form: the two are one statement, and an icon alone is a target no taller than a line of text. Nothing else on the line is part of it: the caption beside a value (`Remaining`, `Total cost`) describes the number rather than the item, and a recipe summary's arrow, separators and cycle time belong to no item at all. None of these displays has a click action of its own, so a click shows the tooltip at once, as it does on a chip (REQ-UI-TOOLTIP-TRIGGER). This covers the header bar's building blocks stock (REQ-UI-BLOCKS-ICON), the building multi-selection's total cost (REQ-UI-MULTI-SELECTION), the remaining scrap of the debris panel and the field multi-selection (REQ-UI-DEBRIS-PANEL, REQ-UI-FIELD-MULTI-SELECTION), every input and output icon of the selection panel's recipe summary, a Shipyard's schematic materials included (REQ-UI-RECIPE-SUMMARY), and the layout configuration dialog's build cost line, which states a ship's materials in that same form (REQ-MOD-UI-DIALOG). For a value it holds whether or not the icon file exists: where a missing icon leaves the fallback text (`Stock: <n> Blocks`, `Scrap remaining`), the value still states an amount of an item and still explains it.
**An item named on something that already carries a tooltip of its own carries none.** One display shows one tooltip, and the one it was given for its own sake is the one that wins: the building block cost on a build button says nothing about blocks, because the button is there to explain the building (REQ-UI-BUILD-COST, REQ-UI-BUILD-TOOLTIP). The module selection buttons are excluded on the same ground even though a module without a `modules.toml` description leaves its button silent (REQ-MOD-UI-DIALOG, REQ-MOD-UI-MODULE-TOOLTIP): the button is a described control by design, and whether one module happens to carry the text is a gap in the config rather than a decision about the UI — the same material icon must not explain itself on one button and not on the one beside it.
**Everywhere else the item is explained, on a clickable control or not**: the asteroid expansion button's cost line (REQ-UI-EXPAND-BUTTON), the blueprint cards' costs (REQ-UI-BLUEPRINT-CARD), the recipe summaries on the selection dialog's option buttons (REQ-UI-SELECT-OPTIONS), and the recipe lines of the unlock-choice dialog's options (REQ-DEF-SCHEMATIC-DROP). These say what they do and nothing about the items they name, and the two answers do not compete: an option button says what a recipe makes, an item tooltip says where an input comes from.
**On a clickable control the tooltip shows on hover only.** The click belongs to the control — it buys the expansion, picks the blueprint, selects the recipe — so it cannot also be the gesture that explains (REQ-UI-TOOLTIP-TRIGGER). A click shows the tooltip at once wherever the item is named on something with no click action of its own: an item chip, a value in a row, the selection panel's recipe summary, and the recipe lines of an unlock-choice option, whose card is chosen through a button of its own rather than by being clicked (REQ-DEF-SCHEMATIC-DROP).
**An item named inside a tooltip carries none either.** The recipe lines of the item production tooltip name items as a recipe summary does, but a tooltip opened from a tooltip would replace the one being read, since only one is ever on screen and the pointer holds up only what it rests on (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS).
### Layout
The screen is a single column: a header bar across the top and the game world view filling the whole area below it. There is no side panel. All three permanent UI widgets float over the game world — the build button bar (REQ-UI-BUILD-BAR) at its bottom center, the selection panel (REQ-UI-SELECTION-PANEL) beside whatever is currently selected — or wherever the player has dragged it by its header (REQ-UI-SELECTION-PANEL-DRAG) — shown only while something is selected and holding its place on the screen until the next selection, and the controls panel (REQ-UI-CONTROLS-PANEL) in its bottom-left corner, beside the build button bar and rising above it only when the two would overlap. Blueprints have no permanent screen real estate; they are reached through modal dialogs (REQ-UI-BLUEPRINT-DIALOG):
The screen is a single column: a header bar across the top and the game world view filling the whole area below it. There is no side panel. All three permanent UI widgets float over the game world — the build button bar (REQ-UI-BUILD-BAR) at its bottom center, the selection panel (REQ-UI-SELECTION-PANEL) beside whatever is currently selected — or wherever the player has dragged it by its header (REQ-UI-SELECTION-PANEL-DRAG) — shown only while something is selected and holding its place on the screen until the next selection, and the controls panel (REQ-UI-CONTROLS-PANEL) in its bottom-left corner, beside the build button bar and rising above it only when the two would overlap. Each of the three keeps a place on the screen; the asteroid expansion button (REQ-UI-EXPAND-BUTTON) floats over the world as well but keeps a place in the **world** instead, standing on the ground it would buy and panning away with it, which is why it is not drawn below. Blueprints have no permanent screen real estate; they are reached through modal dialogs (REQ-UI-BLUEPRINT-DIALOG):
```
+-----------------------------------------------------------+
@@ -448,39 +475,60 @@ The screen is a single column: a header bar across the top and the game world vi
(full window width)
```
- REQ-UI-HEADER: The header bar spans the full width of the game window and always shows the elapsed survival time, the current global building blocks stock, and the artifact count (REQ-WIN-ARTIFACT-COUNT) displayed as `Artifacts: x/y` (where `x` is the current artifact count and `y` is `world.toml [world].artifact_win_count`) on the left, the boss wave counter and boss countdown (REQ-UI-BOSS-STATUS) and an asteroid expansion button (REQ-UI-EXPAND-BUTTON) to the left of the speed buttons, and game speed controls on the right.
- REQ-UI-BLOCKS-ICON: In the header bar (REQ-UI-HEADER), the global building blocks stock is displayed as `Stock: <n>` followed by the `building_block` item icon (REQ-UI-ITEM-ICON) — e.g. `Stock: 200` then a small block icon — replacing the `Building Blocks: <n>` text label. The icon is sized to the header text height. When no icon file exists for `building_block` (a missing icon is not an error, REQ-UI-ITEM-ICON), the display falls back to the `Stock: <n> Blocks` text. The hover tooltip (REQ-UI-BLOCKS-TOOLTIP) applies in either form.
- REQ-UI-BLOCKS-TOOLTIP: The header bar's building blocks stock display (REQ-UI-HEADER) shows a hover tooltip with the descriptive text defined in `world.toml [world].building_blocks_tooltip` — intended to tell the player what building blocks are used for and how to obtain them. If the field is unset, the stock display shows no tooltip. This tooltip is distinct from the build/module button tooltips (REQ-UI-BUILD-TOOLTIP, REQ-MOD-UI-MODULE-TOOLTIP).
- REQ-UI-ARTIFACTS-TOOLTIP: The header bar's artifact count display (REQ-UI-HEADER) shows a hover tooltip with the descriptive text defined in `world.toml [world].artifact_tooltip` — intended to tell the player what artifacts are, how they are obtained (REQ-DEF-SCHEMATIC-DROP), and that collecting `world.toml [world].artifact_win_count` of them wins the game (REQ-WIN-ARTIFACT-COUNT). If the field is unset, the artifact count display shows no tooltip. This tooltip is distinct from the building blocks tooltip (REQ-UI-BLOCKS-TOOLTIP) and the build/module button tooltips (REQ-UI-BUILD-TOOLTIP, REQ-MOD-UI-MODULE-TOOLTIP).
- REQ-UI-HEADER: The header bar spans the full width of the game window and always shows the elapsed survival time, the current global building blocks stock, and the artifact count (REQ-WIN-ARTIFACT-COUNT) displayed as `Artifacts: x/y` (where `x` is the current artifact count and `y` is `world.toml [world].artifact_win_count`) on the left, the boss wave counter and boss countdown (REQ-UI-BOSS-STATUS) to the left of the speed buttons, and game speed controls on the right. The asteroid expansion button is not among them: it stands in the world on the ground it would buy (REQ-UI-EXPAND-BUTTON).
- REQ-UI-BLOCKS-ICON: In the header bar (REQ-UI-HEADER), the global building blocks stock is displayed as `Stock: <n>` followed by the `building_block` item icon (REQ-UI-ITEM-ICON) — e.g. `Stock: 200` then a small block icon — replacing the `Building Blocks: <n>` text label. The icon is sized to the header text height. When no icon file exists for `building_block` (a missing icon is not an error, REQ-UI-ITEM-ICON), the display falls back to the `Stock: <n> Blocks` text. The display states an amount of an item, so it shows that item's production tooltip in either form (REQ-UI-ITEM-VALUE-TOOLTIP).
- REQ-UI-ARTIFACTS-TOOLTIP: The header bar's artifact count display (REQ-UI-HEADER) shows a tooltip — on hover and, the display having no click action of its own, on click as well (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS) — with the descriptive text defined in `world.toml [world].artifact_tooltip` — intended to tell the player what artifacts are, how they are obtained (REQ-DEF-SCHEMATIC-DROP), and that collecting `world.toml [world].artifact_win_count` of them wins the game (REQ-WIN-ARTIFACT-COUNT). If the field is unset, the artifact count display shows no tooltip. An artifact count is not an amount of an item, so unlike the block stock beside it (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-VALUE-TOOLTIP) it has no production path to show and states configured text instead — the one display in the header bar that does. It is distinct as well from the build/module button tooltips (REQ-UI-BUILD-TOOLTIP, REQ-MOD-UI-MODULE-TOOLTIP).
- REQ-UI-BOSS-STATUS: The header bar displays, to the left of the speed buttons, the current boss wave counter (REQ-WAV-BOSS-COUNTER) and the time remaining on the boss countdown (REQ-WAV-BOSS-COUNTDOWN). The boss wave counter is shown as `Boss Wave #<x>` and the countdown as `Next boss: <M:SS>`, where `<M:SS>` is the remaining seconds formatted as whole minutes and two-digit seconds. Both values update continuously as the simulation runs.
- REQ-UI-SPEED: The game speed controls in the header bar are buttons for 0×, 0.5×, 1×, 2×, and 10× speed. The currently active speed is shown as selected. All game simulation (production, movement, threat accumulation, wave timing) scales with the selected speed. 0× pauses the game.
- REQ-UI-PAUSE-BORDER: While the game is paused (speed 0×, whether set via the speed controls (REQ-UI-SPEED), the Space toggle (REQ-UI-HOTKEYS), or an auto-pausing modal), a vignette border is drawn around the edges of the game world view to make the paused state hard to miss. The border is black and fades in the alpha channel from fully transparent at its inner (center-facing) edge to 50% opacity at the viewport edge, over a thickness of 100 pixels (capped at half the smaller viewport dimension on very small views).
- REQ-UI-DECONSTRUCT-BORDER: While deconstruct mode is active (REQ-UI-DECONSTRUCT-BUTTON, REQ-UI-HOTKEYS), a vignette border is drawn around the edges of the game world view to signal the mode, matching the geometry of the paused-state vignette (REQ-UI-PAUSE-BORDER): a 100-pixel thickness (capped at half the smaller viewport dimension on very small views) with the four sides meeting along mitred corner diagonals. It fades in the alpha channel from fully transparent at its inner (center-facing) edge to the deconstruct tint color at the viewport edge. The color — including its alpha, which sets the peak opacity at the viewport edge — is read from `visuals.toml [overlays].deconstruct_tint`, the same deconstruct-mode color used for the hover tint. The border is presentation-only and has no effect on the simulation. If the game is both paused and in deconstruct mode, both vignettes are drawn and compose over each other.
- REQ-UI-EXPAND-BUTTON: The header bar shows an asteroid expansion button captioned `Expand: <x>` followed by the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON) in place of the trailing `Blocks` word, where `<x>` is the current expansion cost computed from `world.toml [expansion].cost_building_blocks_formula` at the current number of purchased expansions (REQ-EXP-COST). When no icon file exists for `building_block`, the caption falls back to the `Expand: <x> Blocks` text. Clicking the button unlocks the next asteroid expansion (REQ-EXP-UNLOCK, REQ-GW-ASTEROID-EXPAND), spending that many building blocks from the global stock. The button is disabled when the player cannot currently afford the cost (consistent with REQ-UI-BUILD-DISABLED). The caption updates as the cost changes with each purchased expansion.
- REQ-UI-EXPAND-BUTTON: **The asteroid expansion button stands on the ground it would buy.** It is not a fixed control in the header bar: it floats over the game world view (REQ-UI-WORLD-SIZE) **centered on the columns the next expansion unlocks** — the `world.toml [expansion].columns_per_expansion_tiles` locked columns immediately left of the buildable edge (REQ-UI-LOCKED-ASTEROID, REQ-GW-ASTEROID-EXPAND). That is a position in the world, not on the screen, so the button **pans with the view** (REQ-UI-SCROLL) as the tiles beneath it do, and leaves the view entirely when they do: it is part of that piece of ground rather than a control the screen always carries. Nothing brings it back while the player looks elsewhere, and nothing needs to — the pan limit keeps the columns it stands on within reach at all times, since the leftmost pan centers the buildable edge and those columns lie just left of it (REQ-GW-SCROLL-LIMIT). The middle of those columns is the middle of the view vertically, the asteroid running the world's full height (REQ-GW-HEIGHT, REQ-GW-TILE-SIZE).
The button keeps its size from its face rather than filling the columns it marks, and that face is **two lines**: `Expand` on the first, and the cost on the second as `<x>` followed by the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON) in place of a trailing `Blocks` word, where `<x>` is the current expansion cost computed from `world.toml [expansion].cost_building_blocks_formula` at the current number of purchased expansions (REQ-EXP-COST). When no icon file exists for `building_block`, the second line falls back to the `<x> Blocks` text. Two lines rather than one caption because the cost is then a display of its own: **the cost line is what carries the item production tooltip**, as every other value stating an amount of an item does (REQ-UI-ITEM-VALUE-TOOLTIP), on hover only — the click is the button's. The word `Expand` carries nothing; it names the action, not an item. Clicking it unlocks the next asteroid expansion (REQ-EXP-UNLOCK, REQ-GW-ASTEROID-EXPAND), spending that many building blocks from the global stock. The button is disabled when the player cannot currently afford the cost (consistent with REQ-UI-BUILD-DISABLED). Its caption and position both update with each purchased expansion: the cost rises and the button moves a further `columns_per_expansion_tiles` to the left, onto the next stretch of locked ground.
- **Input.** Mouse events over the button are consumed by it and never reach the game world, as they are over the floating panels (REQ-UI-BUILD-BAR, REQ-UI-SELECTION-PANEL): hovering it shows no builder-mode ghost on the tile beneath, and clicking it neither places a building nor changes the selection. Unlike those panels it is not part of their placement pass (REQ-UI-SELECTION-PANEL), and they do not step around it: the button marks a place in the world, so a panel may cover it as it covers any other world content.
- REQ-UI-WORLD-SIZE: The game world view occupies the full width of the game window and the full height below the header bar. No widget insets it: the build button bar (REQ-UI-BUILD-BAR), the selection panel (REQ-UI-SELECTION-PANEL), and the controls panel (REQ-UI-CONTROLS-PANEL) float over it.
- REQ-UI-SELECTION-PANEL: The **selection panel** (the panel described under Selection Panel, REQ-UI-SINGLE-SELECTION and following) is a widget that **floats over the game world view** (REQ-UI-WORLD-SIZE), placed **beside the objects it describes** rather than at a fixed corner of the view, so it appears where the player is already looking. It is **sized to its content in both width and height**, so it grows and shrinks as the content changes. It keeps the same small margin from the view's edges that it uses as its gap from the selection.
- REQ-UI-SELECTION-PANEL: The **selection panel** (the panel described under Selection Panel, REQ-UI-SINGLE-SELECTION and following) is a widget that **floats over the game world view** (REQ-UI-WORLD-SIZE), placed **beside the objects it describes** rather than at a fixed corner of the view, so it appears where the player is already looking. It is **sized to its content in both width and height**, so it grows and shrinks as the content changes. Two distances shape its placement, and they are deliberately different: a small **edge margin** it keeps from the view's edges and from the widgets it steps around, and a larger **selection gap** of half a tile (REQ-GW-TILE-SIZE) it keeps from the selection itself, so the panel stands clear of the objects it describes instead of touching them. The selection gap applies **horizontally only**, on the side facing the selection; vertically the panel stays level with the selection (see **Vertical placement**).
- **Anchor rectangle.** The panel is placed against the screen rectangle of the selection **at the moment that selection started**: the footprint of the single object selected (a building or construction site, an actor, or a piece of debris), or, when the selection started as a multi-selection (REQ-UI-MULTI-SELECT), the bounding box of all the objects it started with.
- **Side.** The panel goes to the **right** of the anchor rectangle, separated from it by the panel's margin, whenever it fits within the view there. Otherwise it goes to the **left** of the anchor rectangle by that same margin. When it fits on neither side — a bounding box spanning most of the view, or an object too close to an edge — it is placed on whichever side leaves more room and then pushed inside the view. That is the one case in which the panel covers part of the selection.
- **Vertical placement.** The panel's **top edge is aligned with the anchor rectangle's top edge** and it extends downward. Its bottom is limited by the lowest of: the view's bottom edge less the panel's margin; and the top edge, less that margin, of the build button bar (REQ-UI-BUILD-BAR) or the controls panel (REQ-UI-CONTROLS-PANEL) — but each of those two only where the panel's own horizontal extent actually overlaps that widget's current rectangle, so a panel whose column misses them is not shortened by them. Should the panel not fit above that limit, it is shifted up, as far as the view's top margin and no further; if it still does not fit, its height is capped at the space available there and the content scrolls vertically within it.
- **Fixed for the life of the selection.** The anchor rectangle and the side are determined once, when the selection starts, and are not revisited while that selection lasts; the panel's own size is the only thing that may still move it (see **Resizing in place** below). The player may override the resulting position by dragging the panel's header (REQ-UI-SELECTION-PANEL-DRAG); the dragged position then takes the anchor rectangle's and the side's place for the rest of that selection. The panel **keeps its place on the screen** when the player scrolls the view (REQ-UI-SCROLL) and when a selected object moves under it (a selected ship flying away), rather than following the object — which may leave it beside nothing, or beside an object that has left the view entirely. It likewise does not move when the selection is **expanded** by adding objects or reduced by removing them (REQ-UI-MULTI-SELECT), nor when a selected object is destroyed or deconstructed. Starting a **new** selection — clicking a different object, or a box drag that replaces the selection — places the panel anew against the new anchor rectangle.
- **Resizing in place.** Only the anchor rectangle and the chosen side are fixed for the life of the selection (or, once the panel has been dragged, the dragged desired position — REQ-UI-SELECTION-PANEL-DRAG); the panel's geometry is **re-solved from them** whenever its content size changes (a section appearing or disappearing as the selection's state changes), the view is resized, or the build button bar's or controls panel's rectangle changes. Re-solving keeps the two edges the panel was placed by — its top edge, and the edge facing the anchor rectangle (its left edge when it sits to the right of the selection, its right edge when it sits to the left) — so the panel grows away from the selection rather than over it, and it never switches sides for as long as the selection lasts. What re-solving may change is the vertical result: growth that would take the panel outside the view or into either of those two widgets is resolved as in **Vertical placement** above, by shifting it up and capping its height, and a panel that shrinks again regains the room.
- **Side.** The panel goes to the **right** of the anchor rectangle, separated from it by the selection gap, whenever it fits within the view there. Otherwise it goes to the **left** of the anchor rectangle by that same gap. The room a side offers is measured accordingly: from the anchor rectangle's edge to the view's edge, less the selection gap and less the edge margin. When it fits on neither side — a bounding box spanning most of the view, or an object too close to an edge — it is placed on whichever side leaves more room and then pushed inside the view. That is the one case in which the panel covers part of the selection.
- **Vertical placement.** The panel's **top edge is aligned with the anchor rectangle's top edge** and it extends downward. The selection gap plays no part here: the panel's top sits level with the top of the topmost object it describes, the gap separating the two horizontally alone. Its bottom is limited by the lowest of: the view's bottom edge less the edge margin; and the top edge, less that same margin, of the build button bar (REQ-UI-BUILD-BAR) or the controls panel (REQ-UI-CONTROLS-PANEL) — but each of those two only where the panel's own horizontal extent actually overlaps that widget's current rectangle, so a panel whose column misses them is not shortened by them. Should the panel not fit above that limit, it is shifted up, as far as the edge margin at the view's top and no further; if it still does not fit, its height is capped at the space available there and the content scrolls vertically within it.
- **Fixed for the life of the selection.** The anchor rectangle, the selection gap, and the side are determined once, when the selection starts, and are not revisited while that selection lasts; the panel's own size is the only thing that may still move it (see **Resizing in place** below). The gap is therefore half a tile as the tile stood in that moment, and a view resize that changes the tile size (REQ-GW-TILE-SIZE) does not change it: the anchor rectangle it is measured from is a screen rectangle frozen in the same moment, and re-measuring one against a later tile size than the other has no meaning. The player may override the resulting position by dragging the panel's header (REQ-UI-SELECTION-PANEL-DRAG); the dragged position then takes the anchor rectangle's and the side's place for the rest of that selection. The panel **keeps its place on the screen** when the player scrolls the view (REQ-UI-SCROLL) and when a selected object moves under it (a selected ship flying away), rather than following the object — which may leave it beside nothing, or beside an object that has left the view entirely. It likewise does not move when the selection is **expanded** by adding objects or reduced by removing them (REQ-UI-MULTI-SELECT), nor when a selected object is destroyed or deconstructed. Starting a **new** selection — clicking a different object, or a box drag that replaces the selection — places the panel anew against the new anchor rectangle.
- **Resizing in place.** Only the anchor rectangle, the selection gap, and the chosen side are fixed for the life of the selection (or, once the panel has been dragged, the dragged desired position — REQ-UI-SELECTION-PANEL-DRAG); the panel's geometry is **re-solved from them** whenever its content size changes (a section appearing or disappearing as the selection's state changes), the view is resized, or the build button bar's or controls panel's rectangle changes. Re-solving keeps the two edges the panel was placed by — its top edge, and the edge facing the anchor rectangle (its left edge when it sits to the right of the selection, its right edge when it sits to the left) — so the panel grows away from the selection rather than over it, and it never switches sides for as long as the selection lasts. What re-solving may change is the vertical result: growth that would take the panel outside the view or into either of those two widgets is resolved as in **Vertical placement** above, by shifting it up and capping its height, and a panel that shrinks again regains the room.
- **Visibility.** The panel is shown only while at least one object is selected. With an empty selection it is not shown at all (REQ-UI-EMPTY-SELECTION), leaving the full game world view visible.
- **Overlay behavior.** As for the build button bar (REQ-UI-BUILD-BAR): the panel occludes the strip of the game world it covers; the world view itself keeps its full extent and the view's scrolling, ghost rendering, and tile geometry are unaffected. It is drawn above the pause and deconstruct vignettes (REQ-UI-PAUSE-BORDER, REQ-UI-DECONSTRUCT-BORDER), which keep their full band underneath it, and below the modal dim (REQ-UI-MODAL-DIM), which covers the entire game window including the panel. The panel never overlaps the build button bar or the controls panel, because it stays above both wherever their rectangles meet its own; neither of them ever moves on the panel's account (REQ-UI-BUILD-BAR, REQ-UI-CONTROLS-PANEL).
- **Input.** Mouse events over the panel are consumed by the panel and never reach the game world: hovering it shows no builder-mode ghost at the tile beneath, and clicking it neither places a building nor changes the selection. Right-clicking the panel does not exit builder mode (REQ-BLD-BUILDER-MODE) or cancel a belt drag (REQ-BLD-BELT-DRAG). Beside the controls its content offers, the panel's own chrome offers one gesture: the header drag that moves it (REQ-UI-SELECTION-PANEL-DRAG).
- REQ-UI-SELECTION-PANEL-DRAG: **Moving the panel by its header.** The player can move the selection panel by pressing the left mouse button on the panel's **header** (REQ-UI-SELECTION-CARD) and dragging: the panel follows the cursor for the duration of the drag and stays where it is dropped on release. The header is the whole drag handle, and no other part of the panel starts a drag.
- **Desired position, not resolved position.** A drag sets only the panel's **desired top-left corner** in view coordinates. Where the panel actually lands is resolved from that desired position by the rules of REQ-UI-SELECTION-PANEL, exactly as an anchor-derived position is: the panel keeps its margin from the view's edges; its bottom is limited by the top edge, less that margin, of the build button bar (REQ-UI-BUILD-BAR) and of the controls panel (REQ-UI-CONTROLS-PANEL), but each only where the panel's own horizontal extent actually overlaps that widget's current rectangle; and a panel that does not fit above that limit is shifted up as far as the view's top margin and, failing that, capped in height with its content scrolling. The player therefore cannot park the panel over either widget, and neither widget ever moves on the panel's account (REQ-UI-BUILD-BAR, REQ-UI-CONTROLS-PANEL) — stepping around them stays entirely the panel's job.
- **Desired position, not resolved position.** A drag sets only the panel's **desired top-left corner** in view coordinates. Where the panel actually lands is resolved from that desired position by the rules of REQ-UI-SELECTION-PANEL, exactly as an anchor-derived position is: the panel keeps its edge margin from the view's edges; its bottom is limited by the top edge, less that same margin, of the build button bar (REQ-UI-BUILD-BAR) and of the controls panel (REQ-UI-CONTROLS-PANEL), but each only where the panel's own horizontal extent actually overlaps that widget's current rectangle; and a panel that does not fit above that limit is shifted up as far as the edge margin at the view's top and, failing that, capped in height with its content scrolling. The player therefore cannot park the panel over either widget, and neither widget ever moves on the panel's account (REQ-UI-BUILD-BAR, REQ-UI-CONTROLS-PANEL) — stepping around them stays entirely the panel's job.
- **The desired position survives the resolution.** Resolving does not overwrite what the player set: the desired position is retained as dropped, so a panel that had to be shifted up or shortened returns to it as soon as the obstruction stops overlapping it — its content shrinks, the bar's button set changes (REQ-LOCK-BUILDING), the controls panel's context changes, or the view is resized. A desired position that the current view cannot honour at all is likewise kept, so enlarging the window brings the panel back to it.
- **What the drag replaces.** From the first drag on, the desired position replaces the anchor rectangle and the side (REQ-UI-SELECTION-PANEL) for the rest of the current selection; the panel no longer has a side and never switches to one. Re-solving (the **Resizing in place** rule of REQ-UI-SELECTION-PANEL) then keeps the top and left edges of the desired position, in place of the top edge and the edge facing the anchor, so the panel still grows away from where the player put it rather than over it. The panel may be dragged repeatedly; each drag replaces the previous desired position.
- **What the drag replaces.** From the first drag on, the desired position replaces the anchor rectangle and the side (REQ-UI-SELECTION-PANEL) for the rest of the current selection; the panel no longer has a side and never switches to one. The selection gap goes with the anchor rectangle it was measured from and plays no further part: a player who drags the panel onto the selection is free to put it there. Re-solving (the **Resizing in place** rule of REQ-UI-SELECTION-PANEL) then keeps the top and left edges of the desired position, in place of the top edge and the edge facing the anchor, so the panel still grows away from where the player put it rather than over it. The panel may be dragged repeatedly; each drag replaces the previous desired position.
- **Scope: the current selection.** The desired position lasts as long as the selection it was set in — across the panel's own resizing, view resizes, and view scrolling (REQ-UI-SELECTION-PANEL), and across the selection being expanded or reduced (REQ-UI-MULTI-SELECT). Starting a **new** selection discards it: the panel is placed anew against the new anchor rectangle (REQ-UI-SELECTION-PANEL), and the player drags it again if they want it elsewhere.
- **Input.** The drag consumes its mouse events like every other event over the panel (REQ-UI-SELECTION-PANEL): the press, the movement, and the release never reach the game world, so dragging the header neither box-selects (REQ-UI-MULTI-SELECT) nor places belts (REQ-BLD-BELT-DRAG). The drag continues while the cursor moves outside the panel or outside the view, and ends when the left button is released, wherever that happens. A press and release on the header without movement moves nothing and has no other effect.
- **Presentation only.** Moving the panel is not a player command: it never enters the replay stream and has no effect on the simulation, consistent with the controls panel's collapsed state (REQ-UI-CONTROLS-PANEL). The desired position is not saved to disk.
- REQ-UI-PANEL-MODAL: **A modal opened from the selection panel opens on the panel.** A modal the player opens from a control inside the selection panel is placed **centered on the panel's current rectangle** rather than centered on the game window, so it appears where the player is already looking and under the cursor that just clicked the control. This is the same reason the panel itself is placed beside the selection instead of at a fixed corner (REQ-UI-SELECTION-PANEL): a modal centered on the window sends the cursor back across the view and then back again. Two modals are opened from the panel — the recipe/schematic selection dialog (REQ-UI-SELECT-BUTTON), from the selection button; and the layout configuration dialog (REQ-MOD-UI-DIALOG), both from the "Configure" button (REQ-MOD-UI-PREVIEW) and when it opens automatically after a schematic change (REQ-MOD-UI-AUTO-DIALOG).
- **The panel's rectangle as it currently stands.** The modal is centered on where the panel actually is when the modal opens: the position resolved from the anchor rectangle (REQ-UI-SELECTION-PANEL) or, once the player has dragged the panel, the position they dragged it to (REQ-UI-SELECTION-PANEL-DRAG). The panel is always shown when one of these modals opens, since the modal is opened from a control within it (REQ-UI-EMPTY-SELECTION).
- **Kept inside the game window.** Should the modal, centered that way, extend past an edge of the game window, it is pushed back inside; its size is never changed to make it fit. A modal larger than the window in a dimension is instead aligned with the window's top or left edge in that dimension, so the part read first stays visible.
- **Placement is all that changes.** The modal is modal as before, pauses the game and restores the speed on close as before (REQ-UI-SELECT-BUTTON, REQ-MOD-UI-DIALOG), shows the dim over the entire window including the panel it sits on (REQ-UI-MODAL-DIM), and is dismissed the same way. That it covers the panel costs nothing: while it is open the panel is dimmed and takes no input anyway.
- **Kept inside the game window.** Should the modal, centered that way, extend past an edge of the game window, it is pushed back inside. A modal that cannot fit the window in a dimension is aligned with the window's top or left edge in that dimension, so the part read first stays visible, and the content that does not fit is reached by scrolling within the modal rather than by the modal growing past the window (REQ-UI-MODAL-CHROME).
- **Placement is all that changes.** The modal is modal as before, pauses the game and restores the speed on close as before (REQ-UI-SELECT-BUTTON, REQ-MOD-UI-DIALOG), shows the dim over the entire window including the panel it sits on (REQ-UI-MODAL-DIM), and is dismissed the same way. That it covers the panel costs nothing: while it is open the panel is dimmed and takes no input anyway — a click on the part of the panel the modal leaves uncovered is a click outside the modal and dismisses it, like any other click beyond its frame (REQ-UI-DIALOG-DISMISS).
- **Only these modals.** Every other modal is placed as before, centered on the game window: the escape menu (REQ-UI-GAME-MENU), the blueprint save and selection dialogs (REQ-UI-BLUEPRINT-CREATE, REQ-UI-BLUEPRINT-DIALOG), and the schematic choice dialog (REQ-DEF-SCHEMATIC-DROP), none of which is opened from the panel. So is a modal opened from another modal rather than from the panel — the Create Blueprint name dialog within the layout configuration dialog (REQ-MOD-UI-BLUEPRINT-CREATE) — which is placed against the modal that opened it.
- **Presentation only.** The placement is computed once, when the modal opens, and is not revisited while it is open; the panel cannot move meanwhile, being behind the modal and receiving no input. It is not a player command, never enters the replay stream, and has no effect on the simulation.
- REQ-UI-MODAL-DIM: While a modal dialog, menu, or full-screen state screen is open on top of the game, a transparent black overlay (a dim/scrim) is drawn over the **entire game window** — the header bar, the game world view, and the widgets floating over it (the build button bar, REQ-UI-BUILD-BAR, the selection panel, REQ-UI-SELECTION-PANEL, and the controls panel, REQ-UI-CONTROLS-PANEL) — behind that modal, so the game reads as inactive while the modal holds focus. The overlay is shown for every modal that auto-pauses the simulation — the escape menu (REQ-UI-GAME-MENU), the recipe/schematic selection dialog (REQ-UI-SELECT-BUTTON), the layout configuration dialog (REQ-MOD-UI-DIALOG), the schematic choice dialog (REQ-DEF-SCHEMATIC-DROP), the blueprint save dialog (REQ-UI-BLUEPRINT-CREATE), and the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) — as well as the game-over screen (REQ-HQ-GAME-OVER) and the win screen (REQ-WIN-SCREEN), which end rather than pause the game. When modals are nested (for example the Create Blueprint name dialog (REQ-MOD-UI-BLUEPRINT-CREATE) opened from the layout configuration dialog), only a single dim is shown over the game window; nested modals do not stack additional overlays. The same applies when one modal hands directly off to another — the blueprint save dialog opening the blueprint selection dialog on confirm (REQ-UI-BLUEPRINT-CREATE): the dim persists across the handoff rather than flickering off and back on, and the simulation is not resumed in between. The dim color and opacity are read from `visuals.toml [overlays]` (a semi-transparent black modal-dim color), consistent with the other overlay colors. The overlay is presentation-only and has no effect on the simulation.
- REQ-UI-MODAL-CHROME: **Every modal the player meets while playing is drawn by the game.** A modal is not an operating-system window: it has no title bar, no window border, and no window-manager close button, and the player can neither move it, resize it, nor drag it out of the game window. It is drawn inside the game window, on the dim that covers that window (REQ-UI-MODAL-DIM), which is the surface it sits on rather than a scrim behind a separate window. This holds for every one of them: the recipe/schematic selection dialog (REQ-UI-SELECT-BUTTON), the layout configuration dialog (REQ-MOD-UI-DIALOG), the blueprint save and selection dialogs (REQ-UI-BLUEPRINT-CREATE, REQ-UI-BLUEPRINT-DIALOG), the Create Blueprint name dialog (REQ-MOD-UI-BLUEPRINT-CREATE), the schematic choice dialog (REQ-DEF-SCHEMATIC-DROP), the escape menu (REQ-UI-GAME-MENU), and the game-over and win screens (REQ-HQ-GAME-OVER, REQ-WIN-SCREEN). One look for all of them, and one place the player's attention stays.
- **Each draws its own header.** Where a modal has a title it is a line the modal draws, as the blueprint selection dialog already draws `Blueprints` (REQ-UI-BLUEPRINT-DIALOG); where it has a close control it is a drawn button, as that dialog's `×` is. A modal without either shows neither — the schematic choice dialog has no way out but choosing (REQ-DEF-SCHEMATIC-DROP), and nothing about being a drawn modal gives it one.
- **It never leaves the window.** A modal is placed inside the game window (REQ-UI-PANEL-MODAL) and stays there. Content too large for the window **scrolls within the modal** rather than extending past the window's edge, so nothing is placed where the player cannot reach it.
- **The exception is failure reporting.** A failure that leaves nothing to draw on — a config file that fails to load at startup or on the reload a Restart performs (REQ-CFG-RELOAD), a blueprint file that cannot be read (REQ-UI-BLUEPRINT-LOAD) — is reported by a plain system message box instead. Such a message must reach the player when the game window is not in a state to host anything, so it cannot be built on the machinery whose failure it is reporting.
- **Presentation only.** How a modal is framed has no effect on the simulation and never enters the replay stream.
- REQ-UI-MODAL-DIM: While a modal dialog, menu, or full-screen state screen is open on top of the game, a transparent black overlay (a dim/scrim) is drawn over the **entire game window** — the header bar, the game world view, and the widgets floating over it (the build button bar, REQ-UI-BUILD-BAR, the selection panel, REQ-UI-SELECTION-PANEL, and the controls panel, REQ-UI-CONTROLS-PANEL) — behind that modal, so the game reads as inactive while the modal holds focus. The modal is drawn on that overlay rather than in a window of its own (REQ-UI-MODAL-CHROME), so the dim is the surface it sits on and not a separate layer that has to be kept in step with it. The overlay is shown for every modal that auto-pauses the simulation — the escape menu (REQ-UI-GAME-MENU), the recipe/schematic selection dialog (REQ-UI-SELECT-BUTTON), the layout configuration dialog (REQ-MOD-UI-DIALOG), the schematic choice dialog (REQ-DEF-SCHEMATIC-DROP), the blueprint save dialog (REQ-UI-BLUEPRINT-CREATE), and the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) — as well as the game-over screen (REQ-HQ-GAME-OVER) and the win screen (REQ-WIN-SCREEN), which end rather than pause the game. When modals are nested (for example the Create Blueprint name dialog (REQ-MOD-UI-BLUEPRINT-CREATE) opened from the layout configuration dialog), only a single dim is shown over the game window; nested modals do not stack additional overlays. The same applies when one modal hands directly off to another — the blueprint save dialog opening the blueprint selection dialog on confirm (REQ-UI-BLUEPRINT-CREATE): the dim persists across the handoff rather than flickering off and back on, and the simulation is not resumed in between. The dim color and opacity are read from `visuals.toml [overlays]` (a semi-transparent black modal-dim color), consistent with the other overlay colors. The overlay is presentation-only and has no effect on the simulation.
- REQ-UI-DIALOG-DISMISS: **An open dialog is dismissed by Q or by a click outside it.** Either gesture does exactly what that dialog's own Cancel or close already does and nothing else, and both reach the same three dialogs. Q is the key that backs the player out in the game world (REQ-UI-HOTKEYS), doing the same on a dialog: a second key alongside Escape rather than a new behavior, so the player backs out of a dialog with the key their hand is already on. The click is the gesture that already puts a thing away by landing beside it — a click on empty world space clears the selection and with it the selection panel (REQ-UI-ENTITY-CLICK-SELECT, REQ-UI-EMPTY-SELECTION) — so a dialog is left the same way, by clicking away from it. The three dialogs that take both:
- **The recipe/schematic selection dialog** (REQ-UI-SELECT-BUTTON) — closes with the current recipe or schematic unchanged.
- **The blueprint selection dialog** (REQ-UI-BLUEPRINT-DIALOG) — closes with no other effect, as its close button does.
- **The layout configuration dialog** (REQ-MOD-UI-DIALOG) — the dismissal is its Cancel, discarding every change made in this dialog session. Here it backs out **one step at a time**, as Q does in the game world: while a module is selected for placement (REQ-MOD-PLACEMENT) it clears that selection, while remove mode is active (REQ-MOD-REMOVE) it leaves remove mode, and only with neither active does it cancel the dialog. A single press or click therefore never both leaves a mode and discards the session — which is what keeps a mis-aimed click outside the frame from costing the player a layout they were in the middle of placing.
In each case the simulation speed is restored as it is on any other close (REQ-UI-SELECT-BUTTON, REQ-MOD-UI-DIALOG, REQ-UI-BLUEPRINT-DIALOG), and a dialog opened from another (REQ-MOD-UI-BLUEPRINT-CREATE) is dismissed before the one that opened it, Q reaching whichever holds focus.
**What counts as a click outside.** A left button press and release that both land outside the dialog's own rectangle. The dialog is modal and dims the whole window (REQ-UI-MODAL-DIM), so "outside" is everything beyond that rectangle without distinction — the dimmed game world, the floating panels, the header bar — including the selection panel a panel-centered modal is sitting on (REQ-UI-PANEL-MODAL). A gesture that *begins* inside the dialog and ends outside it — a scrollbar dragged past the frame, the cursor leaving the layout grid before the button comes up — is not a click outside and dismisses nothing, so no drag can end by discarding the dialog it was made in. Only the left button does this; a right click outside has no effect.
**The click is spent on the dismissal.** It closes the dialog and does nothing to whatever it landed on: it selects no building and clears no selection, presses no button, and places nothing. The window behind a modal takes no input while the modal is open, and dismissing the modal does not turn that click into one — the player clicks away once to close, and again if they then want to act on what is underneath.
**Where neither gesture is a dismissal.** Q stays an ordinary character in the two dialogs that take a typed name — the blueprint save dialog (REQ-UI-BLUEPRINT-CREATE) and the Create Blueprint name dialog of the layout configuration dialog (REQ-MOD-UI-BLUEPRINT-CREATE) — where a dismissal key would be unable to tell a name from a command; a click outside them dismisses nothing either, for the related reason that a half-typed name is work in progress that no stray gesture may discard. They are left by their own Cancel or Escape. While one of them holds focus nothing behind it is dismissible either: the dialog that opened it becomes reachable again only once the one on top is gone. The escape menu (REQ-UI-GAME-MENU) keeps Escape and its Continue button, the game-over and win screens (REQ-HQ-GAME-OVER, REQ-WIN-SCREEN) are ended by their own buttons, and the schematic choice dialog is not dismissible at all — by key, by click outside, or otherwise (REQ-DEF-SCHEMATIC-DROP).
### Game World
@@ -492,7 +540,7 @@ The screen is a single column: a header bar across the top and the game world vi
Because the contest-zone boundaries shift as the scrollable area grows with each push (REQ-GW-PUSH-EXPAND, REQ-GW-SCROLL-LIMIT), the ramp bands are recomputed from the current contest-zone boundaries. This is a presentation-only concern and does not affect the simulation, consistent with REQ-UI-NO-ZOOM.
- REQ-UI-WORLD-ICON: In the game world, a building is drawn with an icon's glyph symbol centered on its footprint, in place of the letter identity glyph. The icon is an SVG loaded from `data/icons/buildings/`; only the icon's glyph is drawn in the world — in a contrasting ink (white over dark fills, dark over light fills) so it stays legible — and its colored chip background is omitted, because the footprint is already filled with the building's `visuals.toml` fill color. This applies to the production buildings (Miner, Smelter, Assembler, Reprocessing Plant, Shipyard, Salvage Bay), the HQ, and the player and enemy defence stations, wherever the identity label appears: operational buildings, construction sites (REQ-UI-CONSTRUCTION-PROGRESS), and the builder-mode and blueprint-placement ghosts. **Belts, splitters, and tunnels are excluded** — they keep their existing tile rendering so their orientation and flow stay readable (a centered icon would obscure direction). Their build-menu buttons still use icons (REQ-UI-BUILD-ICON); in particular the shared Tunnel button's `tunnel_entry.svg` is a build-button icon only, not a world icon. The directional output-port glyphs (REQ-UI-PORT-GLYPH, REQ-UI-PORT-TARGET-GLYPH) are a separate indicator and are unaffected. A building or station with no icon file falls back to its `visuals.toml` text glyph; a type with neither icon nor glyph shows no identity label. A missing icon is not an error, consistent with REQ-UI-BUILD-ICON.
- REQ-UI-ITEM-ICON: In the game world, an item is drawn as its `visuals.toml` colored square (`fill` + `outline`, the square of REQ-GW-TILE-SIZE) carrying its **item icon** on top. The square is drawn for every item, with or without an icon: it is what gives the item contrast against the tile beneath it, and its outline is what separates neighbouring items where they overlap on a belt. The icon is a self-contained, full-color SVG (rendered as-is, unlike the glyph-only building icons of REQ-UI-WORLD-ICON), loaded at runtime from `data/icons/items/` — a sibling of the config directory, read the same way as the building icons (REQ-UI-BUILD-ICON) — one file per item type named after the item's id (e.g. `iron_ore.svg`). The square fills the item's half-tile rect, keeping the size, spacing, and draw-order rules of REQ-GW-TILE-SIZE; the icon is drawn **inset** within that rect so a frame of the square's color stays visible all around it — required because each icon's viewBox is cropped tight to its artwork, so an icon drawn at the full rect would cover the square entirely. This applies wherever an item is drawn: on belts, splitters, and tunnel ends, and while emerging from or sinking into a building port (REQ-MAT-OUTPUT-EMERGE, REQ-MAT-INPUT-INTAKE). An item type with no icon file shows the colored square alone; a missing icon is not an error, consistent with REQ-UI-BUILD-ICON. **The colored square travels with the icon into the UI.** Wherever the UI displays an item *as an item* — the selection panel's item chips (REQ-UI-SINGLE-SELECTION, REQ-UI-HQ-PANEL), the recipe summary's input and output icons (REQ-UI-RECIPE-SUMMARY), and those same icons wherever a recipe is drawn in that form: on the selection dialog's option buttons (REQ-UI-SELECT-OPTIONS), in the item production tooltip (REQ-UI-ITEM-TOOLTIP), and in the unlock-choice dialog's recipe lines (REQ-DEF-SCHEMATIC-DROP) — the icon is drawn on that same square, by the same rules: the item's `fill` and `outline` from `visuals.toml`, the icon inset within the square so a frame of the square's color stays visible all around it, and the square alone when the item has no icon file. The square fills the rect the display allots to the icon, as it fills the half-tile rect in the world. One item therefore reads the same in a panel as it does on a belt. The one exception is an **inline icon standing in for the item's name beside a number** on a line of text: the `building_block` icon in place of the word `Blocks` (REQ-UI-BLOCKS-ICON, REQ-UI-EXPAND-BUTTON, REQ-UI-BUILD-COST, REQ-UI-MULTI-SELECTION, REQ-UI-BLUEPRINT-CARD), and the `scrap` icon in place of the word `Scrap` in the debris panel's remaining-scrap value (REQ-UI-DEBRIS-PANEL, REQ-UI-FIELD-MULTI-SELECTION). There the icon is a decoration on a line of text rather than an item display: it is drawn bare, without the square, and sized to the height of the text it sits in. Where the same value is instead shown *as an item* it keeps the square, as the HQ's block stock chip does beside the header bar's bare block icon (REQ-UI-HQ-PANEL). For performance, each item icon is rasterized to a pixmap cached per target pixel size — re-rasterized only when the tile pixel size changes (e.g. on view resize) — rather than re-rendered from vector every frame.
- REQ-UI-ITEM-ICON: In the game world, an item is drawn as its `visuals.toml` colored square (`fill` + `outline`, the square of REQ-GW-TILE-SIZE) carrying its **item icon** on top. The square is drawn for every item, with or without an icon: it is what gives the item contrast against the tile beneath it, and its outline is what separates neighbouring items where they overlap on a belt. The icon is a self-contained, full-color SVG (rendered as-is, unlike the glyph-only building icons of REQ-UI-WORLD-ICON), loaded at runtime from `data/icons/items/` — a sibling of the config directory, read the same way as the building icons (REQ-UI-BUILD-ICON) — one file per item type named after the item's id (e.g. `iron_ore.svg`). The square fills the item's half-tile rect, keeping the size, spacing, and draw-order rules of REQ-GW-TILE-SIZE; the icon is drawn **inset** within that rect so a frame of the square's color stays visible all around it — required because each icon's viewBox is cropped tight to its artwork, so an icon drawn at the full rect would cover the square entirely. This applies wherever an item is drawn: on belts, splitters, and tunnel ends, and while emerging from or sinking into a building port (REQ-MAT-OUTPUT-EMERGE, REQ-MAT-INPUT-INTAKE). An item type with no icon file shows the colored square alone; a missing icon is not an error, consistent with REQ-UI-BUILD-ICON. **The colored square travels with the icon into the UI.** Wherever the UI displays an item *as an item* — the selection panel's item chips (REQ-UI-SINGLE-SELECTION, REQ-UI-HQ-PANEL), the recipe summary's input and output icons (REQ-UI-RECIPE-SUMMARY), and those same icons wherever a recipe is drawn in that form: on the selection dialog's option buttons (REQ-UI-SELECT-OPTIONS), in the item production tooltip (REQ-UI-ITEM-TOOLTIP), and in the unlock-choice dialog's recipe lines (REQ-DEF-SCHEMATIC-DROP) — the icon is drawn on that same square, by the same rules: the item's `fill` and `outline` from `visuals.toml`, the icon inset within the square so a frame of the square's color stays visible all around it, and the square alone when the item has no icon file. The square fills the rect the display allots to the icon, as it fills the half-tile rect in the world. One item therefore reads the same in a panel as it does on a belt. The one exception is an **inline icon standing in for the item's name beside a number** on a line of text: the `building_block` icon in place of the word `Blocks` (REQ-UI-BLOCKS-ICON, REQ-UI-EXPAND-BUTTON, REQ-UI-BUILD-COST, REQ-UI-MULTI-SELECTION, REQ-UI-BLUEPRINT-CARD), and the `scrap` icon in place of the word `Scrap` in the debris panel's remaining-scrap value (REQ-UI-DEBRIS-PANEL, REQ-UI-FIELD-MULTI-SELECTION). There the icon is a decoration on a line of text rather than an item display: it is drawn bare, without the square, and sized to the height of the text it sits in. It still stands in for the item's name, so the value it sits in explains that item as an item chip does, unless it sits inside a button (REQ-UI-ITEM-VALUE-TOOLTIP). Where the same value is instead shown *as an item* it keeps the square, as the HQ's block stock chip does beside the header bar's bare block icon (REQ-UI-HQ-PANEL). For performance, each item icon is rasterized to a pixmap cached per target pixel size — re-rasterized only when the tile pixel size changes (e.g. on view resize) — rather than re-rendered from vector every frame.
- REQ-UI-CONSTRUCTION-PROGRESS: Construction sites display the building's identity symbol centered on the footprint (same as an operational building) — its icon glyph, or the text glyph as a fallback (REQ-UI-WORLD-ICON). Below the symbol — or centered on the footprint if the building has neither an icon nor a glyph — a construction progress percentage is shown (integer, e.g. `42%`), increasing from 0% to 100% as construction completes.
- REQ-UI-PORT-GLYPH: Every output port of every building is indicated by a directional glyph drawn on the port's tile. The glyph is a `>` rotated to face the port's exit direction (`>` for East, `^` for North, `<` for West, `v` for South). It is drawn at the midpoint between the tile center and the tile edge that the port exits through (i.e. halfway from center toward the exit edge). The indicator is rendered for all building states: operational buildings, construction sites, and the builder-mode ghost. Buildings with multiple output ports (e.g. splitters) show one indicator per port.
- REQ-UI-PORT-TARGET-GLYPH: While in builder mode (REQ-BLD-BUILDER-MODE), the builder-mode ghost additionally shows, for each of the building's output ports, a directional glyph drawn centered in the port's **target cell** — the cell immediately outside the footprint that the port pushes into, i.e. the cell the surface-mask output-port indicator occupies (see Surface Mask Format). As in REQ-UI-PORT-GLYPH the glyph is a `>` rotated to face the port's exit direction (`>` East, `^` North, `<` West, `v` South), previewing where the port's output will go before placement. This is in addition to the on-tile port glyph of REQ-UI-PORT-GLYPH, and — unlike that indicator — is shown only for the builder-mode ghost, not for operational buildings, construction sites, or the blueprint-placement ghost (REQ-UI-BLUEPRINT-PLACE). A building with multiple output ports (e.g. a splitter) shows one target-cell glyph per port. The target-cell glyph is drawn larger than the on-tile port glyph so it stands out as the flow-direction preview. Exceptions: the Tunnel Entry shows no target-cell glyph, because it receives items (which may arrive from any of its non-mouth edges, REQ-BLD-TUNNEL-ENTRY) rather than emitting into a single adjacent cell; the Shipyard shows none either, because its output port is a ship-spawn point (REQ-SHP-SPAWN-PLAYER) rather than a belt-item output (REQ-MAT-OUTPUT-EMERGE).
@@ -506,19 +554,30 @@ The screen is a single column: a header bar across the top and the game world vi
- The Salvage Bay has no recipe and no production cycle (REQ-BLD-SALVAGE-BAY); its status light uses only two states: **green** while its output buffer holds at least one unit of scrap, and **red** while its output buffer is empty. The Salvage Bay's status light is never grey or yellow.
- The four fill colors (grey, green, red, yellow) and the outline color are read from `visuals.toml [status_light]`, consistent with the other rendering-only colors. The status light is presentation-only and has no effect on the simulation.
- REQ-UI-HP-BARS: All entities with HP — the HQ, player and enemy defence stations, and player and enemy ships — render an HP bar below them. The bar is always visible regardless of current HP. The bar's filled portion represents the fraction of current HP to maximum HP.
- REQ-UI-LOCKED-ASTEROID: **The asteroid the player has not unlocked yet is drawn, tinted — and the part of it one purchase away is tinted apart from the rest.** Every asteroid column left of the buildable edge — the edge that moves left with each expansion (REQ-GW-ASTEROID-EXPAND) — is drawn in the asteroid's own fill under a tint, so the player sees the ground expansion will win them rather than empty space. Two tints, both read from `visuals.toml [overlays]`:
- the `world.toml [expansion].columns_per_expansion_tiles` columns immediately left of the buildable edge — the ones the next purchase unlocks, and the ones the expansion button stands on (REQ-UI-EXPAND-BUTTON) — take **`next_expansion`**;
- everything further left takes **`locked_asteroid`**.
`next_expansion` is the **more transparent** of the two, so the ground one purchase away reads as nearer to being the player's than the ground behind it, and the boundary between them shows exactly how far the next expansion reaches. Both are tints over the same asteroid fill: the distinction is how much of that fill shows through, not a different color of ground. The tinted area has **no left edge of its own**: expansions are unbounded (REQ-EXP-COST prices them but never stops them), so the tint runs as far left as the view reaches. What bounds it in practice is the pan limit (REQ-GW-SCROLL-LIMIT): the view stops with the buildable edge at its center, so the locked area fills the left half of the view at the leftmost pan and no more of it is ever seen. Locked tiles are ground the player cannot build on until they are unlocked (REQ-BLD-PLACE-VALID).
- REQ-UI-NO-ZOOM: The view has a fixed zoom level; the player cannot zoom in or out.
- REQ-UI-HOTKEYS: Global keyboard shortcuts:
- **Space** — toggles pause. Pressing Space pauses (sets speed to 0×) and stores the previously selected non-zero speed; pressing Space again restores that speed.
- **W** — increases game speed by one step in the sequence 0×, 0.5×, 1×, 2×, 10× (no wrap-around past 10×).
- **S** — decreases game speed by one step in the same sequence (no wrap-around past 0×).
- **A / D** — scroll the view left / right (REQ-UI-SCROLL).
- **Q** — context-sensitive. If a build mode is active (builder mode or blueprint placement mode), pressing Q exits it. Otherwise, pressing Q toggles deconstruct mode: it enters deconstruct mode if inactive, or exits deconstruct mode if already active. (See also REQ-UI-DECONSTRUCT-BUTTON for the equivalent button.)
- **Q** — context-sensitive: one key that backs out of whatever the player is currently in, and enters deconstruct mode when they are in nothing. Its cases are evaluated in order:
- A dialog that takes Q is open — Q dismisses it, and the cases below do not apply: the dialog holds focus, and the game world is not what the player is backing out of (REQ-UI-DIALOG-DISMISS).
- A build mode is active (builder mode, blueprint placement mode, or deconstruct mode) — Q exits it.
- Something is selected — Q clears the selection (REQ-UI-EMPTY-SELECTION). The two cases never both apply, a selection and a build mode being mutually exclusive (REQ-UI-SELECTION-EXCLUSIVE); the order is stated only to fix the reading.
- Neither — Q enters deconstruct mode (see also REQ-UI-DECONSTRUCT-BUTTON for the equivalent button, which enters it from any of these states and clears the selection in doing so).
Entering deconstruct mode by keyboard while holding a selection therefore takes two presses — the first clears it, the second enters the mode — whereas the Deconstruct button does it in one click.
- **R / Shift+R** — in builder mode, rotate the ghost counter-clockwise / clockwise (REQ-BLD-ROTATE).
- **C** — create a temporary blueprint from the current selection and enter its placement mode (REQ-UI-BLUEPRINT-TEMP). Has effect only when at least one player-placeable building is selected; otherwise it does nothing.
- **V** — re-enter placement mode for the last temporary blueprint created with C (REQ-UI-BLUEPRINT-TEMP). Does nothing when no temporary blueprint exists.
- **Ctrl+C** — save the current selection as a named blueprint: opens the blueprint save dialog (REQ-UI-BLUEPRINT-CREATE). Has effect only when at least one player-placeable building is selected; otherwise it does nothing.
- **Ctrl+V** — opens the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG), from which a saved blueprint is picked for placement. It is available whenever the game is being played, regardless of the current selection or of which build mode is active, and opens the dialog even when no blueprints are saved yet.
- **Escape** — opens the escape menu (REQ-UI-GAME-MENU). While a blueprint dialog is open, Escape closes that dialog instead (REQ-UI-BLUEPRINT-DIALOG).
- **Escape** — opens the escape menu (REQ-UI-GAME-MENU). While a dismissible dialog is open, Escape closes that dialog instead — the blueprint dialogs (REQ-UI-BLUEPRINT-DIALOG) and the two dialogs Q also dismisses (REQ-UI-DIALOG-DISMISS). The schematic choice dialog is the exception it cannot close (REQ-DEF-SCHEMATIC-DROP).
- **Build mode selection** — pressing a build hotkey activates builder mode for the corresponding building type, equivalent to clicking its build button (REQ-BLD-BUILDER-MODE):
- **1** — Belt, **2** — Splitter, **3** — Tunnel (the unified tunnel build mode, REQ-BLD-TUNNEL-MODE). Hotkey 4 is unused.
- **Shift+1** — Miner, **Shift+2** — Smelter, **Shift+3** — Assembler, **Shift+4** — Shipyard, **Shift+5** — Salvage Bay, **Shift+6** — Reprocessing Plant.
@@ -538,7 +597,7 @@ The screen is a single column: a header bar across the top and the game world vi
### Escape Menu
- REQ-UI-GAME-MENU: Pressing Escape at any time opens the escape menu as a modal dialog and pauses the simulation (sets speed to 0×). On close, the simulation speed is restored to what it was before the menu was opened — so if the game was already paused, it remains paused. The menu contains three buttons:
- REQ-UI-GAME-MENU: Pressing Escape at any time opens the escape menu as a modal dialog drawn by the game (REQ-UI-MODAL-CHROME) and pauses the simulation (sets speed to 0×). On close, the simulation speed is restored to what it was before the menu was opened — so if the game was already paused, it remains paused. The menu contains three buttons:
- **Continue** — closes the menu and returns to the game.
- **Restart** — resets the simulation to its initial state and closes the menu at 1× speed.
- **Quit** — closes the application.
@@ -552,6 +611,9 @@ The panel shows exactly one **content** at a time, picked from the catalog in RE
- REQ-UI-EMPTY-SELECTION: When nothing is selected (no building, construction site, ship, defence station, or piece of debris), the selection panel is not shown at all — it is hidden rather than shown empty, so the full game world view is visible (REQ-UI-SELECTION-PANEL). It reappears as soon as an object is selected.
- REQ-UI-SELECTION-CATEGORIES: **Selection categories and precedence.** Every selectable object belongs to one of two mutually exclusive selection categories: **buildings** (buildings and construction sites) and **field objects** (ships and defence stations — player or enemy — together with debris). A single selection holds objects from only one category at a time. Field objects of different kinds may be selected together (e.g. several ships plus debris, freely mixing player and enemy actors). Buildings are exclusive and take precedence — **buildings win**: selecting a building (by click, Ctrl+click, or a box-drag covering at least one building) clears any field selection and yields a buildings-only selection, and conversely selecting any field object clears any building selection. Point hit-testing prefers a building over a coincident field object, and among field objects prefers an actor (ship or defence station) over a coincident piece of debris (REQ-UI-ENTITY-CLICK-SELECT, REQ-UI-DEBRIS-CLICK-SELECT).
- REQ-UI-SELECTION-EXCLUSIVE: **A selection and a build mode are mutually exclusive.** At any moment the player is either holding a selection or in one of the build modes — builder mode (REQ-BLD-BUILDER-MODE), blueprint placement mode (REQ-UI-BLUEPRINT-MODE), or deconstruct mode (REQ-UI-DECONSTRUCT-BUTTON) — never both. **Entering any build mode clears the selection**, whichever way the mode is entered: a build button, a build hotkey, the Deconstruct button, the Q deconstruct toggle, C, or picking a blueprint card (REQ-UI-HOTKEYS, REQ-UI-BLUEPRINT-TEMP, REQ-UI-BLUEPRINT-DIALOG). Switching directly from one build mode to another therefore has no selection left to clear. The converse direction needs no rule of its own: while a build mode is active there is no gesture that selects — a left click places, marks for demolition, or transfers settings instead (REQ-BLD-BUILDER-MODE, REQ-BLD-DECONSTRUCT-CLICK, REQ-UI-BLUEPRINT-TRANSFER) — so a selection can only be made after the mode is left.
- **A selection is read before it is cleared.** The gestures that act on the selection and then enter a mode capture it first: C builds its temporary blueprint from the selection and only then enters placement mode (REQ-UI-BLUEPRINT-TEMP), and Ctrl+C's save dialog creates its blueprint before the selection dialog it opens can start a placement (REQ-UI-BLUEPRINT-CREATE). Neither loses what it was invoked on.
- **What follows from it.** The selection panel is never shown while a build mode is active, being hidden on an empty selection (REQ-UI-EMPTY-SELECTION), and the world draws no selection outlines there. The controls panel's contexts (REQ-UI-CONTROLS-CONTENT) become a partition of the state rather than a precedence rule: exactly one of General, Selection, Build, Blueprint, and Deconstruct applies, and the Selection context's "no build mode active" clause restates the exclusivity instead of resolving an overlap. Nothing here reaches the simulation — selection and build mode are both presentation state, and clearing a selection is not a player command, never enters the replay stream, and has no effect on the simulation.
- REQ-UI-SELECTION-CARD: **Card structure.** Every panel content is a card with the same three parts, top to bottom:
- **Header** — always shown. It holds the selection's identity symbol on the left — the building's icon glyph (REQ-UI-WORLD-ICON), a ship's schematic color swatch, or the kind symbol of a defence station or piece of debris — the selection's name beside it, and one optional **right slot**. The right slot holds a status indicator (REQ-UI-SELECTION-STATUS), a ship's current behavior (REQ-UI-SHIP-BEHAVIOR), or an object count — never more than one of them; which one applies is stated per content in REQ-UI-SELECTION-CONTENT. The header carries no control of its own, and doubles as the panel's drag handle (REQ-UI-SELECTION-PANEL-DRAG).
- **Configuration group** — the controls that change how the selected object is set up: the recipe/schematic selection control (REQ-UI-SELECT-BUTTON), a shipyard's layout preview and Configure button (REQ-MOD-UI-PREVIEW), and a splitter's output filters (REQ-BLD-SPLITTER). It is shown identically for an operational building and for a construction site of the same type (REQ-BLD-SITE-CONFIG).
@@ -581,34 +643,38 @@ The panel shows exactly one **content** at a time, picked from the catalog in RE
- **Debris** — several pieces of debris and nothing else. Their remaining scrap sums into one value (REQ-UI-DEBRIS-PANEL).
Every other multi-selection falls back to the count summary. In particular a selection mixing a splitter with belts does not aggregate (a splitter carries per-object output filters, which have no aggregate), and neither do several production buildings of one type (per-building buffers and cycle progress have no aggregate).
- REQ-UI-SINGLE-SELECTION: When one building is selected, the panel shows its symbol and name in the header (REQ-UI-SELECTION-CARD), its current recipe or schematic selection (REQ-UI-SELECT-BUTTON) and recipe summary (REQ-UI-RECIPE-SUMMARY) in the configuration group, and its input and output buffer contents in the runtime group. Each buffered item is shown as an **item chip** bearing that item's icon on its colored square (REQ-UI-ITEM-ICON) and its current count, and hovering a chip shows that item's production tooltip (REQ-UI-ITEM-TOOLTIP):
- REQ-UI-SINGLE-SELECTION: When one building is selected, the panel shows its symbol and name in the header (REQ-UI-SELECTION-CARD), its current recipe or schematic selection (REQ-UI-SELECT-BUTTON) and recipe summary (REQ-UI-RECIPE-SUMMARY) in the configuration group, and its input and output buffer contents in the runtime group. Each buffered item is shown as an **item chip** bearing that item's icon on its colored square (REQ-UI-ITEM-ICON) and its current count, and hovering or clicking a chip shows that item's production tooltip (REQ-UI-ITEM-TOOLTIP):
- an **input** chip shows the per-cycle amount below the count (the items consumed per run, e.g. `/ 2 per cycle`), or the count alone when the building has no selected recipe or schematic to give one;
- an **output** chip shows the count against **that item's own** output buffer capacity as `a / b` (REQ-MAT-OUTPUT-BUFFER), with the item's name below. Each output chip therefore stands for one buffer, and a Reprocessing Plant shows one per possible roll.
- an **output** chip shows the count against **that item's own** output buffer capacity as `a / b` (REQ-MAT-OUTPUT-BUFFER), with the item's name below. Each output chip therefore stands for one buffer, and a Reprocessing Plant shows one for every item any of its output groups can produce (REQ-MAT-OUTPUT-GROUP).
Input and output chips form separately captioned sections (REQ-UI-SELECTION-CARD). A section lists a chip for **every item the building's cycle involves**, whether or not the buffer currently holds any: an empty buffer reads `0` rather than its chip disappearing, so the card keeps one shape while the building runs. A section left with no chips at all is not shown. The production section (REQ-UI-PRODUCTION-PROGRESS) sits **between them**, so the card reads in the direction the materials flow: what goes in, what is being made of it, what has come out. For a selected construction site the buffer sections are omitted (REQ-BLD-SITE-CONFIG).
**Only unlocked items are listed.** Should a building's buffers carry an entry for an item the player cannot make yet, it is left out of both sections, consistent with the rest of the UI hiding what is not unlocked yet (REQ-LOCK-UI-RECIPE, REQ-LOCK-UI-SPLITTER).
- REQ-UI-RECIPE-SUMMARY: Below the recipe/schematic selection control, a building running a recipe or schematic shows a one-line **recipe summary**: each input item's icon on its colored square (REQ-UI-ITEM-ICON) with its per-cycle amount and the inputs separated by `+`, an arrow, each output item's icon on its colored square with its per-cycle amount, and the cycle time in seconds. It restates what the building will do without opening the selection dialog, and it is the panel's only display of the cycle time. For a Shipyard the summary is built from the schematic's materials and production time including the placed modules' contributions (REQ-BLD-SHIPYARD, REQ-MOD-STAT-CALC), matching the buffers beneath it. A building with no recipe or schematic selected shows no summary — including an auto-recipe building that has yet to select one (REQ-BLD-AUTO-RECIPE), which shows none until it does and keeps it from then on, so the card does not resize in step with the building's status (REQ-UI-SELECTION-STATUS, REQ-UI-SELECTION-PANEL).
- REQ-UI-RECIPE-SUMMARY: Below the recipe/schematic selection control, a building running a recipe or schematic shows a one-line **recipe summary**: each input item's icon on its colored square (REQ-UI-ITEM-ICON) with its per-cycle amount and the inputs separated by `+`, an arrow, then what the recipe produces, and the cycle time in seconds. The output side lists each item of an output group with its icon and per-cycle amount, the items within a group separated by `+` as the inputs are — they are produced together — and the **groups separated by `/`**, since only one of them happens (REQ-MAT-OUTPUT-GROUP). A recipe with a single group therefore reads exactly as before, and a Reprocessing Plant's reads as the alternatives it is rather than as one combined yield. It restates what the building will do without opening the selection dialog, and it is the panel's only display of the cycle time. Each input and output icon names an item and explains it on hover or click, together with the amount beside it (REQ-UI-ITEM-VALUE-TOOLTIP) — so the summary is also where the player follows a recipe's inputs back to what makes them, without the item having to be in a buffer to be asked about. For a Shipyard the summary is built from the schematic's materials and production time including the placed modules' contributions (REQ-BLD-SHIPYARD, REQ-MOD-STAT-CALC), matching the buffers beneath it. A building with no recipe or schematic selected shows no summary — including an auto-recipe building that has yet to select one (REQ-BLD-AUTO-RECIPE), which shows none until it does and keeps it from then on, so the card does not resize in step with the building's status (REQ-UI-SELECTION-STATUS, REQ-UI-SELECTION-PANEL).
- REQ-UI-PRODUCTION-PROGRESS: For buildings that produce items or ships (miner, smelter, assembler, reprocessing plant, shipyard), the panel's runtime group shows a captioned **production section** between the input and output buffer sections (REQ-UI-SINGLE-SELECTION): a horizontal progress bar filled to the completion of the active production cycle, with that completion beside the caption as an integer percentage (e.g. `72%`), or the text `idle` in place of the percentage and an empty bar when no production cycle is active. The cycle time is shown in the recipe summary (REQ-UI-RECIPE-SUMMARY) rather than repeated here. When no recipe or schematic is selected, the production section is not shown at all.
- REQ-UI-MULTI-SELECT: The player selects multiple objects by box-drag or by Ctrl+clicking individual objects to add or remove them from the selection. Multi-select operates within a single category (REQ-UI-SELECTION-CATEGORIES). A box-drag that covers at least one building selects buildings (any field objects within the box are ignored — buildings win); a box-drag that covers no building but does cover ships, defence stations, or debris selects all of those field objects together (REQ-UI-ENTITY-CLICK-SELECT, REQ-UI-DEBRIS-MULTI-SELECT).
- REQ-UI-MULTI-SELECTION: When multiple buildings are selected and the selection does not aggregate (REQ-UI-SELECTION-AGGREGATE), the panel shows a count summary. Its header names the size of the selection as `<n> buildings` in place of an object name, and carries no symbol and nothing in its right slot. Below it is one row per selected building type — the type's symbol, its name, and the number selected as `x<count>` — one type per row, and no per-building detail. A final row shows the **total building block cost** of the selection, captioned `Total cost` with the value followed by the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON): the sum of each selected building's placement cost (`buildings.toml [[building]].cost`, per REQ-BLD-COST), counting only player-placeable buildings (buildings with a button in the build button bar); non-player-placeable buildings (the HQ and defence stations) are excluded from the total, consistent with the blueprint total (REQ-UI-BLUEPRINT-CARD). Construction sites count at their building type's full placement cost regardless of construction progress.
- **Rectangle geometry.** The box is **not** snapped to tiles: its two corners are the exact world positions the button went down at and the cursor is at now, so the rectangle is drawn where the mouse actually went and follows it pixel by pixel. The corners are held in world coordinates rather than screen ones, so the anchor stays on the spot in the world it was placed on when the view scrolls under a held button (REQ-UI-SCROLL).
- **Coverage.** What the box covers follows the same rectangle, not the tiles it touches. An object that occupies whole tiles — a building, a construction site, a defence station — is covered when the rectangle overlaps any of its body cells, so grazing a building's tile selects it. An object that has a position rather than a footprint — a ship, a piece of debris — is covered when the rectangle contains its centre, so what the player sees enclosed by the rectangle is exactly what the release selects. This is also what makes box and click agree: a click already hit-tests ships and debris against their world positions (REQ-UI-ENTITY-CLICK-SELECT, REQ-UI-DEBRIS-CLICK-SELECT), not against the tile they stand on.
- **When the rectangle appears.** The rectangle is drawn only once the cursor has moved at least **2 pixels** from the position the button went down at — a press alone draws nothing, so a plain click does not flash a rectangle. The threshold is in screen pixels because it only separates a click from a drag, which is a question of hand steadiness. Once shown, the rectangle stays shown for the rest of the drag, including when the cursor comes back to where it started. It is measured against where the anchor sits on screen at that moment, so scrolling the view while the button is held moves no cursor but still crosses the threshold, the box having grown all the same. Below the threshold the gesture is a click, and the box it resolves on release is the **whole tile** the button went down on — that is what makes a click select or mark what it points at (REQ-UI-SELECTION-CATEGORIES, REQ-BLD-DECONSTRUCT-CLICK) rather than the empty rectangle a motionless cursor spans.
- **Rectangle color.** While dragging, the selection rectangle is drawn as an outline in `visuals.toml [overlays].selected_outline` — the same color and config entry as the outline drawn in the world around the objects that end up selected, so the box and the selection it produces read as one thing. **Exception:** while deconstruct mode is active (REQ-UI-DECONSTRUCT-BUTTON, REQ-UI-HOTKEYS), the box drag marks buildings for demolition instead (REQ-BLD-DECONSTRUCT-BOX) and the rectangle is drawn in the deconstruct color — the RGB of `visuals.toml [overlays].deconstruct_tint`, drawn **fully opaque**. That entry's alpha channel governs only the fills it tints (the deconstruct-mode hover tint and queued buildings, REQ-UI-DECONSTRUCT-BORDER, REQ-BLD-DECON-QUEUE) and is not applied to this outline, which would otherwise be too faint to see. The rectangle's geometry is the same in both modes.
- REQ-UI-MULTI-SELECTION: When multiple buildings are selected and the selection does not aggregate (REQ-UI-SELECTION-AGGREGATE), the panel shows a count summary. Its header names the size of the selection as `<n> buildings` in place of an object name, and carries no symbol and nothing in its right slot. Below it is one row per selected building type — the type's symbol, its name, and the number selected as `x<count>` — one type per row, and no per-building detail. A final row shows the **total building block cost** of the selection, captioned `Total cost` with the value followed by the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON) and showing that item's production tooltip (REQ-UI-ITEM-VALUE-TOOLTIP): the sum of each selected building's placement cost (`buildings.toml [[building]].cost`, per REQ-BLD-COST), counting only player-placeable buildings (buildings with a button in the build button bar); non-player-placeable buildings (the HQ and defence stations) are excluded from the total, consistent with the blueprint total (REQ-UI-BLUEPRINT-CARD). Construction sites count at their building type's full placement cost regardless of construction progress.
- REQ-UI-CONFIG-INLINE: Recipe and schematic configuration for a selected building is shown within this panel, in its configuration group (REQ-UI-SELECTION-CARD). Recipe selection (miner, assembler, smelter, reprocessing plant) and schematic selection (shipyard) use the selection button and dialog (REQ-UI-SELECT-BUTTON) rather than an inline control. For shipyards, the panel additionally shows the ship layout preview and "Configure" button below the schematic selection button (REQ-MOD-UI-PREVIEW).
- REQ-UI-SELECT-BUTTON: **Recipe and schematic selection control.** Recipe selection (Miner ore type, Assembler recipe, and the Smelter's and Reprocessing Plant's recipe per REQ-BLD-AUTO-RECIPE) and schematic selection (Shipyard) are each presented in the selection panel as a single **selection button** whose caption is the name of the currently selected recipe or schematic, or a placeholder ("Select recipe" / "Select schematic") when none is selected. Clicking the button opens a modal **selection dialog** that pauses the game (speed set to 0×; on close, the speed is restored to what it was before the dialog was opened) and that opens centered on the selection panel, as every modal opened from the panel does (REQ-UI-PANEL-MODAL). The dialog contains a vertical list of option buttons, one per selectable option, each describing itself (REQ-UI-SELECT-OPTIONS) — only options that are currently unlocked are shown (REQ-LOCK-UI-RECIPE for recipes, REQ-LOCK-UI-SCHEMATIC for schematics). Neither the option buttons nor the selection button carries a tooltip: an option button states what it makes on its own face, and what the building has selected is drawn beneath the selection button as the recipe summary (REQ-UI-RECIPE-SUMMARY), with the production paths of the items involved reachable by hovering the card's item chips (REQ-UI-ITEM-TOOLTIP). Clicking an option button selects that recipe/schematic, closes the dialog, and updates the selection button's caption in the selection panel. The dialog can be dismissed without changing the current selection (e.g. closing it without clicking an option). Selecting a new recipe or schematic has the same effects as before (REQ-MAT-INPUT-BUFFER, REQ-MAT-OUTPUT-BUFFER, REQ-BLD-SHIPYARD).
- REQ-UI-SELECT-OPTIONS: **Option list of the selection dialog.** The selection dialog (REQ-UI-SELECT-BUTTON) lists its options as a **single vertical column** of buttons, one per option, rather than a grid: each button is as wide as the dialog and states what the option does, which needs a line of its own. No option button carries a tooltip — the button face is the whole description, so the player reads every option's inputs, product, and time from the list itself without hovering anything. Should the column be taller than the space the window leaves the dialog — a fully unlocked Assembler offers more options than any window can hold, and a modal is never resized to fit (REQ-UI-PANEL-MODAL) — the list **scrolls** within the dialog rather than the dialog growing past the window.
- A **recipe** option (Miner, Assembler) shows the **recipe name** on its first line and, beneath it, that recipe drawn as the recipe summary line draws it (REQ-UI-RECIPE-SUMMARY): each input item's icon on its colored square with its per-cycle amount, an arrow, each output item's icon with its amount, and the cycle time. A miner recipe consumes nothing, so its line begins at the arrow.
- REQ-UI-SELECT-BUTTON: **Recipe and schematic selection control.** Recipe selection (Miner ore type, Assembler recipe, and the Smelter's and Reprocessing Plant's recipe per REQ-BLD-AUTO-RECIPE) and schematic selection (Shipyard) are each presented in the selection panel as a single **selection button** whose caption is the name of the currently selected recipe or schematic, or a placeholder ("Select recipe" / "Select schematic") when none is selected. Clicking the button opens a modal **selection dialog** that pauses the game (speed set to 0×; on close, the speed is restored to what it was before the dialog was opened) and that opens centered on the selection panel, as every modal opened from the panel does (REQ-UI-PANEL-MODAL). The dialog contains a vertical list of option buttons, one per selectable option, each describing itself (REQ-UI-SELECT-OPTIONS) — only options that are currently unlocked are shown (REQ-LOCK-UI-RECIPE for recipes, REQ-LOCK-UI-SCHEMATIC for schematics). Neither the option buttons nor the selection button carries a tooltip **of its own** — the items they name explain themselves as they do everywhere else (REQ-UI-ITEM-VALUE-TOOLTIP), which is a different question from what the option does: an option button states what it makes on its own face, and what the building has selected is drawn beneath the selection button as the recipe summary (REQ-UI-RECIPE-SUMMARY), with the production paths of the items involved reachable from that summary's own icons and from the card's item chips (REQ-UI-ITEM-TOOLTIP, REQ-UI-ITEM-VALUE-TOOLTIP). Clicking an option button selects that recipe/schematic, closes the dialog, and updates the selection button's caption in the selection panel. The dialog can be dismissed without changing the current selection — by closing it without clicking an option, by Escape, by Q, or by clicking outside it (REQ-UI-DIALOG-DISMISS). Selecting a new recipe or schematic has the same effects as before (REQ-MAT-INPUT-BUFFER, REQ-MAT-OUTPUT-BUFFER, REQ-BLD-SHIPYARD).
- REQ-UI-SELECT-OPTIONS: **Option list of the selection dialog.** The selection dialog (REQ-UI-SELECT-BUTTON) lists its options as a **single vertical column** of buttons, one per option, rather than a grid: each button is as wide as the dialog and states what the option does, which needs a line of its own. No option button carries a tooltip describing the option — the button face is the whole description, so the player reads every option's inputs, product, and time from the list itself without hovering anything. What the button face does not say is where an input comes from, and that the items it names answer themselves, on hover (REQ-UI-ITEM-VALUE-TOOLTIP): the click stays the gesture that picks the option. Should the column be taller than the space the window leaves the dialog — a fully unlocked Assembler offers more options than any window can hold, and a modal is never resized to fit (REQ-UI-PANEL-MODAL) — the list **scrolls** within the dialog rather than the dialog growing past the window.
- A **recipe** option shows the **recipe name** on its first line and, beneath it, that recipe drawn as the recipe summary line draws it (REQ-UI-RECIPE-SUMMARY): each input item's icon on its colored square with its per-cycle amount, an arrow, its output groups with their amounts, and the cycle time. A miner recipe consumes nothing, so its line begins at the arrow.
- A **ship schematic** option (Shipyard) shows the ship's `display_name` on its first line and, beneath it, the icons and quantities of its base required materials (`[ship.schematic].materials`, excluding any module contributions) with the base production time (`[ship.schematic].production_time_seconds`). A ship is not an item and has no icon of its own, so this line names no output: the button's caption is what it produces.
- The `(None)` option shows its text caption alone. On an auto-recipe building it is captioned `(Auto)` instead, because there it does not leave the building idle but returns it to automatic selection (REQ-BLD-AUTO-RECIPE).
- REQ-UI-ITEM-TOOLTIP: **Item production tooltip.** Hovering an item chip in the selection panel — an input or output buffer chip (REQ-UI-SINGLE-SELECTION) or the HQ's block stock chip (REQ-UI-HQ-PANEL) — shows a tooltip telling the player where that item comes from. It has a heading and a body:
- the heading is the **hovered item's name**. For an input chip this is the only place the item is named at all, since such a chip carries a count and no name (REQ-UI-SINGLE-SELECTION).
- the body is the caption `Produced by` followed by one **recipe line** per unlocked recipe that produces the item. A recipe line is a small **card** of two rows: the icon of the building that runs the recipe (REQ-UI-BUILD-ICON) and the recipe's name on the first, and the recipe itself on the second, drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) — each input item's icon on its colored square with its per-cycle amount, the inputs separated by `+`, an arrow, each output item's icon with its amount, and the cycle time. Two rows rather than one because an identity and a cycle read as different things, and a single row of icons, names and numbers runs too long to scan; a card around each because several producers stacked as bare lines read as one field of icons and numbers rather than as separate recipes. A line drawn where its surroundings already frame it — on an option button (REQ-UI-SELECT-OPTIONS), or as the panel's recipe summary — takes no card of its own. An item may have several producers — an iron ingot is smelted from ore, smelted from scrap, and recovered by reprocessing — and the building icon and recipe name are what tell those lines apart and tell the player which building to place for which path.
- REQ-UI-ITEM-TOOLTIP: **Item production tooltip.** Hovering an item chip in the selection panel — an input or output buffer chip (REQ-UI-SINGLE-SELECTION) or the HQ's block stock chip (REQ-UI-HQ-PANEL) — shows a tooltip telling the player where that item comes from. A chip has no click action of its own, so clicking one shows the same tooltip at once (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS). It has a heading and a body:
- the heading is the **chip's item name**. For an input chip this is the only place the item is named at all, since such a chip carries a count and no name (REQ-UI-SINGLE-SELECTION).
- the body is the caption `Produced by` followed by one **recipe line** per unlocked recipe that produces the item. A recipe line is a small **card** of two rows: the icon of the building that runs the recipe (REQ-UI-BUILD-ICON) and the recipe's name on the first, and the recipe itself on the second, drawn as the recipe summary draws it (REQ-UI-RECIPE-SUMMARY) — each input item's icon on its colored square with its per-cycle amount, the inputs separated by `+`, an arrow, its output groups with their amounts, and the cycle time. Two rows rather than one because an identity and a cycle read as different things, and a single row of icons, names and numbers runs too long to scan; a card around each because several producers stacked as bare lines read as one field of icons and numbers rather than as separate recipes. A line drawn where its surroundings already frame it — on an option button (REQ-UI-SELECT-OPTIONS), or as the panel's recipe summary — takes no card of its own. An item may have several producers — an iron ingot is smelted from ore, smelted from scrap, and recovered by reprocessing — and the building icon and recipe name are what tell those lines apart and tell the player which building to place for which path.
**Only recipes the player can run are listed**, consistent with the rest of the UI hiding what the player cannot make yet. What that means differs by building, because only Miner and Assembler recipes are unlocked individually (REQ-LOCK-UI-RECIPE): those are listed once unlocked, while a Smelter's or Reprocessing Plant's recipes (REQ-BLD-SMELTER, REQ-BLD-REPROCESSING) are listed once **their building** is unlocked (REQ-LOCK-BUILDING) — there is no sense in naming a path through a plant the player cannot place. Two cases have no recipe line to show, and each says so in place of the list rather than leaving the tooltip bare:
- **An item no recipe produces at all.** Scrap is salvaged from debris (REQ-RES-DEBRIS-DROP) rather than crafted, so its tooltip reads `Salvaged from debris` in place of the `Produced by` caption and lists nothing beneath it.
- **An item whose every producing recipe is still locked.** The caption stays `Produced by`, and the single line beneath it reads `Undiscovered`: the player is told the item is made somehow, without being shown a path they have not unlocked yet.
The tooltip belongs to item chips only. The selection dialog shows no tooltips at all, its buttons describing themselves (REQ-UI-SELECT-OPTIONS), and the icons of the recipe summary line (REQ-UI-RECIPE-SUMMARY) show none either: they are parts of one line that already describes one recipe, rather than standalone item displays.
Which displays show this tooltip is REQ-UI-ITEM-VALUE-TOOLTIP: item chips, the values that state an amount of an item with a bare inline icon, and the icons of a recipe summary wherever one is drawn — on the option buttons of the selection dialog too, whose faces describe the option and say nothing about its items (REQ-UI-SELECT-OPTIONS). The exceptions are an item named on a display that carries a tooltip of its own, and the recipe lines within this tooltip itself, which are already inside one.
- REQ-UI-BELT-CLEAR: When one or more belt, splitter, tunnel entry, or tunnel exit tiles are selected, the panel's runtime group shows a **"Clear stuck items"** button that removes all items from the selected tiles. Clearing a tunnel entry or exit also discards all items currently in transit through that tunnel (REQ-BLD-TUNNEL-TRANSIT). This can be used to resolve stalled belts, splitters, and tunnels. The button acts on every selected tile, which is why a selection of belts and tunnel ends aggregates into one content rather than a count summary (REQ-UI-SELECTION-AGGREGATE).
- REQ-UI-HQ-PANEL: When the HQ is selected, the panel shows the HQ's **HP** as a bar labelled `current / maximum` (REQ-HQ-STATS, REQ-UI-HP-BARS) and, beneath it, the **global building blocks stock** — the same value as the header bar's stock display (REQ-UI-BLOCKS-ICON), rendered as an item chip (REQ-UI-SINGLE-SELECTION) carrying the `building_block` icon on its colored square — a chip is an item display, so it takes the square even though the header bar's inline block icon does not (REQ-UI-ITEM-ICON, REQ-UI-BLOCKS-ICON), and hovering it shows the item production tooltip as any other chip does (REQ-UI-ITEM-TOOLTIP). The HP comes first, as it does on every card that has it (REQ-UI-SELECTION-CARD). The HQ has no input or output buffers of its own: building blocks delivered by belt go straight into the global stock (REQ-HQ-BELT-INPUT), and showing that stock on the HQ is what tells the player to route blocks there. The HQ has no configuration group and no status indicator (REQ-UI-SELECTION-STATUS), and it is never a construction site.
- REQ-UI-HQ-PANEL: When the HQ is selected, the panel shows the HQ's **HP** as a bar labelled `current / maximum` (REQ-HQ-STATS, REQ-UI-HP-BARS) and, beneath it, the **global building blocks stock** — the same value as the header bar's stock display (REQ-UI-BLOCKS-ICON), rendered as an item chip (REQ-UI-SINGLE-SELECTION) carrying the `building_block` icon on its colored square — a chip is an item display, so it takes the square even though the header bar's inline block icon does not (REQ-UI-ITEM-ICON, REQ-UI-BLOCKS-ICON), and hovering or clicking it shows the item production tooltip as any other chip does (REQ-UI-ITEM-TOOLTIP). The HP comes first, as it does on every card that has it (REQ-UI-SELECTION-CARD). The HQ has no input or output buffers of its own: building blocks delivered by belt go straight into the global stock (REQ-HQ-BELT-INPUT), and showing that stock on the HQ is what tells the player to route blocks there. The HQ has no configuration group and no status indicator (REQ-UI-SELECTION-STATUS), and it is never a construction site.
- REQ-UI-ENTITY-CLICK-SELECT: The player can click any ship (player or enemy) or any defence station (player or enemy) in the game world to select it. A plain click on a ship or defence station makes it the sole selection, clearing any previous selection. Ships and defence stations can be multi-selected — by Ctrl+clicking individual actors to add or remove them, or by box-drag (REQ-UI-MULTI-SELECT) — and can be selected together with debris and with one another in a single field selection (REQ-UI-SELECTION-CATEGORIES), freely mixing player and enemy actors. Actors cannot be selected together with buildings: selecting a ship or defence station clears any building selection, and selecting a building clears the actors (buildings win). Clicking a piece of debris adds to or establishes a field selection (REQ-UI-DEBRIS-CLICK-SELECT). Clicking empty world space (no building, ship, defence station, or piece of debris) clears the selection.
- REQ-UI-SHIP-STATS-PANEL: When exactly one ship is selected (REQ-UI-ENTITY-CLICK-SELECT) and no debris is selected, the selection panel shows a **ship stats panel**. (If debris is also selected, the panel shows the compact count summary instead, per REQ-UI-FIELD-MULTI-SELECTION.) The panel structure mirrors REQ-MOD-UI-STATS-PANEL but reflects the ship's actual live state: stats are computed from its installed modules per REQ-MOD-STAT-CALC. Its header (REQ-UI-SELECTION-CARD) carries the schematic's color swatch and display name, with the ship's current behavior in the right slot (REQ-UI-SHIP-BEHAVIOR). The panel always shows all hull stats: HP (current / maximum) as a **bar** with the two values beside its caption, then max linear speed, sensor range, main acceleration, maneuvering acceleration, angular acceleration, and max rotation speed as label/value rows. In addition, capability module summaries are shown below the hull stats, each as its own outlined row, conditioned on which module types are installed and using the same aggregation rules as REQ-MOD-UI-STATS-PANEL: weapons (combined DPS, maximum range), salvage (combined collection rate, maximum range), and repair (combined repair rate, maximum range), each appearing only if at least one instance of that module type is installed. While debug draw mode is active (REQ-UI-DEBUG-DRAW), the panel additionally shows the ship's derived threat cost (REQ-MOD-THREAT).
- REQ-UI-SHIP-BEHAVIOR: The ship stats panel (REQ-UI-SHIP-STATS-PANEL) additionally displays the selected ship's **current behavior** in its header's right slot (REQ-UI-SELECTION-CARD) — a single label naming the top-priority behavior currently governing the ship's navigation, as resolved by the fixed-priority behavior arbitration. Only the winning behavior is named; lower-priority behaviors that are suppressed are not shown, and neither are the salvage/repair cycles that run regardless of the active behavior (REQ-SHP-SALVAGE, REQ-SHP-REPAIR). The label updates live as the ship's behavior changes, and it is always shown (independent of debug draw mode, unlike the threat-cost line of REQ-UI-SHIP-STATS-PANEL). This applies to both player and enemy ships (REQ-UI-ENTITY-CLICK-SELECT); enemy ships only ever show **Engaging** or **Advancing**. The behavior labels (all wrapped in `tr()`) are:
@@ -620,10 +686,10 @@ The panel shows exactly one **content** at a time, picked from the catalog in RE
- **Standby** — the ship is holding with its fleet (REQ-SHP-STANDBY).
- **Advancing** — the ship is executing the baseline forward advance with no higher-priority behavior active (player: REQ-SHP-COMBAT advance toward the enemy; enemy: REQ-SHP-ENEMY-AI advance toward the asteroid).
- REQ-UI-STATION-STATS-PANEL: When exactly one defence station is selected (REQ-UI-ENTITY-CLICK-SELECT) and no debris is selected, the selection panel shows a **station stats panel** displaying the station's stats computed at its current level: HP (current / maximum) as a **bar** with the two values beside its caption, then damage, range, and fire rate as label/value rows, matching the ship stats panel's rendering (REQ-UI-SHIP-STATS-PANEL). Its header carries no right slot: a station has no behavior label and no status light. (If debris is also selected, the panel shows the compact count summary instead, per REQ-UI-FIELD-MULTI-SELECTION.)
- REQ-UI-FIELD-MULTI-SELECTION: A full single-object stats panel (REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL, REQ-UI-DEBRIS-PANEL) is shown when the field selection holds exactly one object — one ship, one defence station, or one piece of debris — and, for debris only, when it holds several pieces of debris and nothing else, which aggregate into that same content (REQ-UI-SELECTION-AGGREGATE). Every other field selection of more than one object — multiple actors, or any mix of actors and debris — shows a **count summary** instead. Its header reads `Mixed selection` with the total number of selected objects in the right slot (REQ-UI-SELECTION-CARD). Below it is one row per type — the type's symbol, its name, and the number selected as `x<count>`, the same `x`-count notation as the recipe tooltip and the building multi-selection (REQ-UI-MULTI-SELECTION). Ships are grouped by schematic display name and defence stations as a group, distinguishing player from enemy; all selected pieces of debris are grouped into a single `Debris` row whose count is the number of selected pieces. No per-object detail is shown. If debris is part of the selection, its row is followed by an indented sub-row giving the summed remaining scrap across all selected debris as the amount followed by the bare `scrap` icon, exactly as the debris panel states it (REQ-UI-DEBRIS-PANEL, REQ-UI-ITEM-ICON). Building selections use REQ-UI-SINGLE-SELECTION / REQ-UI-MULTI-SELECTION instead.
- REQ-UI-FIELD-MULTI-SELECTION: A full single-object stats panel (REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL, REQ-UI-DEBRIS-PANEL) is shown when the field selection holds exactly one object — one ship, one defence station, or one piece of debris — and, for debris only, when it holds several pieces of debris and nothing else, which aggregate into that same content (REQ-UI-SELECTION-AGGREGATE). Every other field selection of more than one object — multiple actors, or any mix of actors and debris — shows a **count summary** instead. Its header reads `Mixed selection` with the total number of selected objects in the right slot (REQ-UI-SELECTION-CARD). Below it is one row per type — the type's symbol, its name, and the number selected as `x<count>`, the same `x`-count notation as the recipe tooltip and the building multi-selection (REQ-UI-MULTI-SELECTION). Ships are grouped by schematic display name and defence stations as a group, distinguishing player from enemy; all selected pieces of debris are grouped into a single `Debris` row whose count is the number of selected pieces. No per-object detail is shown. If debris is part of the selection, its row is followed by an indented sub-row giving the summed remaining scrap across all selected debris as the amount followed by the bare `scrap` icon, exactly as the debris panel states it and with the same tooltip (REQ-UI-DEBRIS-PANEL, REQ-UI-ITEM-ICON, REQ-UI-ITEM-VALUE-TOOLTIP). Building selections use REQ-UI-SINGLE-SELECTION / REQ-UI-MULTI-SELECTION instead.
- REQ-UI-DEBRIS-CLICK-SELECT: The player can click any piece of debris (REQ-RES-DEBRIS-DROP) in the game world to select it. Debris are field objects (REQ-UI-SELECTION-CATEGORIES) and can be selected together with ships and defence stations, but not with buildings. A plain click on a piece of debris makes it the sole selection, clearing any previous selection; selecting a building clears any debris (buildings win), and selecting a piece of debris clears any building selection. Hit-testing prefers a building over a coincident actor or piece of debris, and an actor (ship or defence station) over a coincident piece of debris: a piece of debris is selected only when no building or actor is under the cursor. A selected piece of debris that despawns or is fully collected (REQ-RES-DEBRIS-DROP) is removed from the selection; if no selected object remains, the panel becomes empty (REQ-UI-EMPTY-SELECTION).
- REQ-UI-DEBRIS-MULTI-SELECT: Multiple pieces of debris can be selected by box-drag or by Ctrl+clicking individual pieces to add or remove them, mirroring building multi-select (REQ-UI-MULTI-SELECT). Debris shares the field-object category with ships and defence stations (REQ-UI-SELECTION-CATEGORIES), so a field selection may hold debris and actors together. Ctrl+clicking a piece of debris while a field selection is active adds or removes that piece within the same selection; Ctrl+clicking a piece of debris while a building selection is active first clears the buildings and begins a field selection (buildings win). Conversely, selecting a building while a field selection is active clears it. Box-drag disambiguation follows REQ-UI-MULTI-SELECT (a box covering any building selects buildings; a box covering no building selects the ships, defence stations, and debris within it).
- REQ-UI-DEBRIS-PANEL: When debris is selected and no actors are (REQ-UI-FIELD-MULTI-SELECTION), the selection panel shows a **debris stats panel** structured like the ship and station stats panels (REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL): a header reading **"Debris"**, followed by a single stat row captioned **"Remaining"**, in the same label/value style as a ship hull stat row. Its value is the scrap amount followed by the `scrap` item icon drawn **bare, without its colored square** and sized to the row's text height — the same inline form the header bar uses for building blocks (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON). The icon stands in for the word `Scrap`, which is why the caption names neither the item nor its unit; when no icon file exists for `scrap` (a missing icon is not an error, REQ-UI-ITEM-ICON), the row falls back to the caption `Scrap remaining` with the amount alone as its value. With one piece selected the row shows that piece's remaining scrap amount (REQ-RES-DEBRIS-DROP) and the header's right slot is empty. With several pieces selected the same content is shown aggregated (REQ-UI-SELECTION-AGGREGATE): the number of selected pieces appears in the header's right slot as `x<count>` and the row shows the summed remaining scrap across them. When debris is selected together with actors, the debris are instead summarized within the count summary (REQ-UI-FIELD-MULTI-SELECTION): a `Debris` row giving the number of selected pieces, followed by an indented sub-row with their summed remaining scrap, stated in the same amount-plus-bare-icon form. The displayed scrap value updates as selected debris are partially collected or despawn (REQ-UI-DEBRIS-CLICK-SELECT).
- REQ-UI-DEBRIS-PANEL: When debris is selected and no actors are (REQ-UI-FIELD-MULTI-SELECTION), the selection panel shows a **debris stats panel** structured like the ship and station stats panels (REQ-UI-SHIP-STATS-PANEL, REQ-UI-STATION-STATS-PANEL): a header reading **"Debris"**, followed by a single stat row captioned **"Remaining"**, in the same label/value style as a ship hull stat row. Its value is the scrap amount followed by the `scrap` item icon drawn **bare, without its colored square** and sized to the row's text height — the same inline form the header bar uses for building blocks (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON). The icon stands in for the word `Scrap`, which is why the caption names neither the item nor its unit and why the value shows the scrap production tooltip — `Salvaged from debris`, for an item no recipe makes (REQ-UI-ITEM-VALUE-TOOLTIP, REQ-UI-ITEM-TOOLTIP); when no icon file exists for `scrap` (a missing icon is not an error, REQ-UI-ITEM-ICON), the row falls back to the caption `Scrap remaining` with the amount alone as its value. With one piece selected the row shows that piece's remaining scrap amount (REQ-RES-DEBRIS-DROP) and the header's right slot is empty. With several pieces selected the same content is shown aggregated (REQ-UI-SELECTION-AGGREGATE): the number of selected pieces appears in the header's right slot as `x<count>` and the row shows the summed remaining scrap across them. When debris is selected together with actors, the debris are instead summarized within the count summary (REQ-UI-FIELD-MULTI-SELECTION): a `Debris` row giving the number of selected pieces, followed by an indented sub-row with their summed remaining scrap, stated in the same amount-plus-bare-icon form. The displayed scrap value updates as selected debris are partially collected or despawn (REQ-UI-DEBRIS-CLICK-SELECT).
### Build Button Bar
@@ -634,9 +700,9 @@ The panel shows exactly one **content** at a time, picked from the catalog in RE
- REQ-UI-BUILD-COST: Each button is **icon-only with a cost**, its face composed of three elements: the button's **hotkey badge** in the top-left corner, the building's icon (REQ-UI-BUILD-ICON) centered below it, and the building block cost centered under the icon, shown with the `building_block` item icon (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON) to the right of the number in place of the trailing `Blocks` word, e.g. `2` then a small block icon. The building name is not shown on the button; it is shown in the button's hover tooltip instead (REQ-UI-BUILD-TOOLTIP). When no icon file exists for `building_block`, the cost is shown as the bare number. The Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON) has no cost and shows its name as a text caption in the cost's place.
- **Hotkey badge.** The badge names the build hotkey that activates the button (REQ-UI-HOTKEYS), so the player can learn the shortcuts from the bar itself. It is rendered dimmer than the cost so it reads as secondary, but at the same size and in bold, because a smaller badge is not legible. A plain-digit hotkey is shown as the bare digit (`1`, `2`, `3`); a Shift+digit hotkey is shown with an upwards arrow prefixed and no separator (`↑1``↑6`); the Deconstruct button shows `Q`. A button whose building type has no build hotkey shows no badge and keeps the same face size, so the row stays even.
- REQ-UI-BUILD-ICON: Each build button shows an icon. Icons are SVG files loaded at runtime from `data/icons/buildings/` (a sibling of the config directory, read the same way as `visuals.toml`), one file per button named after the building's id (e.g. `belt.svg`, `reprocessing_plant.svg`). The shared Tunnel button (REQ-UI-BUILD-BAR) uses `tunnel_entry.svg`; the Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON) uses `deconstruct.svg`. Each icon is a rounded colored "chip" bearing a white line glyph, the chip color following the building's fill color in `visuals.toml`. A missing icon file leaves the button showing its building name as a text caption in place of the icon, so the button stays identifiable in the icon-only bar (REQ-UI-BUILD-COST); it is not an error.
- REQ-UI-BUILD-TOOLTIP: Each building-type button shows a hover tooltip consisting of the building name followed by the descriptive text defined for that building type in `buildings.toml` (the optional per-building tooltip field). Because the button caption is icon-only (REQ-UI-BUILD-COST), the name is always part of the tooltip; if a building type defines no tooltip text, the tooltip shows the name alone. This tooltip is distinct from the item production tooltip of the selection panel's item chips (REQ-UI-ITEM-TOOLTIP); the recipe/schematic selection dialog has no tooltip at all (REQ-UI-SELECT-OPTIONS). The Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON) is not a building type and so has no config-defined tooltip; it instead shows its own refund tooltip defined in REQ-UI-DECONSTRUCT-BUTTON.
- REQ-UI-BUILD-TOOLTIP: Each building-type button shows a hover tooltip — hover only, its click entering builder mode instead (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS) — consisting of the building name followed by the descriptive text defined for that building type in `buildings.toml` (the optional per-building tooltip field). Because the button caption is icon-only (REQ-UI-BUILD-COST), the name is always part of the tooltip; if a building type defines no tooltip text, the tooltip shows the name alone. It is what keeps the block cost on the button face silent, a display carrying only one tooltip and this being the one the button is for (REQ-UI-ITEM-VALUE-TOOLTIP); the item production tooltip of the selection panel's item chips is a different tooltip again (REQ-UI-ITEM-TOOLTIP). The Deconstruct button (REQ-UI-DECONSTRUCT-BUTTON) is not a building type and so has no config-defined tooltip; it instead shows its own refund tooltip defined in REQ-UI-DECONSTRUCT-BUTTON.
- REQ-UI-BUILD-DISABLED: Buttons for buildings the player cannot currently afford are shown as disabled. A disabled button's icon (REQ-UI-BUILD-ICON) is rendered in a greyed variant, with its colored chip background recolored grey while the white glyph is retained.
- REQ-UI-DECONSTRUCT-BUTTON: A dedicated **Deconstruct** button is shown in the build button bar (REQ-UI-BUILD-BAR), as the last entry of the row and **visually separated** from the building-type buttons by a gap (not a divider line), because it toggles a mode rather than selecting a building type. Its face follows REQ-UI-BUILD-COST with two differences: its hotkey badge reads `Q`, and because it has no building block cost it shows its **Deconstruct** name as a text caption where the building-type buttons show their cost — so it is the one labelled button in the bar. It is therefore wider than the building-type buttons, which share a uniform width. Clicking it toggles deconstruct mode on and off, equivalent to the Q deconstruct toggle (REQ-UI-HOTKEYS). The button is shown in a visually active/pressed state while deconstruct mode is active. The button shows a hover tooltip stating the deconstruction refund (REQ-BLD-DECONSTRUCT): that deconstructing a fully-built building returns `world.toml [world].refund_percentage` percent of its building block cost once deconstruction completes, and that a construction site removed before it finishes building is refunded in full. When `refund_percentage` is 100% both cases yield the same refund, and the tooltip is simplified to state the single refund percentage without distinguishing the two cases. Unlike the building-type button tooltips (REQ-UI-BUILD-TOOLTIP), this tooltip is not config-defined text but is composed from the refund percentage.
- REQ-UI-DECONSTRUCT-BUTTON: A dedicated **Deconstruct** button is shown in the build button bar (REQ-UI-BUILD-BAR), as the last entry of the row and **visually separated** from the building-type buttons by a gap (not a divider line), because it toggles a mode rather than selecting a building type. Its face follows REQ-UI-BUILD-COST with two differences: its hotkey badge reads `Q`, and because it has no building block cost it shows its **Deconstruct** name as a text caption where the building-type buttons show their cost — so it is the one labelled button in the bar. It is therefore wider than the building-type buttons, which share a uniform width. Clicking it toggles deconstruct mode on and off; entering the mode clears the selection (REQ-UI-SELECTION-EXCLUSIVE), which is the one way in which it differs from the Q key (REQ-UI-HOTKEYS): Q clears a selection before it enters the mode, so with something selected the button gets there in one click and Q in two. The button is shown in a visually active/pressed state while deconstruct mode is active. The button shows a hover tooltip — hover only, its click toggling the mode instead (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS) — stating the deconstruction refund (REQ-BLD-DECONSTRUCT): that deconstructing a fully-built building returns `world.toml [world].refund_percentage` percent of its building block cost once deconstruction completes, and that a construction site removed before it finishes building is refunded in full. When `refund_percentage` is 100% both cases yield the same refund, and the tooltip is simplified to state the single refund percentage without distinguishing the two cases. Unlike the building-type button tooltips (REQ-UI-BUILD-TOOLTIP), this tooltip is not config-defined text but is composed from the refund percentage.
### Controls Panel
@@ -650,7 +716,7 @@ The controls panel tells the player which controls are available right now. It i
- **Input.** Mouse events over the panel are consumed by the panel and never reach the game world: hovering it shows no builder-mode ghost at the tile beneath, and clicking it neither places a building nor changes the selection. Right-clicking the panel does not exit builder mode (REQ-BLD-BUILDER-MODE) or cancel a belt drag (REQ-BLD-BELT-DRAG). The only control the panel itself offers is the header click that collapses and expands it.
- REQ-UI-CONTROLS-CARD: **Card structure.** The panel is a card with two parts, top to bottom:
- **Header** — always shown, and the panel's only interactive element (REQ-UI-CONTROLS-PANEL). It holds a colored context dot on the left, the context's name beside it in upper case, and, for contexts that define one, a **detail suffix** separated by a middle dot (`BUILD MODE · Assembler`). The name and detail per context are given in REQ-UI-CONTROLS-CONTENT.
- **Rows** — one per available control, shown only while the panel is expanded. Each row is one or more **key badges** on the left — the key or mouse button drawn as a small bordered chip — and a **label** beside them naming what it does. An action reachable two ways carries both badges in the same row (`RMB` `Q` — Exit placement) rather than occupying two rows. A row whose action leaves the current mode is drawn with the destructive badge styling, distinguishing it from the rows that act within the mode. No row is ever drawn greyed or otherwise disabled: a control the player cannot currently use is not shown at all (REQ-UI-CONTROLS-ACCURACY).
- **Rows** — one per available control, shown only while the panel is expanded. Each row is one or more **key badges** on the left — the key or mouse button drawn as a small bordered chip — and a **label** beside them naming what it does. An action reachable two ways carries both badges in the same row (`RMB` `Q` — Exit placement) rather than occupying two rows. A row whose action hands the current context back — leaving a build mode, or clearing the selection (REQ-UI-SELECTION-EXCLUSIVE) — is drawn with the destructive badge styling, distinguishing it from the rows that act within the context; to the player both are the one key that backs out, so both are marked alike. No row is ever drawn greyed or otherwise disabled: a control the player cannot currently use is not shown at all (REQ-UI-CONTROLS-ACCURACY).
The rows that are live in every context (REQ-UI-CONTROLS-CONTENT) are shown last, under a divider and the caption `ALWAYS AVAILABLE`. This holds in every context including the General one, which has context rows of its own above the divider like any other, so the card is read the same way wherever the player is.
- REQ-UI-CONTROLS-CONTENT: **Content catalog.** The control context follows from the active build mode and the selection alone. Build modes are mutually exclusive (REQ-BLD-BUILDER-MODE), so exactly one context applies at any moment:
@@ -659,12 +725,14 @@ The controls panel tells the player which controls are available right now. It i
|---|---|---|---|
| General | no build mode active, nothing selected | `GENERAL` | — |
| Selection | no build mode active, at least one object selected | `SELECTION` | `<n> buildings` or `<n> objects` |
| Build | builder mode active (REQ-BLD-BUILDER-MODE) | `BUILD MODE` | the building type's name |
| Build | builder mode active (REQ-BLD-BUILDER-MODE) | `BUILD MODE` | the name of the building type that would be placed at the hovered position, so in tunnel mode it follows the resolved end and reads `Tunnel Entry` or `Tunnel Exit` (REQ-BLD-TUNNEL-MODE) |
| Blueprint | blueprint placement mode active (REQ-UI-BLUEPRINT-MODE) | `BLUEPRINT MODE` | the blueprint's name, or `Temporary` for a temporary blueprint (REQ-UI-BLUEPRINT-TEMP) |
| Deconstruct | deconstruct mode active (REQ-UI-DECONSTRUCT-BUTTON) | `DECONSTRUCT MODE` | — |
The Selection context's detail counts the selection and names its category (REQ-UI-SELECTION-CATEGORIES): `<n> buildings` for a building selection, `<n> objects` for a field selection, in the singular at a count of one. The Build and Blueprint contexts show **the same rows** and differ only in their header.
**The row that hands the context back is last.** Where a context has one — `Q` — Clear selection in the Selection context, `RMB` `Q` — Exit placement in Build and Blueprint, `RMB` `Q` — Exit deconstruct mode in Deconstruct — it is the final context row, below the rows that act within the context, and it carries the destructive badge styling (REQ-UI-CONTROLS-CARD). The General context has none: with no mode to leave and nothing selected, its `Q` row enters deconstruct mode rather than leaving anything, and is an ordinary row that happens to come last.
**Always-available rows**, shown in every context:
| Badges | Label | Shown |
@@ -687,9 +755,9 @@ The controls panel tells the player which controls are available right now. It i
| | `LMB` drag | Select area |
| | `Ctrl` `LMB` | Add / remove from selection |
| | `Ctrl` `LMB` drag | Add area to selection |
| | `Q` | Deconstruct mode |
| | `C` | Copy to temporary blueprint |
| | `Ctrl` `C` | Create blueprint |
| | `Q` | Clear selection |
| Build, Blueprint | `LMB` | Place |
| | `LMB` drag | Place belt line |
| | `R` / `Shift` `R` | Rotate |
@@ -705,7 +773,6 @@ The controls panel tells the player which controls are available right now. It i
- **`LMB` — Place** reads **Apply settings** instead whenever the ghost under the cursor resolves to a configuration transfer (REQ-UI-BLUEPRINT-TRANSFER) — a single-building blueprint hovering a same-type building of a configurable type, which is the case in which clicking hands over settings rather than placing anything. A blueprint holding more than one building keeps the `Place` label, since its click both places and transfers (REQ-UI-BLUEPRINT-PLACE).
- REQ-UI-CONTROLS-ACCURACY: **The panel never advertises a binding that would do nothing.** Every row shown must, if triggered in the situation the panel is showing it in, have the effect its label names; a binding that is inert in the current context is omitted rather than shown greyed (REQ-UI-CONTROLS-CARD). The relation holds in one direction only: the panel may omit a binding that is available, and deliberately does so in three cases:
- **Build hotkeys** (REQ-UI-HOTKEYS) are live in every context, but are advertised on the build buttons' badges (REQ-UI-BUILD-COST) instead of taking eleven rows in every context of this panel.
- **`C` and `Ctrl` `C`** are omitted from the Build, Blueprint, and Deconstruct contexts even though a selection surviving into a build mode keeps them working. They belong to the Selection context, and repeating them in every mode would defeat the panel's purpose of showing what the player's current situation affords.
- **`Ctrl` `LMB` and `Ctrl` `LMB` drag** work with nothing selected — they select the object under the cursor much as a plain click would — but are shown only in the Selection context. "Add / remove from selection" names an operation on a selection, and there is none to operate on until something is selected; the plain `LMB` row already covers what the gesture does before then.
- **`F3` and `F4`** (REQ-UI-DEBUG-DRAW) are development controls rather than player controls and appear in no context.
@@ -715,14 +782,14 @@ The controls panel tells the player which controls are available right now. It i
Blueprints occupy no permanent screen space. They are saved with **Ctrl+C** from the current selection (REQ-UI-BLUEPRINT-CREATE) and picked for placement from the blueprint selection dialog, opened with **Ctrl+V** (REQ-UI-BLUEPRINT-DIALOG). The unmodified **C** and **V** keys are the throwaway counterparts of the same two gestures: they capture and re-place a single unnamed temporary blueprint that is never saved and never listed (REQ-UI-BLUEPRINT-TEMP). Blueprints have no widget on the game screen at all. (The ship layout blueprint panel of the layout configuration dialog, REQ-MOD-UI-BLUEPRINT-PANEL, is a separate feature and is unaffected.)
- REQ-UI-BLUEPRINT-CREATE: Pressing **Ctrl+C** (REQ-UI-HOTKEYS) opens the modal **blueprint save dialog**, which pauses the simulation and dims the game window (REQ-UI-MODAL-DIM). It has effect only when at least one player-placeable building (i.e. a building with a button in the build button bar) is currently selected; non-player-placeable buildings (HQ, defence stations) in the selection do not count toward this condition, and pressing Ctrl+C with an empty selection or a selection of only non-player-placeable buildings does nothing (no dialog opens). A selected player-placeable building may be either an operational building or a construction site (a building placed but not yet fully built, REQ-BLD-SITE-CONFIG); both count toward this condition and are captured identically (REQ-UI-BLUEPRINT-STORAGE). The dialog prompts the player to enter a name and has Confirm and Cancel buttons. Clicking Cancel — or pressing Escape, or closing the dialog — closes it with no effect and does not open the blueprint selection dialog. Clicking Confirm with a non-empty name creates a blueprint from the current selection, silently excluding any non-player-placeable buildings, appends it to the blueprint list, closes the save dialog, and immediately opens the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) showing the new blueprint among the others.
- REQ-UI-BLUEPRINT-CREATE: Pressing **Ctrl+C** (REQ-UI-HOTKEYS) opens the modal **blueprint save dialog**, which pauses the simulation and dims the game window (REQ-UI-MODAL-DIM). It has effect only when at least one player-placeable building (i.e. a building with a button in the build button bar) is currently selected; non-player-placeable buildings (HQ, defence stations) in the selection do not count toward this condition, and pressing Ctrl+C with an empty selection or a selection of only non-player-placeable buildings does nothing (no dialog opens). A selected player-placeable building may be either an operational building or a construction site (a building placed but not yet fully built, REQ-BLD-SITE-CONFIG); both count toward this condition and are captured identically (REQ-UI-BLUEPRINT-STORAGE). The dialog is drawn by the game like every other modal (REQ-UI-MODAL-CHROME): it prompts the player to enter a name under its own title and has Confirm and Cancel buttons. Clicking Cancel — or pressing Escape — closes it with no effect and does not open the blueprint selection dialog. It is not dismissed by Q or by a click outside it, a half-typed name being work in progress (REQ-UI-DIALOG-DISMISS). Clicking Confirm with a non-empty name creates a blueprint from the current selection, silently excluding any non-player-placeable buildings, appends it to the blueprint list, closes the save dialog, and immediately opens the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) showing the new blueprint among the others.
- REQ-UI-BLUEPRINT-DIALOG: The **blueprint selection dialog** is the only place saved blueprints are shown. It is opened by pressing **Ctrl+V** (REQ-UI-HOTKEYS) and by confirming a save (REQ-UI-BLUEPRINT-CREATE). It is modal, pauses the simulation, and dims the game window (REQ-UI-MODAL-DIM). The dialog has a fixed size and consists of:
- A **title bar** reading `Blueprints`, followed by a small dimmed **hotkey badge** reading `Ctrl+V` — the same "learn the shortcut from the widget" device as the build button badges (REQ-UI-BUILD-COST) — and, at the far right, a **close ("×") button**.
- A **title bar** the dialog draws itself (REQ-UI-MODAL-CHROME) reading `Blueprints`, followed by a small dimmed **hotkey badge** reading `Ctrl+V` — the same "learn the shortcut from the widget" device as the build button badges (REQ-UI-BUILD-COST) — and, at the far right, a **close ("×") button**.
- Below it, a **scrollable two-column grid of blueprint cards** (REQ-UI-BLUEPRINT-CARD), one per saved blueprint, filling the grid left to right and top to bottom in creation order. The column count is fixed at two; the grid scrolls vertically when the cards do not fit, and does not scroll horizontally.
- When no blueprints are saved, the dialog still opens and shows an empty-state message in place of the grid, telling the player that blueprints are created with Ctrl+C from a selection of buildings.
Clicking the close button, pressing Escape, or closing the dialog through the window manager closes it with no other effect: the current selection, build mode, and blueprint list are unchanged, and the simulation speed is restored to what it was before the dialog was opened. While the dialog is open, Escape closes it rather than opening the escape menu (REQ-UI-GAME-MENU).
Clicking the close button, pressing Escape, pressing Q, or clicking outside the dialog (REQ-UI-DIALOG-DISMISS) closes it with no other effect: the current selection, build mode, and blueprint list are unchanged, and the simulation speed is restored to what it was before the dialog was opened. While the dialog is open, Escape closes it rather than opening the escape menu (REQ-UI-GAME-MENU), and Q closes it rather than acting on the game world beneath — as does the click, which is spent on closing the dialog and does not reach what it landed on.
```
+------------------------------------------------------+
@@ -738,7 +805,7 @@ Blueprints occupy no permanent screen space. They are saved with **Ctrl+C** from
+------------------------------------------------------+
```
- REQ-UI-BLUEPRINT-TEMP: Pressing the **C** key (REQ-UI-HOTKEYS) creates a **temporary blueprint** from the current selection and immediately enters blueprint placement mode for it, without opening the naming dialog. It has effect only when at least one player-placeable building is currently selected — the same condition as REQ-UI-BLUEPRINT-CREATE; pressing C with an empty selection, or a selection containing only non-player-placeable buildings (HQ, defence stations), does nothing at all, and in particular leaves any existing temporary blueprint in place. Entering this mode replaces any currently active build, blueprint placement, or deconstruct mode. The temporary blueprint is captured exactly as a saved blueprint (REQ-UI-BLUEPRINT-STORAGE), silently excluding any non-player-placeable buildings from the selection, but it is never named, never shown in the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG), and never persisted to `blueprints.toml` (REQ-UI-BLUEPRINT-SAVE). Placement behaves identically to a saved blueprint's placement mode (REQ-UI-BLUEPRINT-MODE, REQ-UI-BLUEPRINT-PLACE): a ghost is rendered per building, R / Shift+R rotate the entire constellation, placement follows the same per-building validity and total-cost rules, and after a successful placement the mode stays active so the blueprint can be placed again. Right-clicking in the game world exits placement mode; unlike the mode, the temporary blueprint itself survives, so it can be entered again with V.
- REQ-UI-BLUEPRINT-TEMP: Pressing the **C** key (REQ-UI-HOTKEYS) creates a **temporary blueprint** from the current selection and immediately enters blueprint placement mode for it, without opening the naming dialog. It has effect only when at least one player-placeable building is currently selected — the same condition as REQ-UI-BLUEPRINT-CREATE; pressing C with an empty selection, or a selection containing only non-player-placeable buildings (HQ, defence stations), does nothing at all, and in particular leaves any existing temporary blueprint in place. Entering this mode replaces any currently active build, blueprint placement, or deconstruct mode, and clears the selection — the blueprint is captured from it first, so C loses nothing (REQ-UI-SELECTION-EXCLUSIVE). The temporary blueprint is captured exactly as a saved blueprint (REQ-UI-BLUEPRINT-STORAGE), silently excluding any non-player-placeable buildings from the selection, but it is never named, never shown in the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG), and never persisted to `blueprints.toml` (REQ-UI-BLUEPRINT-SAVE). Placement behaves identically to a saved blueprint's placement mode (REQ-UI-BLUEPRINT-MODE, REQ-UI-BLUEPRINT-PLACE): a ghost is rendered per building, R / Shift+R rotate the entire constellation, placement follows the same per-building validity and total-cost rules, and after a successful placement the mode stays active so the blueprint can be placed again. Right-clicking in the game world exits placement mode; unlike the mode, the temporary blueprint itself survives, so it can be entered again with V.
Pressing the **V** key re-enters blueprint placement mode for the temporary blueprint, capturing nothing new: it is independent of the current selection, can be pressed any number of times, and yields exactly the mode described above. Like C it replaces any currently active build, blueprint placement, or deconstruct mode, and it does not test whether the player can currently afford the blueprint — cost is enforced at placement (REQ-UI-BLUEPRINT-PLACE), consistently with C. Pressing V when no temporary blueprint exists does nothing: no mode is entered and any currently active mode is left untouched.
@@ -749,7 +816,7 @@ Blueprints occupy no permanent screen space. They are saved with **Ctrl+C** from
- REQ-UI-BLUEPRINT-CARD: Each blueprint in the blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG) is shown as a **card**. All cards share a uniform size. A card contains, from top to bottom:
- The **blueprint name**.
- A **contents line** summarizing what the blueprint holds: one `<building name> x <count>` entry per building type it contains, comma-separated, in descending count order with ties broken by the order the types appear in the build button bar (REQ-UI-BUILD-BAR). This is the same `x`-count notation as the building multi-selection summary (REQ-UI-MULTI-SELECTION). If the entries do not fit on the line, the line is elided at its end rather than wrapped or shrunk, so every card keeps the same height.
- The **total building block cost** of the blueprint (sum of the individual costs of all constituent buildings), shown with the `building_block` item icon to the right of the number in place of a trailing `Blocks` word, exactly as elsewhere in the UI (REQ-UI-BLOCKS-ICON, REQ-UI-BUILD-COST). When no icon file exists for `building_block`, the cost is shown as the bare number.
- The **total building block cost** of the blueprint (sum of the individual costs of all constituent buildings), shown with the `building_block` item icon to the right of the number in place of a trailing `Blocks` word, exactly as elsewhere in the UI (REQ-UI-BLOCKS-ICON, REQ-UI-BUILD-COST). When no icon file exists for `building_block`, the cost is shown as the bare number. The card carries no tooltip of its own, so the cost explains the item it names on hover, the click staying the gesture that takes the blueprint (REQ-UI-ITEM-VALUE-TOOLTIP).
- A **delete icon ("×")** in the card's bottom-right corner (REQ-UI-BLUEPRINT-DELETE).
A card shows no preview of the blueprint's layout.
@@ -790,7 +857,7 @@ Blueprints occupy no permanent screen space. They are saved with **Ctrl+C** from
- After the transfer the game stays in blueprint placement mode, so further same-type buildings can be clicked in turn.
- A blueprint placement applies every transfer among its ghosts in the same click that places its new construction sites (REQ-UI-BLUEPRINT-PLACE); the placement is all-or-nothing, so if any ghost is invalid nothing is placed and nothing is transferred.
- REQ-UI-BLUEPRINT-DELETE: Clicking the delete icon ("×") on a blueprint card (REQ-UI-BLUEPRINT-CARD) immediately removes that blueprint from the list, without a confirmation prompt. The blueprint selection dialog stays open and its card grid reflows to close the gap. If the deleted blueprint was active in blueprint placement mode, that mode is exited.
- REQ-UI-BLUEPRINT-DELETE: Clicking the delete icon ("×") on a blueprint card (REQ-UI-BLUEPRINT-CARD) immediately removes that blueprint from the list, without a confirmation prompt. The icon carries a hover tooltip naming what it does, since a bare "×" on a card could as easily mean closing something (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS). The blueprint selection dialog stays open and its card grid reflows to close the gap. If the deleted blueprint was active in blueprint placement mode, that mode is exited.
- REQ-UI-BLUEPRINT-SAVE: On application shutdown, all current blueprints are serialized to a file named `blueprints.toml` located in the same directory as the application executable. The TOML structure matches REQ-UI-BLUEPRINT-STORAGE. Write errors are silently ignored on shutdown (no button, no dialog).

View File

@@ -32,15 +32,46 @@ std::vector<RecipeOutput> parseRecipeOutputs(const toml::array& arr,
RecipeOutput out;
out.item = utility::requireString(mt["item"], file, elemPath + ".item");
out.amount = static_cast<int>(utility::requireInt(mt["amount"], file, elemPath + ".amount"));
result.push_back(std::move(out));
}
return result;
}
// The several-group form: one [[recipe.output_group]] entry per possible result, each
// carrying its weight and the items it yields together (REQ-MAT-OUTPUT-GROUP).
std::vector<RecipeOutputGroup> parseOutputGroups(const toml::array& arr,
const std::string& file,
const std::string& path)
{
std::vector<RecipeOutputGroup> result;
result.reserve(arr.size());
for (std::size_t i = 0; i < arr.size(); ++i)
{
const std::string elemPath = path + "[" + std::to_string(i) + "]";
const toml::table* t = arr[i].as_table();
if (t == nullptr)
{
throw utility::makeError(file, elemPath, "not a table");
}
toml::table& mt = const_cast<toml::table&>(*t);
RecipeOutputGroup group;
const toml::array& items =
utility::requireArray(mt["items"], file, elemPath + ".items");
group.items = parseRecipeOutputs(items, file, elemPath + ".items");
if (group.items.empty())
{
throw utility::makeError(file, elemPath + ".items", "produces nothing");
}
if (const std::optional<double> p = mt["probability"].value<double>())
{
out.probability = *p;
group.probability = *p;
}
else if (const std::optional<int64_t> p = mt["probability"].value<int64_t>())
{
out.probability = static_cast<double>(*p);
group.probability = static_cast<double>(*p);
}
result.push_back(std::move(out));
result.push_back(std::move(group));
}
return result;
}
@@ -91,8 +122,34 @@ RecipesConfig ConfigLoader::loadRecipes(const std::string& path)
def.inputs = utility::parseIngredients(inputs, file, elemPath + ".inputs");
}
const toml::array& outputs = utility::requireArray(mt["outputs"], file, elemPath + ".outputs");
def.outputs = parseRecipeOutputs(outputs, file, elemPath + ".outputs");
// Either form, never both (REQ-MAT-OUTPUT-GROUP): `outputs` is the single-group
// shorthand that all but the reprocessing recipes use, `output_group` the several-
// group form. The shorthand carries no weight -- with one group nothing is picked.
const bool hasOutputs = mt.contains("outputs");
const bool hasGroups = mt.contains("output_group");
if (hasOutputs && hasGroups)
{
throw utility::makeError(file, elemPath,
"has both 'outputs' and 'output_group'; use one or the other");
}
if (hasGroups)
{
const toml::array& groups =
utility::requireArray(mt["output_group"], file, elemPath + ".output_group");
def.outputGroups = parseOutputGroups(groups, file, elemPath + ".output_group");
if (def.outputGroups.empty())
{
throw utility::makeError(file, elemPath + ".output_group", "is empty");
}
}
else
{
const toml::array& outputs =
utility::requireArray(mt["outputs"], file, elemPath + ".outputs");
RecipeOutputGroup group;
group.items = parseRecipeOutputs(outputs, file, elemPath + ".outputs");
def.outputGroups.push_back(std::move(group));
}
cfg.recipes.push_back(std::move(def));
}

View File

@@ -27,12 +27,6 @@ WorldConfig ConfigLoader::loadWorld(const std::string& path)
cfg.orbitFactor = utility::requireDouble(tbl["world"]["orbit_factor"], file, "world.orbit_factor");
cfg.rallyOrbitRadius_tiles = utility::requireDouble(tbl["world"]["rally_orbit_radius_tiles"], file, "world.rally_orbit_radius_tiles");
if (const std::optional<std::string> tip =
tbl["world"]["building_blocks_tooltip"].value<std::string>())
{
cfg.buildingBlocksTooltip = *tip;
}
if (const std::optional<std::string> tip =
tbl["world"]["artifact_tooltip"].value<std::string>())
{

View File

@@ -1,5 +1,6 @@
#pragma once
#include <algorithm>
#include <optional>
#include <string>
#include <vector>
@@ -14,14 +15,22 @@ struct RecipeIngredient
int amount;
};
// One entry in [[recipe]].outputs. For reprocessing_plant recipes, probability
// is populated and outputs are rolled with weighted pick at cycle start
// (REQ-BLD-REPROCESSING, REQ-MAT-CYCLE). For other buildings, probability is
// std::nullopt and all outputs are produced on every cycle.
// One item produced by an output group -- amount units of a named item
// (REQ-MAT-OUTPUT-GROUP).
struct RecipeOutput
{
std::string item;
int amount;
};
// One possible result of a production cycle: the items it yields, produced together, and
// the weight this group is picked with among the recipe's groups (REQ-MAT-OUTPUT-GROUP).
// A recipe with a single group always produces it, so the weight is meaningful only where
// there are several -- which is the only difference between what used to be called a
// deterministic and a probabilistic recipe.
struct RecipeOutputGroup
{
std::vector<RecipeOutput> items;
std::optional<double> probability;
};
@@ -30,7 +39,8 @@ struct RecipeDef
std::string id; // Unique recipe id; used by UI for selection.
BuildingType building; // Which BuildingType can run this recipe.
std::vector<RecipeIngredient> inputs;
std::vector<RecipeOutput> outputs;
// Never empty: one group is the ordinary recipe (REQ-MAT-OUTPUT-GROUP).
std::vector<RecipeOutputGroup> outputGroups;
double durationSeconds;
// Assembler only. When true, this recipe is available from game start
// regardless of the implicit item graph — used for base recipes that no
@@ -40,6 +50,38 @@ struct RecipeDef
bool unlockedAtStart = false;
};
// Every distinct item any group of this recipe can produce, in config order. Most callers
// only want to know what a recipe can make at all -- which items it has buffers for, which
// recipes produce an item -- and not which group yields what.
inline std::vector<std::string> getProducibleItems(const RecipeDef& recipe)
{
std::vector<std::string> items;
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
for (const RecipeOutput& out : group.items)
{
if (std::find(items.begin(), items.end(), out.item) == items.end())
{
items.push_back(out.item);
}
}
}
return items;
}
// True when some group of this recipe yields the given item.
inline bool producesItem(const RecipeDef& recipe, const std::string& itemId)
{
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
for (const RecipeOutput& out : group.items)
{
if (out.item == itemId) { return true; }
}
}
return false;
}
struct RecipesConfig
{
std::vector<RecipeDef> recipes;

View File

@@ -63,4 +63,19 @@ struct ShipsConfig
}
return nullptr;
}
// The definition to configure a layout against, or nullptr when there is no layout
// to configure: no schematic is selected at all (the empty id the "(None)" option
// sets, REQ-UI-SELECT-OPTIONS), the id names no ship, or the ship defines no layout
// grid. Every entry to the layout configuration dialog asks this before opening it
// and the panel asks it before offering the button that opens it, so the dialog
// cannot appear over a grid with no cells (REQ-MOD-UI-DIALOG, REQ-MOD-UI-PREVIEW,
// REQ-MOD-UI-AUTO-DIALOG).
const ShipDef* findLayoutShipDef(const std::string& id) const
{
if (id.empty()) { return nullptr; }
const ShipDef* def = findShipDef(id);
if (!def || def->layout.empty()) { return nullptr; }
return def;
}
};

View File

@@ -79,10 +79,6 @@ struct WorldConfig
double orbitFactor; // REQ-SHP-ORBIT (multiplies tool range for orbit radius)
double rallyOrbitRadius_tiles; // REQ-SHP-ORBIT (fixed orbit radius around the rally point)
// Optional hover-tooltip for the header building blocks stock display
// (REQ-UI-BLOCKS-TOOLTIP). Presentation-only; the simulation ignores it.
std::optional<std::string> buildingBlocksTooltip;
// Optional hover-tooltip for the header artifact count display
// (REQ-UI-ARTIFACTS-TOOLTIP). Presentation-only; the simulation ignores it.
std::optional<std::string> artifactTooltip;

View File

@@ -135,6 +135,17 @@ void BuildModeController::exitCurrentMode()
enterMode(BuildMode::None);
}
void BuildModeController::clearHover()
{
m_ghostTile.reset();
m_ghostValid = false;
m_tunnelGhostType = BuildingType::TunnelEntry;
m_tunnelPartnerTile.reset();
m_blueprintGhostTile.reset();
m_hoveredGhostIsTransfer = false;
m_deconstructHoverBuildingId.reset();
}
BuildingType BuildModeController::getBuilderType() const
{
return m_builderType;
@@ -150,7 +161,7 @@ BuildingType BuildModeController::getEffectiveBuilderType() const
return isTunnelMode() ? m_tunnelGhostType : m_builderType;
}
QPoint BuildModeController::getGhostTile() const
const std::optional<QPoint>& BuildModeController::getGhostTile() const
{
return m_ghostTile;
}
@@ -240,7 +251,7 @@ Blueprint& BuildModeController::getMutableBlueprint()
return m_blueprint;
}
QPoint BuildModeController::getBlueprintGhostTile() const
const std::optional<QPoint>& BuildModeController::getBlueprintGhostTile() const
{
return m_blueprintGhostTile;
}

View File

@@ -54,6 +54,15 @@ public:
// Backs out of whichever mode is active, if any (the Q key and right-click).
void exitCurrentMode();
// --- hover ----------------------------------------------------------------
// Drops everything that follows from a cursor pointing at the world — both
// ghost tiles, placement validity, the resolved tunnel end, the transfer flag,
// the deconstruct hover — for a cursor that points at no tile at all, because it
// rests on a panel or has left the window (REQ-BLD-GHOST). The active mode is
// untouched: the player is still building, just not over anything. A belt drag's
// path is untouched too, since a drag keeps hovering while the button is held.
void clearHover();
// --- builder mode ---------------------------------------------------------
// Only meaningful while isBuilderMode().
BuildingType getBuilderType() const;
@@ -64,7 +73,9 @@ public:
// tunnel mode, the plain builder type otherwise.
BuildingType getEffectiveBuilderType() const;
QPoint getGhostTile() const;
// Unset while the cursor points at no tile (clearHover), which is the one case
// where builder mode draws no ghost at all.
const std::optional<QPoint>& getGhostTile() const;
Rotation getGhostRotation() const;
bool isGhostValid() const;
void setGhostTile(QPoint tile);
@@ -92,7 +103,8 @@ public:
// Mutable so the caller can rotate the layout in place; rotating a blueprint
// needs building footprints from the config, which does not belong here.
Blueprint& getMutableBlueprint();
QPoint getBlueprintGhostTile() const;
// Unset for a cursor pointing at no tile, as for the builder ghost above.
const std::optional<QPoint>& getBlueprintGhostTile() const;
void setBlueprintGhostTile(QPoint tile);
// Whether the ghost under the cursor would hand its settings to the building
@@ -115,7 +127,7 @@ private:
BuildMode m_mode = BuildMode::None;
BuildingType m_builderType = BuildingType::Belt;
QPoint m_ghostTile;
std::optional<QPoint> m_ghostTile;
Rotation m_ghostRotation = Rotation::East;
bool m_ghostValid = false;
BuildingType m_tunnelGhostType = BuildingType::TunnelEntry;
@@ -125,9 +137,9 @@ private:
QPoint m_beltDragAnchor;
std::vector<BeltPathTile> m_beltDragPath;
Blueprint m_blueprint;
QPoint m_blueprintGhostTile;
bool m_hoveredGhostIsTransfer = false;
Blueprint m_blueprint;
std::optional<QPoint> m_blueprintGhostTile;
bool m_hoveredGhostIsTransfer = false;
std::optional<BuildingId> m_deconstructHoverBuildingId;
};

View File

@@ -17,6 +17,7 @@ SET(HDRS
${CMAKE_CURRENT_SOURCE_DIR}/WorldCoordinates.h
${CMAKE_CURRENT_SOURCE_DIR}/WorldCamera.h
${CMAKE_CURRENT_SOURCE_DIR}/FloatingPanelPlacement.h
${CMAKE_CURRENT_SOURCE_DIR}/SelectionBox.h
${CMAKE_CURRENT_SOURCE_DIR}/SelectionController.h
${CMAKE_CURRENT_SOURCE_DIR}/BuildModeController.h
${CMAKE_CURRENT_SOURCE_DIR}/ControlAction.h

View File

@@ -31,7 +31,9 @@ struct MouseBindingEntry
// Resolution is first-match-wins over these tables, so an entry that must beat another
// on the same input is listed above it -- CancelBeltLine before ExitMode on the right
// mouse button. Everything else is disjoint by availability.
// mouse button. Everything else is disjoint by availability: Q carries three actions
// whose availability rules partition the situations between them, so their order here is
// the order the reader meets them and nothing more (REQ-UI-HOTKEYS).
const KeyBindingEntry KEY_BINDINGS[] = {
{ControlAction::Move, Qt::Key_A, Qt::NoModifier},
{ControlAction::Move, Qt::Key_D, Qt::NoModifier},
@@ -48,8 +50,9 @@ const KeyBindingEntry KEY_BINDINGS[] = {
// nothing and is what puts "R" and "Shift+R" on the row.
{ControlAction::Rotate, Qt::Key_R, Qt::NoModifier},
{ControlAction::Rotate, Qt::Key_R, Qt::ShiftModifier},
{ControlAction::EnterDeconstruct, Qt::Key_Q, Qt::NoModifier},
{ControlAction::ExitMode, Qt::Key_Q, Qt::NoModifier},
{ControlAction::ClearSelection, Qt::Key_Q, Qt::NoModifier},
{ControlAction::EnterDeconstruct, Qt::Key_Q, Qt::NoModifier},
{ControlAction::OpenMenu, Qt::Key_Escape, Qt::NoModifier},
};
@@ -114,9 +117,21 @@ bool isControlActionAvailable(ControlAction action, const ControlContext& contex
case ControlAction::SelectArea:
case ControlAction::AddToSelection:
case ControlAction::AddAreaToSelection:
case ControlAction::EnterDeconstruct:
return context.mode == BuildMode::None;
// The three cases of Q, in the order REQ-UI-HOTKEYS evaluates them: it leaves the
// active mode, else clears the selection, else enters deconstruct mode. A selection
// and a build mode never coexist (REQ-UI-SELECTION-EXCLUSIVE), so the first two are
// already disjoint; what the empty-selection condition below adds is the third step,
// which is why entering deconstruct mode by key takes two presses while something is
// selected -- the Deconstruct button still gets there in one click.
case ControlAction::ClearSelection:
return context.mode == BuildMode::None
&& context.selection != ControlSelection::None;
case ControlAction::EnterDeconstruct:
return context.mode == BuildMode::None
&& context.selection == ControlSelection::None;
// Both need something a blueprint can be made of; a selection of ships or debris
// leaves them inert (REQ-UI-HOTKEYS).
case ControlAction::CopyTemporary:
@@ -209,13 +224,16 @@ std::vector<ControlAction> getContextActions(const ControlContext& context)
return filterAvailable({ControlAction::ToggleDeconstruct,
ControlAction::DeconstructArea, ControlAction::ExitMode},
context);
// ClearSelection is listed last for the same reason ExitMode is above: the row that
// backs the player out of the context sits at the bottom of the context's rows
// wherever there is one (REQ-UI-CONTROLS-CONTENT).
case ControlContextKind::Selection:
return filterAvailable({ControlAction::Select, ControlAction::SelectArea,
ControlAction::AddToSelection,
ControlAction::AddAreaToSelection,
ControlAction::EnterDeconstruct,
ControlAction::CopyTemporary,
ControlAction::CreateBlueprint},
ControlAction::CreateBlueprint,
ControlAction::ClearSelection},
context);
case ControlContextKind::General:
break;

View File

@@ -54,6 +54,7 @@ enum class ControlAction
// No build mode active, with something selected.
CopyTemporary,
CreateBlueprint,
ClearSelection,
// Builder and blueprint placement mode.
Place,
@@ -109,7 +110,10 @@ enum class ControlContextKind
struct ControlContext
{
BuildMode mode = BuildMode::None;
BuildingType builderType = BuildingType::Belt; // while mode == Builder
// While mode == Builder: the type a click would place at the current hover position,
// not the type the mode was entered with — tunnel mode resolves to either end
// (REQ-BLD-TUNNEL-MODE).
BuildingType builderType = BuildingType::Belt;
bool draggingBelt = false;
// A single-building blueprint whose ghost is over a configuration-transfer target,
// so clicking hands over settings rather than placing (REQ-UI-BLUEPRINT-TRANSFER).

View File

@@ -57,12 +57,13 @@ int getAvailableBottomPx(const QRect& band, const std::vector<QRect>& occupiedRe
}
PanelSide chooseSide(const QRect& band, const QRect& anchorRect, int widthPx,
int marginPx)
int selectionGapPx)
{
// What each side offers: the gap between the anchor and that edge of the band, less
// the margin the panel keeps from the anchor.
const int roomRightPx = band.right() - anchorRect.right() - marginPx;
const int roomLeftPx = anchorRect.left() - band.left() - marginPx;
// What each side offers: the room between the anchor and that edge of the band, less
// the gap the panel keeps from the anchor. The band's own inset from the view has
// already taken the edge margin off.
const int roomRightPx = band.right() - anchorRect.right() - selectionGapPx;
const int roomLeftPx = anchorRect.left() - band.left() - selectionGapPx;
if (roomRightPx >= widthPx)
{
@@ -79,20 +80,20 @@ PanelSide chooseSide(const QRect& band, const QRect& anchorRect, int widthPx,
QRect placeBesideAnchor(const QRect& band, const QRect& anchorRect, PanelSide side,
QSize wantedSize, const std::vector<QRect>& occupiedRects,
int marginPx)
int selectionGapPx, int marginPx)
{
const int widthPx = std::min(wantedSize.width(), band.width());
// Against the anchor on the chosen side, growing away from it: the edge facing the
// A gap from the anchor on the chosen side, growing away from it: the edge facing the
// selection is the one that stays put as the panel's content resizes. A panel that
// does not fit there is pushed back inside the view rather than hanging off it, which
// is what puts it over the selection when neither side had room.
const int wantedLeftPx = (side == PanelSide::Right)
? anchorRect.right() + marginPx + 1
: anchorRect.left() - marginPx - widthPx;
? anchorRect.right() + selectionGapPx + 1
: anchorRect.left() - selectionGapPx - widthPx;
// Top-aligned with the anchor, then lifted by however much of it hangs below what is
// free.
// Top-aligned with the anchor -- the gap separates the two horizontally and plays no
// part here -- then lifted by however much of the panel hangs below what is free.
return fitInBand(band, wantedLeftPx, anchorRect.top(), wantedSize, occupiedRects,
marginPx);
}

View File

@@ -10,6 +10,12 @@
// owner places them in one ordered pass, each into the space the earlier ones left free,
// and these are the rules they place themselves by. Pure geometry -- no widget is
// involved, which is what lets the rules be tested without a display.
//
// Two distances run through these rules and are deliberately different (see
// REQ-UI-SELECTION-PANEL). marginPx is the edge margin: what a widget keeps from the
// view's edges and from the widgets it steps around. selectionGapPx is the gap the
// selection panel keeps from the selection it describes -- half a tile, which is the
// wider of the two, so the panel stands clear of the objects rather than touching them.
// The lowest bottom edge available to a widget occupying the horizontal span
// [leftPx, rightPx] inside band: the band's own bottom, or marginPx above the topmost
@@ -29,19 +35,21 @@ enum class PanelSide
// The side a panel widthPx wide takes beside anchorRect: the right of it where it fits
// within band, otherwise the left, and where it fits on neither, whichever side leaves
// more room -- the one case in which the panel ends up over the selection
// (REQ-UI-SELECTION-PANEL). Decided once when the selection starts and kept for as long
// as it lasts, so a card that grows later never flips the panel across the object.
// (REQ-UI-SELECTION-PANEL). The room a side offers is what is left of it once the panel's
// gap from the selection is taken off. Decided once when the selection starts and kept for
// as long as it lasts, so a card that grows later never flips the panel across the object.
PanelSide chooseSide(const QRect& band, const QRect& anchorRect, int widthPx,
int marginPx);
int selectionGapPx);
// Where a panel of wantedSize stands beside anchorRect on the given side: separated from
// it by marginPx and growing away from it, its top edge on the anchor's top edge, pushed
// inside band and above whatever occupies it. The returned height is short of
// wantedSize's when there was not enough room, which is the caller's cue to scroll its
// content (REQ-UI-SELECTION-PANEL).
// it by selectionGapPx and growing away from it, its top edge on the anchor's top edge,
// pushed inside band and above whatever occupies it. The gap is horizontal only -- the
// panel's top sits level with the anchor's, however wide the gap. The returned height is
// short of wantedSize's when there was not enough room, which is the caller's cue to
// scroll its content (REQ-UI-SELECTION-PANEL).
QRect placeBesideAnchor(const QRect& band, const QRect& anchorRect, PanelSide side,
QSize wantedSize, const std::vector<QRect>& occupiedRects,
int marginPx);
int selectionGapPx, int marginPx);
// Where a panel of wantedSize stands once the player has dragged it to desiredTopLeftPx:
// at that point, by the same rules that place it beside a selection -- pushed inside band,

View File

@@ -0,0 +1,34 @@
#pragma once
#include <QPoint>
#include <QRectF>
#include <QVector2D>
// The coverage rules of a selection box (REQ-UI-MULTI-SELECT, REQ-BLD-DECONSTRUCT-BOX).
//
// The box is a rectangle in world coordinates — tiles as the unit, but fractional,
// because the drag follows the mouse and is not snapped to the tile grid. The two
// rules below are the whole of what "covered by the box" means; they live here so the
// building query and the entity queries answer it identically.
//
// Both callers pass a normalized rectangle: neither rule normalizes on its own.
// Whether the box overlaps the unit square of `tile` — the rule for anything that
// occupies whole tiles (buildings, construction sites, defence station bodies). The
// comparisons are inclusive, so a box that only grazes the tile's edge still covers
// it, and a box with no area covers the tile it lies on.
inline bool boxCoversTile(const QRectF& worldBox, QPoint tile)
{
return worldBox.left() <= static_cast<qreal>(tile.x()) + 1.0
&& worldBox.right() >= static_cast<qreal>(tile.x())
&& worldBox.top() <= static_cast<qreal>(tile.y()) + 1.0
&& worldBox.bottom() >= static_cast<qreal>(tile.y());
}
// Whether the box contains `worldPos` — the rule for anything that has a position
// rather than a footprint (ships, debris). Their centre is what the box must enclose,
// so that what the rectangle visibly holds is what the drag selects.
inline bool boxCoversPoint(const QRectF& worldBox, QVector2D worldPos)
{
return worldBox.contains(QPointF(worldPos.x(), worldPos.y()));
}

View File

@@ -25,6 +25,7 @@ SET(HDRS
${CMAKE_CURRENT_SOURCE_DIR}/SpeedStepRequestedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/GhostRotationRequestedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/ModeCancelRequestedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/SelectionClearRequestedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/DebugDrawToggleRequestedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/DeconstructModeChangedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/BuildingTypeSelectedEvent.h
@@ -46,6 +47,7 @@ SET(HDRS
${CMAKE_CURRENT_SOURCE_DIR}/CommandRequestedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/FloatingLayoutInvalidatedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/PlayerCommandsAppliedEvent.h
${CMAKE_CURRENT_SOURCE_DIR}/ViewScrolledEvent.h
PARENT_SCOPE
)

View File

@@ -5,8 +5,9 @@
// Fired when the current asteroid-expansion cost changes (REQ-EXP-COST): once at
// startup and again after each expansion is purchased. Carries no payload — the
// header Expand button re-reads Simulation::getCurrentExpansionCost() to update
// its caption and enabled state (REQ-UI-EXPAND-BUTTON).
// expansion button re-reads Simulation::getCurrentExpansionCost() to update its cost
// line and enabled state, and moves onto the next stretch of locked ground, the
// buildable edge having shifted with the purchase (REQ-UI-EXPAND-BUTTON).
class ExpansionCostChangedEvent : public Event
{
};

View File

@@ -15,11 +15,17 @@
// is while the selection grows; and because the rectangle is screen space frozen at that
// moment, scrolling the view or a selected ship flying off does not move the panel
// either.
//
// The gap the panel keeps from that rectangle travels with it, for the same reason: it is
// half a tile as the tile stood in this moment (REQ-UI-SELECTION-PANEL, REQ-GW-TILE-SIZE)
// and stays that for as long as the selection lasts, a rectangle frozen in one moment
// having no meaningful distance to a tile size measured in another.
class SelectionAnchorChangedEvent : public Event
{
public:
explicit SelectionAnchorChangedEvent(QRect rectPx)
: rectPx(rectPx) {}
SelectionAnchorChangedEvent(QRect rectPx, int selectionGapPx)
: rectPx(rectPx), selectionGapPx(selectionGapPx) {}
const QRect rectPx;
const int selectionGapPx;
};

View File

@@ -0,0 +1,11 @@
#pragma once
#include "Event.h"
// The player pressed the key that drops the current selection (REQ-UI-HOTKEYS). Separate
// from ModeCancelRequestedEvent although both are Q: which of the two a press means is
// settled by the action table, and an event that meant either would force the receiver to
// decide it a second time.
class SelectionClearRequestedEvent : public Event
{
};

View File

@@ -0,0 +1,15 @@
#pragma once
#include "Event.h"
// Fired when the game world view's scroll position actually moved (REQ-UI-SCROLL), once
// per frame at most and not at all while the view sits still. Carries no payload: what it
// says is that the world-to-widget transform has changed, and whoever cares re-reads it.
//
// It exists for the widgets that keep a place in the world rather than on the screen --
// the asteroid expansion button, which stands on the columns it would buy
// (REQ-UI-EXPAND-BUTTON). The floating panels need nothing of the sort: they are placed
// against the screen and stay put as the view moves under them (ui/FloatingPanel.h).
class ViewScrolledEvent : public Event
{
};

View File

@@ -12,27 +12,27 @@
namespace
{
// Folds the output capacities one recipe implies into `caps`: twice each produced
// item's per-cycle amount (REQ-MAT-OUTPUT-BUFFER). A Reprocessing Plant rolls exactly
// one of its outputs per cycle (REQ-BLD-REPROCESSING), so its per-cycle amount for an
// item is that one outcome's amount rather than a sum over the entries.
// Folds the output capacities one recipe implies into `caps`: twice each produced item's
// per-cycle amount (REQ-MAT-OUTPUT-BUFFER). A cycle yields exactly one output group
// (REQ-MAT-OUTPUT-GROUP), so an item's per-cycle amount is the largest total any single
// group produces of it -- summed within a group, whose items come together, and taken at
// its maximum across groups, of which only one ever happens.
//
// Where a cap is already present the larger wins, which is how an auto-recipe building
// unions the recipes of its type -- the same rule its input caps follow.
void addOutputCaps(std::map<ItemType, int>& caps, BuildingType type,
const RecipeDef& recipe)
// Where a cap is already present the larger wins, which is how a cap unions across the
// recipes it could be sized over -- the same rule the input caps follow.
void addOutputCaps(std::map<ItemType, int>& caps, const RecipeDef& recipe)
{
std::map<ItemType, int> perCycle;
for (const RecipeOutput& out : recipe.outputs)
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
const ItemType item{out.item};
if (type == BuildingType::ReprocessingPlant)
std::map<ItemType, int> inGroup;
for (const RecipeOutput& out : group.items)
{
perCycle[item] = std::max(perCycle[item], out.amount);
inGroup[ItemType{out.item}] += out.amount;
}
else
for (const std::pair<const ItemType, int>& entry : inGroup)
{
perCycle[item] += out.amount;
perCycle[entry.first] = std::max(perCycle[entry.first], entry.second);
}
}
@@ -57,7 +57,7 @@ void initBuffers(Building& b, const RecipeDef& recipe)
b.outputBuffer.items.clear();
b.outputBuffer.caps.clear();
addOutputCaps(b.outputBuffer.caps, b.type, recipe);
addOutputCaps(b.outputBuffer.caps, recipe);
}
void initShipyardBuffers(const GameConfig& config, Building& b)

View File

@@ -48,29 +48,62 @@ BuildingSystem::BuildingSystem(const GameConfig& config,
// ---------------------------------------------------------------------------
std::vector<Item> BuildingSystem::rollReprocessingOutput(const RecipeDef& recipe)
namespace
{
std::vector<const RecipeOutput*> eligible;
std::vector<double> weights;
for (const RecipeOutput& out : recipe.outputs)
// The items of one group, produced together (REQ-MAT-OUTPUT-GROUP).
std::vector<Item> itemsOf(const RecipeOutputGroup& group)
{
std::vector<Item> result;
for (const RecipeOutput& out : group.items)
{
if (!m_isItemUnlocked(out.item)) { continue; }
eligible.push_back(&out);
weights.push_back(out.probability.value_or(1.0));
Item item;
item.type.id = out.item;
for (int i = 0; i < out.amount; ++i)
{
result.push_back(item);
}
}
return result;
}
} // namespace
std::vector<Item> BuildingSystem::rollOutputGroup(const RecipeDef& recipe)
{
// One group: nothing to choose, so no weight is read, no draw is made, and no
// eligibility is tested (REQ-MAT-OUTPUT-GROUP, REQ-LOCK-OUTPUT-POOL).
//
// Not drawing matters beyond speed. A draw here would consume entropy for every
// ordinary recipe, shifting every later random outcome and invalidating recorded
// replays. And eligibility must not apply either: implicit unlocking is derived from
// demand, so an ordinary recipe's output can be perfectly producible while nothing
// yet calls for it -- testing it here would stop the building producing at all.
if (recipe.outputGroups.size() == 1)
{
return itemsOf(recipe.outputGroups.front());
}
// Several groups: only those whose items are all unlocked can be picked, and a group
// holding any locked item is dropped whole, since its items come together
// (REQ-LOCK-OUTPUT-POOL). Weights are renormalized over what is left by
// discrete_distribution.
std::vector<const RecipeOutputGroup*> eligible;
std::vector<double> weights;
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
bool allUnlocked = true;
for (const RecipeOutput& out : group.items)
{
if (!m_isItemUnlocked(out.item)) { allUnlocked = false; break; }
}
if (!allUnlocked) { continue; }
eligible.push_back(&group);
weights.push_back(group.probability.value_or(1.0));
}
if (eligible.empty()) { return {}; }
std::discrete_distribution<int> dist(weights.begin(), weights.end());
const RecipeOutput& chosen = *eligible[static_cast<std::size_t>(dist(m_rng))];
std::vector<Item> result;
Item item;
item.type.id = chosen.item;
for (int i = 0; i < chosen.amount; ++i)
{
result.push_back(item);
}
return result;
return itemsOf(*eligible[static_cast<std::size_t>(dist(m_rng))]);
}
// ---------------------------------------------------------------------------
@@ -572,25 +605,11 @@ void BuildingSystem::tickProduction(FactoryState& state, Tick currentTick)
continue;
}
// 3. Determine chosen outputs (roll for reprocessing).
std::vector<Item> chosen;
if (building.type == BuildingType::ReprocessingPlant)
{
chosen = rollReprocessingOutput(*recipe);
if (chosen.empty()) { continue; }
}
else
{
for (const RecipeOutput& out : recipe->outputs)
{
Item item;
item.type.id = out.item;
for (int i = 0; i < out.amount; ++i)
{
chosen.push_back(item);
}
}
}
// 3. Settle what this cycle produces: its one output group, picked by weight only
// where the recipe has several (REQ-MAT-OUTPUT-GROUP). Empty means every group
// was ineligible, so there is nothing to run.
std::vector<Item> chosen = rollOutputGroup(*recipe);
if (chosen.empty()) { continue; }
// 4. Consume inputs and start cycle.
for (const RecipeIngredient& ing : recipe->inputs)

View File

@@ -224,11 +224,11 @@ private:
// (ignoring output-buffer space); drives the Starved/Blocked distinction of
// the status light (REQ-UI-STATUS-LIGHT).
// Buffers for an auto-recipe building (Smelter, Reprocessing Plant): input
// caps span the union of every recipe of the building's type; no player
// recipe is selected (REQ-BLD-SMELTER, REQ-BLD-REPROCESSING).
// Core input-edge scan shared by operational buildings and construction sites.
std::vector<Item> rollReprocessingOutput(const RecipeDef& recipe);
// What one cycle of this recipe produces: the items of its one output group
// (REQ-MAT-OUTPUT-GROUP). Where the recipe has several, one is picked by weight from
// those currently eligible (REQ-LOCK-OUTPUT-POOL) and the result is empty if none is;
// where it has one, that group is returned with no draw and no eligibility test.
std::vector<Item> rollOutputGroup(const RecipeDef& recipe);
const GameConfig& m_config;

View File

@@ -13,7 +13,7 @@
#include "Rotation.h"
#include "ShipLayout.h"
class GameConfig;
struct GameConfig;
// Player intent, resolved to domain ids / tile coordinates and serializable, that
// mutates the simulation. Every sim mutation during play flows through a Command

View File

@@ -4,6 +4,7 @@
#include <cmath>
#include "EntityAdmin.h"
#include "SelectionBox.h"
#include "PositionComponent.h"
#include "DebrisComponent.h"
#include "ShipIdentityComponent.h"
@@ -82,45 +83,29 @@ entt::entity debrisAtWorldPos(EntityAdmin& admin, QVector2D worldPos)
return bestDebris;
}
std::vector<entt::entity> debrisInBox(EntityAdmin& admin, QPoint tileA, QPoint tileB)
std::vector<entt::entity> debrisInBox(EntityAdmin& admin, const QRectF& worldBox)
{
const int minX = std::min(tileA.x(), tileB.x());
const int maxX = std::max(tileA.x(), tileB.x());
const int minY = std::min(tileA.y(), tileB.y());
const int maxY = std::max(tileA.y(), tileB.y());
std::vector<entt::entity> result;
admin.forEach<DebrisComponent, PositionComponent>(
[&](entt::entity entity, const DebrisComponent& /*sd*/, const PositionComponent& pos)
{
const int tileX = static_cast<int>(std::floor(pos.value.x()));
const int tileY = static_cast<int>(std::floor(pos.value.y()));
if (tileX >= minX && tileX <= maxX && tileY >= minY && tileY <= maxY)
{
result.push_back(entity);
}
if (boxCoversPoint(worldBox, pos.value)) { result.push_back(entity); }
});
return result;
}
std::vector<entt::entity> actorsInBox(EntityAdmin& admin, QPoint tileA, QPoint tileB)
std::vector<entt::entity> actorsInBox(EntityAdmin& admin, const QRectF& worldBox)
{
const int minX = std::min(tileA.x(), tileB.x());
const int maxX = std::max(tileA.x(), tileB.x());
const int minY = std::min(tileA.y(), tileB.y());
const int maxY = std::max(tileA.y(), tileB.y());
std::vector<entt::entity> result;
// Stations: included when any occupied body cell lies in the box.
// Stations occupy whole tiles: included when the box overlaps any occupied cell.
admin.forEach<StationBodyComponent, HealthComponent>(
[&](entt::entity entity, const StationBodyComponent& sb, const HealthComponent& h)
{
if (h.hp <= 0.0f) { return; }
for (const QPoint& cell : sb.bodyCells)
{
if (cell.x() >= minX && cell.x() <= maxX
&& cell.y() >= minY && cell.y() <= maxY)
if (boxCoversTile(worldBox, cell))
{
result.push_back(entity);
return;
@@ -128,19 +113,15 @@ std::vector<entt::entity> actorsInBox(EntityAdmin& admin, QPoint tileA, QPoint t
}
});
// Ships: included when the floored position tile lies in the box. Requiring
// ShipIdentityComponent excludes the HQ proxy and any station bodies.
// Ships have a position rather than a footprint: included when the box contains
// that position. Requiring ShipIdentityComponent excludes the HQ proxy and any
// station bodies.
admin.forEach<ShipIdentityComponent, PositionComponent, HealthComponent>(
[&](entt::entity entity, const ShipIdentityComponent& /*id*/,
const PositionComponent& pos, const HealthComponent& h)
{
if (h.hp <= 0.0f) { return; }
const int tileX = static_cast<int>(std::floor(pos.value.x()));
const int tileY = static_cast<int>(std::floor(pos.value.y()));
if (tileX >= minX && tileX <= maxX && tileY >= minY && tileY <= maxY)
{
result.push_back(entity);
}
if (boxCoversPoint(worldBox, pos.value)) { result.push_back(entity); }
});
return result;

View File

@@ -3,6 +3,7 @@
#include <vector>
#include <QPoint>
#include <QRectF>
#include <QVector2D>
#include "entt/entity/entity.hpp"
@@ -16,13 +17,13 @@ entt::entity entityAtWorldPos(EntityAdmin& admin, QVector2D worldPos);
// after actors: entityAtWorldPos never returns debris (debris has no HealthComponent).
entt::entity debrisAtWorldPos(EntityAdmin& admin, QVector2D worldPos);
// Returns every piece of debris whose position falls within the inclusive tile rectangle
// spanned by tileA and tileB, in any corner order (REQ-UI-DEBRIS-MULTI-SELECT).
std::vector<entt::entity> debrisInBox(EntityAdmin& admin, QPoint tileA, QPoint tileB);
// Returns every piece of debris the selection box covers — that is, whose position it
// contains, per boxCoversPoint (REQ-UI-DEBRIS-MULTI-SELECT). `worldBox` is in world
// coordinates and normalized; it is not snapped to tiles.
std::vector<entt::entity> debrisInBox(EntityAdmin& admin, const QRectF& worldBox);
// Returns every living actor (ship or defence station, player or enemy) that falls
// within the inclusive tile rectangle spanned by tileA and tileB, in any corner order
// (REQ-UI-MULTI-SELECT, REQ-UI-ENTITY-CLICK-SELECT). A ship is included when its floored
// position tile lies in the box; a station is included when any of its body cells does.
// Dead actors (hp <= 0) and the HQ proxy are excluded.
std::vector<entt::entity> actorsInBox(EntityAdmin& admin, QPoint tileA, QPoint tileB);
// Returns every living actor (ship or defence station, player or enemy) the selection
// box covers (REQ-UI-MULTI-SELECT, REQ-UI-ENTITY-CLICK-SELECT): a ship when the box
// contains its position, a station when the box overlaps any of its body cells — the
// two rules of SelectionBox.h. Dead actors (hp <= 0) and the HQ proxy are excluded.
std::vector<entt::entity> actorsInBox(EntityAdmin& admin, const QRectF& worldBox);

View File

@@ -5,6 +5,7 @@
#include "PortGeometry.h"
#include "ProductionRules.h"
#include "SelectionBox.h"
#include "SurfaceMask.h"
#include "Item.h"
@@ -185,22 +186,13 @@ getSiteSplitterInfo(const FactoryState& state, const GameConfig& config, Buildin
std::vector<BuildingId> buildingsInBox(const FactoryState& state,
QPoint cornerA, QPoint cornerB)
const QRectF& worldBox)
{
const int x0 = std::min(cornerA.x(), cornerB.x());
const int y0 = std::min(cornerA.y(), cornerB.y());
const int x1 = std::max(cornerA.x(), cornerB.x());
const int y1 = std::max(cornerA.y(), cornerB.y());
const auto covers = [&](const std::vector<QPoint>& bodyCells)
{
for (const QPoint& cell : bodyCells)
{
if (cell.x() >= x0 && cell.x() <= x1
&& cell.y() >= y0 && cell.y() <= y1)
{
return true;
}
if (boxCoversTile(worldBox, cell)) { return true; }
}
return false;
};

View File

@@ -3,6 +3,7 @@
#include <vector>
#include <QPoint>
#include <QRectF>
#include <QVector2D>
#include "Building.h"
@@ -71,11 +72,12 @@ std::optional<BeltSystem::SplitterInfo> getSiteSplitterInfo(const FactoryState&
const GameConfig& config,
BuildingId id);
// Ids of all buildings and construction sites whose footprint intersects the tile
// box spanned by the two (unordered) corner tiles (REQ-UI-MULTI-SELECT,
// REQ-BLD-DECONSTRUCT-BOX).
// Ids of all buildings and construction sites the selection box covers — those with
// a body cell the box overlaps, per boxCoversTile (REQ-UI-MULTI-SELECT,
// REQ-BLD-DECONSTRUCT-BOX). `worldBox` is in world coordinates and normalized; it is
// not snapped to tiles.
std::vector<BuildingId> buildingsInBox(const FactoryState& state,
QPoint cornerA, QPoint cornerB);
const QRectF& worldBox);
// Every tunnel entry and exit, built or still a construction site, indexed by its
// single-cell tile. Shared by the placement preview and the selection highlight.

View File

@@ -154,33 +154,22 @@ bool outputBufferHasRoom(const Building& b, const ItemType& type, int itemCount)
bool recipeOutputsFit(const Building& b, const RecipeDef& recipe)
{
if (b.type == BuildingType::ReprocessingPlant)
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
// One roll yields one of these, so each is measured on its own -- but all of them
// have to fit, since which one it will be is not known yet.
for (const RecipeOutput& out : recipe.outputs)
// A group's items come together, so an item listed twice in one is produced in the
// sum of those amounts and judged once, as a sum.
std::map<ItemType, int> perCycle;
for (const RecipeOutput& out : group.items)
{
if (!outputBufferHasRoom(b, ItemType{out.item}, out.amount))
perCycle[ItemType{out.item}] += out.amount;
}
for (const std::pair<const ItemType, int>& entry : perCycle)
{
if (!outputBufferHasRoom(b, entry.first, entry.second))
{
return false;
}
}
return true;
}
// A deterministic cycle deposits all of its outputs together. An item listed more
// than once is produced in the sum of those amounts, so it is judged once, as a sum.
std::map<ItemType, int> perCycle;
for (const RecipeOutput& out : recipe.outputs)
{
perCycle[ItemType{out.item}] += out.amount;
}
for (const std::pair<const ItemType, int>& entry : perCycle)
{
if (!outputBufferHasRoom(b, entry.first, entry.second))
{
return false;
}
}
return true;
}

View File

@@ -64,12 +64,11 @@ bool hasInputsToStart(const GameConfig& config, const Building& b);
// counts against that material's capacity (REQ-MAT-OUTPUT-EMERGE, REQ-MAT-OUTPUT-BUFFER).
bool outputBufferHasRoom(const Building& b, const ItemType& type, int itemCount);
// True when every output a cycle of this recipe could produce would fit -- the gate a
// cycle has to pass before it may start (REQ-MAT-CYCLE). For a deterministic recipe that
// is its own outputs. A Reprocessing Plant rolls one of its outputs per cycle
// (REQ-BLD-REPROCESSING), so each possibility is judged on its own and all must fit: the
// roll is committed the moment the cycle starts, and testing every outcome rather than
// the rolled one is what keeps a stalled output belt from biasing the distribution.
// True when every one of the recipe's output groups would fit -- the gate a cycle has to
// pass before it may start (REQ-MAT-CYCLE, REQ-MAT-OUTPUT-GROUP). With a single group that
// is simply that group. With several the pick is committed the moment the cycle starts, so
// every outcome must fit: testing all of them rather than the picked one is what keeps a
// stalled output belt from biasing the distribution.
bool recipeOutputsFit(const Building& b, const RecipeDef& recipe);
// True when a production cycle could actually start right now: some candidate recipe

View File

@@ -97,35 +97,42 @@ ThreatCostTable computeThreatCostTable(const GameConfig& config)
// values are raw from config; we normalize them per-recipe below).
std::map<std::string, std::vector<RecipeRef>> reprocessingRecipes;
// What decides which model an item's threat follows is the recipe's shape, not the
// building running it (REQ-MAT-OUTPUT-GROUP): a recipe with several groups yields one
// of them by chance, so its items cost the cycle divided by their odds; a recipe with
// one group yields it every cycle, so its items cost the cycle outright.
for (const RecipeDef& recipe : config.recipes.recipes)
{
if (recipe.building == BuildingType::ReprocessingPlant)
if (recipe.outputGroups.size() > 1)
{
// Compute the total weight across all outputs of this reprocessing recipe
// so we can normalize each output's probability.
// Total weight across the groups, so each group's probability normalizes.
double totalWeight = 0.0;
for (const RecipeOutput& out : recipe.outputs)
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
totalWeight += out.probability.value_or(1.0);
totalWeight += group.probability.value_or(1.0);
}
if (totalWeight <= 0.0)
{
continue;
}
for (const RecipeOutput& out : recipe.outputs)
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
RecipeRef ref;
ref.recipe = &recipe;
ref.outputItem = out.item;
ref.outputAmount = out.amount;
ref.probability = out.probability.value_or(1.0) / totalWeight;
reprocessingRecipes[out.item].push_back(ref);
const double probability = group.probability.value_or(1.0) / totalWeight;
for (const RecipeOutput& out : group.items)
{
RecipeRef ref;
ref.recipe = &recipe;
ref.outputItem = out.item;
ref.outputAmount = out.amount;
ref.probability = probability;
reprocessingRecipes[out.item].push_back(ref);
}
}
}
else
{
// Check whether this non-reprocessing recipe consumes scrap.
// Check whether this single-group recipe consumes scrap.
bool consumesScrap = false;
for (const RecipeIngredient& input : recipe.inputs)
{
@@ -136,7 +143,7 @@ ThreatCostTable computeThreatCostTable(const GameConfig& config)
}
}
for (const RecipeOutput& out : recipe.outputs)
for (const RecipeOutput& out : recipe.outputGroups.front().items)
{
if (!consumesScrap)
{
@@ -288,8 +295,13 @@ ThreatCostTable computeThreatCostTable(const GameConfig& config)
scrapPerCycle += input.amount;
}
// Per unit: the cycle's cost, divided by the odds of getting this group
// at all and then by how many units that group yields (REQ-THREAT-ITEM).
const double perUnitDivisor =
ref.probability * static_cast<double>(ref.outputAmount);
if (perUnitDivisor <= 0.0) { continue; }
double threat = (table.scrapThreat * scrapPerCycle
+ ref.recipe->durationSeconds) / ref.probability;
+ ref.recipe->durationSeconds) / perUnitDivisor;
std::map<std::string, double>::iterator existing = resolved.find(item);
if (existing == resolved.end() || threat > existing->second)

View File

@@ -244,9 +244,9 @@ UnlockState::UnlockedSets UnlockState::computeUnlockedSets(
if (def.building == BuildingType::Assembler
&& (def.unlockedAtStart || unlockedRecipeSchematicIds.count(def.id) > 0))
{
for (const RecipeOutput& out : def.outputs)
for (const std::string& item : getProducibleItems(def))
{
result.itemIds.insert(out.item);
result.itemIds.insert(item);
}
}
}
@@ -272,9 +272,9 @@ UnlockState::UnlockedSets UnlockState::computeUnlockedSets(
continue;
}
bool producesUnlocked = false;
for (const RecipeOutput& out : recipe.outputs)
for (const std::string& item : getProducibleItems(recipe))
{
if (result.itemIds.count(out.item) > 0)
if (result.itemIds.count(item) > 0)
{
producesUnlocked = true;
break;

View File

@@ -288,6 +288,66 @@ TEST_CASE("The effective builder type follows the resolved tunnel end", "[buildm
REQUIRE(controller.getTunnelPartnerTile() == QPoint(5, 5));
}
TEST_CASE("Clearing the hover drops everything the cursor pointed at", "[buildmode]")
{
// A cursor that leaves the world hovers nothing, so the ghost and its resolved
// tunnel end go with it, while the mode itself stays active (REQ-BLD-GHOST).
BuildModeController controller;
controller.enterBuilderMode(BuildingType::TunnelEntry);
controller.setGhostTile(QPoint(7, 2));
controller.setGhostValidity(true);
controller.setTunnelGhost(BuildingType::TunnelExit, QPoint(5, 2));
controller.clearHover();
REQUIRE(controller.isBuilderMode());
REQUIRE_FALSE(controller.getGhostTile().has_value());
REQUIRE_FALSE(controller.isGhostValid());
REQUIRE(controller.getEffectiveBuilderType() == BuildingType::TunnelEntry);
REQUIRE_FALSE(controller.getTunnelPartnerTile().has_value());
}
TEST_CASE("Clearing the hover keeps a belt drag's path", "[buildmode]")
{
// A drag holds the button and goes on hovering wherever the cursor travels, so
// nothing clears it short of releasing or cancelling (REQ-BLD-BELT-DRAG).
BuildModeController controller;
controller.enterBuilderMode(BuildingType::Belt);
controller.beginBeltDrag(QPoint(3, 4));
controller.setBeltDragPath({BeltPathTile{QPoint(3, 4), Rotation::East}});
controller.clearHover();
REQUIRE(controller.isDraggingBelt());
REQUIRE(controller.getBeltDragPath().size() == 1);
}
TEST_CASE("Clearing the hover drops the blueprint ghost and its transfer", "[buildmode]")
{
BuildModeController controller;
controller.enterBlueprintMode(makeBlueprint());
controller.setBlueprintGhostTile(QPoint(9, 9));
controller.setHoveredGhostTransfer(true);
controller.clearHover();
REQUIRE(controller.isBlueprintMode());
REQUIRE_FALSE(controller.getBlueprintGhostTile().has_value());
REQUIRE_FALSE(controller.isHoveredGhostTransfer());
}
TEST_CASE("Clearing the hover drops the deconstruct hover", "[buildmode]")
{
BuildModeController controller;
controller.toggleDeconstructMode();
controller.setDeconstructHoverBuildingId(BuildingId(4));
controller.clearHover();
REQUIRE(controller.isDeconstructMode());
REQUIRE_FALSE(controller.getDeconstructHoverBuildingId().has_value());
}
TEST_CASE("A non-tunnel builder ignores any resolved tunnel end", "[buildmode]")
{
BuildModeController controller;

View File

@@ -11,6 +11,7 @@
#include <vector>
#include <QPoint>
#include <QRectF>
#include "BeltSystem.h"
#include "Building.h"
@@ -103,14 +104,20 @@ struct PlacementFixture
BuildingSystem bs;
// Defaults to the configured belt speed; pass kFastBeltSpeed_tps where the test
// needs items to arrive immediately.
explicit PlacementFixture(std::optional<double> beltSpeed_tps = std::nullopt)
// needs items to arrive immediately. Everything counts as unlocked unless the test
// says otherwise, which is what the output-group eligibility rule turns on
// (REQ-LOCK-OUTPUT-POOL).
explicit PlacementFixture(
std::optional<double> beltSpeed_tps = std::nullopt,
std::function<bool(const std::string&)> isItemUnlocked = nullptr)
: belts(beltSpeed_tps.value_or(cfg.world.beltSpeed_tps))
, bs(cfg, belts,
[this]() { return nextBuildingId++; },
[this](int n) { stock += n; },
[](const std::string&, QVector2D, const std::optional<ShipLayoutConfig>&) {},
[](const std::string&) -> bool { return true; },
isItemUnlocked ? std::move(isItemUnlocked)
: std::function<bool(const std::string&)>(
[](const std::string&) { return true; }),
rng)
{
}
@@ -135,6 +142,26 @@ TEST_CASE("BuildingSystem: place miner occupies expected body tiles", "[building
REQUIRE_FALSE(isTileOccupied(f.state, QPoint(1, 1)));
}
TEST_CASE("buildingsInBox covers a body cell the box only reaches into", "[building]")
{
PlacementFixture f;
const BuildingId id = f.bs.place(f.state, BuildingType::Miner, QPoint(0, 0),
Rotation::East, 0).value();
// Body at (0,0),(1,0),(0,1). The box is unsnapped and lies wholly within cell
// (1,0) without filling it, which is enough: a building is covered when the box
// overlaps any of its body cells (REQ-UI-MULTI-SELECT, Coverage).
const std::vector<BuildingId> grazed =
buildingsInBox(f.state, QRectF(1.6, 0.4, 0.2, 0.2));
REQUIRE(grazed.size() == 1);
REQUIRE(grazed.front() == id);
// (1,1) is the output-port tile, not a body cell, so a box inside it covers
// nothing even though it is surrounded by the miner's cells.
REQUIRE(buildingsInBox(f.state, QRectF(1.2, 1.2, 0.5, 0.5)).empty());
}
// -- World-bounds rejection (REQ-BLD-PLACE-VALID) ---------------------------
TEST_CASE("BuildingSystem: place rejects a building above the world (y < 0)", "[building]")
@@ -927,6 +954,135 @@ TEST_CASE("BuildingSystem: setRecipe clears output buffer and active production"
// Reprocessing plant -- per-item output buffers (REQ-MAT-OUTPUT-BUFFER)
// ---------------------------------------------------------------------------
TEST_CASE("ConfigLoader: the outputs shorthand and one output_group load alike",
"[config]")
{
// `outputs = [...]` is exactly one group holding those items (REQ-MAT-OUTPUT-GROUP),
// so a recipe written either way behaves identically.
PlacementFixture f;
const RecipeDef* shorthand =
f.cfg.recipes.findRecipeDef("iron_ingot", BuildingType::Smelter);
REQUIRE(shorthand != nullptr);
REQUIRE(shorthand->outputGroups.size() == 1);
REQUIRE_FALSE(shorthand->outputGroups.front().probability.has_value());
// Sizing and the cycle gate read it as one group like any other.
Building smelter; smelter.type = BuildingType::Smelter;
smelter.recipeId = shorthand->id;
initBuffers(smelter, *shorthand);
REQUIRE(smelter.outputBuffer.caps.at(ItemType{"iron_ingot"})
== 2 * shorthand->outputGroups.front().items.front().amount);
REQUIRE(recipeOutputsFit(smelter, *shorthand));
}
TEST_CASE("BuildingSystem: a single-group recipe consumes no randomness", "[building]")
{
// Nothing is picked where there is one group, so no draw is made (REQ-MAT-OUTPUT-GROUP).
// Drawing here would consume entropy for every ordinary recipe and shift every later
// random outcome, which is what the two fixtures below would expose: they differ only
// in how far their generators have been advanced.
PlacementFixture quiet;
PlacementFixture advanced;
for (int i = 0; i < 50; ++i) { (void)advanced.rng(); }
Tick tickA = 0;
Tick tickB = 0;
const BuildingId a =
quiet.bs.place(quiet.state, BuildingType::Miner, QPoint(0, 0), Rotation::East, 0).value();
const BuildingId b =
advanced.bs.place(advanced.state, BuildingType::Miner, QPoint(0, 0), Rotation::East, 0).value();
quiet.bs.setRecipe(quiet.state, a, "mine_iron_ore");
advanced.bs.setRecipe(advanced.state, b, "mine_iron_ore");
const int ticks = static_cast<int>(secondsToTicks(10.0)) + 40;
runTicks(quiet.bs, quiet.cfg, quiet.state, quiet.belts, quiet.stock, ticks, tickA);
runTicks(advanced.bs, advanced.cfg, advanced.state, advanced.belts, advanced.stock,
ticks, tickB);
const Building* minerA = findBuilding(quiet.state, a);
const Building* minerB = findBuilding(advanced.state, b);
REQUIRE(minerA != nullptr);
REQUIRE(minerB != nullptr);
REQUIRE(minerA->getOutputItemCount() > 0);
REQUIRE(minerA->getOutputItemCount() == minerB->getOutputItemCount());
REQUIRE(minerA->production.has_value() == minerB->production.has_value());
}
TEST_CASE("BuildingSystem: a group's items are sized and gated together", "[building]")
{
// A group yields all of its items at once (REQ-MAT-OUTPUT-GROUP), so each is buffered
// at twice its own amount and the cycle needs room for all of them at once. No config
// recipe has a multi-item group yet, so one is built here.
PlacementFixture f;
RecipeDef recipe;
recipe.id = "multi_item_group";
recipe.building = BuildingType::Assembler;
recipe.durationSeconds = 1.0;
recipe.inputs.push_back(RecipeIngredient{"iron_ore", 1});
RecipeOutputGroup group;
group.items.push_back(RecipeOutput{"iron_ingot", 2});
group.items.push_back(RecipeOutput{"silicon", 1});
recipe.outputGroups.push_back(group);
Building assembler; assembler.type = BuildingType::Assembler;
initBuffers(assembler, recipe);
REQUIRE(assembler.outputBuffer.caps.at(ItemType{"iron_ingot"}) == 4);
REQUIRE(assembler.outputBuffer.caps.at(ItemType{"silicon"}) == 2);
// Both fit while both have room.
REQUIRE(recipeOutputsFit(assembler, recipe));
// One item of the group short of room blocks the whole cycle, even though the other
// still has plenty: the group cannot be produced in halves.
assembler.outputBuffer.items.push_back(makeItem("silicon"));
assembler.outputBuffer.items.push_back(makeItem("silicon"));
REQUIRE(outputBufferHasRoom(assembler, ItemType{"iron_ingot"}, 2));
REQUIRE_FALSE(outputBufferHasRoom(assembler, ItemType{"silicon"}, 1));
REQUIRE_FALSE(recipeOutputsFit(assembler, recipe));
}
TEST_CASE("BuildingSystem: a group with a locked item is never picked", "[building]")
{
// A group's items come together, so a group holding any locked item is dropped whole
// (REQ-LOCK-OUTPUT-POOL). Here only circuit_board is unlocked, so every cycle must
// yield that group however the weights are stacked -- iron_ingot's group carries the
// largest weight of the three and would dominate were the filter not applied.
PlacementFixture f(std::nullopt,
[](const std::string& id) { return id == "circuit_board"; });
Tick tick = 0;
const BuildingId id = f.bs.place(f.state, BuildingType::ReprocessingPlant,
QPoint(0, 0), Rotation::East, 0).value();
runTicks(f.bs, f.cfg, f.state, f.belts, f.stock,
static_cast<int>(secondsToTicks(25.0)) + 1, tick);
f.bs.setRecipe(f.state, id, "reprocessing_cycle");
// Run many cycles, refilling the scrap and draining the output each time so the plant
// never stalls. A broken filter would show iron_ingot within a few rounds.
int produced = 0;
for (int round = 0; round < 20; ++round)
{
f.bs.forEachBuilding(f.state, [](Building& building) {
if (building.type != BuildingType::ReprocessingPlant) { return; }
building.inputBuffer.counts[ItemType{"scrap"}] =
building.inputBuffer.caps.at(ItemType{"scrap"});
building.outputBuffer.items.clear();
for (std::vector<BeltItemSlot>& lane : building.emergingItems) { lane.clear(); }
});
runTicks(f.bs, f.cfg, f.state, f.belts, f.stock,
static_cast<int>(secondsToTicks(3.0)) + 1, tick);
for (const Item& item : outputSideItems(*findBuilding(f.state, id)))
{
CHECK(item.type.id == "circuit_board");
++produced;
}
}
REQUIRE(produced > 0);
}
TEST_CASE("BuildingSystem: reprocessing plant sizes one output buffer per possible roll",
"[building]")
{
@@ -1834,9 +1990,10 @@ TEST_CASE("BuildingSystem: getProductionStatus classifies production state", "[b
// Sized the way the simulation sizes it (REQ-MAT-OUTPUT-BUFFER).
initBuffers(assembler, *assemblerRecipe);
const std::string outputItemId = assemblerRecipe->outputs.front().item;
const std::string outputItemId =
assemblerRecipe->outputGroups.front().items.front().item;
int cycleOutput = 0;
for (const RecipeOutput& out : assemblerRecipe->outputs)
for (const RecipeOutput& out : assemblerRecipe->outputGroups.front().items)
{
cycleOutput += out.amount;
}
@@ -1875,17 +2032,21 @@ TEST_CASE("BuildingSystem: getProductionStatus classifies production state", "[b
{
if (r.building != BuildingType::Assembler || r.inputs.empty()) { continue; }
int total = 0;
for (const RecipeOutput& out : r.outputs) { total += out.amount; }
for (const RecipeOutput& out : r.outputGroups.front().items)
{
total += out.amount;
}
if (total >= 2) { multiOutputRecipe = &r; break; }
}
REQUIRE(multiOutputRecipe != nullptr);
int cycleOutput = 0;
for (const RecipeOutput& out : multiOutputRecipe->outputs)
for (const RecipeOutput& out : multiOutputRecipe->outputGroups.front().items)
{
cycleOutput += out.amount;
}
const std::string outputItemId = multiOutputRecipe->outputs.front().item;
const std::string outputItemId =
multiOutputRecipe->outputGroups.front().items.front().item;
Building assembler; assembler.type = BuildingType::Assembler;
assembler.recipeId = multiOutputRecipe->id;
@@ -1924,7 +2085,7 @@ TEST_CASE("BuildingSystem: getProductionStatus classifies production state", "[b
}
}
REQUIRE(reprocessingRecipe != nullptr);
REQUIRE(reprocessingRecipe->outputs.size() >= 2);
REQUIRE(reprocessingRecipe->outputGroups.size() >= 2);
Building plant; plant.type = BuildingType::ReprocessingPlant;
plant.recipeId = reprocessingRecipe->id;
@@ -1939,8 +2100,10 @@ TEST_CASE("BuildingSystem: getProductionStatus classifies production state", "[b
// Fill one outcome's buffer and leave the rest untouched -> yellow, even though
// the other outcomes still have room.
const std::string firstItemId = reprocessingRecipe->outputs.front().item;
const std::string lastItemId = reprocessingRecipe->outputs.back().item;
const std::string firstItemId =
reprocessingRecipe->outputGroups.front().items.front().item;
const std::string lastItemId =
reprocessingRecipe->outputGroups.back().items.front().item;
for (int i = 0; i < plant.outputBuffer.caps.at(ItemType{firstItemId}); ++i)
{
plant.outputBuffer.items.push_back(makeItem(firstItemId));

View File

@@ -84,11 +84,6 @@ TEST_CASE("ConfigLoader loads the committed bin/config/ configs end-to-end", "[c
REQUIRE(cfg.world.rallyOrbitRadius_tiles == Approx(5.0));
REQUIRE(cfg.world.scrapPerThreat == Approx(1.0));
// Optional header building blocks tooltip (REQ-UI-BLOCKS-TOOLTIP).
REQUIRE(cfg.world.buildingBlocksTooltip.has_value());
REQUIRE(*cfg.world.buildingBlocksTooltip ==
"Spend building blocks to build; deliver them to the HQ to gain more.");
// Optional header artifact tooltip (REQ-UI-ARTIFACTS-TOOLTIP).
REQUIRE(cfg.world.artifactTooltip.has_value());
REQUIRE(*cfg.world.artifactTooltip ==
@@ -130,22 +125,26 @@ TEST_CASE("ConfigLoader loads the committed bin/config/ configs end-to-end", "[c
REQUIRE(*salvageBayIt->tooltip == "Drop-off point for salvage ships.");
REQUIRE_FALSE(minerIt->tooltip.has_value());
// recipes.toml reprocessing cycle has three weighted outputs.
// recipes.toml -- the reprocessing cycle is written as three weighted output groups,
// each yielding one item (REQ-MAT-OUTPUT-GROUP).
const auto reproIt = std::find_if(
cfg.recipes.recipes.begin(), cfg.recipes.recipes.end(),
[](const RecipeDef& r) { return r.id == "reprocessing_cycle"; });
REQUIRE(reproIt != cfg.recipes.recipes.end());
REQUIRE(reproIt->building == BuildingType::ReprocessingPlant);
REQUIRE(reproIt->outputs.size() == 3);
REQUIRE(reproIt->outputs[0].probability.has_value());
REQUIRE(reproIt->outputGroups.size() == 3);
REQUIRE(reproIt->outputGroups[0].probability.has_value());
REQUIRE(reproIt->outputGroups[0].items.size() == 1);
// Non-reprocessing recipes don't carry probability.
// The `outputs = [...]` shorthand loads as one group carrying no weight: with a single
// group nothing is picked, so there is nothing to weigh.
const auto ironIngotIt = std::find_if(
cfg.recipes.recipes.begin(), cfg.recipes.recipes.end(),
[](const RecipeDef& r) { return r.id == "iron_ingot"; });
REQUIRE(ironIngotIt != cfg.recipes.recipes.end());
REQUIRE(ironIngotIt->outputs.size() == 1);
REQUIRE_FALSE(ironIngotIt->outputs[0].probability.has_value());
REQUIRE(ironIngotIt->outputGroups.size() == 1);
REQUIRE(ironIngotIt->outputGroups[0].items.size() == 1);
REQUIRE_FALSE(ironIngotIt->outputGroups[0].probability.has_value());
// ships.toml — combat ships have default_modules with a weapon; salvage ships don't.
const auto interceptorIt = std::find_if(

View File

@@ -198,19 +198,29 @@ TEST_CASE("ControlAction: contexts are named by mode and selection", "[controls]
== ControlContextKind::Deconstruct);
}
TEST_CASE("ControlAction: Q enters deconstruct mode, or leaves the active one",
// The three cases of Q, in the order REQ-UI-HOTKEYS evaluates them.
TEST_CASE("ControlAction: Q leaves the active mode, else clears, else deconstructs",
"[controls]")
{
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, generalContext())
== ControlAction::EnterDeconstruct);
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, selectionContext())
== ControlAction::EnterDeconstruct);
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, builderContext(BuildingType::Belt))
== ControlAction::ExitMode);
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, blueprintContext())
== ControlAction::ExitMode);
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, deconstructContext())
== ControlAction::ExitMode);
// Whatever the selection holds: clearing it is not a buildings-only action.
ControlContext fieldSelection = selectionContext(false);
fieldSelection.selection = ControlSelection::FieldObjects;
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, selectionContext())
== ControlAction::ClearSelection);
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, fieldSelection)
== ControlAction::ClearSelection);
// Only with nothing to clear and no mode to leave does Q enter deconstruct mode --
// which is what makes it two presses from a selection.
REQUIRE(resolveKeyAction(Qt::Key_Q, Qt::NoModifier, generalContext())
== ControlAction::EnterDeconstruct);
}
TEST_CASE("ControlAction: Ctrl distinguishes the chords, other modifiers do not",
@@ -320,9 +330,14 @@ TEST_CASE("ControlAction: selection rows appear only once something is selected"
REQUIRE(contains(general, ControlAction::EnterDeconstruct));
REQUIRE_FALSE(contains(general, ControlAction::AddToSelection));
REQUIRE_FALSE(contains(general, ControlAction::CreateBlueprint));
REQUIRE_FALSE(contains(general, ControlAction::ClearSelection));
REQUIRE(contains(selection, ControlAction::AddToSelection));
REQUIRE(contains(selection, ControlAction::AddAreaToSelection));
REQUIRE(contains(selection, ControlAction::CreateBlueprint));
REQUIRE(contains(selection, ControlAction::EnterDeconstruct));
// Q clears here instead of entering deconstruct mode, and its row sits last, as the
// row that hands the context back does in every context (REQ-UI-CONTROLS-CONTENT).
REQUIRE(contains(selection, ControlAction::ClearSelection));
REQUIRE_FALSE(contains(selection, ControlAction::EnterDeconstruct));
REQUIRE(selection.back() == ControlAction::ClearSelection);
}

View File

@@ -1,5 +1,6 @@
#include "catch.hpp"
#include <QRectF>
#include <QSize>
#include <QVector2D>
@@ -210,17 +211,16 @@ TEST_CASE("entityAtWorldPos never returns debris", "[debris]")
REQUIRE((entityAtWorldPos(admin, QVector2D(3.0f, 4.0f)) == entt::null));
}
TEST_CASE("debrisInBox returns exactly the debris inside the tile rectangle", "[debris]")
TEST_CASE("debrisInBox returns exactly the debris the box encloses", "[debris]")
{
EntityAdmin admin;
DebrisSystem ss(admin);
const entt::entity inA = ss.spawn(QVector2D(1.2f, 2.7f), 1, 100); // tile (1,2)
const entt::entity inB = ss.spawn(QVector2D(4.9f, 5.1f), 1, 100); // tile (4,5)
const entt::entity inA = ss.spawn(QVector2D(1.2f, 2.7f), 1, 100);
const entt::entity inB = ss.spawn(QVector2D(4.9f, 5.1f), 1, 100);
const entt::entity outX = ss.spawn(QVector2D(10.0f, 10.0f), 1, 100);
// Box given in reversed corner order to confirm normalization.
const std::vector<entt::entity> hit = debrisInBox(admin, QPoint(5, 5), QPoint(0, 0));
const std::vector<entt::entity> hit = debrisInBox(admin, QRectF(0.0, 0.0, 6.0, 6.0));
REQUIRE(hit.size() == 2);
REQUIRE(contains(hit, inA));
@@ -228,6 +228,23 @@ TEST_CASE("debrisInBox returns exactly the debris inside the tile rectangle", "[
REQUIRE_FALSE(contains(hit, outX));
}
TEST_CASE("debrisInBox cuts within a tile, not along the tile grid", "[debris]")
{
EntityAdmin admin;
DebrisSystem ss(admin);
const entt::entity inTile = ss.spawn(QVector2D(1.8f, 2.5f), 1, 100);
// Same tile (1,2) as the piece above, but on the far side of the box's left edge:
// a tile-snapped box would take both (REQ-UI-MULTI-SELECT, Coverage).
const entt::entity outTile = ss.spawn(QVector2D(1.2f, 2.5f), 1, 100);
const std::vector<entt::entity> hit = debrisInBox(admin, QRectF(1.5, 2.0, 4.0, 4.0));
REQUIRE(hit.size() == 1);
REQUIRE(contains(hit, inTile));
REQUIRE_FALSE(contains(hit, outTile));
}
TEST_CASE("actorsInBox returns living ships and stations, excluding debris and dead actors",
"[actor]")
{
@@ -236,10 +253,10 @@ TEST_CASE("actorsInBox returns living ships and stations, excluding debris and d
// Two living ships inside the box: one player, one enemy.
const entt::entity playerShip = admin.spawnShip(
QVector2D(1.5f, 2.5f), 100.0f, 100.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 5.0f,
"fighter", false); // tile (1,2)
"fighter", false);
const entt::entity enemyShip = admin.spawnShip(
QVector2D(4.2f, 5.8f), 100.0f, 100.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 5.0f,
"raider", true); // tile (4,5)
"raider", true);
// A dead ship inside the box is excluded.
const entt::entity deadShip = admin.spawnShip(
@@ -251,7 +268,7 @@ TEST_CASE("actorsInBox returns living ships and stations, excluding debris and d
QVector2D(20.0f, 20.0f), 100.0f, 100.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 5.0f,
"fighter", false);
// A station is included when any body cell lies inside the box.
// A station is included when the box overlaps any body cell.
const std::vector<QPoint> stationCells{ QPoint(2, 2), QPoint(3, 2) };
const entt::entity station = admin.spawnStation(
QPoint(2, 2), QSize(2, 1), stationCells, 200.0f, 200.0f, true);
@@ -260,7 +277,7 @@ TEST_CASE("actorsInBox returns living ships and stations, excluding debris and d
admin.spawnDebris(QVector2D(1.0f, 1.0f), 5, Tick(1000));
admin.spawnHqProxy(QVector2D(0.5f, 0.5f), 500.0f, 500.0f);
const std::vector<entt::entity> hit = actorsInBox(admin, QPoint(5, 5), QPoint(0, 0));
const std::vector<entt::entity> hit = actorsInBox(admin, QRectF(0.0, 0.0, 6.0, 6.0));
REQUIRE(hit.size() == 3);
REQUIRE(contains(hit, playerShip));
@@ -269,3 +286,32 @@ TEST_CASE("actorsInBox returns living ships and stations, excluding debris and d
REQUIRE_FALSE(contains(hit, deadShip));
REQUIRE_FALSE(contains(hit, outsideShip));
}
TEST_CASE("actorsInBox takes a ship by its position and a station by its footprint",
"[actor]")
{
EntityAdmin admin;
// Ship inside the tile the box only reaches into: taken, because the box contains
// its position (REQ-UI-MULTI-SELECT, Coverage).
const entt::entity shipInside = admin.spawnShip(
QVector2D(3.9f, 3.9f), 100.0f, 100.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 5.0f,
"fighter", false);
// Same tile (3,3), outside the box: a tile-snapped box would take it too.
const entt::entity shipOutside = admin.spawnShip(
QVector2D(3.1f, 3.1f), 100.0f, 100.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 5.0f,
"fighter", false);
// The box reaches 0.5 tiles into the station's only cell, which is enough: a
// station is covered when the box overlaps its footprint.
const std::vector<QPoint> stationCells{ QPoint(4, 3) };
const entt::entity station = admin.spawnStation(
QPoint(4, 3), QSize(1, 1), stationCells, 200.0f, 200.0f, true);
const std::vector<entt::entity> hit = actorsInBox(admin, QRectF(3.5, 3.5, 1.0, 1.0));
REQUIRE(hit.size() == 2);
REQUIRE(contains(hit, shipInside));
REQUIRE(contains(hit, station));
REQUIRE_FALSE(contains(hit, shipOutside));
}

View File

@@ -12,7 +12,11 @@ static QRect makeBand()
return QRect(0, 0, 1000, 600);
}
static const int kMarginPx = 8;
// The two distances the rules run on, deliberately different (REQ-UI-SELECTION-PANEL):
// the edge margin the panel keeps from the view and from the widgets it steps around, and
// the wider gap it keeps from the selection -- half a tile, so 20 px at a 40 px tile.
static const int kMarginPx = 8;
static const int kSelectionGapPx = 20;
TEST_CASE("With nothing in the way a widget may use the whole band", "[layout]")
{
@@ -74,25 +78,34 @@ TEST_CASE("A widget filling the column leaves nothing", "[layout]")
TEST_CASE("The panel stands to the right of the selection where it fits", "[layout]")
{
// REQ-UI-SELECTION-PANEL: right of the anchor is the first choice.
REQUIRE(chooseSide(makeBand(), QRect(100, 100, 60, 60), 300, kMarginPx)
REQUIRE(chooseSide(makeBand(), QRect(100, 100, 60, 60), 300, kSelectionGapPx)
== PanelSide::Right);
}
TEST_CASE("The panel goes left when the right cannot hold it", "[layout]")
{
// A selection near the right edge leaves 100 px there, not enough for a 300 px
// panel, and the left is wide open.
REQUIRE(chooseSide(makeBand(), QRect(880, 100, 20, 60), 300, kMarginPx)
// A selection near the right edge leaves 80 px there once the gap it keeps from the
// selection is taken off, not enough for a 300 px panel, and the left is wide open.
REQUIRE(chooseSide(makeBand(), QRect(880, 100, 20, 60), 300, kSelectionGapPx)
== PanelSide::Left);
}
TEST_CASE("The room a side offers is measured less the gap", "[layout]")
{
// A 200 px panel beside a selection whose right edge leaves 214 px to the band's: it
// fits there on the margin alone, but not once the wider gap is taken off.
const QRect anchorRect(766, 100, 20, 60);
REQUIRE(chooseSide(makeBand(), anchorRect, 200, kMarginPx) == PanelSide::Right);
REQUIRE(chooseSide(makeBand(), anchorRect, 200, kSelectionGapPx) == PanelSide::Left);
}
TEST_CASE("Fitting on neither side, the panel takes the roomier one", "[layout]")
{
// A bounding box spanning most of the view: 192 px free on the left, 92 on the
// A bounding box spanning most of the view: 180 px free on the left, 80 on the
// right, and a 300 px panel fits in neither. It covers as little as it can.
REQUIRE(chooseSide(makeBand(), QRect(200, 100, 700, 200), 300, kMarginPx)
REQUIRE(chooseSide(makeBand(), QRect(200, 100, 700, 200), 300, kSelectionGapPx)
== PanelSide::Left);
REQUIRE(chooseSide(makeBand(), QRect(100, 100, 700, 200), 300, kMarginPx)
REQUIRE(chooseSide(makeBand(), QRect(100, 100, 700, 200), 300, kSelectionGapPx)
== PanelSide::Right);
}
@@ -102,17 +115,30 @@ TEST_CASE("Fitting on neither side, the panel takes the roomier one", "[layout]"
TEST_CASE("The panel sits beside the anchor with its top edges aligned", "[layout]")
{
// REQ-UI-SELECTION-PANEL: separated by the margin, growing away from the selection,
// top edge on the anchor's top edge.
// REQ-UI-SELECTION-PANEL: separated by the gap it keeps from the selection, growing
// away from it, top edge on the anchor's top edge.
const QRect placed = placeBesideAnchor(makeBand(), QRect(100, 120, 60, 60),
PanelSide::Right, QSize(300, 200), {},
kMarginPx);
REQUIRE(placed == QRect(168, 120, 300, 200));
kSelectionGapPx, kMarginPx);
REQUIRE(placed == QRect(180, 120, 300, 200));
const QRect placedLeft = placeBesideAnchor(makeBand(), QRect(500, 120, 60, 60),
const QRect placedLeft = placeBesideAnchor(makeBand(), QRect(520, 120, 60, 60),
PanelSide::Left, QSize(300, 200), {},
kMarginPx);
REQUIRE(placedLeft == QRect(192, 120, 300, 200));
kSelectionGapPx, kMarginPx);
REQUIRE(placedLeft == QRect(200, 120, 300, 200));
}
TEST_CASE("The gap separates the panel horizontally only", "[layout]")
{
// REQ-UI-SELECTION-PANEL: widening the gap moves the panel further from the selection
// sideways and nowhere else -- its top stays level with the top of what it describes.
const QRect anchorRect(100, 120, 60, 60);
REQUIRE(placeBesideAnchor(makeBand(), anchorRect, PanelSide::Right, QSize(300, 200),
{}, 0, kMarginPx)
== QRect(160, 120, 300, 200));
REQUIRE(placeBesideAnchor(makeBand(), anchorRect, PanelSide::Right, QSize(300, 200),
{}, kSelectionGapPx, kMarginPx)
== QRect(180, 120, 300, 200));
}
TEST_CASE("A panel that would hang below the view is lifted", "[layout]")
@@ -121,19 +147,20 @@ TEST_CASE("A panel that would hang below the view is lifted", "[layout]")
// the band, so it rises until it fits rather than overrunning it.
const QRect placed = placeBesideAnchor(makeBand(), QRect(100, 500, 60, 60),
PanelSide::Right, QSize(300, 200), {},
kMarginPx);
REQUIRE(placed == QRect(168, 400, 300, 200));
kSelectionGapPx, kMarginPx);
REQUIRE(placed == QRect(180, 400, 300, 200));
}
TEST_CASE("A panel standing over another widget rises above it", "[layout]")
{
// The controls panel in the bottom-left is in the way of a panel placed to the left
// of a selection: it clears the top of it by the margin (REQ-UI-CONTROLS-PANEL).
// of a selection: it clears the top of it by the edge margin, the gap from the
// selection having settled its left edge (REQ-UI-CONTROLS-PANEL).
const std::vector<QRect> occupied = { QRect(0, 300, 260, 300) };
const QRect placed = placeBesideAnchor(makeBand(), QRect(500, 250, 60, 60),
PanelSide::Left, QSize(300, 200), occupied,
kMarginPx);
REQUIRE(placed == QRect(192, 92, 300, 200));
kSelectionGapPx, kMarginPx);
REQUIRE(placed == QRect(180, 92, 300, 200));
}
TEST_CASE("A panel taller than the space left is capped", "[layout]")
@@ -141,8 +168,8 @@ TEST_CASE("A panel taller than the space left is capped", "[layout]")
// Capping is the caller's cue to scroll: it asked for 700 and got what there was.
const QRect placed = placeBesideAnchor(makeBand(), QRect(100, 100, 60, 60),
PanelSide::Right, QSize(300, 700), {},
kMarginPx);
REQUIRE(placed == QRect(168, 0, 300, 600));
kSelectionGapPx, kMarginPx);
REQUIRE(placed == QRect(180, 0, 300, 600));
}
TEST_CASE("A panel that fits on neither side is pushed inside the view", "[layout]")
@@ -151,7 +178,7 @@ TEST_CASE("A panel that fits on neither side is pushed inside the view", "[layou
// stands as far from the anchor as the band allows, not off the edge of it.
const QRect placed = placeBesideAnchor(makeBand(), QRect(100, 100, 700, 200),
PanelSide::Right, QSize(300, 200), {},
kMarginPx);
kSelectionGapPx, kMarginPx);
REQUIRE(placed == QRect(700, 100, 300, 200));
}

View File

@@ -690,3 +690,31 @@ TEST_CASE("calculateShipStats: maneuvering_thrusters additive maneuvering_accele
const float expected = (base_mpss + 10.0f) / tileSize;
CHECK(stats.maneuveringAcceleration_tpss == Approx(expected));
}
// The precondition every entry to the layout configuration dialog checks
// (REQ-MOD-UI-DIALOG, REQ-MOD-UI-AUTO-DIALOG, REQ-MOD-UI-PREVIEW). The empty id is the
// one that used to slip through: "(None)" clears a shipyard and differs from whatever
// was set, which is not the same as naming a schematic to configure.
TEST_CASE("ShipsConfig: a layout is configurable only for a ship that has one",
"[modules][config]")
{
const GameConfig cfg = loadTestConfig();
const ShipDef* interceptor = cfg.ships.findLayoutShipDef("interceptor");
REQUIRE(interceptor != nullptr);
CHECK(interceptor->id == "interceptor");
CHECK_FALSE(interceptor->layout.empty());
// The "(None)" option's id, and an id naming no ship at all.
CHECK(cfg.ships.findLayoutShipDef("") == nullptr);
CHECK(cfg.ships.findLayoutShipDef("no_such_ship") == nullptr);
// A ship that exists but defines no grid has nothing to place modules on either,
// where plain findShipDef still finds it.
ShipsConfig gridless;
ShipDef def;
def.id = "hull_only";
gridless.ships.push_back(def);
CHECK(gridless.findShipDef("hull_only") != nullptr);
CHECK(gridless.findLayoutShipDef("hull_only") == nullptr);
}

View File

@@ -30,6 +30,8 @@
#include "BlueprintLibrary.h"
#include "IconCaption.h"
#include "ItemIconCache.h"
#include "ItemTooltip.h"
#include "TooltipTrigger.h"
namespace
{
@@ -112,9 +114,10 @@ namespace
return face;
}
// A composed card face and the size to show it at; the button needs both, and only
// the composer knows the size it arrived at.
struct CardFace { QIcon icon; QSize size; };
// A composed card face, the size to show it at, and where in it the cost ended up:
// the button needs the first two, and only the composer knows the third, which is
// what the cost's tooltip is hung on (REQ-UI-ITEM-VALUE-TOOLTIP).
struct CardFace { QIcon icon; QSize size; QRect costRect; };
// The two-mode face of one card. The modes differ only in the text color, so an
// unaffordable card greys itself when Qt swaps the pixmap on the disabled button
@@ -141,62 +144,42 @@ namespace
textColor, dimColor, faceSize);
result.icon.addPixmap(face, mode);
result.size = result.size.expandedTo(getLogicalSize(face));
// Where composeCardFace put it: bottom left, its own width. Both modes
// compose the same text, so both arrive at the same rect.
const QSize costSize = getLogicalSize(costPixmap);
result.costRect = QRect(0, faceSize.height() - costSize.height(),
costSize.width(), costSize.height());
}
return result;
}
}
BlueprintSelectionDialog::BlueprintSelectionDialog(BlueprintLibrary* library,
ItemIconCache* itemIcons,
const ItemTooltipContext& context,
QWidget* parent)
: QDialog(parent)
: ModalDialog(parent)
, m_library(library)
, m_itemIcons(itemIcons)
, m_context(context)
, m_itemIcons(context.itemIcons)
{
setWindowTitle(tr("Blueprints"));
setModal(true);
// Frameless: the dialog draws its own header row, so an OS title bar would only
// repeat it (REQ-UI-BLUEPRINT-DIALOG). Square corners rather than rounded ones --
// rounding a top-level window needs a translucent background, which is unreliable
// on Windows. The border matches the build bar and the selection panel.
setWindowFlags(Qt::Dialog | Qt::FramelessWindowHint);
setAttribute(Qt::WA_StyledBackground, true);
setStyleSheet(QStringLiteral(
"BlueprintSelectionDialog { background-color: palette(window);"
" border: 1px solid palette(mid); }"));
QVBoxLayout* mainLayout = new QVBoxLayout(this);
mainLayout->setContentsMargins(kSpacingPx, kSpacingPx, kSpacingPx, kSpacingPx);
mainLayout->setSpacing(kSpacingPx);
QHBoxLayout* headerLayout = new QHBoxLayout();
headerLayout->setSpacing(kSpacingPx);
QLabel* titleLabel = new QLabel(tr("Blueprints"), this);
QFont headerFont = titleLabel->font();
headerFont.setBold(true);
titleLabel->setFont(headerFont);
headerLayout->addWidget(titleLabel);
QHBoxLayout* headerLayout = addHeader(mainLayout, tr("Blueprints"), true);
// Dimmed and bold, the treatment the build button hotkey badges use, so the
// shortcut reads as a reminder rather than a second title (REQ-UI-BUILD-COST).
// Inserted right after the title, left of the stretch the header ends with.
QLabel* hotkeyBadge = new QLabel(tr("Ctrl+V"), this);
hotkeyBadge->setFont(headerFont);
QFont badgeFont = hotkeyBadge->font();
badgeFont.setBold(true);
hotkeyBadge->setFont(badgeFont);
QPalette badgePalette = hotkeyBadge->palette();
badgePalette.setColor(hotkeyBadge->foregroundRole(),
palette().color(QPalette::Disabled, QPalette::WindowText));
hotkeyBadge->setPalette(badgePalette);
headerLayout->addWidget(hotkeyBadge);
headerLayout->addStretch();
QPushButton* closeButton = new QPushButton(QString(kCrossGlyph), this);
closeButton->setFixedSize(kSmallButtonSizePx, kSmallButtonSizePx);
closeButton->setToolTip(tr("Close"));
connect(closeButton, &QPushButton::clicked, this, &QDialog::reject);
headerLayout->addWidget(closeButton);
mainLayout->addLayout(headerLayout);
headerLayout->insertWidget(1, hotkeyBadge);
QScrollArea* scrollArea = new QScrollArea(this);
scrollArea->setWidgetResizable(true);
@@ -222,13 +205,11 @@ BlueprintSelectionDialog::BlueprintSelectionDialog(BlueprintLibrary* library,
setFixedSize(gridWidth + style()->pixelMetric(QStyle::PM_ScrollBarExtent)
+ 2 * kSpacingPx,
gridHeight + kSmallButtonSizePx + 3 * kSpacingPx);
}
// A frameless dialog does not get Qt's automatic centering on its parent.
if (parent)
{
const QRect parentRect = parent->window()->geometry();
move(parentRect.center() - QPoint(width() / 2, height() / 2));
}
bool BlueprintSelectionDialog::isDismissible() const
{
return true;
}
std::optional<int> BlueprintSelectionDialog::getChosenIndex() const
@@ -291,12 +272,28 @@ void BlueprintSelectionDialog::rebuildGrid()
body->setEnabled(m_library->getCanAfford(i));
cardLayout->addWidget(body);
// The cost is painted into the face, so what explains the item it names is a
// child of its own laid over that band -- placed by hand like the delete icon
// below (REQ-UI-ITEM-VALUE-TOOLTIP). The face is centered in the button, which
// is what the offset accounts for. A child of the body rather than a sibling, so
// that the press it does not handle still reaches the button and picks the
// blueprint; hover only, for the same reason (REQ-UI-TOOLTIP-TRIGGER).
QWidget* costArea = new QWidget(body);
const QPoint faceOrigin((cardSize.width() - face.size.width()) / 2,
(cardSize.height() - face.size.height()) / 2);
costArea->setGeometry(QRect(faceOrigin + face.costRect.topLeft(),
face.costRect.size()));
ItemTooltip::attachTo(*costArea, m_context, kBlockItemId,
TooltipTrigger::Trigger::HoverOnly);
// A sibling of the body rather than one of its children, and outside the
// layout: Qt disables a widget's children along with it, and the delete icon
// must stay enabled on an unaffordable card (REQ-UI-BLUEPRINT-DELETE).
QPushButton* deleteButton = new QPushButton(QString(kCrossGlyph), card);
deleteButton->setFixedSize(kSmallButtonSizePx, kSmallButtonSizePx);
deleteButton->setToolTip(tr("Delete blueprint"));
// Hover only: the click deletes the blueprint (REQ-UI-TOOLTIP-TRIGGER).
TooltipTrigger::attachText(*deleteButton, tr("Delete blueprint"),
TooltipTrigger::Trigger::HoverOnly);
deleteButton->move(cardSize.width() - kSmallButtonSizePx - kCardPaddingPx / 2,
cardSize.height() - kSmallButtonSizePx - kCardPaddingPx / 2);
deleteButton->raise();

View File

@@ -2,39 +2,46 @@
#include <optional>
#include <QDialog>
#include "ItemTooltipContext.h"
#include "ModalDialog.h"
class BlueprintLibrary;
class ItemIconCache;
class QGridLayout;
class QWidget;
// The blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG): a frameless modal panel
// showing every saved blueprint as a card in a scrolling two-column grid. The caller
// pauses the game and raises the dim overlay while it is open.
// The blueprint selection dialog (REQ-UI-BLUEPRINT-DIALOG): a modal panel showing every
// saved blueprint as a card in a scrolling two-column grid. The caller pauses the game
// while it is open.
//
// Clicking a card accepts the dialog and reports that blueprint's index; the caller
// enters placement mode afterwards, so the dialog is already closed by then
// (REQ-UI-BLUEPRINT-CARD). Deleting acts on the library immediately and leaves the
// dialog open (REQ-UI-BLUEPRINT-DELETE). Escape and the close button dismiss it with
// no other effect.
class BlueprintSelectionDialog : public QDialog
// dialog open (REQ-UI-BLUEPRINT-DELETE). Escape, Q, the close button, and a click
// outside dismiss it with no other effect (REQ-UI-DIALOG-DISMISS).
class BlueprintSelectionDialog : public ModalDialog
{
Q_OBJECT
public:
// Neither the library nor the icon cache is owned; both outlive the dialog.
BlueprintSelectionDialog(BlueprintLibrary* library, ItemIconCache* itemIcons,
// The context's item cache draws the block icon beside each cost, and the rest of it
// lets that cost explain the item it names (REQ-UI-ITEM-VALUE-TOOLTIP). Neither the
// library nor anything in the context is owned; both outlive the dialog.
BlueprintSelectionDialog(BlueprintLibrary* library,
const ItemTooltipContext& context,
QWidget* parent = nullptr);
std::optional<int> getChosenIndex() const;
bool isDismissible() const override;
private:
void rebuildGrid();
void onCardClicked(int index);
void onDeleteClicked(int index);
BlueprintLibrary* m_library;
ItemTooltipContext m_context;
ItemIconCache* m_itemIcons;
QWidget* m_gridContainer;
QGridLayout* m_grid;

View File

@@ -29,6 +29,7 @@
#include "InputMapper.h"
#include "ItemIconCache.h"
#include "Simulation.h"
#include "TooltipTrigger.h"
namespace
{
@@ -211,10 +212,12 @@ BuildButtonBar::BuildButtonBar(Simulation* sim, const GameConfig* config,
btn->setCheckable(true);
// The button face carries no name (REQ-UI-BUILD-COST), so the tooltip always
// leads with it and adds the config description when there is one
// (REQ-UI-BUILD-TOOLTIP).
btn->setToolTip(def.tooltip
// (REQ-UI-BUILD-TOOLTIP). Hover only: the click enters builder mode
// (REQ-UI-TOOLTIP-TRIGGER).
TooltipTrigger::attachText(*btn, def.tooltip
? QStringLiteral("%1\n%2").arg(name, QString::fromStdString(*def.tooltip))
: name);
: name,
TooltipTrigger::Trigger::HoverOnly);
layout->addWidget(btn);
const int idx = static_cast<int>(m_buttons.size());
@@ -253,7 +256,9 @@ BuildButtonBar::BuildButtonBar(Simulation* sim, const GameConfig* config,
"block cost once removed; a construction site removed before it is built "
"is refunded in full.")
.arg(refundPercentage);
m_deconstructButton->setToolTip(deconstructTooltip);
// Hover only: the click toggles the mode (REQ-UI-TOOLTIP-TRIGGER).
TooltipTrigger::attachText(*m_deconstructButton, deconstructTooltip,
TooltipTrigger::Trigger::HoverOnly);
layout->addWidget(m_deconstructButton);
connect(m_deconstructButton, &QPushButton::clicked, this, [this]() {
EventManager::getInstance()->sendEventImmediately(

View File

@@ -5,8 +5,11 @@ SET(HDRS
${CMAKE_CURRENT_SOURCE_DIR}/VisualsConfig.h
${CMAKE_CURRENT_SOURCE_DIR}/VisualsLoader.h
${CMAKE_CURRENT_SOURCE_DIR}/MainWindow.h
${CMAKE_CURRENT_SOURCE_DIR}/ModalDimOverlay.h
${CMAKE_CURRENT_SOURCE_DIR}/MessageDialog.h
${CMAKE_CURRENT_SOURCE_DIR}/ModalDialog.h
${CMAKE_CURRENT_SOURCE_DIR}/ModalLayer.h
${CMAKE_CURRENT_SOURCE_DIR}/ModalPauseScope.h
${CMAKE_CURRENT_SOURCE_DIR}/NameInputDialog.h
${CMAKE_CURRENT_SOURCE_DIR}/GameWorldView.h
${CMAKE_CURRENT_SOURCE_DIR}/InputMapper.h
${CMAKE_CURRENT_SOURCE_DIR}/WorldPrimitives.h
@@ -14,6 +17,7 @@ SET(HDRS
${CMAKE_CURRENT_SOURCE_DIR}/HeaderBar.h
${CMAKE_CURRENT_SOURCE_DIR}/FloatingPanel.h
${CMAKE_CURRENT_SOURCE_DIR}/BuildButtonBar.h
${CMAKE_CURRENT_SOURCE_DIR}/ExpandButton.h
${CMAKE_CURRENT_SOURCE_DIR}/SelectionPanel.h
${CMAKE_CURRENT_SOURCE_DIR}/SelectionBounds.h
${CMAKE_CURRENT_SOURCE_DIR}/ControlsPanel.h
@@ -26,6 +30,10 @@ SET(HDRS
${CMAKE_CURRENT_SOURCE_DIR}/SchematicChoiceDialog.h
${CMAKE_CURRENT_SOURCE_DIR}/RecipeSelectionDialog.h
${CMAKE_CURRENT_SOURCE_DIR}/RecipeLineRow.h
${CMAKE_CURRENT_SOURCE_DIR}/Tooltip.h
${CMAKE_CURRENT_SOURCE_DIR}/ItemTooltip.h
${CMAKE_CURRENT_SOURCE_DIR}/ItemTooltipContext.h
${CMAKE_CURRENT_SOURCE_DIR}/TooltipTrigger.h
${CMAKE_CURRENT_SOURCE_DIR}/OptionButton.h
${CMAKE_CURRENT_SOURCE_DIR}/ItemProducers.h
${CMAKE_CURRENT_SOURCE_DIR}/ItemIconCache.h
@@ -43,13 +51,17 @@ SET(SRCS
${SRCS}
${CMAKE_CURRENT_SOURCE_DIR}/VisualsLoader.cpp
${CMAKE_CURRENT_SOURCE_DIR}/MainWindow.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ModalDimOverlay.cpp
${CMAKE_CURRENT_SOURCE_DIR}/MessageDialog.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ModalDialog.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ModalLayer.cpp
${CMAKE_CURRENT_SOURCE_DIR}/NameInputDialog.cpp
${CMAKE_CURRENT_SOURCE_DIR}/GameWorldView.cpp
${CMAKE_CURRENT_SOURCE_DIR}/InputMapper.cpp
${CMAKE_CURRENT_SOURCE_DIR}/WorldPrimitives.cpp
${CMAKE_CURRENT_SOURCE_DIR}/WorldRenderer.cpp
${CMAKE_CURRENT_SOURCE_DIR}/HeaderBar.cpp
${CMAKE_CURRENT_SOURCE_DIR}/BuildButtonBar.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ExpandButton.cpp
${CMAKE_CURRENT_SOURCE_DIR}/SelectionPanel.cpp
${CMAKE_CURRENT_SOURCE_DIR}/SelectionBounds.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ControlsPanel.cpp
@@ -62,6 +74,9 @@ SET(SRCS
${CMAKE_CURRENT_SOURCE_DIR}/SchematicChoiceDialog.cpp
${CMAKE_CURRENT_SOURCE_DIR}/RecipeSelectionDialog.cpp
${CMAKE_CURRENT_SOURCE_DIR}/RecipeLineRow.cpp
${CMAKE_CURRENT_SOURCE_DIR}/Tooltip.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ItemTooltip.cpp
${CMAKE_CURRENT_SOURCE_DIR}/TooltipTrigger.cpp
${CMAKE_CURRENT_SOURCE_DIR}/OptionButton.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ItemProducers.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ItemIconCache.cpp

View File

@@ -63,6 +63,7 @@ QString getControlActionLabel(ControlAction action, const ControlContext& contex
case ControlAction::EnterDeconstruct: return Strings::tr("Deconstruct mode");
case ControlAction::CopyTemporary: return Strings::tr("Copy to temporary blueprint");
case ControlAction::CreateBlueprint: return Strings::tr("Create blueprint");
case ControlAction::ClearSelection: return Strings::tr("Clear selection");
case ControlAction::Place: return Strings::tr("Place");
case ControlAction::ApplySettings: return Strings::tr("Apply settings");
case ControlAction::PlaceBeltLine: return Strings::tr("Place belt line");

View File

@@ -57,14 +57,17 @@ QWidget* makeRow(ControlAction action, const ControlContext& context, QWidget* p
// Every badge is rendered from the binding the resolver matches, so a chip cannot
// claim a key that does nothing (REQ-UI-CONTROLS-ACCURACY). The chips of the row
// that leaves the mode are the ones marked, not its label (REQ-UI-CONTROLS-CARD).
const bool exitsMode = (action == ControlAction::ExitMode);
// that leaves the context are the ones marked, not its label (REQ-UI-CONTROLS-CARD):
// leaving a build mode and clearing the selection are the same gesture to the player,
// one key that hands the context back, so they are marked alike.
const bool backsOut = (action == ControlAction::ExitMode
|| action == ControlAction::ClearSelection);
const std::vector<ControlBinding> bindings = getControlActionBindings(action, context);
for (const ControlBinding& binding : bindings)
{
QLabel* badge = new QLabel(getControlBindingBadge(binding), row);
badge->setObjectName(exitsMode ? QStringLiteral("controlBadgeExit")
: QStringLiteral("controlBadge"));
badge->setObjectName(backsOut ? QStringLiteral("controlBadgeExit")
: QStringLiteral("controlBadge"));
layout->addWidget(badge);
}

99
src/ui/ExpandButton.cpp Normal file
View File

@@ -0,0 +1,99 @@
#include "ExpandButton.h"
#include <QLabel>
#include <QPalette>
#include <QPixmap>
#include <QVBoxLayout>
#include "Command.h"
#include "CommandRequestedEvent.h"
#include "EventManager.h"
#include "FloatingLayoutInvalidatedEvent.h"
#include "IconCaption.h"
#include "ItemIconCache.h"
#include "ItemTooltip.h"
#include "Simulation.h"
#include "TooltipTrigger.h"
ExpandButton::ExpandButton(const ItemTooltipContext& context, QWidget* parent)
: OptionButton(parent)
, m_context(context)
{
QVBoxLayout* face = new QVBoxLayout(this);
face->setContentsMargins(8, 4, 8, 4);
face->setSpacing(1);
// Names the action, not an item, so it says nothing of its own and stays out of the
// mouse's way -- a click anywhere on the face reaches the button beneath it.
QLabel* actionLabel = new QLabel(tr("Expand"), this);
actionLabel->setAlignment(Qt::AlignCenter);
actionLabel->setAttribute(Qt::WA_TransparentForMouseEvents, true);
face->addWidget(actionLabel);
// The cost line, deliberately not transparent to the mouse: it names an item and has
// to be hoverable to explain it. Hover only, the click being the button's
// (REQ-UI-ITEM-VALUE-TOOLTIP). A label ignores presses, so they still reach the
// button.
m_costLabel = new QLabel(this);
m_costLabel->setAlignment(Qt::AlignCenter);
face->addWidget(m_costLabel);
ItemTooltip::attachTo(*m_costLabel, m_context, kBlockItemId,
TooltipTrigger::Trigger::HoverOnly);
// Carries no payload: the simulation derives the cost and the column count from its
// own expansion counter (REQ-EXP-UNLOCK, REQ-GW-ASTEROID-EXPAND).
connect(this, &QPushButton::clicked, this, []() {
EventManager::getInstance()->sendEventImmediately(
std::make_shared<CommandRequestedEvent>(
std::make_shared<ExpandAsteroidCommand>()));
});
refresh();
registerForEvents();
}
ExpandButton::~ExpandButton()
{
unregisterForEvents();
}
void ExpandButton::handleEvent(std::shared_ptr<const ExpansionCostChangedEvent> /*event*/)
{
refresh();
}
void ExpandButton::handleEvent(std::shared_ptr<const BuildingBlocksChangedEvent> /*event*/)
{
refresh();
}
void ExpandButton::refresh()
{
const int blocks = m_context.sim->getBuildingBlocksStock();
const int expansionCost = m_context.sim->getCurrentExpansionCost();
setEnabled(blocks >= expansionCost);
// The cost reads as it does everywhere else: the number, then the block icon in place
// of a trailing `Blocks` word (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-ICON). With no icon
// file the word comes back, since nothing else on the line would name the item.
const QPixmap icon = m_context.itemIcons->getInlineIcon(kBlockItemId, font());
if (icon.isNull())
{
m_costLabel->setPixmap(QPixmap());
m_costLabel->setText(tr("%1 Blocks").arg(expansionCost));
}
else
{
m_costLabel->setText(QString());
m_costLabel->setPixmap(renderCaptionWithIcon(
QString::number(expansionCost), icon, font(),
palette().color(isEnabled() ? QPalette::Active : QPalette::Disabled,
QPalette::ButtonText)));
}
// A cost of a different width re-centers the button on its columns, which is the
// owner's to do (ui/FloatingPanel.h, MainWindow::placeExpandButton).
EventManager::getInstance()->sendEventImmediately(
std::make_shared<FloatingLayoutInvalidatedEvent>());
}

44
src/ui/ExpandButton.h Normal file
View File

@@ -0,0 +1,44 @@
#pragma once
#include <memory>
#include "BuildingBlocksChangedEvent.h"
#include "EventHandler.h"
#include "ExpansionCostChangedEvent.h"
#include "ItemTooltipContext.h"
#include "OptionButton.h"
class QLabel;
// The asteroid expansion button (REQ-UI-EXPAND-BUTTON): a button that stands in the game
// world on the columns the next purchase would unlock, rather than in the header bar.
//
// It knows what it says and what it costs; where it stands is MainWindow's to decide, the
// position being a place in the world and this button knowing nothing of the view's scroll
// (MainWindow::placeExpandButton).
//
// Its face is two lines, `Expand` over the cost, so that the cost is a display naming an
// item and can explain it the way every other item value does -- on hover only, the click
// belonging to the button (REQ-UI-ITEM-VALUE-TOOLTIP).
class ExpandButton : public OptionButton,
public CombinedEventHandler<ExpansionCostChangedEvent,
BuildingBlocksChangedEvent>
{
Q_OBJECT
public:
// Nothing in the context is owned; all of it must outlive this widget.
explicit ExpandButton(const ItemTooltipContext& context, QWidget* parent = nullptr);
~ExpandButton() override;
private:
void handleEvent(std::shared_ptr<const ExpansionCostChangedEvent> event) override;
void handleEvent(std::shared_ptr<const BuildingBlocksChangedEvent> event) override;
// Re-states the cost and whether the player can pay it. Asks for a fresh placement
// pass afterwards, because a wider cost re-centers the button.
void refresh();
ItemTooltipContext m_context;
QLabel* m_costLabel;
};

View File

@@ -68,6 +68,7 @@
#include "BuildingBlocksChangedEvent.h"
#include "UnlockedBuildingsChangedEvent.h"
#include "ExpansionCostChangedEvent.h"
#include "ViewScrolledEvent.h"
#include "GameSpeedChangedEvent.h"
#include "SchematicChoicesAvailableEvent.h"
#include "PlayerCommandsAppliedEvent.h"
@@ -148,6 +149,7 @@ GameWorldView::GameWorldView(Simulation* sim, const GameConfig* config,
, m_debugDraw(false)
, m_rng(std::random_device{}())
, m_boxSelecting(false)
, m_boxDragMoved(false)
, m_gameOverShown(false)
, m_schematicChoiceShown(false)
{
@@ -294,12 +296,21 @@ void GameWorldView::onFrame()
const bool viewMoved =
m_camera.advance(m_panDirection, elapsed, getScrollBounds());
// While the view scrolls, the tile under a stationary cursor changes,
// so refresh the box-select rectangle even though no mouse move fires.
if (m_boxSelecting && viewMoved)
// Two things no mouse move reports: the world position under a stationary
// cursor changing as the view scrolls, and the cursor crossing onto a panel
// or out of the window, which ends the hover (REQ-BLD-GHOST).
if (viewMoved || isHoverLive() != m_hoverLive)
{
m_boxCurrentTile =
getCoordinates().widgetToTile(mapFromGlobal(QCursor::pos()));
refreshHover();
}
// The world-to-widget transform has changed, which no other event reports. What
// stands in the world rather than on the screen re-places itself on this
// (REQ-UI-EXPAND-BUTTON).
if (viewMoved)
{
EventManager::getInstance()->sendEventImmediately(
std::make_shared<ViewScrolledEvent>());
}
}
@@ -420,8 +431,14 @@ void GameWorldView::paintGL()
WorldRenderFrame GameWorldView::makeRenderFrame() const
{
return WorldRenderFrame{m_selection, m_buildMode, m_activeBeams, m_boxSelecting,
m_boxStartTile, m_boxCurrentTile, m_debugDraw};
// A box only reaches the renderer once the gesture reads as a drag: below the
// threshold there is nothing to draw and nothing the box marks that hovering does
// not mark already (REQ-UI-MULTI-SELECT).
std::optional<QRectF> boxWorldRect;
if (m_boxSelecting && m_boxDragMoved) { boxWorldRect = getBoxWorldRect(); }
return WorldRenderFrame{m_selection, m_buildMode, m_activeBeams, boxWorldRect,
m_debugDraw};
}
// ---------------------------------------------------------------------------
@@ -743,8 +760,10 @@ void GameWorldView::transferConfigTo(BuildingId id, const BlueprintBuilding& sou
void GameWorldView::updateTunnelGhost()
{
// The connection preview and entry/exit switch only apply at a valid placement
// (REQ-BLD-TUNNEL-MODE); at an invalid position the ghost stays a plain entry.
if (!m_buildMode.isGhostValid())
// (REQ-BLD-TUNNEL-MODE); at an invalid position, and where the cursor points at
// no tile at all, the ghost stays a plain entry.
const std::optional<QPoint>& ghostTile = m_buildMode.getGhostTile();
if (!ghostTile.has_value() || !m_buildMode.isGhostValid())
{
m_buildMode.setTunnelGhost(BuildingType::TunnelEntry, std::nullopt);
return;
@@ -754,7 +773,7 @@ void GameWorldView::updateTunnelGhost()
const TunnelLookup lookup = makeTunnelLookup(tunnels);
const TunnelCompletion completion =
resolveTunnelCompletion(lookup, m_buildMode.getGhostTile(),
resolveTunnelCompletion(lookup, *ghostTile,
m_buildMode.getGhostRotation(),
m_config->world.tunnelMaxDistance_tiles, m_cursorWorldPos);
m_buildMode.setTunnelGhost(completion.resolvedType, completion.partnerTile);
@@ -1132,7 +1151,12 @@ ControlContext GameWorldView::getControlContext() const
context.mode = m_buildMode.getMode();
context.draggingBelt = m_buildMode.isDraggingBelt();
context.hoveredGhostIsTransfer = m_buildMode.isHoveredGhostTransfer();
if (m_buildMode.isBuilderMode()) { context.builderType = m_buildMode.getBuilderType(); }
// The type a click would actually place, so the panel agrees with the ghost when
// tunnel mode resolves to an exit (REQ-BLD-TUNNEL-MODE).
if (m_buildMode.isBuilderMode())
{
context.builderType = m_buildMode.getEffectiveBuilderType();
}
// Buildings win over field objects, so the two are never both non-empty
// (REQ-UI-SELECTION-CATEGORIES).
@@ -1221,9 +1245,10 @@ void GameWorldView::mousePressEvent(QMouseEvent* event)
case ControlAction::ToggleDeconstruct:
// Start a deconstruct box drag; a plain click resolves as a 1x1 box on
// release (REQ-BLD-DECONSTRUCT-CLICK, REQ-BLD-DECONSTRUCT-BOX).
m_boxSelecting = true;
m_boxStartTile = tile;
m_boxCurrentTile = tile;
m_boxSelecting = true;
m_boxStartWorld = coordinates.widgetToWorld(event->pos());
m_boxCurrentWorld = m_boxStartWorld;
m_boxDragMoved = false;
break;
case ControlAction::Select:
@@ -1236,8 +1261,9 @@ void GameWorldView::mousePressEvent(QMouseEvent* event)
// selectAtPoint has already cleared the selection unless Ctrl is
// preserving it for an additive drag.
m_boxSelecting = true;
m_boxStartTile = tile;
m_boxCurrentTile = tile;
m_boxStartWorld = coordinates.widgetToWorld(event->pos());
m_boxCurrentWorld = m_boxStartWorld;
m_boxDragMoved = false;
}
break;
@@ -1290,8 +1316,10 @@ void GameWorldView::selectInBox(bool additive)
// mode: a Ctrl box adds and never deselects, where a Ctrl click toggles.
const SelectionMode mode = additive ? SelectionMode::Add : SelectionMode::Replace;
const QRectF worldBox = getBoxWorldRect();
const std::vector<BuildingId> boxIds =
buildingsInBox(m_sim->getFactoryState(), m_boxStartTile, m_boxCurrentTile);
buildingsInBox(m_sim->getFactoryState(), worldBox);
if (!boxIds.empty())
{
publishSelectionAnchor(mode, boxIds, {}, {});
@@ -1299,10 +1327,8 @@ void GameWorldView::selectInBox(bool additive)
return;
}
const std::vector<entt::entity> boxActors =
actorsInBox(m_sim->getAdmin(), m_boxStartTile, m_boxCurrentTile);
const std::vector<entt::entity> boxDebris =
debrisInBox(m_sim->getAdmin(), m_boxStartTile, m_boxCurrentTile);
const std::vector<entt::entity> boxActors = actorsInBox(m_sim->getAdmin(), worldBox);
const std::vector<entt::entity> boxDebris = debrisInBox(m_sim->getAdmin(), worldBox);
if (!boxActors.empty() || !boxDebris.empty())
{
publishSelectionAnchor(mode, {}, boxActors, boxDebris);
@@ -1314,40 +1340,43 @@ void GameWorldView::selectInBox(bool additive)
if (!additive) { m_selection.clearAll(); }
}
void GameWorldView::publishSelectionAnchor(SelectionMode mode,
const std::vector<BuildingId>& buildings,
const std::vector<entt::entity>& actors,
const std::vector<entt::entity>& debris)
void GameWorldView::clearSelectionForBuildMode()
{
// An additive gesture onto something already selected is growing that selection, not
// starting one, and the panel stays where it was put (REQ-UI-SELECTION-PANEL).
const bool startsSelection =
(mode == SelectionMode::Replace) || (m_selection.getSelectedBuildings().empty()
&& m_selection.getSelectedActors().empty()
&& m_selection.getSelectedDebris().empty());
if (!startsSelection)
{
return;
}
// Screen space, frozen here: the panel is placed against where the selection is at
// this moment and stays there, however far the view scrolls or the objects move
// afterwards.
const QRect anchorRect = getSelectionWidgetRect(*m_sim, getCoordinates(),
buildings, actors, debris);
if (anchorRect.isNull())
{
return;
}
EventManager::getInstance()->sendEventImmediately(
std::make_shared<SelectionAnchorChangedEvent>(anchorRect));
m_selection.clearAll();
}
void GameWorldView::mouseMoveEvent(QMouseEvent* event)
bool GameWorldView::isHoverLive() const
{
// underMouse() is false while the cursor sits on one of the floating panels,
// which are siblings of this widget rather than children, and while it is
// outside the window. A drag holding the button is the exception: it tracks the
// cursor wherever it goes until the button comes back up (REQ-UI-MULTI-SELECT,
// REQ-BLD-BELT-DRAG).
return underMouse() || m_boxSelecting || m_buildMode.isDraggingBelt();
}
void GameWorldView::refreshHover()
{
if (isHoverLive())
{
updateHoverAt(mapFromGlobal(QCursor::pos()));
}
else
{
m_buildMode.clearHover();
m_hoverLive = false;
}
}
void GameWorldView::updateHoverAt(QPoint cursorWidgetPos)
{
// Reached either from a mouse move, which only this widget receives, or from a
// hover refresh that has already established the cursor is on the world.
m_hoverLive = true;
const WorldCoordinates coordinates = getCoordinates();
const QPoint tile = coordinates.widgetToTile(event->pos());
m_cursorWorldPos = coordinates.widgetToWorld(event->pos());
const QPoint tile = coordinates.widgetToTile(cursorWidgetPos);
m_cursorWorldPos = coordinates.widgetToWorld(cursorWidgetPos);
if (m_buildMode.isBuilderMode())
{
@@ -1392,14 +1421,82 @@ void GameWorldView::mouseMoveEvent(QMouseEvent* event)
else if (m_buildMode.isDeconstructMode())
{
m_buildMode.setDeconstructHoverBuildingId(buildingAtTile(tile));
if (m_boxSelecting) { m_boxCurrentTile = tile; }
if (m_boxSelecting) { updateBoxDrag(cursorWidgetPos); }
}
else if (m_boxSelecting)
{
m_boxCurrentTile = tile;
updateBoxDrag(cursorWidgetPos);
}
}
void GameWorldView::updateBoxDrag(QPoint cursorWidgetPos)
{
const WorldCoordinates coordinates = getCoordinates();
m_boxCurrentWorld = coordinates.widgetToWorld(cursorWidgetPos);
// Measured against where the anchor sits on screen right now, not against where
// the button went down: a view that scrolls under a held button moves the anchor
// away from a motionless cursor, and that is a drag as much as moving the mouse
// is (REQ-UI-MULTI-SELECT).
const QPointF anchorWidgetPos = coordinates.worldToWidget(m_boxStartWorld);
const qreal travel_px = std::abs(cursorWidgetPos.x() - anchorWidgetPos.x())
+ std::abs(cursorWidgetPos.y() - anchorWidgetPos.y());
if (travel_px >= kBoxDragThresholdPixels) { m_boxDragMoved = true; }
}
QRectF GameWorldView::getBoxWorldRect() const
{
if (!m_boxDragMoved)
{
// Still a click: the rectangle it spans has no area and would cover nothing,
// so the box is the whole tile the button went down on instead — what the
// click points at (REQ-UI-MULTI-SELECT, REQ-BLD-DECONSTRUCT-CLICK).
return QRectF(std::floor(m_boxStartWorld.x()), std::floor(m_boxStartWorld.y()),
1.0, 1.0);
}
return QRectF(QPointF(m_boxStartWorld.x(), m_boxStartWorld.y()),
QPointF(m_boxCurrentWorld.x(), m_boxCurrentWorld.y())).normalized();
}
void GameWorldView::publishSelectionAnchor(SelectionMode mode,
const std::vector<BuildingId>& buildings,
const std::vector<entt::entity>& actors,
const std::vector<entt::entity>& debris)
{
// An additive gesture onto something already selected is growing that selection, not
// starting one, and the panel stays where it was put (REQ-UI-SELECTION-PANEL).
const bool startsSelection =
(mode == SelectionMode::Replace) || (m_selection.getSelectedBuildings().empty()
&& m_selection.getSelectedActors().empty()
&& m_selection.getSelectedDebris().empty());
if (!startsSelection)
{
return;
}
// Screen space, frozen here: the panel is placed against where the selection is at
// this moment and stays there, however far the view scrolls or the objects move
// afterwards.
const QRect anchorRect = getSelectionWidgetRect(*m_sim, getCoordinates(),
buildings, actors, debris);
if (anchorRect.isNull())
{
return;
}
// The gap the panel keeps from that rectangle is half a tile (REQ-UI-SELECTION-PANEL),
// and this is where the tile size is known. It is sampled in the same moment as the
// rectangle and travels with it, so both describe the view as it stood when the
// selection started.
const int selectionGapPx = qRound(getCoordinates().getTilePx() / 2.0f);
EventManager::getInstance()->sendEventImmediately(
std::make_shared<SelectionAnchorChangedEvent>(anchorRect, selectionGapPx));
}
void GameWorldView::mouseMoveEvent(QMouseEvent* event)
{
updateHoverAt(event->pos());
}
void GameWorldView::mouseReleaseEvent(QMouseEvent* event)
{
if (event->button() != Qt::LeftButton) { return; }
@@ -1417,7 +1514,7 @@ void GameWorldView::mouseReleaseEvent(QMouseEvent* event)
m_boxSelecting = false;
const std::vector<BuildingId> boxIds =
buildingsInBox(m_sim->getFactoryState(), m_boxStartTile, m_boxCurrentTile);
buildingsInBox(m_sim->getFactoryState(), getBoxWorldRect());
const bool controlHeld = (event->modifiers() & Qt::ControlModifier) != 0;
const ControlAction dragAction =
@@ -1500,8 +1597,14 @@ void GameWorldView::rotateGhost(bool clockwise)
if (m_buildMode.isBuilderMode())
{
m_buildMode.rotateGhost(clockwise);
// The new facing is kept whatever the cursor is over; what it means for the
// world is only re-resolved while the cursor points at a tile (REQ-BLD-GHOST).
const std::optional<QPoint>& ghostTile = m_buildMode.getGhostTile();
if (!ghostTile.has_value()) { return; }
m_buildMode.setGhostValidity(
canPlaceBuildingHere(m_buildMode.getBuilderType(), m_buildMode.getGhostTile(),
canPlaceBuildingHere(m_buildMode.getBuilderType(), *ghostTile,
m_buildMode.getGhostRotation()));
// A new facing changes which tunnels the ghost could complete (REQ-BLD-TUNNEL-MODE).
if (m_buildMode.isTunnelMode()) { updateTunnelGhost(); }
@@ -1509,7 +1612,7 @@ void GameWorldView::rotateGhost(bool clockwise)
// without waiting for the next mouse move (REQ-BLD-BELT-DRAG).
if (m_buildMode.isDraggingBelt())
{
recomputeBeltDragPath(m_buildMode.getGhostTile());
recomputeBeltDragPath(*ghostTile);
}
}
else if (m_buildMode.isBlueprintMode())
@@ -1638,7 +1741,12 @@ void GameWorldView::handleEvent(std::shared_ptr<const BeamFiredEvent> event)
void GameWorldView::handleEvent(std::shared_ptr<const BuildingTypeSelectedEvent> event)
{
clearSelectionForBuildMode();
m_buildMode.enterBuilderMode(event->type);
// A mode entered by hotkey usually leaves the cursor exactly where it was, and no
// mouse move follows to place the ghost; entered from a build button it leaves the
// cursor on the bar, where there is nothing to hover (REQ-BLD-GHOST).
refreshHover();
}
void GameWorldView::handleEvent(std::shared_ptr<const ExitBuilderModeRequestedEvent> /*event*/)
@@ -1648,12 +1756,18 @@ void GameWorldView::handleEvent(std::shared_ptr<const ExitBuilderModeRequestedEv
void GameWorldView::handleEvent(std::shared_ptr<const DeconstructModeToggleRequestedEvent> /*event*/)
{
clearSelectionForBuildMode();
m_buildMode.toggleDeconstructMode();
refreshHover();
}
void GameWorldView::handleEvent(std::shared_ptr<const BlueprintPlacementRequestedEvent> event)
{
// The blueprint arrives already built from the selection this drops
// (REQ-UI-BLUEPRINT-TEMP, REQ-UI-SELECTION-EXCLUSIVE).
clearSelectionForBuildMode();
m_buildMode.enterBlueprintMode(event->blueprint);
refreshHover();
}
void GameWorldView::handleEvent(std::shared_ptr<const ExitBlueprintModeRequestedEvent> /*event*/)
@@ -1696,14 +1810,19 @@ void GameWorldView::handleEvent(std::shared_ptr<const GhostRotationRequestedEven
void GameWorldView::handleEvent(std::shared_ptr<const ModeCancelRequestedEvent> /*event*/)
{
// One key backs out of whichever mode is active, and enters deconstruct mode
// when none is (REQ-UI-HOTKEYS).
// One key backs out of whichever mode is active, and enters deconstruct mode
// when none is (REQ-UI-HOTKEYS).
// One key backs out of whichever mode is active, and enters deconstruct mode when
// none is (REQ-UI-HOTKEYS). The selection case of that key never reaches here: it
// resolves to its own event, so there is nothing left to clear by the time the
// fallthrough enters deconstruct mode (REQ-UI-SELECTION-EXCLUSIVE).
if (m_buildMode.getMode() == BuildMode::None) { m_buildMode.toggleDeconstructMode(); }
else { m_buildMode.exitCurrentMode(); }
}
void GameWorldView::handleEvent(std::shared_ptr<const SelectionClearRequestedEvent> /*event*/)
{
m_selection.clearAll();
}
void GameWorldView::handleEvent(std::shared_ptr<const DebugDrawToggleRequestedEvent> /*event*/)
{
m_debugDraw = !m_debugDraw;

View File

@@ -37,6 +37,7 @@
#include "ModeCancelRequestedEvent.h"
#include "PanDirectionChangedEvent.h"
#include "PauseToggleRequestedEvent.h"
#include "SelectionClearRequestedEvent.h"
#include "SpeedStepRequestedEvent.h"
#include "DebugDrawToggledEvent.h"
#include "ArtifactCountChangedEvent.h"
@@ -83,6 +84,7 @@ class GameWorldView : public QOpenGLWidget,
SpeedStepRequestedEvent,
GhostRotationRequestedEvent,
ModeCancelRequestedEvent,
SelectionClearRequestedEvent,
DebugDrawToggleRequestedEvent,
CommandRequestedEvent>
{
@@ -118,6 +120,13 @@ public:
// no blueprint is active and for the unnamed temporary one (REQ-UI-BLUEPRINT-TEMP).
QString getActiveBlueprintName() const;
// The world <-> widget transform for the current viewport size and scroll
// position. Cheap to build and deliberately not cached: it is a snapshot that
// a resize or a scroll invalidates, so every user takes a fresh one. Public because
// a widget standing in the world needs it to find its place (REQ-UI-EXPAND-BUTTON);
// a ViewScrolledEvent says when it has gone stale.
WorldCoordinates getCoordinates() const;
protected:
void initializeGL() override;
void paintGL() override;
@@ -149,6 +158,7 @@ private:
void handleEvent(std::shared_ptr<const SpeedStepRequestedEvent> event) override;
void handleEvent(std::shared_ptr<const GhostRotationRequestedEvent> event) override;
void handleEvent(std::shared_ptr<const ModeCancelRequestedEvent> event) override;
void handleEvent(std::shared_ptr<const SelectionClearRequestedEvent> event) override;
void handleEvent(std::shared_ptr<const DebugDrawToggleRequestedEvent> event) override;
void handleEvent(std::shared_ptr<const CommandRequestedEvent> event) override;
@@ -186,11 +196,6 @@ private:
// Gathers the interaction state the renderer needs for this frame.
WorldRenderFrame makeRenderFrame() const;
// The world <-> widget transform for the current viewport size and scroll
// position. Cheap to build and deliberately not cached: it is a snapshot that
// a resize or a scroll invalidates, so every user takes a fresh one.
WorldCoordinates getCoordinates() const;
float getAsteroidLeftEdge() const;
float getEnemyStationRightEdge() const;
// The camera's current pan limits, read fresh from the simulation each frame:
@@ -226,6 +231,38 @@ private:
// which is the only case that goes on to start a box drag.
bool selectAtPoint(QPoint tile, QVector2D worldPos, bool additive);
void selectInBox(bool additive);
// A build mode and a selection are mutually exclusive, so entering any mode drops
// the selection (REQ-UI-SELECTION-EXCLUSIVE). Called from each of the three events
// that enter a mode -- the only ways in, whichever button or key the player used.
// Clearing an empty selection publishes nothing, so the exiting half of the
// deconstruct toggle costs nothing.
void clearSelectionForBuildMode();
// Whether the cursor points at the game world at all: it does while it is over
// this widget, and while a belt or box drag holds the button, which goes on
// following the cursor onto the floating panels and past the window edge.
bool isHoverLive() const;
// Re-derives the hover from wherever the cursor is now, or drops it when the
// cursor points at nothing (REQ-BLD-GHOST). The entry point for everything a
// mouse move does not cover: a scrolling view, a cursor crossing onto a panel or
// out of the window, and a mode just entered under a cursor that has not moved.
void refreshHover();
// Re-resolves everything that follows from where the cursor points into the world:
// the ghost tile and its validity, the tunnel ends, a running belt or box drag, the
// deconstruct hover. Called for every mouse move, and once per frame while the view
// scrolls under a cursor that has not moved, since that changes the world position
// the cursor points at just as moving the mouse does (REQ-BLD-GHOST).
void updateHoverAt(QPoint cursorWidgetPos);
// Moves the running box drag's far corner to the world position under
// `cursorWidgetPos` and, once the cursor sits far enough from where the anchor is
// drawn, promotes the gesture from a click to a drag. Every corner update goes
// through here, including the ones a scrolling view causes under a cursor that
// has not moved (REQ-UI-MULTI-SELECT).
void updateBoxDrag(QPoint cursorWidgetPos);
// The box the drag currently spans, in world coordinates and normalized: the
// rectangle between its two corners once it reads as a drag, and the whole tile
// the button went down on before that (REQ-UI-MULTI-SELECT). Both what is drawn
// and what is selected come from here, so they can never disagree.
QRectF getBoxWorldRect() const;
// Publishes where on the screen the selection about to be made sits, so the
// selection panel can be placed beside it (REQ-UI-SELECTION-PANEL). Called with
// what is about to be selected, immediately before selecting it, and publishes
@@ -260,6 +297,11 @@ private:
// paused or slowed, instead of fading on wall-clock time (REQ-SHP-FIRING-BEAM).
static constexpr Tick kBeamLifetimeTicks = secondsToTicks(0.3);
// How far the cursor must travel from the press position, in widget pixels
// (Manhattan distance), before a box drag shows its rectangle
// (REQ-UI-MULTI-SELECT).
static constexpr int kBoxDragThresholdPixels = 2;
Simulation* m_sim;
const GameConfig* m_config;
const VisualsConfig* m_visuals;
@@ -298,6 +340,11 @@ private:
// end tile closest to the cursor when snapping to a building (REQ-BLD-BELT-DRAG)
// and to resolve the tunnel ghost sub-tile (REQ-BLD-TUNNEL-MODE).
QVector2D m_cursorWorldPos;
// Whether the hover state currently stands for a cursor pointing at the world,
// so that losing it is noticed once rather than every frame. Kept here rather
// than asked of Qt per reader: it has to agree with what was last written to the
// build mode controller, not with where the cursor happens to be mid-frame.
bool m_hoverLive = false;
bool m_debugDraw;
@@ -308,8 +355,17 @@ private:
// Not owned; set after construction, so null until MainWindow has built it.
const BlueprintLibrary* m_blueprintLibrary = nullptr;
bool m_boxSelecting;
QPoint m_boxStartTile;
QPoint m_boxCurrentTile;
// The drag's two corners in world coordinates, unsnapped: where the button went
// down and where the cursor is now (REQ-UI-MULTI-SELECT). World rather than
// widget coordinates so the anchor keeps the spot in the world it was placed on
// when the view scrolls under a held button.
QVector2D m_boxStartWorld;
QVector2D m_boxCurrentWorld;
// Whether the cursor has moved far enough from the anchor for this to read as a
// drag. Until it has, the rectangle is not drawn and the box resolves as the
// whole anchor tile (REQ-UI-MULTI-SELECT). Sticky for the rest of the drag, so
// coming back to the press position does not hide the rectangle again.
bool m_boxDragMoved;
// Interprets this widget's key events into semantic actions and publishes them
// (REQ-UI-HOTKEYS). Owned here for now because this is the widget that holds

View File

@@ -4,62 +4,54 @@
#include <string>
#include <QHBoxLayout>
#include <QIcon>
#include <QLabel>
#include <QPalette>
#include <QPushButton>
#include <QSignalMapper>
#include <QSize>
#include "Command.h"
#include "CommandRequestedEvent.h"
#include "EventManager.h"
#include "IconCaption.h"
#include "ItemIconCache.h"
#include "ItemTooltip.h"
#include "Simulation.h"
#include "SpeedChangeRequestedEvent.h"
#include "Tick.h"
#include "TooltipTrigger.h"
const double HeaderBar::kSpeeds[] = { 0.0, 0.5, 1.0, 2.0, 10.0 };
const int HeaderBar::kSpeedCount = 5;
HeaderBar::HeaderBar(const Simulation* sim, const GameConfig* config,
ItemIconCache* itemIcons, QWidget* parent)
HeaderBar::HeaderBar(const ItemTooltipContext& context, QWidget* parent)
: QWidget(parent)
, m_itemIcons(itemIcons)
, m_sim(sim)
, m_context(context)
{
QHBoxLayout* layout = new QHBoxLayout(this);
layout->setContentsMargins(8, 4, 8, 4);
layout->setSpacing(8);
m_timeLabel = new QLabel("00:00", this);
// Both displays state a value and do nothing when clicked, so a click brings the
// tooltip up at once rather than waiting the hover out (REQ-UI-TOOLTIP-TRIGGER).
// The stock states an amount of an item, so what it shows is that item's production
// tooltip, as every other display naming an item does
// (REQ-UI-BLOCKS-ICON, REQ-UI-ITEM-VALUE-TOOLTIP).
m_blocksLabel = new QLabel(this);
if (config->world.buildingBlocksTooltip)
{
m_blocksLabel->setToolTip(
QString::fromStdString(*config->world.buildingBlocksTooltip));
}
ItemTooltip::attachTo(*m_blocksLabel, m_context, kBlockItemId,
TooltipTrigger::Trigger::HoverAndClick);
updateBlocksLabel();
// An artifact count is no item amount, so it has no production path to show and
// states configured text instead (REQ-UI-ARTIFACTS-TOOLTIP).
m_artifactsLabel = new QLabel(tr("Artifacts: 0/?"), this);
if (config->world.artifactTooltip)
if (m_context.config->world.artifactTooltip)
{
m_artifactsLabel->setToolTip(
QString::fromStdString(*config->world.artifactTooltip));
TooltipTrigger::attachText(
*m_artifactsLabel,
QString::fromStdString(*m_context.config->world.artifactTooltip),
TooltipTrigger::Trigger::HoverAndClick);
}
m_bossWaveLabel = new QLabel(tr("Boss Wave #1"), this);
m_nextBossLabel = new QLabel(tr("Next boss: 5:00"), this);
// Asteroid expansion button, to the left of the speed buttons (REQ-UI-HEADER,
// REQ-UI-EXPAND-BUTTON). Caption/enabled state are set on the first
// ExpansionCostChangedEvent; clicking requests an ExpandAsteroidCommand.
m_expandButton = new QPushButton(tr("Expand"), this);
connect(m_expandButton, &QPushButton::clicked, this, []() {
EventManager::getInstance()->sendEventImmediately(
std::make_shared<CommandRequestedEvent>(
std::make_shared<ExpandAsteroidCommand>()));
});
const int itemSpacing = 20;
layout->addWidget(m_timeLabel);
@@ -72,8 +64,6 @@ HeaderBar::HeaderBar(const Simulation* sim, const GameConfig* config,
layout->addSpacing(itemSpacing);
layout->addWidget(m_nextBossLabel);
layout->addSpacing(itemSpacing);
layout->addWidget(m_expandButton);
layout->addSpacing(itemSpacing);
const char* labels[] = { "0x", "0.5x", "1x", "2x", "10x" };
QSignalMapper* mapper = new QSignalMapper(this);
@@ -101,7 +91,7 @@ HeaderBar::~HeaderBar()
void HeaderBar::handleEvent(std::shared_ptr<const TickAdvancedEvent> /*event*/)
{
const int totalSeconds = static_cast<int>(ticksToSeconds(m_sim->getCurrentTick()));
const int totalSeconds = static_cast<int>(ticksToSeconds(m_context.sim->getCurrentTick()));
m_timeLabel->setText(
QString("%1:%2")
.arg(totalSeconds / 60, 2, 10, QChar('0'))
@@ -111,19 +101,13 @@ void HeaderBar::handleEvent(std::shared_ptr<const TickAdvancedEvent> /*event*/)
void HeaderBar::handleEvent(std::shared_ptr<const BuildingBlocksChangedEvent> /*event*/)
{
updateBlocksLabel();
updateExpandButton();
}
void HeaderBar::handleEvent(std::shared_ptr<const ExpansionCostChangedEvent> /*event*/)
{
updateExpandButton();
}
void HeaderBar::updateBlocksLabel()
{
const int blocks = m_sim->getBuildingBlocksStock();
const int blocks = m_context.sim->getBuildingBlocksStock();
const QPixmap icon = m_itemIcons->getInlineIcon(kBlockItemId, font());
const QPixmap icon = m_context.itemIcons->getInlineIcon(kBlockItemId, font());
if (icon.isNull())
{
// Fallback text form when no building_block icon exists (REQ-UI-BLOCKS-ICON).
@@ -135,41 +119,6 @@ void HeaderBar::updateBlocksLabel()
m_blocksLabel->palette().color(QPalette::WindowText)));
}
void HeaderBar::updateExpandButton()
{
const int blocks = m_sim->getBuildingBlocksStock();
const int expansionCost = m_sim->getCurrentExpansionCost();
m_expandButton->setEnabled(blocks >= expansionCost);
const QPixmap icon = m_itemIcons->getInlineIcon(kBlockItemId, font());
if (icon.isNull())
{
// Fallback text form when no building_block icon exists (REQ-UI-EXPAND-BUTTON).
m_expandButton->setIcon(QIcon());
m_expandButton->setText(tr("Expand: %1 Blocks").arg(expansionCost));
return;
}
const QString text = tr("Expand: %1").arg(expansionCost);
const QPalette& pal = m_expandButton->palette();
const QPixmap normal = renderCaptionWithIcon(
text, icon, m_expandButton->font(), pal.color(QPalette::ButtonText));
const QPixmap greyed = renderCaptionWithIcon(
text, icon, m_expandButton->font(),
pal.color(QPalette::Disabled, QPalette::ButtonText));
QIcon buttonIcon;
buttonIcon.addPixmap(normal, QIcon::Normal);
buttonIcon.addPixmap(greyed, QIcon::Disabled);
m_expandButton->setText(QString());
m_expandButton->setIcon(buttonIcon);
const qreal dpr = normal.devicePixelRatio();
m_expandButton->setIconSize(QSize(
static_cast<int>(normal.width() / dpr),
static_cast<int>(normal.height() / dpr)));
}
void HeaderBar::handleEvent(std::shared_ptr<const GameSpeedChangedEvent> event)
{
for (int i = 0; i < kSpeedCount; ++i)
@@ -181,12 +130,12 @@ void HeaderBar::handleEvent(std::shared_ptr<const GameSpeedChangedEvent> event)
void HeaderBar::handleEvent(std::shared_ptr<const BossWaveUpdatedEvent> /*event*/)
{
const Tick countdownTicks = m_sim->getBossCountdownTicks();
const Tick countdownTicks = m_context.sim->getBossCountdownTicks();
const int bossSeconds = static_cast<int>(
ticksToSeconds(countdownTicks > 0 ? countdownTicks : 0));
m_bossWaveLabel->setText(
tr("Boss Wave #%1")
.arg(m_sim->getBossWaveCounter()));
.arg(m_context.sim->getBossWaveCounter()));
m_nextBossLabel->setText(
tr("Next boss: %1:%2")
.arg(bossSeconds / 60)
@@ -197,8 +146,8 @@ void HeaderBar::handleEvent(std::shared_ptr<const ArtifactCountChangedEvent> /*e
{
m_artifactsLabel->setText(
tr("Artifacts: %1/%2")
.arg(m_sim->getArtifactCount())
.arg(m_sim->getConfig().world.artifacts.artifactWinCount));
.arg(m_context.sim->getArtifactCount())
.arg(m_context.sim->getConfig().world.artifacts.artifactWinCount));
}
void HeaderBar::onSpeedButton(int index)

View File

@@ -11,9 +11,9 @@
#include "BossWaveUpdatedEvent.h"
#include "BuildingBlocksChangedEvent.h"
#include "EventHandler.h"
#include "ExpansionCostChangedEvent.h"
#include "GameConfig.h"
#include "GameSpeedChangedEvent.h"
#include "ItemTooltipContext.h"
#include "Tick.h"
#include "TickAdvancedEvent.h"
@@ -25,7 +25,6 @@ class Simulation;
class HeaderBar : public QWidget,
public CombinedEventHandler<TickAdvancedEvent,
BuildingBlocksChangedEvent,
ExpansionCostChangedEvent,
GameSpeedChangedEvent,
BossWaveUpdatedEvent,
ArtifactCountChangedEvent>
@@ -33,11 +32,12 @@ class HeaderBar : public QWidget,
Q_OBJECT
public:
// itemIcons is the window-wide per-item icon cache (REQ-UI-ITEM-ICON); used to
// show the building_block icon in the stock display and expand button
// (REQ-UI-BLOCKS-ICON, REQ-UI-EXPAND-BUTTON). Not owned; must outlive this widget.
HeaderBar(const Simulation* sim, const GameConfig* config,
ItemIconCache* itemIcons, QWidget* parent = nullptr);
// The context carries the simulation the bar reads, the config, and the icon caches
// -- the item cache draws the building_block icon in the stock display
// (REQ-UI-BLOCKS-ICON), and the stock display explains that item with the cache's
// help (REQ-UI-ITEM-VALUE-TOOLTIP). Nothing in it is owned; all of it must outlive
// this widget.
explicit HeaderBar(const ItemTooltipContext& context, QWidget* parent = nullptr);
~HeaderBar() override;
private slots:
@@ -46,15 +46,10 @@ private slots:
private:
void handleEvent(std::shared_ptr<const TickAdvancedEvent> event) override;
void handleEvent(std::shared_ptr<const BuildingBlocksChangedEvent> event) override;
void handleEvent(std::shared_ptr<const ExpansionCostChangedEvent> event) override;
void handleEvent(std::shared_ptr<const GameSpeedChangedEvent> event) override;
void handleEvent(std::shared_ptr<const BossWaveUpdatedEvent> event) override;
void handleEvent(std::shared_ptr<const ArtifactCountChangedEvent> event) override;
// Refreshes the Expand button caption and enabled state from the current
// expansion cost and building block stock (REQ-UI-EXPAND-BUTTON).
void updateExpandButton();
// Refreshes the building blocks stock display from the simulation:
// `Stock: <n>` with the building_block icon after it, or the
// `Stock: <n> Blocks` text fallback when no icon file exists
@@ -66,14 +61,12 @@ private:
QLabel* m_artifactsLabel;
QLabel* m_bossWaveLabel;
QLabel* m_nextBossLabel;
QPushButton* m_expandButton;
std::vector<QPushButton*> m_speedButtons;
ItemIconCache* m_itemIcons; // Not owned; lives in MainWindow.
// The simulation is the single source of truth for everything the header
// displays; the change events are only refresh signals.
const Simulation* m_sim;
// Not owned; all of it lives in MainWindow. The simulation it names is the single
// source of truth for everything the header displays; the change events are only
// refresh signals.
ItemTooltipContext m_context;
static const double kSpeeds[];
static const int kSpeedCount;

View File

@@ -17,6 +17,7 @@
#include "ModeCancelRequestedEvent.h"
#include "PanDirectionChangedEvent.h"
#include "PauseToggleRequestedEvent.h"
#include "SelectionClearRequestedEvent.h"
#include "SpeedStepRequestedEvent.h"
#include "TemporaryBlueprintCaptureRequestedEvent.h"
#include "TemporaryBlueprintPlaceRequestedEvent.h"
@@ -153,6 +154,10 @@ bool InputMapper::handleKeyPress(QKeyEvent* event, const ControlContext& context
EventManager::getInstance()->sendEventImmediately(
std::make_shared<ModeCancelRequestedEvent>());
return true;
case ControlAction::ClearSelection:
EventManager::getInstance()->sendEventImmediately(
std::make_shared<SelectionClearRequestedEvent>());
return true;
case ControlAction::CopyTemporary:
// The BlueprintLibrary owns the selection and blueprint-capture logic; it drives
// placement mode from there (REQ-UI-BLUEPRINT-TEMP).

View File

@@ -7,18 +7,6 @@
namespace
{
bool producesItem(const RecipeDef& recipe, const std::string& itemId)
{
for (const RecipeOutput& output : recipe.outputs)
{
if (output.item == itemId)
{
return true;
}
}
return false;
}
bool isAvailable(const RecipeDef& recipe, const Simulation& sim)
{
if (recipe.building == BuildingType::Miner

102
src/ui/ItemTooltip.cpp Normal file
View File

@@ -0,0 +1,102 @@
#include "ItemTooltip.h"
#include <QFont>
#include <QLabel>
#include <QVBoxLayout>
#include "DisplayName.h"
#include "GameConfig.h"
#include "ItemProducers.h"
#include "RecipeLineRow.h"
#include "RecipesConfig.h"
#include "Simulation.h"
namespace
{
std::vector<RecipeLineRow::Amount> toAmounts(
const std::vector<RecipeIngredient>& ingredients)
{
std::vector<RecipeLineRow::Amount> amounts;
amounts.reserve(ingredients.size());
for (const RecipeIngredient& ingredient : ingredients)
{
amounts.push_back(RecipeLineRow::Amount{ ingredient.item, ingredient.amount });
}
return amounts;
}
} // namespace
void ItemTooltip::attachTo(QWidget& target, const ItemTooltipContext& context,
const std::string& itemId, TooltipTrigger::Trigger trigger)
{
ItemTooltip* tooltip = new ItemTooltip(context, itemId, &target);
TooltipTrigger::attach(target, *tooltip, trigger);
}
ItemTooltip::ItemTooltip(const ItemTooltipContext& context, const std::string& itemId,
QWidget* parent)
: Tooltip(parent)
, m_context(context)
, m_itemId(itemId)
{
}
void ItemTooltip::refreshContent()
{
clearContent();
QVBoxLayout* layout = getContentLayout();
// The heading names the item. For an input chip this is the only place it is named
// at all, since such a chip carries a count and no name (REQ-UI-SINGLE-SELECTION).
QLabel* heading =
new QLabel(QString::fromStdString(toDisplayName(m_itemId)), this);
QFont headingFont = heading->font();
headingFont.setBold(true);
heading->setFont(headingFont);
layout->addWidget(heading);
heading->show();
const ItemProduction production =
findItemProduction(m_itemId, *m_context.sim, *m_context.config);
// Scrap is salvaged from debris rather than crafted (REQ-RES-DEBRIS-DROP), so it
// says where it comes from in place of the caption and lists nothing.
QLabel* caption = new QLabel(production.origin == ItemOrigin::Salvaged
? tr("Salvaged from debris")
: tr("Produced by"), this);
layout->addWidget(caption);
caption->show();
if (production.origin == ItemOrigin::Undiscovered)
{
// Made somehow, but by nothing the player has unlocked -- named without being
// shown a path they cannot take yet (REQ-UI-ITEM-TOOLTIP).
QLabel* undiscovered = new QLabel(tr("Undiscovered"), this);
layout->addWidget(undiscovered);
undiscovered->show();
return;
}
for (const RecipeDef* recipe : production.recipes)
{
RecipeLineRow::Spec spec;
spec.building = recipe->building;
spec.name = QString::fromStdString(toDisplayName(recipe->id));
spec.inputs = toAmounts(recipe->inputs);
spec.outputGroups = RecipeLineRow::toOutputGroups(*recipe);
spec.durationSeconds = recipe->durationSeconds;
// Boxed, because an item with several producers stacks several of these and a run
// of bare lines reads as one field of icons (REQ-UI-ITEM-TOOLTIP). The items it
// names carry no tooltip of their own: this is already one
// (REQ-UI-ITEM-VALUE-TOOLTIP).
RecipeLineRow* line =
new RecipeLineRow(m_context.itemIcons, m_context.buildingIcons, this);
line->setCardChrome(true);
layout->addWidget(line);
line->setLine(spec);
}
}

36
src/ui/ItemTooltip.h Normal file
View File

@@ -0,0 +1,36 @@
#pragma once
#include <string>
#include "ItemTooltipContext.h"
#include "Tooltip.h"
#include "TooltipTrigger.h"
// The tooltip an item's name carries: the item, and every way the player can currently
// produce it, each drawn as a recipe line (REQ-UI-ITEM-TOOLTIP).
//
// Its content is drawn -- item squares, building chips and all -- rather than written,
// which is what it adds to the plain text tooltip it derives from. Rebuilt on every show,
// because what produces an item changes as the player unlocks recipes
// (REQ-LOCK-UI-RECIPE).
class ItemTooltip : public Tooltip
{
Q_OBJECT
public:
// Gives one display the tooltip of the item it names (REQ-UI-ITEM-VALUE-TOOLTIP).
// The tooltip is parented to the target and dies with it. HoverOnly wherever the
// target sits on something the player clicks, whose click is not free to explain.
static void attachTo(QWidget& target, const ItemTooltipContext& context,
const std::string& itemId, TooltipTrigger::Trigger trigger);
ItemTooltip(const ItemTooltipContext& context, const std::string& itemId,
QWidget* parent = nullptr);
protected:
void refreshContent() override;
private:
ItemTooltipContext m_context;
std::string m_itemId;
};

View File

@@ -0,0 +1,27 @@
#pragma once
struct GameConfig;
class BuildingIconCache;
class ItemIconCache;
class Simulation;
// Everything an item production tooltip reads (REQ-UI-ITEM-TOOLTIP): the simulation it
// asks which recipes the player has unlocked, the immutable config holding the recipes
// themselves, and the two icon caches its recipe lines are drawn from.
//
// Its own bundle rather than the selection panel's (SelectionContext), because an item is
// named all over the UI -- the header bar, the dialogs, the panel -- and every one of
// those places has to be able to explain it (REQ-UI-ITEM-VALUE-TOOLTIP). The panel's
// context carries visuals and the debug flag besides, which no tooltip reads.
//
// Nothing here is owned: a view onto objects living in MainWindow, which it must not
// outlive.
struct ItemTooltipContext
{
// Const because a tooltip only ever reads: what produces an item is a question, not
// a command.
const Simulation* sim = nullptr;
const GameConfig* config = nullptr;
ItemIconCache* itemIcons = nullptr;
BuildingIconCache* buildingIcons = nullptr;
};

View File

@@ -10,12 +10,11 @@
#include <QDialog>
#include <QDir>
#include <QFile>
#include <QInputDialog>
#include <QLineEdit>
#include <QMessageBox>
#include <QPushButton>
#include <QPoint>
#include <QResizeEvent>
#include <QVBoxLayout>
#include <QVector2D>
#include "BlueprintLibrary.h"
#include "BlueprintSelectionDialog.h"
@@ -31,11 +30,15 @@
#include "HeaderBar.h"
#include "SelectionPanel.h"
#include "ControlsPanel.h"
#include "ExpandButton.h"
#include "ShipLayoutBlueprintSerializer.h"
#include "ShipLayoutDialog.h"
#include "BuildingIconCache.h"
#include "ItemIconCache.h"
#include "MessageDialog.h"
#include "ModalLayer.h"
#include "ModalPauseScope.h"
#include "NameInputDialog.h"
#include "Simulation.h"
#include "Tick.h"
#include "VisualsLoader.h"
@@ -60,7 +63,7 @@ MainWindow::MainWindow(Simulation* sim, const std::string& configDir,
m_buildingIcons = std::make_unique<BuildingIconCache>(
QDir::cleanPath(configDirPath + "/../icons/buildings"));
m_headerBar = new HeaderBar(sim, &sim->getConfig(), m_itemIcons.get(), this);
m_headerBar = new HeaderBar(getItemTooltipContext(), this);
m_gameWorldView = new GameWorldView(sim, &sim->getConfig(), &m_visuals, m_configDir,
m_itemIcons.get(), m_replay.get(), this);
@@ -74,6 +77,13 @@ MainWindow::MainWindow(Simulation* sim, const std::string& configDir,
m_buildingIcons.get(), m_itemIcons.get(),
this);
// Stands in the world rather than on the screen, on the columns the next expansion
// unlocks (REQ-UI-EXPAND-BUTTON). A sibling of the world view like the panels, which
// is what keeps the builder-mode ghost off the tile beneath it and the click off the
// world (REQ-BLD-GHOST): the view's hover follows underMouse(), false while the
// cursor rests on a sibling.
m_expandButton = new ExpandButton(getItemTooltipContext(), this);
// The blueprints have no widget of their own: they are saved with Ctrl+C and picked
// from a modal dialog (REQ-UI-BLUEPRINT-DIALOG), both driven from this window
// because only it can pause the game and raise the dim overlay. Built after the
@@ -98,14 +108,21 @@ MainWindow::MainWindow(Simulation* sim, const std::string& configDir,
// after the view for the same stacking reason as the panels above it.
m_controlsPanel = new ControlsPanel(m_gameWorldView, this);
// Created last so it stacks above the other children; covers the whole window and
// dims the game behind modal dialogs/menus (REQ-UI-MODAL-DIM).
m_dimOverlay = new ModalDimOverlay(m_visuals.overlays.modalDim, this);
// Created last so it stacks above the other children; covers the whole window,
// dims the game behind every modal, and is what those modals are drawn on
// (REQ-UI-MODAL-DIM, REQ-UI-MODAL-CHROME).
m_modalLayer = new ModalLayer(m_visuals.overlays.modalDim, this);
m_gameWorldView->setFocus();
connect(qApp, &QApplication::focusChanged, this, [this](QWidget*, QWidget* newWidget) {
if (newWidget && newWidget != m_gameWorldView && !QApplication::activeModalWidget())
// A modal holds the focus while it is open, whether it is one of ours on the
// layer or a system message box (REQ-UI-MODAL-CHROME). A null widget -- the focus
// going nowhere at all -- is caught too: the world view is what answers keys when
// no modal is up, so leaving the window with no focus widget would leave the
// hotkeys dead (REQ-UI-HOTKEYS).
if (newWidget != m_gameWorldView && !QApplication::activeModalWidget()
&& !m_modalLayer->isActive())
{
m_gameWorldView->setFocus();
}
@@ -145,6 +162,15 @@ void MainWindow::resizeEvent(QResizeEvent* event)
void MainWindow::closeEvent(QCloseEvent* event)
{
// A modal on the layer runs a nested event loop over widgets this window owns, so
// the window must outlive it. A modal window used to block the close outright; this
// does the same for a modal that is only a widget (REQ-UI-MODAL-CHROME).
if (m_modalLayer->isActive())
{
event->ignore();
return;
}
const QString path = QCoreApplication::applicationDirPath() + "/ship_layouts.toml";
QFile file(path);
if (file.open(QIODevice::WriteOnly | QIODevice::Text))
@@ -173,7 +199,7 @@ void MainWindow::layoutPanels()
const QRect worldRect(0, headerH, totalW, totalH - headerH);
m_headerBar->setGeometry(0, 0, totalW, headerH);
m_gameWorldView->setGeometry(worldRect);
m_dimOverlay->setGeometry(0, 0, totalW, totalH);
m_modalLayer->setGeometry(0, 0, totalW, totalH);
// The floating widgets are placed in one ordered pass, each into the space the
// earlier ones have not taken (FloatingPanel.h). The order is the priority the
@@ -207,6 +233,11 @@ void MainWindow::layoutPanels()
}
}
// Last, and never added to occupiedRects: it marks a place in the world, so the
// panels do not step around it and it does not step around them
// (REQ-UI-EXPAND-BUTTON).
placeExpandButton();
m_layingOut = false;
}
@@ -223,11 +254,15 @@ void MainWindow::handleEvent(std::shared_ptr<const SchematicChoicesAvailableEven
{
ModalPauseScope pause(*m_gameWorldView);
ModalDimScope dim(*m_dimOverlay);
SchematicChoiceDialog dialog(event->choices, m_sim->getConfig().recipes,
m_itemIcons.get(), m_buildingIcons.get(), this);
dialog.exec();
getItemTooltipContext(), m_modalLayer);
m_modalLayer->execute(dialog);
// The command goes out unconditionally because the dialog cannot be dismissed: it
// returns only once an option was clicked, so the index always names that option
// (REQ-DEF-SCHEMATIC-DROP). It is also the only thing that resolves the drop -- the
// poll that opened this dialog will not open it again while the choices stay pending
// (GameWorldView::onFrame) -- so a path that skipped the command would strand it.
std::shared_ptr<ApplySchematicChoiceCommand> command =
std::make_shared<ApplySchematicChoiceCommand>();
command->choiceIndex = dialog.getChosenIndex();
@@ -239,17 +274,17 @@ void MainWindow::handleEvent(std::shared_ptr<const EscapeMenuRequestedEvent> /*e
{
ModalPauseScope pause(*m_gameWorldView);
ModalDimScope dim(*m_dimOverlay);
QMessageBox box(this);
box.setWindowTitle(tr("Paused"));
QPushButton* continueBtn = box.addButton(tr("Continue"), QMessageBox::AcceptRole);
QPushButton* restartBtn = box.addButton(tr("Restart"), QMessageBox::ResetRole);
QPushButton* quitBtn = box.addButton(tr("Quit"), QMessageBox::DestructiveRole);
box.setEscapeButton(continueBtn);
box.exec();
MessageDialog box(tr("Paused"), QString(), m_modalLayer);
const int continueIndex = box.addButton(tr("Continue"));
const int restartIndex = box.addButton(tr("Restart"));
const int quitIndex = box.addButton(tr("Quit"));
// Escape stands for Continue, as it did when this was a system box
// (REQ-UI-GAME-MENU).
box.setEscapeButtonIndex(continueIndex);
m_modalLayer->execute(box);
QAbstractButton* clicked = box.clickedButton();
if (clicked == restartBtn)
const std::optional<int> clicked = box.getClickedButtonIndex();
if (clicked == restartIndex)
{
std::optional<GameConfig> newConfig = reloadConfig();
if (!newConfig.has_value())
@@ -267,7 +302,7 @@ void MainWindow::handleEvent(std::shared_ptr<const EscapeMenuRequestedEvent> /*e
EventManager::getInstance()->sendEventImmediately(
std::make_shared<CommandRequestedEvent>(command));
}
else if (clicked == quitBtn)
else if (clicked == quitIndex)
{
pause.release();
close();
@@ -284,7 +319,7 @@ std::optional<GameConfig> MainWindow::reloadConfig()
GameConfig newConfig = ConfigLoader::loadFromDirectory(m_configDir);
VisualsConfig newVisuals = VisualsLoader::load(m_configDir + "/visuals.toml");
m_visuals = std::move(newVisuals);
m_dimOverlay->setDimColor(m_visuals.overlays.modalDim);
m_modalLayer->setDimColor(m_visuals.overlays.modalDim);
// The composed item squares carry the colors they were painted with, so they
// are dropped for the new ones to take effect (REQ-UI-ITEM-ICON).
m_itemIcons->clearPixmapCache();
@@ -313,16 +348,15 @@ void MainWindow::openShipLayoutDialog(BuildingId shipyardId,
}
}
ModalDimScope dim(*m_dimOverlay);
ShipLayoutDialog dialog(&m_sim->getConfig(), schematicId, currentLayout,
ShipLayoutDialog dialog(schematicId, currentLayout,
m_layoutBlueprints,
std::move(unlockedModuleIds),
m_gameWorldView->isDebugDrawEnabled(),
m_itemIcons.get(), this);
getItemTooltipContext(), m_modalLayer);
// Opened from the panel's "Configure" button (REQ-MOD-UI-PREVIEW) or straight after
// a schematic change (REQ-MOD-UI-AUTO-DIALOG), so it opens on the panel either way.
placeOnSelectionPanel(dialog);
if (dialog.exec() == QDialog::Accepted && dialog.getResult().has_value())
if (m_modalLayer->execute(dialog, getSelectionPanelAnchor()) == QDialog::Accepted
&& dialog.getResult().has_value())
{
std::shared_ptr<SetShipLayoutCommand> command =
std::make_shared<SetShipLayoutCommand>();
@@ -333,43 +367,18 @@ void MainWindow::openShipLayoutDialog(BuildingId shipyardId,
}
}
void MainWindow::placeOnSelectionPanel(QDialog& dialog) const
QRect MainWindow::getSelectionPanelAnchor() const
{
// The panel is up whenever one of these modals opens -- they are opened from its own
// controls, and it is shown whenever anything is selected (REQ-UI-EMPTY-SELECTION).
// Were it not, there would be no rectangle to center on and Qt's own centering on
// this window stands.
if (!m_selectionPanel->isVisible()) { return; }
// The dialog has never been shown, so it is still at its default size until its
// layout has run; centering it before that would use the wrong extent.
dialog.adjustSize();
const QSize dialogSize = dialog.size();
// Were it not, there would be no rectangle to center on and the layer's own centering
// stands (REQ-UI-PANEL-MODAL).
if (!m_selectionPanel->isVisible()) { return QRect(); }
// The panel's live geometry, so a panel the player has dragged
// (REQ-UI-SELECTION-PANEL-DRAG) carries the modal with it.
const QRect panelRect(m_selectionPanel->mapToGlobal(QPoint(0, 0)),
m_selectionPanel->size());
const QRect windowRect(mapToGlobal(QPoint(0, 0)), size());
QPoint topLeft(panelRect.center().x() - dialogSize.width() / 2,
panelRect.center().y() - dialogSize.height() / 2);
// Pushed back inside the window, never resized to fit (REQ-UI-PANEL-MODAL). The far
// edge is clamped first and the near edge second, which is what aligns a dialog too
// large for the window with the window's top-left corner rather than pushing it off
// the opposite edge.
topLeft.setX(qMax(windowRect.left(),
qMin(topLeft.x(), windowRect.right() - dialogSize.width() + 1)));
topLeft.setY(qMax(windowRect.top(),
qMin(topLeft.y(), windowRect.bottom() - dialogSize.height() + 1)));
// Positions the dialog's frame, whose size is not known until it is first shown, so
// the result sits low by the title bar height against a true center -- measuring it
// would mean showing the dialog at the wrong place first. The move also marks the
// dialog as positioned, which is what stops QDialog from centering it on this window
// when it is shown.
dialog.move(topLeft);
// (REQ-UI-SELECTION-PANEL-DRAG) carries the modal with it. Panel and layer are both
// children of this window, so the panel's geometry needs no mapping.
return m_selectionPanel->geometry();
}
void MainWindow::handleEvent(std::shared_ptr<const LayoutDialogRequestedEvent> event)
@@ -385,6 +394,15 @@ void MainWindow::handleEvent(std::shared_ptr<const LayoutDialogRequestedEvent> e
}
const std::string& schematicId = b ? b->recipeId : s->recipeId;
// Nothing to configure without a schematic and a grid to place modules on. The
// Configure button that publishes this is already disabled then (REQ-MOD-UI-PREVIEW),
// so this guards the event rather than the button: the dialog would otherwise open
// over a grid of no cells.
if (!m_sim->getConfig().ships.findLayoutShipDef(schematicId))
{
return;
}
const std::optional<ShipLayoutConfig>& layoutOpt =
b ? b->shipLayout : s->shipLayout;
@@ -413,7 +431,7 @@ void MainWindow::handleEvent(std::shared_ptr<const RecipeSelectionRequestedEvent
// Held across both the selection dialog and any auto-opened layout dialog so the
// dim stays continuously visible through that sequence (REQ-UI-MODAL-DIM).
ModalDimScope dim(*m_dimOverlay);
ModalLayerHold dim(*m_modalLayer);
const BuildingType type = b ? b->type : s->type;
// Captured as a copy: a queued command may drain during the modal dialog's
@@ -428,10 +446,10 @@ void MainWindow::handleEvent(std::shared_ptr<const RecipeSelectionRequestedEvent
bool autoOpenLayout = false;
std::string chosenSchematic;
RecipeSelectionDialog dialog(options, title, m_itemIcons.get(),
m_buildingIcons.get(), this);
placeOnSelectionPanel(dialog);
if (dialog.exec() == QDialog::Accepted && dialog.getChosenId().has_value())
RecipeSelectionDialog dialog(options, title, getItemTooltipContext(),
m_modalLayer);
if (m_modalLayer->execute(dialog, getSelectionPanelAnchor()) == QDialog::Accepted
&& dialog.getChosenId().has_value())
{
std::shared_ptr<SetRecipeCommand> command = std::make_shared<SetRecipeCommand>();
command->id = event->buildingId;
@@ -440,8 +458,12 @@ void MainWindow::handleEvent(std::shared_ptr<const RecipeSelectionRequestedEvent
std::make_shared<CommandRequestedEvent>(command));
// REQ-MOD-UI-AUTO-DIALOG: picking a new schematic for a shipyard opens the
// layout configuration dialog immediately. Only on an actual change.
if (type == BuildingType::Shipyard && *dialog.getChosenId() != oldSchematic)
// layout configuration dialog immediately. Only on an actual change, and only
// for an actual schematic: "(None)" clears the shipyard and carries the empty
// id (REQ-UI-SELECT-OPTIONS), which differs from whatever was set but is not a
// schematic to configure.
if (type == BuildingType::Shipyard && *dialog.getChosenId() != oldSchematic
&& m_sim->getConfig().ships.findLayoutShipDef(*dialog.getChosenId()))
{
autoOpenLayout = true;
chosenSchematic = *dialog.getChosenId();
@@ -469,30 +491,78 @@ void MainWindow::handleEvent(std::shared_ptr<const BlueprintSaveRequestedEvent>
// over to, so the dim never blinks off and the simulation is not resumed in between
// (REQ-UI-MODAL-DIM).
ModalPauseScope pause(*m_gameWorldView);
ModalDimScope dim(*m_dimOverlay);
ModalLayerHold dim(*m_modalLayer);
bool ok = false;
const QString name = QInputDialog::getText(
this, tr("Create Blueprint"), tr("Blueprint name:"), QLineEdit::Normal,
QString(), &ok);
NameInputDialog nameDialog(tr("Create Blueprint"), tr("Blueprint name:"),
m_modalLayer);
const int result = m_modalLayer->execute(nameDialog);
// Cancel, Escape, or an empty name: no blueprint, and no selection dialog.
if (!ok || name.trimmed().isEmpty()) { return; }
if (result != QDialog::Accepted || nameDialog.getName().isEmpty()) { return; }
m_blueprintLibrary->saveSelectionAs(name.trimmed());
m_blueprintLibrary->saveSelectionAs(nameDialog.getName());
showBlueprintSelectionDialog();
}
void MainWindow::handleEvent(std::shared_ptr<const BlueprintSelectionRequestedEvent> /*event*/)
{
ModalPauseScope pause(*m_gameWorldView);
ModalDimScope dim(*m_dimOverlay);
showBlueprintSelectionDialog();
}
void MainWindow::placeExpandButton()
{
// Null while the button is still being built: refreshing its cost asks for a
// placement pass, and the first refresh happens inside its own constructor.
if (m_expandButton == nullptr)
{
return;
}
// The columns the next purchase unlocks: the ones immediately left of the buildable
// edge (REQ-GW-ASTEROID-EXPAND, REQ-UI-LOCKED-ASTEROID). Their middle, and the
// world's middle vertically, is where the button goes (REQ-UI-EXPAND-BUTTON).
const int asteroidWidth_tiles = m_sim->getCurrentAsteroidWidth_tiles();
const float columns_tiles = static_cast<float>(
m_sim->getConfig().world.expansion.columnsPerExpansion_tiles);
const QVector2D center_tiles(
-static_cast<float>(asteroidWidth_tiles) - columns_tiles / 2.0f,
static_cast<float>(m_sim->getConfig().world.heightTiles) / 2.0f);
// The transform is the view's, so the point it yields is in the view's coordinates;
// the button is a sibling of the view, so it is lifted into this window's.
const QPointF centerInView_px =
m_gameWorldView->getCoordinates().worldToWidget(center_tiles);
const QPoint center_px = m_gameWorldView->geometry().topLeft()
+ QPoint(static_cast<int>(centerInView_px.x()),
static_cast<int>(centerInView_px.y()));
// Neither clamped nor hidden: the button belongs to that ground and leaves the view
// with it, which the window's own edge takes care of (REQ-UI-EXPAND-BUTTON).
const QSize buttonSize = m_expandButton->sizeHint();
m_expandButton->setGeometry(QRect(
center_px - QPoint(buttonSize.width() / 2, buttonSize.height() / 2),
buttonSize));
}
void MainWindow::handleEvent(std::shared_ptr<const ViewScrolledEvent> /*event*/)
{
// The ground moved under the button; nothing else about the layout changed, so this
// is the one widget to re-place (REQ-UI-EXPAND-BUTTON).
placeExpandButton();
}
ItemTooltipContext MainWindow::getItemTooltipContext() const
{
return ItemTooltipContext{ m_sim, &m_sim->getConfig(), m_itemIcons.get(),
m_buildingIcons.get() };
}
void MainWindow::showBlueprintSelectionDialog()
{
BlueprintSelectionDialog dialog(m_blueprintLibrary.get(), m_itemIcons.get(), this);
if (dialog.exec() == QDialog::Accepted && dialog.getChosenIndex().has_value())
BlueprintSelectionDialog dialog(m_blueprintLibrary.get(), getItemTooltipContext(),
m_modalLayer);
if (m_modalLayer->execute(dialog) == QDialog::Accepted
&& dialog.getChosenIndex().has_value())
{
// Entered after the dialog has closed, which is the order REQ-UI-BLUEPRINT-CARD
// describes: clicking a card closes the dialog and enters placement mode.
@@ -507,17 +577,18 @@ void MainWindow::handleEvent(std::shared_ptr<const GameOverEvent> /*event*/)
const int minutes = totalSeconds / 60;
const int seconds = totalSeconds % 60;
ModalDimScope dim(*m_dimOverlay);
QMessageBox box(this);
box.setWindowTitle(tr("Game Over"));
box.setText(tr("HQ destroyed!\nSurvival time: %1:%2")
.arg(minutes, 2, 10, QChar('0'))
.arg(seconds, 2, 10, QChar('0')));
QPushButton* restartBtn = box.addButton(tr("Restart"), QMessageBox::AcceptRole);
box.addButton(tr("Quit"), QMessageBox::RejectRole);
box.exec();
MessageDialog box(tr("Game Over"),
tr("HQ destroyed!\nSurvival time: %1:%2")
.arg(minutes, 2, 10, QChar('0'))
.arg(seconds, 2, 10, QChar('0')),
m_modalLayer);
const int restartIndex = box.addButton(tr("Restart"));
const int quitIndex = box.addButton(tr("Quit"));
// Escape quits, which is where the system box's reject role sent it.
box.setEscapeButtonIndex(quitIndex);
m_modalLayer->execute(box);
if (box.clickedButton() == restartBtn)
if (box.getClickedButtonIndex() == restartIndex)
{
std::optional<GameConfig> newConfig = reloadConfig();
if (!newConfig.has_value())
@@ -544,17 +615,18 @@ void MainWindow::handleEvent(std::shared_ptr<const WinEvent> /*event*/)
const int minutes = totalSeconds / 60;
const int seconds = totalSeconds % 60;
ModalDimScope dim(*m_dimOverlay);
QMessageBox box(this);
box.setWindowTitle(tr("Won!"));
box.setText(tr("You collected all artifacts!\nSurvival time: %1:%2")
.arg(minutes, 2, 10, QChar('0'))
.arg(seconds, 2, 10, QChar('0')));
QPushButton* restartBtn = box.addButton(tr("Restart"), QMessageBox::AcceptRole);
box.addButton(tr("Quit"), QMessageBox::RejectRole);
box.exec();
MessageDialog box(tr("Won!"),
tr("You collected all artifacts!\nSurvival time: %1:%2")
.arg(minutes, 2, 10, QChar('0'))
.arg(seconds, 2, 10, QChar('0')),
m_modalLayer);
const int restartIndex = box.addButton(tr("Restart"));
const int quitIndex = box.addButton(tr("Quit"));
// Escape quits, which is where the system box's reject role sent it.
box.setEscapeButtonIndex(quitIndex);
m_modalLayer->execute(box);
if (box.clickedButton() == restartBtn)
if (box.getClickedButtonIndex() == restartIndex)
{
std::optional<GameConfig> newConfig = reloadConfig();
if (!newConfig.has_value())

View File

@@ -15,12 +15,14 @@
#include "FloatingLayoutInvalidatedEvent.h"
#include "GameConfig.h"
#include "GameOverEvent.h"
#include "ItemTooltipContext.h"
#include "LayoutDialogRequestedEvent.h"
#include "ModalDimOverlay.h"
#include "ModalLayer.h"
#include "WinEvent.h"
#include "RecipeSelectionRequestedEvent.h"
#include "SchematicChoicesAvailableEvent.h"
#include "ShipLayout.h"
#include "ViewScrolledEvent.h"
#include "ShipLayoutBlueprint.h"
#include "Tick.h"
#include "VisualsConfig.h"
@@ -34,9 +36,9 @@ class ControlsPanel;
class BuildButtonBar;
class BlueprintLibrary;
class BuildingIconCache;
class ExpandButton;
class ItemIconCache;
class QCloseEvent;
class QDialog;
class QResizeEvent;
class MainWindow : public QWidget,
@@ -48,7 +50,8 @@ class MainWindow : public QWidget,
RecipeSelectionRequestedEvent,
BlueprintSaveRequestedEvent,
BlueprintSelectionRequestedEvent,
FloatingLayoutInvalidatedEvent>
FloatingLayoutInvalidatedEvent,
ViewScrolledEvent>
{
Q_OBJECT
@@ -71,6 +74,7 @@ private:
void handleEvent(std::shared_ptr<const BlueprintSaveRequestedEvent> event) override;
void handleEvent(std::shared_ptr<const BlueprintSelectionRequestedEvent> event) override;
void handleEvent(std::shared_ptr<const FloatingLayoutInvalidatedEvent> event) override;
void handleEvent(std::shared_ptr<const ViewScrolledEvent> event) override;
// Reloads the game config and visuals.toml from disk (REQ-CFG-RELOAD), shared
// by every restart path. On success the reloaded visuals are applied to this
@@ -84,16 +88,23 @@ private:
const std::string& schematicId,
const ShipLayoutConfig& currentLayout);
// Centers a modal opened from the selection panel on that panel, kept inside this
// window (REQ-UI-PANEL-MODAL). Called on the constructed dialog before exec(), and
// only for the two modals the panel opens.
void placeOnSelectionPanel(QDialog& dialog) const;
// The rectangle a modal opened from the selection panel is centered on, in this
// window's coordinates, or a null rect when the panel is not up (REQ-UI-PANEL-MODAL).
QRect getSelectionPanelAnchor() const;
// Runs the blueprint selection dialog and enters placement mode for whatever the
// player picked (REQ-UI-BLUEPRINT-DIALOG). Holds no pause or dim scope of its own:
// both callers already hold theirs, which is what keeps the dim continuous when a
// confirmed save hands straight over to this dialog (REQ-UI-MODAL-DIM).
// player picked (REQ-UI-BLUEPRINT-DIALOG). Holds no pause scope of its own: both
// callers already hold theirs, and the save path also holds the layer, which is what
// keeps the dim continuous when a confirmed save hands straight over to this dialog
// (REQ-UI-MODAL-DIM).
void showBlueprintSelectionDialog();
// What every display naming an item needs to explain it (REQ-UI-ITEM-VALUE-TOOLTIP).
// Assembled here because this is where the simulation and the icon caches live.
ItemTooltipContext getItemTooltipContext() const;
// Centers the expansion button on the columns the next purchase unlocks
// (REQ-UI-EXPAND-BUTTON). Its place is in the world, so it is re-derived whenever the
// view scrolls or resizes rather than once per selection like the panels.
void placeExpandButton();
// Places the widgets floating over the game world view, in one ordered pass
// (FloatingPanel.h). Runs on a resize and on every FloatingLayoutInvalidatedEvent.
void layoutPanels();
@@ -113,10 +124,13 @@ private:
SelectionPanel* m_selectionPanel;
ControlsPanel* m_controlsPanel;
BuildButtonBar* m_buildButtonBar;
// Stands in the world on the ground it would buy, so it takes no part in the panels'
// placement pass (REQ-UI-EXPAND-BUTTON).
ExpandButton* m_expandButton = nullptr;
// The saved blueprints themselves; they have no widget of their own any more and
// are reached through the two modal dialogs (REQ-UI-BLUEPRINT-DIALOG).
std::unique_ptr<BlueprintLibrary> m_blueprintLibrary;
ModalDimOverlay* m_dimOverlay = nullptr;
ModalLayer* m_modalLayer = nullptr;
std::vector<ShipLayoutBlueprint> m_layoutBlueprints;
std::shared_ptr<ParsedReplay> m_replay; // non-null => view-only playback

75
src/ui/MessageDialog.cpp Normal file
View File

@@ -0,0 +1,75 @@
#include "MessageDialog.h"
#include <QHBoxLayout>
#include <QLabel>
#include <QPushButton>
#include <QVBoxLayout>
namespace
{
const int kSpacingPx = 8;
}
MessageDialog::MessageDialog(const QString& title, const QString& text, QWidget* parent)
: ModalDialog(parent)
, m_buttonLayout(nullptr)
, m_buttonCount(0)
{
QVBoxLayout* mainLayout = new QVBoxLayout(this);
mainLayout->setContentsMargins(kSpacingPx, kSpacingPx, kSpacingPx, kSpacingPx);
mainLayout->setSpacing(kSpacingPx);
if (!text.isEmpty())
{
QLabel* textLabel = new QLabel(text, this);
mainLayout->addWidget(textLabel);
}
// The buttons sit at the right of their row, the side a dialog is confirmed from.
m_buttonLayout = new QHBoxLayout();
m_buttonLayout->setSpacing(kSpacingPx);
m_buttonLayout->addStretch();
mainLayout->addLayout(m_buttonLayout);
// Last, so it becomes the first row (REQ-UI-MODAL-CHROME). No close button: closing
// is one of the buttons here, or nothing at all.
addHeader(mainLayout, title, false);
}
int MessageDialog::addButton(const QString& caption)
{
const int index = m_buttonCount++;
QPushButton* button = new QPushButton(caption, this);
m_buttonLayout->addWidget(button);
connect(button, &QPushButton::clicked, this, [this, index]() {
onButtonClicked(index);
});
return index;
}
void MessageDialog::setEscapeButtonIndex(int index)
{
m_escapeButtonIndex = index;
}
std::optional<int> MessageDialog::getClickedButtonIndex() const
{
return m_clickedButtonIndex;
}
void MessageDialog::reject()
{
// Escape stands for a button rather than for a dismissal of its own, so the caller
// reads one answer whichever way the player gave it (REQ-UI-GAME-MENU).
if (!m_escapeButtonIndex.has_value())
{
return;
}
onButtonClicked(*m_escapeButtonIndex);
}
void MessageDialog::onButtonClicked(int index)
{
m_clickedButtonIndex = index;
accept();
}

50
src/ui/MessageDialog.h Normal file
View File

@@ -0,0 +1,50 @@
#pragma once
#include <optional>
#include <vector>
#include <QString>
#include "ModalDialog.h"
class QHBoxLayout;
class QLabel;
// The game's own message box (REQ-UI-MODAL-CHROME): a title, an optional line or two of
// text, and a row of buttons the caller names. It stands in for QMessageBox at the three
// places the player is asked to decide something -- the escape menu (REQ-UI-GAME-MENU)
// and the game-over and win screens (REQ-HQ-GAME-OVER, REQ-WIN-SCREEN) -- so that those
// read as part of the game rather than as system alerts.
//
// The caller identifies buttons by the index addButton() hands back, and asks
// getClickedButtonIndex() afterwards; the QDialog result code says only whether a button
// was clicked at all. Q and a click outside do not dismiss it: every button here is a
// decision, and there is no "no change" among them to fall back on.
class MessageDialog : public ModalDialog
{
Q_OBJECT
public:
// text may be empty, for a dialog that is a question its buttons already state.
MessageDialog(const QString& title, const QString& text, QWidget* parent = nullptr);
// Appends a button and returns its index, left to right.
int addButton(const QString& caption);
// Which button Escape stands for. Without one, Escape does nothing -- a dialog whose
// buttons all commit to something has no dismissal to offer.
void setEscapeButtonIndex(int index);
std::optional<int> getClickedButtonIndex() const;
public slots:
void reject() override;
private:
void onButtonClicked(int index);
QHBoxLayout* m_buttonLayout;
int m_buttonCount;
std::optional<int> m_escapeButtonIndex;
std::optional<int> m_clickedButtonIndex;
};

101
src/ui/ModalDialog.cpp Normal file
View File

@@ -0,0 +1,101 @@
#include "ModalDialog.h"
#include <QBoxLayout>
#include <QChar>
#include <QFont>
#include <QHBoxLayout>
#include <QKeyEvent>
#include <QLabel>
#include <QPushButton>
#include <QString>
namespace
{
// The header's own metrics, matching the row the blueprint selection dialog drew
// before this class existed (REQ-UI-BLUEPRINT-DIALOG).
const int kSpacingPx = 8;
const int kSmallButtonSizePx = 22;
const QChar kCrossGlyph(0x00D7); // U+00D7 MULTIPLICATION SIGN
// Q dismisses an open dialog, beside the Escape that QDialog already handles
// (REQ-UI-DIALOG-DISMISS). Ctrl must not be held, matching how the game world's
// table separates a chord from the bare key (resolveKeyAction in
// lib/core/ControlAction.cpp). This deliberately stays out of that table: the table
// answers what an input does in the player's current situation, and a dialog has no
// situation -- it holds focus and takes the key whatever the world beneath it is
// doing.
bool isDismissKey(const QKeyEvent& event)
{
return event.key() == Qt::Key_Q
&& (event.modifiers() & Qt::ControlModifier) == 0;
}
}
ModalDialog::ModalDialog(QWidget* parent)
: QDialog(parent)
{
// An ordinary child widget rather than a window: the layer places it and the dim
// behind it is the same widget's paint (REQ-UI-MODAL-CHROME). Square corners rather
// than rounded ones -- rounding needs a translucent background, which is unreliable
// on Windows. The border matches the build bar and the selection panel.
setWindowFlags(Qt::Widget);
setAttribute(Qt::WA_StyledBackground, true);
// A type selector, so it reaches every subclass but none of the child widgets
// inside them, which draw themselves.
setStyleSheet(QStringLiteral(
"ModalDialog { background-color: palette(window);"
" border: 1px solid palette(mid); }"));
}
bool ModalDialog::isDismissible() const
{
return false;
}
QWidget* ModalDialog::getInitialFocusWidget() const
{
return nullptr;
}
void ModalDialog::requestDismiss()
{
reject();
}
QHBoxLayout* ModalDialog::addHeader(QBoxLayout* mainLayout, const QString& title,
bool withCloseButton)
{
QHBoxLayout* headerLayout = new QHBoxLayout();
headerLayout->setSpacing(kSpacingPx);
QLabel* titleLabel = new QLabel(title, this);
QFont headerFont = titleLabel->font();
headerFont.setBold(true);
titleLabel->setFont(headerFont);
headerLayout->addWidget(titleLabel);
// The stretch is added before the close button so a subclass inserting after the
// title lands left of it, where the blueprint dialog's hotkey badge belongs.
headerLayout->addStretch();
if (withCloseButton)
{
QPushButton* closeButton = new QPushButton(QString(kCrossGlyph), this);
closeButton->setFixedSize(kSmallButtonSizePx, kSmallButtonSizePx);
connect(closeButton, &QPushButton::clicked, this, &QDialog::reject);
headerLayout->addWidget(closeButton);
}
mainLayout->insertLayout(0, headerLayout);
return headerLayout;
}
void ModalDialog::keyPressEvent(QKeyEvent* event)
{
if (isDismissible() && isDismissKey(*event))
{
requestDismiss();
return;
}
QDialog::keyPressEvent(event);
}

54
src/ui/ModalDialog.h Normal file
View File

@@ -0,0 +1,54 @@
#pragma once
#include <QDialog>
class QBoxLayout;
class QHBoxLayout;
class QKeyEvent;
class QString;
// Base of every modal the player meets while playing (REQ-UI-MODAL-CHROME). A modal is
// not an operating system window here: it is an ordinary child widget, hosted and placed
// by the ModalLayer that also paints the dim it sits on, so it has no title bar, no
// window border, and no window-manager close. What a window used to supply, this class
// supplies instead -- the panel background, the drawn header, and the dismissal gestures.
//
// It stays a QDialog for accept()/reject()/result() and the Escape handling built into
// them; only the window-ness is dropped (Qt::Widget flags). Nothing calls exec() on it:
// ModalLayer::execute() runs the modal loop, so that the layer knows what is open.
class ModalDialog : public QDialog
{
Q_OBJECT
public:
explicit ModalDialog(QWidget* parent = nullptr);
// Whether Q and a click outside this dialog dismiss it (REQ-UI-DIALOG-DISMISS). One
// predicate for both gestures because they reach exactly the same dialogs. The
// default refuses both, so a dialog takes the gestures only by saying so: the two
// name dialogs must let Q through as a character, and the schematic choice dialog
// has no way out but choosing (REQ-DEF-SCHEMATIC-DROP).
virtual bool isDismissible() const;
// The widget that should hold the keyboard once the modal is open -- a name prompt's
// line edit -- or nullptr to leave the focus on the modal itself. Asked for by
// ModalLayer rather than read off focusWidget(), because hosting the modal reparents
// it and a reparent clears the focus its constructor set.
virtual QWidget* getInitialFocusWidget() const;
public slots:
// What a dismissal does, whichever gesture asked for it. Cancelling is the default;
// a dialog with modes of its own overrides this to back out of them one at a time
// (ShipLayoutDialog, REQ-UI-DIALOG-DISMISS).
virtual void requestDismiss();
protected:
// Adds the drawn header row -- the title, and a close button at the far right when
// asked for -- as the first row of mainLayout, and returns it so a subclass can
// insert its own widgets after the title (REQ-UI-MODAL-CHROME). The close button
// rejects the dialog, which is what the window-manager close used to do.
QHBoxLayout* addHeader(QBoxLayout* mainLayout, const QString& title,
bool withCloseButton);
void keyPressEvent(QKeyEvent* event) override;
};

View File

@@ -1,46 +0,0 @@
#include "ModalDimOverlay.h"
#include <QPainter>
ModalDimOverlay::ModalDimOverlay(const QColor& dimColor, QWidget* parent)
: QWidget(parent)
, m_dimColor(dimColor)
{
setAttribute(Qt::WA_TransparentForMouseEvents, true);
hide();
}
void ModalDimOverlay::pushModal()
{
if (m_modalDepth++ == 0)
{
raise();
show();
// Force an immediate synchronous paint so the scrim is visible before the
// caller enters a blocking dialog exec() (no undimmed frame flashes through).
repaint();
}
}
void ModalDimOverlay::popModal()
{
if (m_modalDepth > 0 && --m_modalDepth == 0)
{
hide();
}
}
void ModalDimOverlay::setDimColor(const QColor& dimColor)
{
m_dimColor = dimColor;
if (isVisible())
{
update();
}
}
void ModalDimOverlay::paintEvent(QPaintEvent* /*event*/)
{
QPainter painter(this);
painter.fillRect(rect(), m_dimColor);
}

View File

@@ -1,59 +0,0 @@
#pragma once
#include <QColor>
#include <QWidget>
class QPaintEvent;
// A window-wide, semi-transparent scrim drawn over the entire game window while a
// modal dialog or menu is open, behind that modal (REQ-UI-MODAL-DIM). It is a child
// of the main window covering its full rect and is transparent to mouse events, so it
// only dims the game presentation and never intercepts input.
//
// Visibility is reference-counted via pushModal()/popModal() so that a single dim is
// shown across nested or back-to-back modals (e.g. the recipe selection dialog that
// immediately opens the layout dialog) rather than flickering or stacking overlays.
class ModalDimOverlay : public QWidget
{
Q_OBJECT
public:
ModalDimOverlay(const QColor& dimColor, QWidget* parent);
// Raise + show on the first active modal; hide when the last one closes.
void pushModal();
void popModal();
// Update the dim color (e.g. after a config reload on Restart, REQ-CFG-RELOAD).
void setDimColor(const QColor& dimColor);
protected:
void paintEvent(QPaintEvent* event) override;
private:
QColor m_dimColor;
int m_modalDepth = 0;
};
// RAII guard: shows the dim overlay for the duration of a scope (typically around a
// blocking dialog exec()) and hides it (via reference count) on scope exit.
class ModalDimScope
{
public:
explicit ModalDimScope(ModalDimOverlay& overlay)
: m_overlay(overlay)
{
m_overlay.pushModal();
}
~ModalDimScope()
{
m_overlay.popModal();
}
ModalDimScope(const ModalDimScope&) = delete;
ModalDimScope& operator=(const ModalDimScope&) = delete;
private:
ModalDimOverlay& m_overlay;
};

241
src/ui/ModalLayer.cpp Normal file
View File

@@ -0,0 +1,241 @@
#include "ModalLayer.h"
#include <cstddef>
#include <QApplication>
#include <QEventLoop>
#include <QFrame>
#include <QMetaObject>
#include <QMouseEvent>
#include <QPainter>
#include <QPoint>
#include <QScrollArea>
#include <QSize>
#include "ModalDialog.h"
ModalLayer* ModalLayer::findFor(const QWidget& widget)
{
for (QWidget* candidate = widget.parentWidget(); candidate != nullptr;
candidate = candidate->parentWidget())
{
ModalLayer* layer = qobject_cast<ModalLayer*>(candidate);
if (layer != nullptr)
{
return layer;
}
}
return nullptr;
}
ModalLayer::ModalLayer(const QColor& dimColor, QWidget* parent)
: QWidget(parent)
, m_dimColor(dimColor)
{
hide();
}
int ModalLayer::execute(ModalDialog& content, const QRect& anchorRect)
{
// Hosted in a scroll area so a modal larger than the window is reached by scrolling
// instead of being cut off by the window edge (REQ-UI-MODAL-CHROME). When the
// content fits -- which is the normal case -- the host is exactly its size and no
// scroll bar appears, so the player sees the modal alone.
// Noted before anything here touches the focus, and given back when this modal
// closes: the game world beneath for the first modal of a stack, and the modal it was
// opened from for one above that.
QWidget* const focusBefore = QApplication::focusWidget();
QScrollArea* host = new QScrollArea(this);
host->setFrameShape(QFrame::NoFrame);
host->setWidgetResizable(false);
host->setWidget(&content);
// Resolved before the new modal joins the stack, so a null rect means the modal it
// was opened from -- the Create Blueprint dialog opens on the layout dialog beneath
// it (REQ-UI-PANEL-MODAL).
const QRect anchor = !anchorRect.isNull() ? anchorRect
: (m_stack.empty() ? rect()
: m_stack.back().host->geometry());
m_stack.push_back(HostedModal{ &content, host, focusBefore });
// Placed and shown before the layer itself is, so that the frame the layer first
// paints already carries the modal. Showing the layer first put the dim on screen a
// frame before anything stood on it, which read as a black flash
// (REQ-UI-MODAL-DIM). Placing works while the layer is hidden: its geometry is the
// window's whether or not it is shown, and a child shown under a hidden parent
// appears with it.
raise();
place(*host, content, anchor);
host->show();
content.show();
updateVisibility();
// The widget the modal names where it names one -- a name dialog puts the caret in
// its line edit -- and the modal itself otherwise, so keys reach it and not the game
// world behind (REQ-UI-MODAL-CHROME).
QWidget* focusTarget = content.getInitialFocusWidget();
if (focusTarget == nullptr)
{
focusTarget = &content;
}
focusTarget->setFocus();
// The dialog's own loop, run here rather than by QDialog::exec(), so the layer knows
// what is open and can place it, dim behind it, and take the clicks beside it.
QEventLoop loop;
const QMetaObject::Connection connection =
connect(&content, &QDialog::finished, &loop, &QEventLoop::quit);
loop.exec();
disconnect(connection);
// takeWidget() before the host goes: the scroll area owns what it is given, and
// every modal here is a local of its caller. It hands the content back parentless.
host->takeWidget();
content.hide();
delete host;
QPointer<QWidget> focusAfter;
for (std::size_t i = m_stack.size(); i > 0; --i)
{
if (m_stack[i - 1].content == &content)
{
focusAfter = m_stack[i - 1].focusBefore;
m_stack.erase(m_stack.begin() + static_cast<std::ptrdiff_t>(i - 1));
break;
}
}
updateVisibility();
// After the layer is hidden, not before: hiding a widget takes the focus off
// everything on it, which would undo this again.
if (!focusAfter.isNull())
{
focusAfter->setFocus();
}
return content.result();
}
bool ModalLayer::isActive() const
{
return !m_stack.empty();
}
void ModalLayer::addHold()
{
++m_holdCount;
updateVisibility();
}
void ModalLayer::removeHold()
{
if (m_holdCount > 0)
{
--m_holdCount;
updateVisibility();
}
}
void ModalLayer::setDimColor(const QColor& dimColor)
{
m_dimColor = dimColor;
if (isVisible())
{
update();
}
}
void ModalLayer::paintEvent(QPaintEvent* /*event*/)
{
// One dim however many modals are stacked (REQ-UI-MODAL-DIM): the modals above it
// draw their own opaque background, so nesting darkens nothing twice.
QPainter painter(this);
painter.fillRect(rect(), m_dimColor);
}
void ModalLayer::mousePressEvent(QMouseEvent* event)
{
m_pressedOutside = event->button() == Qt::LeftButton
&& isOutsideOpenModal(event->pos());
// Taken whether or not it dismisses anything: the window behind a modal receives no
// input, and closing the modal does not turn this click into one for what lies under
// it (REQ-UI-DIALOG-DISMISS).
event->accept();
}
void ModalLayer::mouseReleaseEvent(QMouseEvent* event)
{
const bool pressedOutside = m_pressedOutside;
m_pressedOutside = false;
event->accept();
if (event->button() != Qt::LeftButton || !pressedOutside
|| !isOutsideOpenModal(event->pos()) || m_stack.empty())
{
return;
}
// A drag that began inside the modal never gets here -- the widget it began on keeps
// the release -- so no gesture ends by discarding the modal it was made in.
ModalDialog* openModal = m_stack.back().content;
if (openModal->isDismissible())
{
openModal->requestDismiss();
}
}
bool ModalLayer::isOutsideOpenModal(const QPoint& position) const
{
if (m_stack.empty())
{
return true;
}
return !m_stack.back().host->geometry().contains(position);
}
void ModalLayer::place(QScrollArea& host, ModalDialog& content,
const QRect& anchorRect) const
{
// The content has never been shown, so it is still at its default size until its
// layout has run; sizing it before that would use the wrong extent.
content.adjustSize();
const QSize hostSize = content.size().boundedTo(size());
host.resize(hostSize);
QPoint topLeft(anchorRect.center().x() - hostSize.width() / 2,
anchorRect.center().y() - hostSize.height() / 2);
// Pushed back inside the layer, which is the game window (REQ-UI-PANEL-MODAL). The
// far edge is clamped first and the near edge second, which is what aligns a modal
// as large as the window with the window's top-left corner rather than pushing it
// off the opposite edge.
topLeft.setX(qMax(0, qMin(topLeft.x(), width() - hostSize.width())));
topLeft.setY(qMax(0, qMin(topLeft.y(), height() - hostSize.height())));
host.move(topLeft);
}
void ModalLayer::updateVisibility()
{
const bool shouldShow = !m_stack.empty() || m_holdCount > 0;
if (shouldShow == isVisible())
{
return;
}
if (shouldShow)
{
raise();
show();
// Painted at once rather than at the next paint event, so no undimmed frame of
// the world flashes through in between. The modal standing on the layer is
// already placed and shown by now, so this one paint puts up both (execute()).
repaint();
}
else
{
hide();
}
}

117
src/ui/ModalLayer.h Normal file
View File

@@ -0,0 +1,117 @@
#pragma once
#include <vector>
#include <QColor>
#include <QPoint>
#include <QPointer>
#include <QRect>
#include <QWidget>
class ModalDialog;
class QMouseEvent;
class QPaintEvent;
class QScrollArea;
// The one surface every modal is shown on (REQ-UI-MODAL-CHROME, REQ-UI-MODAL-DIM): a
// child of the main window covering its whole rect, which paints the dim, hosts the
// open modal, and runs its modal loop. Because it is a widget of the window rather than
// a window of its own, it receives the clicks that land beside the modal -- which a
// blocked window would never see -- and that is what makes the click dismissal possible
// (REQ-UI-DIALOG-DISMISS).
//
// Modals nest: the layer keeps a stack, shows one dim for all of them, and hides itself
// when the last one closes. It is shown while the stack is non-empty or a hold is taken.
class ModalLayer : public QWidget
{
Q_OBJECT
public:
// The layer a widget is shown on, found by walking up its parents, or nullptr when
// it is not on one. How a widget deep inside a modal reaches the layer to open a
// second modal on it, without every widget between them having to carry a pointer.
static ModalLayer* findFor(const QWidget& widget);
ModalLayer(const QColor& dimColor, QWidget* parent);
// Shows content on this layer and runs it until it accepts or rejects, returning its
// QDialog result code. anchorRect (in this layer's coordinates, which are the main
// window's) is what the content is centered on. A null rect centers it on the modal
// it was opened from, and on the layer itself when it is the first one open
// (REQ-UI-PANEL-MODAL).
int execute(ModalDialog& content, const QRect& anchorRect = QRect());
// Whether a modal is open. The main window asks before handing focus back to the
// game world, which it must not do while a modal holds it.
bool isActive() const;
// Keeps the layer shown with nothing on it, so that one modal handing straight over
// to another does not blink the dim off in between (REQ-UI-MODAL-DIM).
void addHold();
void removeHold();
// Update the dim color (e.g. after a config reload on Restart, REQ-CFG-RELOAD).
void setDimColor(const QColor& dimColor);
protected:
void paintEvent(QPaintEvent* event) override;
void mousePressEvent(QMouseEvent* event) override;
void mouseReleaseEvent(QMouseEvent* event) override;
private:
// A modal and the scroll area it is shown in. The host is what the layer places and
// what the player sees the edges of, so it is also the rectangle "outside the modal"
// is measured against.
struct HostedModal
{
ModalDialog* content;
QScrollArea* host;
// What held the keyboard when this modal opened, given back when it closes.
// Hiding the layer, or closing a modal a second one was opened from, leaves the
// window with no focus widget at all, and a window with none answers no keys --
// Escape included, which is what opens the menu (REQ-UI-GAME-MENU). A QPointer
// because a modal may outlive what it took the focus from.
QPointer<QWidget> focusBefore;
};
// Sizes content to what it asks for, capped at the layer, and centers it on
// anchorRect (REQ-UI-PANEL-MODAL).
void place(QScrollArea& host, ModalDialog& content, const QRect& anchorRect) const;
void updateVisibility();
// Whether a point in this layer's coordinates lies beyond the open modal. A click on
// an inert part of the modal -- a label, the space between two controls -- arrives
// here too, propagated by the widget that ignored it, so where the click landed is
// what decides, never that the layer received it.
bool isOutsideOpenModal(const QPoint& position) const;
QColor m_dimColor;
// Set by a left press that landed outside the open modal, so that only a press and a
// release both outside dismiss it (REQ-UI-DIALOG-DISMISS).
bool m_pressedOutside = false;
std::vector<HostedModal> m_stack; // bottom-most first; back() is the open one
int m_holdCount = 0;
};
// RAII guard for addHold()/removeHold().
class ModalLayerHold
{
public:
explicit ModalLayerHold(ModalLayer& layer)
: m_layer(layer)
{
m_layer.addHold();
}
~ModalLayerHold()
{
m_layer.removeHold();
}
ModalLayerHold(const ModalLayerHold&) = delete;
ModalLayerHold& operator=(const ModalLayerHold&) = delete;
private:
ModalLayer& m_layer;
};

View File

@@ -7,7 +7,7 @@
// exit it restores the snapshotted speed and rebases the render frame timer, so the
// wall time the player spent in the dialog is not converted into simulation ticks.
//
// Pairs with ModalDimScope, which the same call sites use for the dim overlay.
// Pairs with ModalLayer, which the same call sites use to show the modal itself.
//
// Two escape hatches for the paths that must not simply restore at scope exit:
// restore() — restore now instead of at scope exit, for when more work has to run

View File

@@ -0,0 +1,63 @@
#include "NameInputDialog.h"
#include <QHBoxLayout>
#include <QLabel>
#include <QLineEdit>
#include <QPushButton>
#include <QVBoxLayout>
namespace
{
const int kSpacingPx = 8;
const int kMinimumWidthPx = 280;
}
NameInputDialog::NameInputDialog(const QString& title, const QString& prompt,
QWidget* parent)
: ModalDialog(parent)
, m_nameEdit(nullptr)
{
QVBoxLayout* mainLayout = new QVBoxLayout(this);
mainLayout->setContentsMargins(kSpacingPx, kSpacingPx, kSpacingPx, kSpacingPx);
mainLayout->setSpacing(kSpacingPx);
QLabel* promptLabel = new QLabel(prompt, this);
mainLayout->addWidget(promptLabel);
m_nameEdit = new QLineEdit(this);
m_nameEdit->setMinimumWidth(kMinimumWidthPx);
mainLayout->addWidget(m_nameEdit);
QHBoxLayout* buttonLayout = new QHBoxLayout();
buttonLayout->setSpacing(kSpacingPx);
buttonLayout->addStretch();
QPushButton* confirmButton = new QPushButton(tr("Confirm"), this);
QPushButton* cancelButton = new QPushButton(tr("Cancel"), this);
buttonLayout->addWidget(confirmButton);
buttonLayout->addWidget(cancelButton);
mainLayout->addLayout(buttonLayout);
connect(confirmButton, &QPushButton::clicked, this, &QDialog::accept);
connect(cancelButton, &QPushButton::clicked, this, &QDialog::reject);
// Enter confirms from the line edit, as it did in the prompt this replaces.
connect(m_nameEdit, &QLineEdit::returnPressed, this, &QDialog::accept);
addHeader(mainLayout, title, false);
// The line edit is what the player came here to use, and it takes Q as a character
// because it holds the focus (REQ-UI-DIALOG-DISMISS). Set here for a dialog shown on
// its own, and named again through getInitialFocusWidget() for the usual case: being
// hosted on the modal layer reparents this dialog, which clears the focus set here.
m_nameEdit->setFocus();
}
QWidget* NameInputDialog::getInitialFocusWidget() const
{
return m_nameEdit;
}
QString NameInputDialog::getName() const
{
return m_nameEdit->text().trimmed();
}

32
src/ui/NameInputDialog.h Normal file
View File

@@ -0,0 +1,32 @@
#pragma once
#include <QString>
#include "ModalDialog.h"
class QLineEdit;
// The game's own name prompt (REQ-UI-MODAL-CHROME): a title, a prompt, a line edit, and
// Confirm and Cancel. It stands in for QInputDialog at the two places a blueprint is
// named -- the blueprint save dialog (REQ-UI-BLUEPRINT-CREATE) and the Create Blueprint
// dialog of the layout configuration dialog (REQ-MOD-UI-BLUEPRINT-CREATE).
//
// Neither Q nor a click outside dismisses it (ModalDialog::isDismissible stays false):
// Q is a character the player may be typing, and a half-typed name is work in progress
// that no stray gesture may discard (REQ-UI-DIALOG-DISMISS). Escape and Cancel remain.
// The caller decides what an empty name means; the dialog reports it trimmed.
class NameInputDialog : public ModalDialog
{
Q_OBJECT
public:
NameInputDialog(const QString& title, const QString& prompt,
QWidget* parent = nullptr);
QString getName() const;
QWidget* getInitialFocusWidget() const override;
private:
QLineEdit* m_nameEdit;
};

View File

@@ -10,6 +10,7 @@
#include "BuildingIconCache.h"
#include "ItemIconCache.h"
#include "ItemTooltip.h"
namespace
{
@@ -47,6 +48,24 @@ void clearRow(QHBoxLayout* layout)
} // namespace
std::vector<std::vector<RecipeLineRow::Amount>> RecipeLineRow::toOutputGroups(
const RecipeDef& recipe)
{
std::vector<std::vector<Amount>> groups;
groups.reserve(recipe.outputGroups.size());
for (const RecipeOutputGroup& group : recipe.outputGroups)
{
std::vector<Amount> amounts;
amounts.reserve(group.items.size());
for (const RecipeOutput& out : group.items)
{
amounts.push_back(Amount{ out.item, out.amount });
}
groups.push_back(std::move(amounts));
}
return groups;
}
RecipeLineRow::RecipeLineRow(ItemIconCache* itemIcons, BuildingIconCache* buildingIcons,
QWidget* parent)
: QWidget(parent)
@@ -87,6 +106,13 @@ void RecipeLineRow::setCardChrome(bool enabled)
: QMargins(0, 0, 0, 0));
}
void RecipeLineRow::setItemTooltips(const ItemTooltipContext& context,
TooltipTrigger::Trigger trigger)
{
m_tooltipContext = context;
m_tooltipTrigger = trigger;
}
void RecipeLineRow::setLine(const Spec& spec)
{
if (spec.isEmpty())
@@ -143,12 +169,21 @@ void RecipeLineRow::rebuild(const Spec& spec)
// Second line: what the cycle costs, makes and takes.
addAmounts(spec.inputs);
if (!spec.inputs.empty() && !spec.outputs.empty())
if (!spec.inputs.empty() && !spec.outputGroups.empty())
{
const QChar rightArrow(0x2192); // U+2192 RIGHTWARDS ARROW
addAndShow(m_amountsLayout, new QLabel(QString(rightArrow), m_amountsRow));
}
addAmounts(spec.outputs);
for (std::size_t i = 0; i < spec.outputGroups.size(); ++i)
{
// Between one group and the next, so alternatives read as a choice rather than as
// one combined yield -- which is what a run of `+` would say (REQ-UI-RECIPE-SUMMARY).
if (i > 0)
{
addAndShow(m_amountsLayout, new QLabel(QStringLiteral("/"), m_amountsRow));
}
addAmounts(spec.outputGroups[i]);
}
if (spec.durationSeconds.has_value() && *spec.durationSeconds > 0.0)
{
@@ -172,25 +207,45 @@ void RecipeLineRow::addAmounts(const std::vector<Amount>& amounts)
{
addAndShow(m_amountsLayout, new QLabel(QStringLiteral("+"), m_amountsRow));
}
// The item's icon on its colored square (REQ-UI-ITEM-ICON). A missing icon file
// is not an error: the square stands alone then, and only an item with no square
// either falls back to its id in text.
const QPixmap icon = (m_itemIcons != nullptr)
? m_itemIcons->getSquarePixmap(entry.itemId, kIconSizePx)
: QPixmap();
if (!icon.isNull())
{
QLabel* iconLabel = new QLabel(m_amountsRow);
iconLabel->setPixmap(icon);
addAndShow(m_amountsLayout, iconLabel);
}
else
{
addAndShow(m_amountsLayout,
new QLabel(QString::fromStdString(entry.itemId), m_amountsRow));
}
addAndShow(m_amountsLayout,
new QLabel(QString::number(entry.amount), m_amountsRow));
addAmount(entry);
}
}
void RecipeLineRow::addAmount(const Amount& entry)
{
// A widget of its own around the pair, so what the player points at is the whole
// statement -- this many of that item -- rather than an icon the height of a line of
// text (REQ-UI-ITEM-VALUE-TOOLTIP). Its spacing is the row's own, so the line reads
// exactly as it did when the two labels sat in the row directly.
QWidget* pair = new QWidget(m_amountsRow);
QHBoxLayout* pairLayout = new QHBoxLayout(pair);
pairLayout->setContentsMargins(0, 0, 0, 0);
pairLayout->setSpacing(m_amountsLayout->spacing());
// The item's icon on its colored square (REQ-UI-ITEM-ICON). A missing icon file
// is not an error: the square stands alone then, and only an item with no square
// either falls back to its id in text.
const QPixmap icon = (m_itemIcons != nullptr)
? m_itemIcons->getSquarePixmap(entry.itemId, kIconSizePx)
: QPixmap();
if (!icon.isNull())
{
QLabel* iconLabel = new QLabel(pair);
iconLabel->setPixmap(icon);
addAndShow(pairLayout, iconLabel);
}
else
{
addAndShow(pairLayout,
new QLabel(QString::fromStdString(entry.itemId), pair));
}
addAndShow(pairLayout, new QLabel(QString::number(entry.amount), pair));
if (m_tooltipContext.has_value())
{
ItemTooltip::attachTo(*pair, *m_tooltipContext, entry.itemId, m_tooltipTrigger);
}
m_amountsLayout->addWidget(pair);
pair->show();
}

View File

@@ -8,6 +8,9 @@
#include <QWidget>
#include "BuildingType.h"
#include "ItemTooltipContext.h"
#include "RecipesConfig.h"
#include "TooltipTrigger.h"
class BuildingIconCache;
class ItemIconCache;
@@ -59,9 +62,12 @@ public:
// name is the caption of the widget around this one instead.
QString name;
std::vector<Amount> inputs;
// Empty for a line that produces no item of its own: a ship schematic, or a
// module's price. No arrow is drawn then.
std::vector<Amount> outputs;
// What the recipe produces, one entry per output group (REQ-MAT-OUTPUT-GROUP).
// The items of a group are drawn joined by `+` because they come together, and the
// groups joined by `/` because only one of them happens. Empty for a line that
// produces no item of its own: a ship schematic, or a module's price. No arrow is
// drawn then.
std::vector<std::vector<Amount>> outputGroups;
std::optional<double> durationSeconds;
// True where the time is added to something else rather than being a cycle of
// its own, and so reads "+3.0 s" (REQ-MOD-UI-DIALOG).
@@ -70,14 +76,19 @@ public:
bool operator==(const Spec& other) const
{
return building == other.building && name == other.name
&& inputs == other.inputs && outputs == other.outputs
&& inputs == other.inputs && outputGroups == other.outputGroups
&& durationSeconds == other.durationSeconds
&& durationIsAddition == other.durationIsAddition;
}
bool isEmpty() const { return inputs.empty() && outputs.empty(); }
bool isEmpty() const { return inputs.empty() && outputGroups.empty(); }
};
// A recipe's output groups as this row states them (REQ-MAT-OUTPUT-GROUP). Shared, so
// that every place drawing a recipe -- the summary, the option buttons, the tooltip
// lines -- converts it the same way rather than each keeping its own copy.
static std::vector<std::vector<Amount>> toOutputGroups(const RecipeDef& recipe);
// Both caches may be null, which leaves the icons off: an item with no square and
// no icon falls back to its id, and a building with no chip to its name alone.
// Neither is owned.
@@ -95,9 +106,24 @@ public:
// by what holds it.
void setCardChrome(bool enabled);
// Lets every amount on the line explain the item it names, the number and the icon
// together as one target (REQ-UI-ITEM-VALUE-TOOLTIP). Off by default, because the
// line is silent wherever what holds it carries a tooltip of its own -- a module
// button (REQ-MOD-UI-MODULE-TOOLTIP) -- or is itself a tooltip (REQ-UI-ITEM-TOOLTIP).
// HoverOnly where the line sits on something the player clicks, whose click is not
// free to explain (REQ-UI-TOOLTIP-TRIGGER).
//
// Call before the first setLine(): the tooltips are attached as the line is built,
// and an unchanged spec is not rebuilt.
void setItemTooltips(const ItemTooltipContext& context,
TooltipTrigger::Trigger trigger);
private:
void rebuild(const Spec& spec);
void addAmounts(const std::vector<Amount>& amounts);
// The icon and the number of one item, side by side in a widget of their own so the
// pair can be pointed at as one thing (REQ-UI-ITEM-VALUE-TOOLTIP).
void addAmount(const Amount& entry);
ItemIconCache* m_itemIcons;
BuildingIconCache* m_buildingIcons;
@@ -112,4 +138,8 @@ private:
// What the row currently shows, so a refresh at tick rate rebuilds it only when the
// recipe actually changed.
Spec m_spec;
// Unset on a line whose items say nothing, which is most of them.
std::optional<ItemTooltipContext> m_tooltipContext;
TooltipTrigger::Trigger m_tooltipTrigger =
TooltipTrigger::Trigger::HoverOnly;
};

View File

@@ -33,16 +33,6 @@ std::vector<RecipeLineRow::Amount> toAmounts(
return amounts;
}
std::vector<RecipeLineRow::Amount> toAmounts(const std::vector<RecipeOutput>& outputs)
{
std::vector<RecipeLineRow::Amount> amounts;
amounts.reserve(outputs.size());
for (const RecipeOutput& output : outputs)
{
amounts.push_back(RecipeLineRow::Amount{ output.item, output.amount });
}
return amounts;
}
} // namespace
@@ -90,7 +80,7 @@ std::vector<RecipeSelectionOption> buildRecipeSelectionOptions(
RecipeLineRow::Spec line;
line.inputs = toAmounts(recipe.inputs);
line.outputs = toAmounts(recipe.outputs);
line.outputGroups = RecipeLineRow::toOutputGroups(recipe);
line.durationSeconds = recipe.durationSeconds;
options.push_back({recipe.id,
@@ -116,13 +106,10 @@ namespace
RecipeSelectionDialog::RecipeSelectionDialog(
const std::vector<RecipeSelectionOption>& options,
const QString& title, ItemIconCache* itemIcons, BuildingIconCache* buildingIcons,
const QString& title, const ItemTooltipContext& context,
QWidget* parent)
: QDialog(parent)
: ModalDialog(parent)
{
setWindowTitle(title);
setModal(true);
QVBoxLayout* mainLayout = new QVBoxLayout(this);
// One vertical column of buttons, each stating what it makes (REQ-UI-SELECT-OPTIONS).
@@ -169,8 +156,17 @@ RecipeSelectionDialog::RecipeSelectionDialog(
nameLabel->setAttribute(Qt::WA_TransparentForMouseEvents, true);
face->addWidget(nameLabel);
RecipeLineRow* line = new RecipeLineRow(itemIcons, buildingIcons, button);
line->setAttribute(Qt::WA_TransparentForMouseEvents, true);
// The button face says what the option makes; what it does not say is where
// an input comes from, and that its items answer themselves. Hover only: the
// click here picks the option (REQ-UI-ITEM-VALUE-TOOLTIP).
//
// Unlike the name above it, the line is not transparent to the mouse: Qt
// never looks inside a transparent widget for the cursor, so its items could
// not be hovered if it were. The press it does not handle propagates to the
// button as it would from any other child, so the option still picks.
RecipeLineRow* line =
new RecipeLineRow(context.itemIcons, context.buildingIcons, button);
line->setItemTooltips(context, TooltipTrigger::Trigger::HoverOnly);
face->addWidget(line);
line->setLine(option.line);
}
@@ -186,6 +182,16 @@ RecipeSelectionDialog::RecipeSelectionDialog(
listLayout->addStretch(1);
scrollArea->setWidget(list);
// Added last so the header sits above a list whose height is already settled; the
// modal draws its own title and close button, having no window frame to carry them
// (REQ-UI-MODAL-CHROME).
addHeader(mainLayout, title, true);
}
bool RecipeSelectionDialog::isDismissible() const
{
return true;
}
std::optional<std::string> RecipeSelectionDialog::getChosenId() const

View File

@@ -4,15 +4,14 @@
#include <string>
#include <vector>
#include <QDialog>
#include <QString>
#include "BuildingType.h"
#include "ItemTooltipContext.h"
#include "ModalDialog.h"
#include "RecipeLineRow.h"
struct GameConfig;
class BuildingIconCache;
class ItemIconCache;
class Simulation;
class QPushButton;
@@ -39,20 +38,25 @@ std::vector<RecipeSelectionOption> buildRecipeSelectionOptions(
BuildingType type, Simulation& sim, const GameConfig& config);
// Modal dialog listing the options in one vertical column (REQ-UI-SELECT-OPTIONS). The
// game is paused by the caller while it is open. Clicking an option selects it
// and closes the dialog; dismissing it (close/Esc) leaves no choice.
class RecipeSelectionDialog : public QDialog
// game is paused by the caller while it is open. Clicking an option selects it and closes
// the dialog; dismissing it (close button, Escape, Q, or a click outside) leaves no
// choice (REQ-UI-DIALOG-DISMISS).
class RecipeSelectionDialog : public ModalDialog
{
Q_OBJECT
public:
// The icon caches draw each option's recipe line (REQ-UI-ITEM-ICON). Not owned.
// The context's icon caches draw each option's recipe line (REQ-UI-ITEM-ICON), and
// the rest of it lets those items explain themselves (REQ-UI-ITEM-VALUE-TOOLTIP).
// Nothing in it is owned.
RecipeSelectionDialog(const std::vector<RecipeSelectionOption>& options,
const QString& title, ItemIconCache* itemIcons,
BuildingIconCache* buildingIcons, QWidget* parent = nullptr);
const QString& title, const ItemTooltipContext& context,
QWidget* parent = nullptr);
std::optional<std::string> getChosenId() const;
bool isDismissible() const override;
private:
void onOptionClicked(int index);

View File

@@ -24,16 +24,6 @@ std::vector<RecipeLineRow::Amount> toAmounts(
return amounts;
}
std::vector<RecipeLineRow::Amount> toAmounts(const std::vector<RecipeOutput>& outputs)
{
std::vector<RecipeLineRow::Amount> amounts;
amounts.reserve(outputs.size());
for (const RecipeOutput& output : outputs)
{
amounts.push_back(RecipeLineRow::Amount{ output.item, output.amount });
}
return amounts;
}
QString grantKindLabel(SchematicType type)
{
@@ -51,18 +41,16 @@ QString grantKindLabel(SchematicType type)
SchematicChoiceDialog::SchematicChoiceDialog(
const std::vector<SchematicChoiceOption>& options,
const RecipesConfig& recipes, ItemIconCache* itemIcons,
BuildingIconCache* buildingIcons,
const RecipesConfig& recipes, const ItemTooltipContext& context,
QWidget* parent)
: QDialog(parent)
: ModalDialog(parent)
, m_chosenIndex(0)
{
setWindowTitle(tr("Schematic Drop"));
setWindowFlags(windowFlags() & ~Qt::WindowCloseButtonHint);
setModal(true);
QVBoxLayout* mainLayout = new QVBoxLayout(this);
// Its own title line, and the only one: a modal draws its title rather than wearing
// one (REQ-UI-MODAL-CHROME), and this dialog carries no close button because there
// is no way out but choosing (REQ-DEF-SCHEMATIC-DROP).
QLabel* titleLabel = new QLabel(tr("Choose a schematic to unlock:"), this);
QFont titleFont = titleLabel->font();
titleFont.setPointSize(titleFont.pointSize() + 2);
@@ -141,18 +129,23 @@ SchematicChoiceDialog::SchematicChoiceDialog(
if (def == nullptr) { continue; }
// The recipe drawn as it is everywhere else, led by the building
// that runs it and its name, so the line says everything there is
// to say about it and carries no tooltip (REQ-DEF-SCHEMATIC-DROP).
// that runs it and its name, so the line says everything there is to
// say about the recipe itself (REQ-DEF-SCHEMATIC-DROP). The items it
// names still explain themselves, and the card around them is not
// clicked -- the Select button below it is -- so a click on one says
// it at once (REQ-UI-ITEM-VALUE-TOOLTIP).
RecipeLineRow::Spec spec;
spec.building = def->building;
spec.name = QString::fromStdString(toDisplayName(def->id));
spec.inputs = toAmounts(def->inputs);
spec.outputs = toAmounts(def->outputs);
spec.outputGroups = RecipeLineRow::toOutputGroups(*def);
spec.durationSeconds = def->durationSeconds;
RecipeLineRow* line =
new RecipeLineRow(itemIcons, buildingIcons, card);
new RecipeLineRow(context.itemIcons, context.buildingIcons, card);
line->setCardChrome(true);
line->setItemTooltips(context,
TooltipTrigger::Trigger::HoverAndClick);
cardLayout->addWidget(line);
line->setLine(spec);
}
@@ -177,6 +170,12 @@ int SchematicChoiceDialog::getChosenIndex() const
return m_chosenIndex;
}
void SchematicChoiceDialog::reject()
{
// Deliberately empty: the dialog stays open until an option is clicked
// (REQ-DEF-SCHEMATIC-DROP). The game is paused meanwhile, so nothing waits on it.
}
void SchematicChoiceDialog::onOptionClicked(int index)
{
m_chosenIndex = index;

View File

@@ -2,28 +2,40 @@
#include <vector>
#include <QDialog>
#include "ItemTooltipContext.h"
#include "ModalDialog.h"
#include "SchematicChoiceOption.h"
struct RecipesConfig;
class BuildingIconCache;
class ItemIconCache;
class SchematicChoiceDialog : public QDialog
// The drop's choice dialog (REQ-DEF-SCHEMATIC-DROP). Unlike every other dialog it cannot
// be dismissed: clicking an option is the only way out, so getChosenIndex() always names
// an option the player picked, and it only ever finishes Accepted. It inherits the base's
// refusal of Q and of a click outside (ModalDialog::isDismissible) and adds the refusal
// of Escape below.
class SchematicChoiceDialog : public ModalDialog
{
Q_OBJECT
public:
// The icon caches draw the recipe lines of the "Unlocks recipes" list
// (REQ-DEF-SCHEMATIC-DROP, REQ-UI-ITEM-ICON, REQ-UI-BUILD-ICON). Not owned.
// The context's icon caches draw the recipe lines of the "Unlocks recipes" list
// (REQ-DEF-SCHEMATIC-DROP, REQ-UI-ITEM-ICON, REQ-UI-BUILD-ICON), and the rest of it
// lets the items those lines name explain themselves (REQ-UI-ITEM-VALUE-TOOLTIP).
// Nothing in it is owned.
SchematicChoiceDialog(const std::vector<SchematicChoiceOption>& options,
const RecipesConfig& recipes, ItemIconCache* itemIcons,
BuildingIconCache* buildingIcons,
const RecipesConfig& recipes,
const ItemTooltipContext& context,
QWidget* parent = nullptr);
int getChosenIndex() const;
public slots:
// Refuses the dismissal (REQ-DEF-SCHEMATIC-DROP): the drop is a reward the player
// has earned, and leaving without choosing would either forfeit it or award the
// option that happens to be first. Escape funnels through QDialog::reject(), so
// declining it here turns it away without swallowing keys one at a time.
void reject() override;
private:
void onOptionClicked(int index);

View File

@@ -17,8 +17,11 @@
namespace
{
// Distance kept between the panel and the edges of the game world view, and between it
// and the widgets it steps around (REQ-UI-SELECTION-PANEL).
// The edge margin: the distance kept between the panel and the edges of the game world
// view, and between it and the widgets it steps around (REQ-UI-SELECTION-PANEL). The gap
// the panel keeps from the selection itself is the wider of the two and is not this: being
// half a tile, it is measured where the tile size is known and arrives with the anchor
// rectangle (SelectionAnchorChangedEvent).
const int kMarginPx = 8;
// Upper bound on the card width. The panel is content-sized, but several of the cards'
@@ -170,12 +173,14 @@ void SelectionPanel::handleEvent(std::shared_ptr<const SelectionChangedEvent> ev
void SelectionPanel::handleEvent(
std::shared_ptr<const SelectionAnchorChangedEvent> event)
{
// A new selection is starting. Both the anchor and the side are settled against it
// and then left alone for as long as it lasts (REQ-UI-SELECTION-PANEL); the side is
// only reset here, being resolved on the next placement once the card's width is
// known. The rect arrives in the world view's coordinates and is translated when the
// panel is placed, the two widgets being siblings in the same parent.
m_anchorRect = event->rectPx;
// A new selection is starting. The anchor, the gap kept from it, and the side are all
// settled against it and then left alone for as long as it lasts
// (REQ-UI-SELECTION-PANEL); the side is only reset here, being resolved on the next
// placement once the card's width is known. The rect arrives in the world view's
// coordinates and is translated when the panel is placed, the two widgets being
// siblings in the same parent.
m_anchorRect = event->rectPx;
m_selectionGapPx = event->selectionGapPx;
m_side.reset();
// A position the player dragged the panel to belongs to the selection it was set in.
// A new selection places the panel anew against its own anchor
@@ -354,7 +359,7 @@ void SelectionPanel::placeIn(const QRect& viewRect, const std::vector<QRect>& oc
wantedSize, occupiedRects, kMarginPx);
}
return placeBesideAnchor(band, anchorRect, *m_side, wantedSize, occupiedRects,
kMarginPx);
m_selectionGapPx, kMarginPx);
};
// Run twice. Parts of a card report an unstyled size until the style has actually
@@ -376,7 +381,7 @@ void SelectionPanel::placeIn(const QRect& viewRect, const std::vector<QRect>& oc
if (!m_side.has_value())
{
m_side = chooseSide(band, anchorRect, contentWidthPx + 2 * borderPx,
kMarginPx);
m_selectionGapPx);
}
// How much height there is depends on where the panel ends up standing: of the

View File

@@ -103,14 +103,16 @@ private:
SelectionContent* m_content = nullptr;
// Where the current selection was on the screen when it started, in the game world
// view's coordinates, and which side of it the panel took. Both are frozen for as
// long as the selection lasts: the anchor because the panel does not chase a
// scrolling view or a moving ship, the side because a card that grows must not flip
// the panel across the object (REQ-UI-SELECTION-PANEL). The side is resolved on the
// first placement after a new anchor, being the first point at which the panel's
// width is known. Dragging the panel supersedes the pair for the rest of the
// view's coordinates, the gap the panel keeps from it, and which side of it the panel
// took. All three are frozen for as long as the selection lasts: the anchor because
// the panel does not chase a scrolling view or a moving ship, the gap because it is
// measured against that frozen rectangle, the side because a card that grows must not
// flip the panel across the object (REQ-UI-SELECTION-PANEL). The side is resolved on
// the first placement after a new anchor, being the first point at which the panel's
// width is known. Dragging the panel supersedes all three for the rest of the
// selection (REQ-UI-SELECTION-PANEL-DRAG).
QRect m_anchorRect;
int m_selectionGapPx = 0;
std::optional<PanelSide> m_side;
// Where the player dragged the panel, in the game world view's coordinates, and the

View File

@@ -5,14 +5,16 @@
#include <functional>
#include "DisplayName.h"
#include "ModalLayer.h"
#include "NameInputDialog.h"
#include "OptionButton.h"
#include "ProductionRules.h"
#include "RecipeLineRow.h"
#include "SectionBox.h"
#include "TooltipTrigger.h"
#include <QGridLayout>
#include <QHBoxLayout>
#include <QInputDialog>
#include <QKeyEvent>
#include <QLabel>
#include <QMouseEvent>
@@ -336,14 +338,18 @@ public:
layout->addWidget(m_scrollArea, 1);
connect(createBtn, &QPushButton::clicked, this, [this]() {
bool ok = false;
const QString name = QInputDialog::getText(
this, tr("Create Blueprint"), tr("Blueprint name:"),
QLineEdit::Normal, QString(), &ok);
if (!ok || name.trimmed().isEmpty()) { return; }
// Opened on the same layer as the dialog this panel sits in, so it stacks
// over it on the one dim (REQ-MOD-UI-BLUEPRINT-CREATE, REQ-UI-MODAL-DIM).
ModalLayer* layer = ModalLayer::findFor(*this);
if (layer == nullptr) { return; }
NameInputDialog nameDialog(tr("Create Blueprint"), tr("Blueprint name:"));
if (layer->execute(nameDialog) != QDialog::Accepted) { return; }
const QString name = nameDialog.getName();
if (name.isEmpty()) { return; }
ShipLayoutBlueprint bp;
bp.name = name.trimmed();
bp.name = name;
bp.shipType = m_shipType;
bp.modules = m_getModules();
m_allBlueprints.push_back(std::move(bp));
@@ -412,17 +418,17 @@ private:
// ShipLayoutDialog implementation
// ---------------------------------------------------------------------------
ShipLayoutDialog::ShipLayoutDialog(const GameConfig* config,
const std::string& shipId,
ShipLayoutDialog::ShipLayoutDialog(const std::string& shipId,
const ShipLayoutConfig& currentLayout,
std::vector<ShipLayoutBlueprint>& allBlueprints,
std::set<std::string> unlockedModuleIds,
bool debugDraw,
ItemIconCache* itemIcons,
const ItemTooltipContext& context,
QWidget* parent)
: QDialog(parent)
, m_config(config)
, m_itemIcons(itemIcons)
: ModalDialog(parent)
, m_context(context)
, m_config(context.config)
, m_itemIcons(context.itemIcons)
, m_shipId(shipId)
, m_unlockedModuleIds(std::move(unlockedModuleIds))
, m_rows(0)
@@ -434,11 +440,8 @@ ShipLayoutDialog::ShipLayoutDialog(const GameConfig* config,
, m_statsPanel(nullptr)
, m_debugDraw(debugDraw)
{
setWindowTitle(tr("Configure Ship Layout"));
setModal(true);
// Find the ship's layout grid.
const ShipDef* shipDef = config->ships.findShipDef(shipId);
const ShipDef* shipDef = m_config->ships.findShipDef(shipId);
if (shipDef)
{
m_shipLayout = shipDef->layout;
@@ -472,6 +475,10 @@ ShipLayoutDialog::ShipLayoutDialog(const GameConfig* config,
// --- UI layout ---
QVBoxLayout* outerLayout = new QVBoxLayout(this);
// The dialog's own title line; it carries no close button, having Confirm and Cancel
// of its own at the bottom (REQ-UI-MODAL-CHROME, REQ-MOD-UI-DIALOG).
addHeader(outerLayout, tr("Configure Ship Layout"), false);
// Top: grid widget.
LayoutGridWidget* gridW = new LayoutGridWidget(this, this);
gridW->setGridData(&m_grid, m_rows, m_cols, &m_placedModules, m_config);
@@ -488,12 +495,15 @@ ShipLayoutDialog::ShipLayoutDialog(const GameConfig* config,
// neither of which costs anything -- and the balancing tool is deliberately built
// without the item icons this line draws with.
QVBoxLayout* leftLayout = new QVBoxLayout();
m_statsPanel = new ShipStatsPanel(config, this);
m_statsPanel = new ShipStatsPanel(m_config, this);
m_statsPanel->setDebugDrawEnabled(m_debugDraw);
leftLayout->addWidget(m_statsPanel);
m_buildCostSection = new SectionBox(tr("Build cost"), this);
m_buildCostLine = new RecipeLineRow(m_itemIcons, nullptr, m_buildCostSection);
// A section of the dialog rather than a control, so its materials explain themselves
// on hover or click, as they do in the panel (REQ-UI-ITEM-VALUE-TOOLTIP).
m_buildCostLine->setItemTooltips(m_context, TooltipTrigger::Trigger::HoverAndClick);
m_buildCostSection->getContentLayout()->addWidget(m_buildCostLine);
leftLayout->addWidget(m_buildCostSection);
leftLayout->addStretch(1);
@@ -510,9 +520,9 @@ ShipLayoutDialog::ShipLayoutDialog(const GameConfig* config,
int row = 0;
const int kCols = 2;
for (int i = 0; i < static_cast<int>(config->modules.modules.size()); ++i)
for (int i = 0; i < static_cast<int>(m_config->modules.modules.size()); ++i)
{
const ModuleDef& def = config->modules.modules[i];
const ModuleDef& def = m_config->modules.modules[i];
if (m_unlockedModuleIds.count(def.id) == 0)
{
m_moduleButtons.push_back(nullptr);
@@ -545,10 +555,15 @@ ShipLayoutDialog::ShipLayoutDialog(const GameConfig* config,
costLine->setLine(cost);
// The config tooltip stays: it says what the module does, which the cost line
// does not (REQ-MOD-UI-MODULE-TOOLTIP).
// does not (REQ-MOD-UI-MODULE-TOOLTIP). Hover only: the click selects the module
// (REQ-UI-TOOLTIP-TRIGGER). The materials on the face stay silent whether or not
// this module fills its description in -- the button is a described control, and
// one module's config gap must not make it read differently from the one beside
// it (REQ-UI-ITEM-VALUE-TOOLTIP).
if (def.tooltip)
{
btn->setToolTip(QString::fromStdString(*def.tooltip));
TooltipTrigger::attachText(*btn, QString::fromStdString(*def.tooltip),
TooltipTrigger::Trigger::HoverOnly);
}
buttonGrid->addWidget(btn, row, col);
m_moduleButtons.push_back(btn);
@@ -575,24 +590,8 @@ ShipLayoutDialog::ShipLayoutDialog(const GameConfig* config,
++row;
}
buttonGrid->addWidget(m_removeButton, row, 0, 1, kCols);
connect(m_removeButton, &QPushButton::clicked, this, [this]() {
if (m_removeMode)
{
m_removeMode = false;
m_removeButton->setChecked(false);
}
else
{
for (QPushButton* btn : m_moduleButtons)
{
if (btn) { btn->setChecked(false); }
}
m_activeModuleIndex = std::nullopt;
m_removeMode = true;
m_removeButton->setChecked(true);
}
updateGridWidget();
});
connect(m_removeButton, &QPushButton::clicked,
this, &ShipLayoutDialog::onRemoveButtonClicked);
centerLayout->addLayout(buttonGrid);
centerLayout->addStretch();
@@ -699,10 +698,25 @@ void ShipLayoutDialog::keyPressEvent(QKeyEvent* event)
}
else
{
QDialog::keyPressEvent(event);
// Q among them, which the base turns into requestDismiss().
ModalDialog::keyPressEvent(event);
}
}
bool ShipLayoutDialog::isDismissible() const
{
return true;
}
void ShipLayoutDialog::requestDismiss()
{
// Both mode exits go through the handler the buttons use, so a dismissal and a
// button can never leave different state behind (REQ-MOD-PLACEMENT, REQ-MOD-REMOVE).
if (m_activeModuleIndex.has_value()) { onModuleButtonClicked(*m_activeModuleIndex); }
else if (m_removeMode) { onRemoveButtonClicked(); }
else { onCancel(); }
}
void ShipLayoutDialog::onModuleButtonClicked(int index)
{
if (m_activeModuleIndex == index)
@@ -723,6 +737,26 @@ void ShipLayoutDialog::onModuleButtonClicked(int index)
updateGridWidget();
}
void ShipLayoutDialog::onRemoveButtonClicked()
{
if (m_removeMode)
{
m_removeMode = false;
m_removeButton->setChecked(false);
}
else
{
for (QPushButton* btn : m_moduleButtons)
{
if (btn) { btn->setChecked(false); }
}
m_activeModuleIndex = std::nullopt;
m_removeMode = true;
m_removeButton->setChecked(true);
}
updateGridWidget();
}
void ShipLayoutDialog::onConfirm()
{
ShipLayoutConfig layout;

View File

@@ -6,10 +6,11 @@
#include <string>
#include <vector>
#include <QDialog>
#include <QPoint>
#include "GameConfig.h"
#include "ItemTooltipContext.h"
#include "ModalDialog.h"
#include "Rotation.h"
#include "ShipLayout.h"
#include "ShipLayoutBlueprint.h"
@@ -20,24 +21,34 @@ class RecipeLineRow;
class SectionBox;
class ShipStatsPanel;
class ShipLayoutDialog : public QDialog
class ShipLayoutDialog : public ModalDialog
{
Q_OBJECT
public:
// itemIcons draws what each module costs and what the layout costs in total
// (REQ-MOD-UI-DIALOG, REQ-MOD-UI-STATS-PANEL). Not owned.
ShipLayoutDialog(const GameConfig* config,
const std::string& shipId,
// The context's item cache draws what each module costs and what the layout costs in
// total (REQ-MOD-UI-DIALOG, REQ-MOD-UI-STATS-PANEL), and the rest of it lets the
// build cost explain the items it names (REQ-UI-ITEM-VALUE-TOOLTIP). Nothing in it is
// owned.
ShipLayoutDialog(const std::string& shipId,
const ShipLayoutConfig& currentLayout,
std::vector<ShipLayoutBlueprint>& allBlueprints,
std::set<std::string> unlockedModuleIds,
bool debugDraw,
ItemIconCache* itemIcons,
const ItemTooltipContext& context,
QWidget* parent = nullptr);
std::optional<ShipLayoutConfig> getResult() const;
bool isDismissible() const override;
public slots:
// Backs out one level per dismissal, as Q does in the game world: the module being
// placed, then remove mode, then the dialog itself, which discards the session
// (REQ-UI-DIALOG-DISMISS). So a single press or click never both leaves a mode and
// throws the session away.
void requestDismiss() override;
protected:
void keyPressEvent(QKeyEvent* event) override;
@@ -46,6 +57,10 @@ signals:
private slots:
void onModuleButtonClicked(int index);
// Enters remove mode, or leaves it when it is already active (REQ-MOD-REMOVE).
// Reached by the Remove button and by a dismissal, which leaves the mode on its way
// out of the dialog (REQ-UI-DIALOG-DISMISS).
void onRemoveButtonClicked();
void onConfirm();
void onCancel();
@@ -65,6 +80,7 @@ private:
std::vector<std::string> rotatedMask(const ModuleDef& def, Rotation rotation) const;
void loadLayoutBlueprint(const std::vector<PlacedModule>& modules);
ItemTooltipContext m_context;
const GameConfig* m_config;
ItemIconCache* m_itemIcons;
std::string m_shipId;

176
src/ui/Tooltip.cpp Normal file
View File

@@ -0,0 +1,176 @@
#include "Tooltip.h"
#include <QFontMetrics>
#include <QGuiApplication>
#include <QLabel>
#include <QLayoutItem>
#include <QPalette>
#include <QRect>
#include <QScreen>
#include <QVBoxLayout>
namespace
{
// Widest a text tooltip gets before it wraps, in device-independent pixels. A config
// description runs to a sentence or two and would otherwise be laid out as one line
// across the whole window.
const int kMaxTextWidthPx = 360;
// Height the wrap is measured against: high enough that it never cuts the text short.
const int kMeasureHeightPx = 10000;
// The screen the given position is on, falling back to the primary screen when it is on
// none of them (a position between two screens of different heights).
QRect availableScreenRect(const QPoint& globalPos)
{
const QScreen* screen = QGuiApplication::screenAt(globalPos);
if (screen == nullptr)
{
screen = QGuiApplication::primaryScreen();
}
return (screen != nullptr) ? screen->availableGeometry() : QRect();
}
} // namespace
Tooltip* Tooltip::s_visibleTooltip = nullptr;
Tooltip* Tooltip::getVisibleTooltip()
{
return s_visibleTooltip;
}
void Tooltip::hideVisibleTooltip()
{
if (s_visibleTooltip != nullptr)
{
s_visibleTooltip->hide();
}
}
Tooltip::Tooltip(QWidget* parent)
: QFrame(parent, Qt::ToolTip)
{
// The palette's tooltip colors behind a themed border, so it reads as a tooltip
// rather than as a stray window.
setFrameShape(QFrame::StyledPanel);
setAutoFillBackground(true);
QPalette tooltipPalette = palette();
tooltipPalette.setColor(QPalette::Window,
tooltipPalette.color(QPalette::ToolTipBase));
tooltipPalette.setColor(QPalette::WindowText,
tooltipPalette.color(QPalette::ToolTipText));
setPalette(tooltipPalette);
m_layout = new QVBoxLayout(this);
m_layout->setContentsMargins(6, 4, 6, 4);
m_layout->setSpacing(2);
}
Tooltip::~Tooltip()
{
// Destroyed while on screen -- a chip whose panel is rebuilt takes its tooltip with
// it (REQ-UI-SINGLE-SELECTION).
if (s_visibleTooltip == this)
{
s_visibleTooltip = nullptr;
}
}
void Tooltip::setText(const QString& text)
{
clearContent();
QLabel* label = new QLabel(text, this);
// Plain text throughout: config strings are read as they are written, never as
// markup Qt happens to recognize.
label->setTextFormat(Qt::PlainText);
label->setWordWrap(true);
// The width the text needs, capped at the wrap measure. Measured rather than left to
// the layout, so the label is laid out at exactly the width its wrapping assumed and
// the tooltip ends up as tall as the wrapped text really is.
const QFontMetrics metrics(label->font());
const QRect wrapped = metrics.boundingRect(
QRect(0, 0, kMaxTextWidthPx, kMeasureHeightPx), Qt::TextWordWrap, text);
label->setFixedWidth(qMin(kMaxTextWidthPx, wrapped.width()));
// The height that wrapping really needs, so a label whose own hint was computed for
// the unwrapped text cannot leave the last lines clipped.
label->setMinimumHeight(wrapped.height());
m_layout->addWidget(label);
}
void Tooltip::showAt(const QPoint& globalPos)
{
// Only ever one tooltip on screen (REQ-UI-TOOLTIP-TRIGGER).
if (s_visibleTooltip != nullptr && s_visibleTooltip != this)
{
s_visibleTooltip->hide();
}
refreshContent();
adjustSize();
// The top-left corner goes on the pointer, so the pointer starts on the tooltip and
// reaches it without crossing a gap (REQ-UI-TOOLTIP-DISMISS). Kept on the screen the
// pointer is on: a tooltip near the right or bottom edge would otherwise be cut off.
// Clamping keeps the pointer inside the tooltip, since it only ever moves the
// tooltip back over the pointer.
const QRect screen = availableScreenRect(globalPos);
QPoint topLeft = globalPos;
if (screen.isValid())
{
topLeft.setX(qMax(screen.left(),
qMin(topLeft.x(), screen.right() - width() + 1)));
topLeft.setY(qMax(screen.top(),
qMin(topLeft.y(), screen.bottom() - height() + 1)));
}
move(topLeft);
show();
raise();
s_visibleTooltip = this;
}
bool Tooltip::getContainsGlobalPos(const QPoint& globalPos) const
{
return isVisible() && frameGeometry().contains(globalPos);
}
void Tooltip::refreshContent()
{
}
QVBoxLayout* Tooltip::getContentLayout()
{
return m_layout;
}
void Tooltip::clearContent()
{
while (QLayoutItem* item = m_layout->takeAt(0))
{
if (item->widget() != nullptr)
{
// Out of the widget tree at once and destroyed later: a child merely taken
// out of the layout would keep its geometry and show through the content
// that replaces it.
item->widget()->setParent(nullptr);
item->widget()->deleteLater();
}
delete item;
}
}
void Tooltip::hideEvent(QHideEvent* event)
{
if (s_visibleTooltip == this)
{
s_visibleTooltip = nullptr;
}
QFrame::hideEvent(event);
}

51
src/ui/Tooltip.h Normal file
View File

@@ -0,0 +1,51 @@
#pragma once
#include <QFrame>
#include <QPoint>
#include <QString>
class QHideEvent;
class QVBoxLayout;
// The popup every tooltip in the UI is drawn in (REQ-UI-TOOLTIP-TRIGGER,
// REQ-UI-TOOLTIP-DISMISS). Shown and hidden by a TooltipTrigger attached to the element
// it describes; it carries no trigger logic of its own.
//
// A window of its own rather than Qt's own tooltip, because ours must not time out, must
// stay up while the pointer is on it, and -- for the item production tooltip
// (REQ-UI-ITEM-TOOLTIP) -- must hold drawn content rather than text. A Qt::ToolTip window
// so it floats above the game window instead of being clipped by it.
class Tooltip : public QFrame
{
Q_OBJECT
public:
// The tooltip currently on screen, if any: only ever one, since the pointer can only
// be on one element.
static Tooltip* getVisibleTooltip();
static void hideVisibleTooltip();
explicit Tooltip(QWidget* parent = nullptr);
~Tooltip() override;
// Plain text content, wrapped at a readable measure. Newlines are kept.
void setText(const QString& text);
// Refreshes the content and shows the tooltip with its top-left corner on the given
// screen position, kept inside the screen (REQ-UI-TOOLTIP-DISMISS).
void showAt(const QPoint& globalPos);
bool getContainsGlobalPos(const QPoint& globalPos) const;
protected:
// Called before every show, for content that goes stale between them. The base
// tooltip's text does not, so this does nothing here.
virtual void refreshContent();
QVBoxLayout* getContentLayout();
void clearContent();
void hideEvent(QHideEvent* event) override;
private:
static Tooltip* s_visibleTooltip;
QVBoxLayout* m_layout;
};

196
src/ui/TooltipTrigger.cpp Normal file
View File

@@ -0,0 +1,196 @@
#include "TooltipTrigger.h"
#include <QApplication>
#include <QCursor>
#include <QEvent>
#include <QMouseEvent>
#include <QTimer>
#include <QWidget>
#include "Tooltip.h"
namespace
{
// How long the pointer rests on an element before its tooltip appears, in milliseconds.
// One delay for every tooltip in the UI, now that none of them is Qt's (REQ-UI-TOOLTIP-TRIGGER).
const int kHoverDelayMs = 500;
// How often a visible tooltip is carried after its element and tested against the
// pointer, in milliseconds. A frame's worth: the element it follows can move with the
// scrolling world (REQ-UI-EXPAND-BUTTON), and anything slower would visibly drag behind
// it. It runs only while a tooltip is up.
const int kTrackingIntervalMs = 16;
} // namespace
void TooltipTrigger::attachText(QWidget& target, const QString& text, Trigger trigger)
{
Tooltip* tooltip = new Tooltip(&target);
tooltip->setText(text);
attach(target, *tooltip, trigger);
}
void TooltipTrigger::attach(QWidget& target, Tooltip& tooltip, Trigger trigger)
{
// Parented to the element, so both die with it.
new TooltipTrigger(target, tooltip, trigger);
}
bool TooltipTrigger::eventFilter(QObject* watched, QEvent* event)
{
if (watched != m_target)
{
return QObject::eventFilter(watched, event);
}
switch (event->type())
{
case QEvent::Enter:
{
m_hoverTimer->start();
break;
}
case QEvent::Leave:
{
m_hoverTimer->stop();
// Not a dismissal in itself: the pointer may be on its way onto the tooltip
// (REQ-UI-TOOLTIP-DISMISS).
hideUnlessPointerHeld();
break;
}
case QEvent::MouseButtonPress:
{
const QMouseEvent* mouseEvent = static_cast<QMouseEvent*>(event);
if (m_trigger != Trigger::HoverAndClick
|| mouseEvent->button() != Qt::LeftButton)
{
break;
}
m_hoverTimer->stop();
// A click on an element whose tooltip is already up leaves it where it is
// (REQ-UI-TOOLTIP-TRIGGER).
if (!m_tooltip->isVisible())
{
showTooltip();
}
// Swallowed: the element does nothing with a click, and the panel beneath it
// must not take it for one of its own (REQ-UI-SELECTION-PANEL-DRAG).
return true;
}
case QEvent::Hide:
{
m_hoverTimer->stop();
hideTooltip();
break;
}
default:
{
break;
}
}
return QObject::eventFilter(watched, event);
}
TooltipTrigger::TooltipTrigger(QWidget& target, Tooltip& tooltip, Trigger trigger)
: QObject(&target)
, m_target(&target)
, m_tooltip(&tooltip)
, m_trigger(trigger)
{
m_hoverTimer = new QTimer(this);
m_hoverTimer->setSingleShot(true);
m_hoverTimer->setInterval(kHoverDelayMs);
connect(m_hoverTimer, &QTimer::timeout, this, &TooltipTrigger::showTooltip);
m_trackingTimer = new QTimer(this);
m_trackingTimer->setInterval(kTrackingIntervalMs);
connect(m_trackingTimer, &QTimer::timeout, this, [this]() {
// Carried along first, so that a tooltip that has just been pulled out from under
// the pointer is found to be out from under it on this same tick.
followTarget();
hideUnlessPointerHeld();
});
m_target->installEventFilter(this);
}
QRect TooltipTrigger::getTargetGlobalRect() const
{
return QRect(m_target->mapToGlobal(QPoint(0, 0)), m_target->size());
}
void TooltipTrigger::showTooltip()
{
// Already up: left where it is rather than moved to wherever the pointer has got to,
// which is what a pointer wandering from the tooltip back onto the element would
// otherwise do (REQ-UI-TOOLTIP-TRIGGER).
if (!m_target->isVisible() || m_tooltip->isVisible())
{
return;
}
m_tooltip->showAt(QCursor::pos());
m_targetGlobalRect = getTargetGlobalRect();
m_trackingTimer->start();
}
void TooltipTrigger::hideTooltip()
{
m_trackingTimer->stop();
m_tooltip->hide();
}
void TooltipTrigger::followTarget()
{
const QRect targetRect = getTargetGlobalRect();
const QPoint travelled = targetRect.topLeft() - m_targetGlobalRect.topLeft();
m_targetGlobalRect = targetRect;
if (travelled.isNull())
{
return;
}
// The tooltip holds the place it was given in relation to its element rather than the
// place it was given on the screen, so an element that travels -- the expansion button
// riding the scrolling world (REQ-UI-EXPAND-BUTTON) -- takes its tooltip with it
// instead of leaving it stranded beside where it used to be. Not clamped back onto
// the screen this time: following the element off the edge is the point, and the
// pointer left behind is what then hides it (REQ-UI-TOOLTIP-DISMISS).
m_tooltip->move(m_tooltip->pos() + travelled);
}
void TooltipTrigger::hideUnlessPointerHeld()
{
if (!m_tooltip->isVisible())
{
m_trackingTimer->stop();
return;
}
// Gone with the element it explains. An element that merely moves is not a dismissal:
// the tooltip travels with it (followTarget), and nothing but the pointer dismisses
// one (REQ-UI-TOOLTIP-DISMISS).
if (!m_target->isVisible())
{
hideTooltip();
return;
}
// Gone with the game window: a tooltip is a topmost window and would otherwise stay
// over whatever the player switched to.
if (QApplication::activeWindow() == nullptr)
{
hideTooltip();
return;
}
const QPoint pointer = QCursor::pos();
if (!getTargetGlobalRect().contains(pointer)
&& !m_tooltip->getContainsGlobalPos(pointer))
{
hideTooltip();
}
}

69
src/ui/TooltipTrigger.h Normal file
View File

@@ -0,0 +1,69 @@
#pragma once
#include <QObject>
#include <QRect>
#include <QString>
class QEvent;
class QTimer;
class QWidget;
class Tooltip;
// Shows and hides one element's tooltip (REQ-UI-TOOLTIP-TRIGGER, REQ-UI-TOOLTIP-DISMISS).
// Attached to the element as an event filter, so a plain QLabel or QPushButton needs no
// subclass of its own to carry a tooltip.
//
// It replaces QWidget::setToolTip throughout the UI: Qt's own tooltip times out, hides on
// the first mouse move, cannot be hovered, and cannot be brought up by a click.
class TooltipTrigger : public QObject
{
Q_OBJECT
public:
// What brings the tooltip up. An element whose click already does something keeps to
// HoverOnly, so one gesture never both acts and explains (REQ-UI-TOOLTIP-TRIGGER).
enum class Trigger
{
HoverOnly,
HoverAndClick
};
// Attaches a text tooltip, created and owned along with the trigger by the target.
static void attachText(QWidget& target, const QString& text, Trigger trigger);
// Attaches a tooltip built by the caller -- the item production tooltip, whose
// content is drawn rather than written (REQ-UI-ITEM-TOOLTIP).
static void attach(QWidget& target, Tooltip& tooltip, Trigger trigger);
protected:
bool eventFilter(QObject* watched, QEvent* event) override;
private:
TooltipTrigger(QWidget& target, Tooltip& tooltip, Trigger trigger);
QRect getTargetGlobalRect() const;
void showTooltip();
void hideTooltip();
// Keeps the tooltip where it was put in relation to its element, so an element that
// moves takes its tooltip along (REQ-UI-TOOLTIP-DISMISS).
void followTarget();
// Hides the tooltip once the pointer is on neither the element nor the tooltip
// itself, which is the only thing that dismisses it (REQ-UI-TOOLTIP-DISMISS).
void hideUnlessPointerHeld();
QWidget* m_target;
Tooltip* m_tooltip;
Trigger m_trigger;
// Held back so a pointer crossing the element on its way elsewhere does not flash the
// tooltip. A click skips it (REQ-UI-TOOLTIP-TRIGGER).
QTimer* m_hoverTimer;
// Runs only while the tooltip is up: it carries the tooltip along with an element
// that moves and tests where the pointer is. Polled rather than read off events:
// enter and leave arrive in an order that depends on which of the two widgets the
// pointer crosses first and a popup window is not a reliable source of them, and a
// move event reaches only the widget whose own position changed -- never a label
// carried along by the button around it, which is the case that matters here.
QTimer* m_trackingTimer;
// Where the element was when the tooltip was last placed, so the next tick can tell
// how far it has travelled since. Only meaningful while the tooltip is up.
QRect m_targetGlobalRect;
};

View File

@@ -45,11 +45,14 @@ struct OverlayVisuals
QColor ghostValid;
QColor ghostInvalid;
QColor deconstructTint;
QColor selectionRect;
QColor tileHighlight;
QColor selectedOutline;
QColor configTransfer; // blueprint ghost over a transfer target (REQ-UI-BLUEPRINT-TRANSFER)
QColor lockedAsteroid;
// Tint over the columns the next expansion unlocks, lighter than lockedAsteroid so
// the ground one purchase away reads apart from the ground behind it
// (REQ-UI-LOCKED-ASTEROID).
QColor nextExpansion;
QColor modalDim;
QColor tunnelPreview; // tunnel connection preview highlight (REQ-BLD-TUNNEL-MODE)
};

View File

@@ -221,11 +221,11 @@ VisualsConfig VisualsLoader::load(const std::string& path)
cfg.overlays.ghostValid = parseColor(requireString(ov, "ghost_valid", "overlays"), "overlays.ghost_valid");
cfg.overlays.ghostInvalid = parseColor(requireString(ov, "ghost_invalid", "overlays"), "overlays.ghost_invalid");
cfg.overlays.deconstructTint = parseColor(requireString(ov, "deconstruct_tint", "overlays"), "overlays.deconstruct_tint");
cfg.overlays.selectionRect = parseColor(requireString(ov, "selection_rect", "overlays"), "overlays.selection_rect");
cfg.overlays.tileHighlight = parseColor(requireString(ov, "tile_highlight", "overlays"), "overlays.tile_highlight");
cfg.overlays.selectedOutline = parseColor(requireString(ov, "selected_outline", "overlays"), "overlays.selected_outline");
cfg.overlays.configTransfer = parseColor(requireString(ov, "config_transfer", "overlays"), "overlays.config_transfer");
cfg.overlays.lockedAsteroid = parseColor(requireString(ov, "locked_asteroid", "overlays"), "overlays.locked_asteroid");
cfg.overlays.nextExpansion = parseColor(requireString(ov, "next_expansion", "overlays"), "overlays.next_expansion");
cfg.overlays.modalDim = parseColor(requireString(ov, "modal_dim", "overlays"), "overlays.modal_dim");
cfg.overlays.tunnelPreview = parseColor(requireString(ov, "tunnel_preview", "overlays"), "overlays.tunnel_preview");
}

View File

@@ -203,9 +203,14 @@ void WorldRenderer::drawTiles(QPainter& painter, const WorldCoordinates& coordin
+ static_cast<int>(std::ceil(coordinates.getViewportWidthTiles())) + 2;
const int bottomTile = m_sim.getConfig().world.heightTiles;
// Asteroid columns left of the buildable edge are not yet unlocked by
// expansion; tint them so the player sees the reachable-but-locked area.
// Asteroid columns left of the buildable edge are not yet unlocked by expansion;
// tint them so the player sees the reachable-but-locked area. The columns one
// purchase away take a lighter tint than the ground behind them, so the boundary
// between the two says how far the next expansion reaches, and the expansion button
// stands in the middle of them (REQ-UI-LOCKED-ASTEROID, REQ-UI-EXPAND-BUTTON).
const int buildableLeftX = -m_sim.getCurrentAsteroidWidth_tiles();
const int nextExpansionLeftX =
buildableLeftX - m_sim.getConfig().world.expansion.columnsPerExpansion_tiles;
painter.setPen(Qt::NoPen);
for (int x = leftTile; x <= rightTile; ++x)
@@ -214,13 +219,16 @@ void WorldRenderer::drawTiles(QPainter& painter, const WorldCoordinates& coordin
? m_visuals.asteroid.fill
: m_visuals.space.fill;
const bool locked = (x < buildableLeftX);
const QColor& tint = (x >= nextExpansionLeftX)
? m_visuals.overlays.nextExpansion
: m_visuals.overlays.lockedAsteroid;
for (int y = 0; y < bottomTile; ++y)
{
const QRectF rect = coordinates.tileRect(QPoint(x, y));
painter.fillRect(rect, fill);
if (locked)
{
painter.fillRect(rect, m_visuals.overlays.lockedAsteroid);
painter.fillRect(rect, tint);
}
}
}
@@ -897,13 +905,16 @@ void WorldRenderer::drawOverlays(QPainter& painter, const WorldCoordinates& coor
/*showPortTargetGlyphs*/ true);
}
}
else
// A cursor that points at no tile — resting on a floating panel, or outside
// the window — hovers nothing, and builder mode then shows no ghost at all
// (REQ-BLD-GHOST).
else if (frame.buildMode.getGhostTile().has_value())
{
// In tunnel mode the ghost shows the position-resolved type (entry or
// exit) and, when it would complete an existing tunnel, the matched end
// and the tiles between it and the ghost are tinted green
// (REQ-BLD-TUNNEL-MODE).
const QPoint ghostTile = frame.buildMode.getGhostTile();
const QPoint ghostTile = *frame.buildMode.getGhostTile();
const std::optional<QPoint>& partnerTile = frame.buildMode.getTunnelPartnerTile();
if (frame.buildMode.isTunnelMode() && frame.buildMode.isGhostValid()
&& partnerTile.has_value())
@@ -931,14 +942,16 @@ void WorldRenderer::drawOverlays(QPainter& painter, const WorldCoordinates& coor
}
}
// Blueprint placement ghost
if (frame.buildMode.isBlueprintMode())
// Blueprint placement ghost, drawn only while the cursor points at a tile, as for
// the builder ghost above (REQ-BLD-GHOST).
if (frame.buildMode.isBlueprintMode()
&& frame.buildMode.getBlueprintGhostTile().has_value())
{
// A single-building blueprint hit-tests the cursor for its transfer target; a
// constellation does not (REQ-UI-BLUEPRINT-TRANSFER). The stored building count,
// not the count after locked types are dropped, so the rule does not shift as the
// player unlocks things.
const QPoint cursorTile = frame.buildMode.getBlueprintGhostTile();
const QPoint cursorTile = *frame.buildMode.getBlueprintGhostTile();
const std::optional<QPoint> hoverTile =
frame.buildMode.getBlueprint().buildings.size() == 1
? std::make_optional(cursorTile) : std::nullopt;
@@ -984,9 +997,9 @@ void WorldRenderer::drawOverlays(QPainter& painter, const WorldCoordinates& coor
// Deconstruct tint: while dragging a deconstruct box, tint every covered
// building/site (REQ-BLD-DECONSTRUCT-BOX); otherwise tint the hovered one.
if (frame.buildMode.isDeconstructMode() && frame.isBoxSelecting)
if (frame.buildMode.isDeconstructMode() && frame.boxWorldRect.has_value())
{
for (BuildingId id : buildingsInBox(m_sim.getFactoryState(), frame.boxStartTile, frame.boxCurrentTile))
for (BuildingId id : buildingsInBox(m_sim.getFactoryState(), *frame.boxWorldRect))
{
const Building* b = findBuilding(m_sim.getFactoryState(), id);
if (b && b->type == BuildingType::Hq) { continue; }
@@ -1019,16 +1032,25 @@ void WorldRenderer::drawOverlays(QPainter& painter, const WorldCoordinates& coor
}
}
// Box-select rectangle
if (frame.isBoxSelecting)
// Box-select rectangle, drawn from the world rectangle itself and unsnapped, so
// the outline sits where the mouse went rather than on the tile grid
// (REQ-UI-MULTI-SELECT).
if (frame.boxWorldRect.has_value())
{
const QPoint tl(std::min(frame.boxStartTile.x(), frame.boxCurrentTile.x()),
std::min(frame.boxStartTile.y(), frame.boxCurrentTile.y()));
const QPoint br(std::max(frame.boxStartTile.x(), frame.boxCurrentTile.x()) + 1,
std::max(frame.boxStartTile.y(), frame.boxCurrentTile.y()) + 1);
const QRectF selRect(coordinates.tileToWidget(tl),
coordinates.tileToWidget(br));
painter.setPen(QPen(m_visuals.overlays.selectionRect, 1));
const QRectF selRect(
coordinates.worldToWidget(QVector2D(frame.boxWorldRect->topLeft())),
coordinates.worldToWidget(QVector2D(frame.boxWorldRect->bottomRight())));
// In deconstruct mode the box marks buildings for demolition, so it is
// drawn in the deconstruct red instead of the selection color; the
// tint's alpha governs only the fills it tints, never this outline
// (REQ-UI-MULTI-SELECT, REQ-BLD-DECONSTRUCT-BOX).
QColor rectColor = m_visuals.overlays.selectedOutline;
if (frame.buildMode.isDeconstructMode())
{
rectColor = m_visuals.overlays.deconstructTint;
rectColor.setAlpha(255);
}
painter.setPen(QPen(rectColor, 1));
painter.setBrush(Qt::NoBrush);
painter.drawRect(selRect);
}

View File

@@ -54,9 +54,11 @@ struct WorldRenderFrame
const SelectionController& selection;
const BuildModeController& buildMode;
const std::vector<ActiveBeam>& beams;
bool isBoxSelecting;
QPoint boxStartTile;
QPoint boxCurrentTile;
// The box being dragged, in world coordinates and normalized, or nullopt when no
// drag is in progress — a press that has not passed the movement threshold is
// still a click and offers none (REQ-UI-MULTI-SELECT). It is the same rectangle
// the view selects by, so what is drawn and what is selected cannot disagree.
std::optional<QRectF> boxWorldRect;
bool isDebugDrawEnabled;
};

View File

@@ -67,6 +67,11 @@ BufferedBuildingContent::BufferedBuildingContent(const SelectionContext& context
// The summary is configuration -- what the building will do -- so it sits with the
// selection control and is shown for a construction site too (REQ-UI-RECIPE-SUMMARY).
m_recipeSummary = new RecipeLineRow(context.itemIcons, context.buildingIcons, this);
// Its icons name items, and nothing in the panel is clicked, so each explains itself
// on hover or click -- which is how the player follows an input back to what makes it
// without that item being in a buffer (REQ-UI-ITEM-VALUE-TOOLTIP).
m_recipeSummary->setItemTooltips(context.getItemTooltipContext(),
TooltipTrigger::Trigger::HoverAndClick);
getConfigurationLayout()->addWidget(m_recipeSummary);
m_inputSection = new SectionBox(tr("Input buffers"), this);
@@ -103,7 +108,7 @@ void BufferedBuildingContent::refreshConfiguration()
const CycleInfo cycle = getCycleInfo(target);
RecipeLineRow::Spec summary;
summary.inputs = toAmounts(cycle.perCycleInputs);
summary.outputs = toAmounts(cycle.perCycleOutputs);
summary.outputGroups = cycle.perCycleOutputGroups;
summary.durationSeconds = cycle.durationSeconds;
m_recipeSummary->setLine(summary);
@@ -192,9 +197,20 @@ std::vector<ItemChipRow::Entry> BufferedBuildingContent::buildOutputEntries(
}
}
// A chip stands for a buffer, and a buffer exists for every item any group can
// produce (REQ-MAT-OUTPUT-BUFFER), so the groups are flattened here.
std::map<std::string, int> producible;
for (const std::vector<RecipeLineRow::Amount>& group : cycle.perCycleOutputGroups)
{
for (const RecipeLineRow::Amount& amount : group)
{
producible[amount.itemId] = std::max(producible[amount.itemId], amount.amount);
}
}
std::vector<ItemChipRow::Entry> entries;
for (const std::string& itemId :
collectItemIds(buffered, cycle.perCycleOutputs, cycle.handledOutputs))
collectItemIds(buffered, producible, cycle.handledOutputs))
{
if (!getContext().sim->isItemUnlocked(itemId)) { continue; }

View File

@@ -6,6 +6,7 @@
#include "BuildingId.h"
#include "ItemChipRow.h"
#include "RecipeLineRow.h"
#include "SelectionContent.h"
struct Building;
@@ -31,7 +32,11 @@ protected:
struct CycleInfo
{
std::map<std::string, int> perCycleInputs;
std::map<std::string, int> perCycleOutputs;
// What one cycle produces, one entry per output group (REQ-MAT-OUTPUT-GROUP), so
// the summary can state alternatives as such. The output chips are listed from
// this too, flattened: a chip stands for a buffer, and a buffer exists for every
// item any group can produce.
std::vector<std::vector<RecipeLineRow::Amount>> perCycleOutputGroups;
// 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

View File

@@ -14,7 +14,6 @@ SET(HDRS
${CMAKE_CURRENT_SOURCE_DIR}/EmptyNote.h
${CMAKE_CURRENT_SOURCE_DIR}/ItemChip.h
${CMAKE_CURRENT_SOURCE_DIR}/ItemChipRow.h
${CMAKE_CURRENT_SOURCE_DIR}/ItemTooltip.h
${CMAKE_CURRENT_SOURCE_DIR}/ProductionSection.h
${CMAKE_CURRENT_SOURCE_DIR}/RecipeSelectionControl.h
${CMAKE_CURRENT_SOURCE_DIR}/ClearBeltControl.h
@@ -48,7 +47,6 @@ SET(SRCS
${CMAKE_CURRENT_SOURCE_DIR}/EmptyNote.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ItemChip.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ItemChipRow.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ItemTooltip.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ProductionSection.cpp
${CMAKE_CURRENT_SOURCE_DIR}/RecipeSelectionControl.cpp
${CMAKE_CURRENT_SOURCE_DIR}/ClearBeltControl.cpp

View File

@@ -5,6 +5,7 @@
#include "DebrisScrap.h"
#include "IconCaption.h"
#include "ItemIconCache.h"
#include "ItemTooltip.h"
#include "Simulation.h"
#include "StatRow.h"
@@ -23,6 +24,11 @@ DebrisContent::DebrisContent(const SelectionContext& context,
m_scrapIcon.isNull() ? tr("Scrap remaining") : tr("Remaining"), this);
m_scrapRow->setValueIcon(m_scrapIcon);
m_scrapRow->setValueEmphasized(true);
// Scrap is an item like any other, so the value explains it -- for scrap, that it is
// salvaged rather than made (REQ-UI-ITEM-VALUE-TOOLTIP, REQ-UI-ITEM-TOOLTIP).
ItemTooltip::attachTo(m_scrapRow->getValueWidget(),
context.getItemTooltipContext(), kScrapItemId,
TooltipTrigger::Trigger::HoverAndClick);
getRuntimeLayout()->addWidget(m_scrapRow);
setIdentity(QPixmap(), tr("Debris"));

View File

@@ -12,6 +12,7 @@
#include "FactionComponent.h"
#include "IconCaption.h"
#include "ItemIconCache.h"
#include "ItemTooltip.h"
#include "ShipIdentityComponent.h"
#include "Simulation.h"
#include "StatRow.h"
@@ -94,6 +95,11 @@ void FieldMultiContent::buildSummary(const std::vector<entt::entity>& actors)
m_scrapRow->setValueIcon(m_scrapIcon);
m_scrapRow->setIndented(true);
m_scrapRow->setValueEmphasized(true);
// The same value as the debris card's, so it explains its item the same way
// (REQ-UI-ITEM-VALUE-TOOLTIP).
ItemTooltip::attachTo(m_scrapRow->getValueWidget(),
getContext().getItemTooltipContext(), kScrapItemId,
TooltipTrigger::Trigger::HoverAndClick);
getRuntimeLayout()->addWidget(m_scrapRow);
}
}

View File

@@ -1,14 +1,13 @@
#include "ItemChip.h"
#include <QCursor>
#include <QFont>
#include <QHBoxLayout>
#include <QLabel>
#include <QPalette>
#include <QTimer>
#include <QVBoxLayout>
#include "ItemTooltip.h"
#include "TooltipTrigger.h"
namespace
{
@@ -17,18 +16,12 @@ namespace
const int kCountSizeRisePt = 2;
const int kSubLineSizeDropPt = 1;
// How long the cursor rests on a chip before its tooltip appears, in milliseconds.
// Matches the feel of an ordinary tooltip, which this one replaces (REQ-UI-ITEM-TOOLTIP).
const int kHoverDelayMs = 500;
} // namespace
ItemChip::ItemChip(const SelectionContext& context, const std::string& itemId,
const QPixmap& icon, QWidget* parent)
: QWidget(parent)
, m_context(context)
, m_itemId(itemId)
{
// Its own boxed chrome, drawn with palette colors like the rest of the panel's
// furniture rather than from visuals.toml, which is for world rendering.
@@ -70,10 +63,18 @@ ItemChip::ItemChip(const SelectionContext& context, const std::string& itemId,
layout->addWidget(m_iconLabel);
layout->addWidget(text);
m_hoverTimer = new QTimer(this);
m_hoverTimer->setSingleShot(true);
m_hoverTimer->setInterval(kHoverDelayMs);
connect(m_hoverTimer, &QTimer::timeout, this, &ItemChip::showTooltip);
// Every child is transparent to the mouse, so the chip is what the pointer is on
// wherever it rests on the face -- a child under it would take the chip's own enter,
// leave and press events (REQ-UI-TOOLTIP-TRIGGER).
m_iconLabel->setAttribute(Qt::WA_TransparentForMouseEvents, true);
m_countLabel->setAttribute(Qt::WA_TransparentForMouseEvents, true);
m_subLineLabel->setAttribute(Qt::WA_TransparentForMouseEvents, true);
text->setAttribute(Qt::WA_TransparentForMouseEvents, true);
// A chip displays a quantity and does nothing when clicked, so a click brings its
// tooltip up at once rather than waiting the hover out (REQ-UI-TOOLTIP-TRIGGER).
ItemTooltip::attachTo(*this, context.getItemTooltipContext(), itemId,
TooltipTrigger::Trigger::HoverAndClick);
}
void ItemChip::setCount(const QString& count)
@@ -86,28 +87,3 @@ void ItemChip::setSubLine(const QString& subLine)
m_subLineLabel->setText(subLine);
m_subLineLabel->setVisible(!subLine.isEmpty());
}
void ItemChip::enterEvent(QEvent* event)
{
m_hoverTimer->start();
QWidget::enterEvent(event);
}
void ItemChip::leaveEvent(QEvent* event)
{
m_hoverTimer->stop();
if (m_tooltip != nullptr)
{
m_tooltip->hide();
}
QWidget::leaveEvent(event);
}
void ItemChip::showTooltip()
{
if (m_tooltip == nullptr)
{
m_tooltip = new ItemTooltip(m_context, m_itemId, this);
}
m_tooltip->showAt(QCursor::pos());
}

View File

@@ -8,16 +8,13 @@
#include "SelectionContext.h"
class ItemTooltip;
class QEvent;
class QLabel;
class QTimer;
// One buffered item: its icon, its count in a larger type, and a sub-line beneath the
// count (REQ-UI-SINGLE-SELECTION). Boxed so a row of them reads as separate quantities
// rather than as a run of text.
//
// Hovering it explains where its item comes from (REQ-UI-ITEM-TOOLTIP).
// Hovering or clicking it explains where its item comes from (REQ-UI-ITEM-TOOLTIP).
class ItemChip : public QWidget
{
Q_OBJECT
@@ -31,21 +28,8 @@ public:
// Left empty for an item with nothing to say beneath its count.
void setSubLine(const QString& subLine);
protected:
void enterEvent(QEvent* event) override;
void leaveEvent(QEvent* event) override;
private:
void showTooltip();
SelectionContext m_context;
std::string m_itemId;
QLabel* m_iconLabel;
QLabel* m_countLabel;
QLabel* m_subLineLabel;
// Held back so a cursor crossing the chip on its way elsewhere does not flash the
// tooltip, the way an ordinary tooltip is.
QTimer* m_hoverTimer;
// Built on the first hover, because most chips are never hovered at all.
ItemTooltip* m_tooltip = nullptr;
QLabel* m_iconLabel;
QLabel* m_countLabel;
QLabel* m_subLineLabel;
};

Some files were not shown because too many files have changed in this diff Show More