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 real cause of "the crafter buttons do nothing", reported three
times. IconButton._blocked_by_modal tested `menu.visible`, but hiding a
parent leaves a child's own `visible` flag true - and the build menu's
info popup is itself one of the modal panels. So opening any building's
info popup and then closing the build menu with the X left an invisible
popup still claiming to be open, and from that moment EVERY button in
the game was blocked, with no way for a player to get out of it.
It tests is_visible_in_tree() now, and closing the build menu also
closes its popup rather than leaving it half-open.
My earlier attempts kept missing it because the probes called the
handlers directly - they exercised the crafter logic, which was fine all
along, and never the input path in that state. The regression test
reproduces the exact sequence: open the build menu, show a building's
info, hide the menu, then check an unrelated button still fires.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three play-testing reports.
1. Buttons behind an open panel were still clickable. There are two
input paths and both leaked. GUI clicks: the research and formation
panels cannot block with mouse_filter = STOP, because their contents
are driven from raw _unhandled_input and a Control consuming touches
through the GUI system swallows them first - so the panels stay
transparent and IconButton now checks whether it is behind one, via a
"modal_menus" group. Raw input: a touch landing on the research panel
but missing a node was left unhandled, so it fell through to
GameController - which sits on the ROOT node and sees whatever its
children ignore - and moved the fleet or pinch-zoomed the world.
2. "Store ore here" looked dead. It was working: the confirmation was
overwritten one frame later by the per-frame status refresh added in
#16, so it flashed for a single frame. Craft-panel messages now
outlive a refresh (3s), and the button stays ENABLED with an empty
hold so pressing it can say why - a greyed button that cannot explain
itself is the same dead-button problem.
3. The mothership's description could overlap the button below it. The
description block was positioned from the TOP while the buttons were
anchored to the BOTTOM, so the gap between them was whatever the
screen height left over - overlapping at 1280 and separating at 960.
It is one bottom-anchored stack now, checked at both.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
