250da8c9aa6ec1c188c4b8f4fef0d642518dcb7d
setRecipe has always returned early when the recipe is unchanged, so a redundant selection does not reset buffers. setShipLayout had no such guard: it cancelled the production cycle and wiped every buffer on any call, including one that set the layout the shipyard already had. That already contradicted REQ-BLD-SHIPYARD, which cancels a cycle only when the player "confirms a layout change", and it becomes load-bearing for the blueprint configuration transfer of REQ-UI-BLUEPRINT-TRANSFER, which is meant to be clicked repeatedly onto matching shipyards. REQ-MAT-INPUT-BUFFER now states the rule generally: setting a configuration to the value it already holds changes nothing, whatever path applies it. An unset layout counts as an empty one. The two are equivalent for buffers, production, and the spawned ship -- the spawn path already converts nullopt to an empty layout deliberately -- so clearing an already-unconfigured shipyard is a no-op too. That is the case a transfer from a layout-less source produces. The only place the two differ is the has_value() bit in StateChecksum, and record and replay take the same branch, so determinism is unaffected. Layout equality is order-sensitive by choice: reporting a change that is not one costs a buffer reset, while missing a real change would leave a shipyard building the wrong ship. BuildingConfigTest's shipyard case used an empty layout as shorthand for "a layout is set", which is now a no-op and left nothing to read back. It configures a real module instead and checks it round-trips. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K
Description
No description provided
Languages
C++
96%
CMake
2.2%
Python
1.2%
C
0.6%