They had no recipe at all: their buffers were unioned over every recipe of
their type, so one smelter accepted all four ores at once, held three kinds of
ingot at once, and ran whichever recipe happened to have its inputs. That is
four recipes coexisting in one building.
New REQ-BLD-AUTO-RECIPE makes them ordinary selectable-recipe buildings that
size their buffers for the one recipe they hold, with a single addition: while
no recipe is set, the first material offered at an input port that any of their
recipes consumes selects it. That covers every intake path, direct coupling
included -- a building that accepts nothing would otherwise leave a coupled
producer stuck at its port forever. Ports in order, config order as tie-break,
so the choice is deterministic.
Once set the recipe never changes on its own, which is what settles the case of
recipes sharing some inputs but not others: there is no second guess to make.
The player changes it through the ordinary selection dialog, which clears the
buffers and so also frees a building holding part of a cycle nothing feeds any
more -- no separate clear action is needed. The dialog's clearing option reads
(Auto) rather than (None) there, since it returns the building to automatic
selection rather than leaving it idle.
Consequently these buildings can now be grey, have a recipe control in the
selection card, and drop the special cases they needed for having no recipe to
name: the buffer-chip union and the recipe summary's "recipe it ran last".
Requirements only; the implementation follows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
A building has one output buffer per item it can produce, so the singular
caption no longer matches what the section lists -- and the input side, which
has always had one buffer per material, already read "Input buffers".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
The Reprocessing Plant held at most one cycle's output, so a single item
anywhere in the building -- buffer or still emerging -- stopped the next cycle.
That cap existed only to deny a reroll: with room for one item, stalling the
output belt could not make the plant discard a roll and try again.
Replace it with the general rule. Every item a recipe can produce gets its own
buffer of twice its per-cycle amount, mirroring the input side, and a cycle
starts only when every output it could produce fits. For a deterministic recipe
that is just its own outputs, so nothing changes there. For the plant it means
all possible rolls must fit, which denies the reroll as before -- a full buffer
for one item stops the plant entirely rather than letting it go on producing
only the others -- while allowing an output amount above one.
Also pins what "the next buffered item" means at the output port now that one
queue no longer implies it: items leave in production order whatever their
type. Status light and output chip wording follow, since a buffer short of a
full cycle's worth blocks exactly as a full one does.
Requirements only; the implementation follows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
The debris panel's stat row spelled out "Scrap remaining". It now reads
"Remaining" with the amount followed by the bare scrap icon -- the same
inline form the header bar uses for building blocks -- and falls back to
the old caption when no scrap icon file exists. The count summary's
indented sub-row states its sum the same way.
REQ-UI-ITEM-ICON named the bare inline icon as a building_block special
case; it now states the general rule (an icon standing in for the item's
name beside a number is drawn without its square) and keeps the boundary
explicit: a value shown as an item still takes the square.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
Recipe display names come from the id, so a recipe that shared its id with
its output item showed the item's name back to the player. Every recipe id
now names the process that runs it: iron_mining, quartz_reduction,
steel_rolling, chip_etching, the *_framing hulls, the *_kit module prefabs,
and the drop-only shortcuts as direct_rolling/-etching/-hardening.
The three shortcut unlock groups are renamed with their recipes, since a
group's name is derived from its id the same way.
Blueprints and replays store recipe ids, so files recorded before this
rename lose their miner and assembler recipe selections.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x
