stop the output chips second-guessing the buffers they stand for
The output chips tested each item against the unlock state before drawing it. That was the right guard when the chips were flattened from a recipe's full group list, locked groups included -- but the cycle now carries only the groups the building can be handed, so every producible id reaching this loop is already one the player can have. Nor could the buffered ids need it: an item enters an output buffer only by being yielded by a group the building was picking from. A chip dropped for being locked would therefore never be hiding a locked item; it would be hiding a buffer with something in it, which is the one thing the section exists to show. The input-side test stays for now, though it is close to dead for its own reasons -- see the note in the follow-up rather than reading anything into its survival here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
This commit is contained in:
@@ -652,7 +652,7 @@ The panel shows exactly one **content** at a time, picked from the catalog in RE
|
||||
|
||||
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).
|
||||
**Only buffers the building really has are listed, and all of them.** The output chips follow the recipe summary above them: one chip per item of the groups the summary states, which are the groups the building can actually be handed (REQ-UI-RECIPE-SUMMARY, REQ-LOCK-OUTPUT-POOL). No further per-item test is applied on top, and none is wanted — an item can only reach an output buffer by being yielded by a group the building was picking from, so a chip suppressed for being locked would not be hiding a locked item, it would be misreporting a buffer the building is filling. The input chips are the selected recipe's inputs, which an unlocked recipe's always are (REQ-LOCK-IMPLICIT step 2 adds the inputs of every recipe that produces something unlocked).
|
||||
- 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.
|
||||
|
||||
**Only groups the player could be handed are stated.** A group holding any locked item is left out whole, exactly as the pool leaves it out when picking (REQ-LOCK-OUTPUT-POOL) — a summary that advertised it would promise a yield the building will never produce, and would disagree with the output buffers beneath it, which list unlocked items only (REQ-UI-SINGLE-SELECTION). A Reprocessing Plant therefore states three alternatives where its recipe lists four and the fourth is still locked. Unlike the pool, the test applies to a single-group recipe too: the pool exempts those so that a building whose one output nothing yet demands still produces, which is a rule about what to run, not about what to state. A recipe left with no group at all would have nothing to draw, but none can be selected, adopted, or applied from a blueprint (REQ-LOCK-UI-RECIPE, REQ-BLD-AUTO-RECIPE, REQ-LOCK-UI-BLUEPRINT), so no building holds one. 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).
|
||||
|
||||
Reference in New Issue
Block a user