Everything lived in one flat directory, so a diff gave no clue what area it
touched and finding the file you wanted meant knowing its exact name. Twelve
folders now, grouped by what a thing IS rather than what type it is - a
vessel's definition, its component scenes and its upgrade resources sit
together, because that is the set you read when you change one of them.
buildings core controllers enemies logistics planets
resources shaders surface ui vessels vfx world
332 files moved and every res:// reference rewritten - 306 files touched,
including the autoload and main-scene paths in project.godot. Nothing renamed:
this is purely where files sit, so the diff is a pile of pure moves and no
behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at
the root, where Godot and the export preset expect them.
Verified three ways, because a suite alone would not have caught all of it:
the full 117 pass, the web export builds clean, and the game renders.
The export is why that matters. The FIRST export after the move failed with
"Attempt to open script 'res://GameState.gd'" - the old path - while
project.godot on disk plainly said res://core/GameState.gd. That is this
project's documented Android FUSE mtime trap: Godot served a cached copy of a
file whose content had changed. A `touch` fixed it. Nothing in the test suite
would have found that, because the suite runs from a copy on a native
filesystem - the one place the bug cannot happen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The loose end from #24. withdraw_to_fleet, unload_into_building and
deliver_cargo were the old one-way moves behind "Load ore" and "Store
ore here"; every one of them is a special case of transfer_to_building /
transfer_to_fleet, and none had a caller left outside tests. The
cargo_delivered signal had no listeners at all.
Not just tidying: unload_into_building routed through
deposit_to_building, which does NOT special-case the mothership - it
writes b.stock, while building_holdings() returns `rocks` for a
mothership and ignores stock entirely. So unload_into_building(
mothership_id) would have parked ore in a field nothing reads, with no
error. Nothing called it that way, but it is a plausibly-named function
sitting there to be reached for later. transfer_to_building handles it.
CARGO_LOAD_BATCH stays - the transfer menu's batch buttons use it; only
its role as withdraw_to_fleet's default argument is gone.
The #24 note expected folding these in to be costly for
test_cargo_readout, which places no buildings. It is not: the transfer
primitives work off GameState records rather than spawned nodes, so a
single add_building() in setup is enough and it stays a display test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This is the actual cause of "the build a ship menu buttons do nothing",
reported four times. Opening the crafter panel stopped recording WHICH
crafter: when the auto-unload was replaced with an explicit store button,
the replaced block reached one line further up than intended and took
`craft_building_id = current_building.building_id` with it. Every handler
in the panel then bailed out at its `if craft_building_id == 0` guard,
while the panel itself still opened and Close still worked - because
Close is the only button that does not need the binding.
The silent `return` on that guard is what let it pass unnoticed, so it
now says so instead.
The test was complicit: it set craft_building_id by hand, which skipped
the exact step that was broken. It now parks the fleet on the crafter,
waits for the action button to debounce in, and presses it - the way the
game does. Verified against the broken code: it fails with
"opening the panel did not record which crafter".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The bug reported three times was in the input path, and every test I had
called the handlers directly - so they all passed while the button was
inert. test_crafter_feedback now taps the control the way a touch does,
including after the build menu has been opened and closed, which is the
sequence that used to block every button in the game.
Verified against the old guard: the direct-call assertions still pass,
and the real tap fails with "store button dead after the build menu was
opened and closed".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Groundwork for #5. vessels_owed carries the VESSEL TYPE rather than a
bare count, so a shield vessel finishing while the player is on a planet
comes back as a shield vessel. Fleet.add_ship takes a type, and vessels
already flying are re-statted when an upgrade is researched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The crafter buttons doing nothing was not the crafter: Ship.gd was left
mid-edit and failed to parse (undeclared SHIELD_COLOR/SHIELD_RADIUS, and
a spawn() that only exists on the concrete VFX subclass). A script that
does not compile takes Main.tscn's whole node tree with it, so every
button in the game was dead. The project directory is the one being
played from, so an unfinished edit there is a broken build - finish or
revert before stopping.
With that fixed, the real gap underneath: an order the crafter cannot
pay for is ACCEPTED and queued (#16), which is indistinguishable from a
dead button. Ordering now reports either "building now" or "queued - N
more ore must be delivered here", and the transient message is rendered
LAST so it is the first line read rather than buried under the standing
fleet-capacity note.
test_crafter_feedback covers all three presses and asserts the message
survives the per-frame refresh, which is the specific way this looked
broken before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
