metaheavens/spaceship
Watch
1
0
Fork
You've already forked spaceship
 0
Code Issues 4 Pull requests Projects 1 Releases Packages Wiki Activity
spaceship/world/Main.tscn

2145 lines
49 KiB
Text
Raw Normal View History

Implement #80, #81, #82 and #83 #80 - desktop combat. The mouse aims, the left button fires, and the number keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin sticks are built for thumbs; on a desktop they mean dragging a virtual stick with a pointer that could simply BE the crosshair. The pointer path hands its heading to FireStickController rather than driving weapons itself, so exactly one thing in the scene aims a gun, and a held stick wins - a finger on it is a deliberate act, a mouse resting somewhere is not. Abilities gained fire_at(), which aims and fires in one call instead of pretending to be a press-drag-release touch. It is gated on the absence of a touchscreen, because Godot emulates a mouse button from every touch and without that a tap on a phone would fire the guns. The gate has an explicit override, and not for tidiness: headless reports a touchscreen, so with the automatic answer alone the aiming could never be exercised by a test and the only covered behaviour would be the guard. #81 - the bottom-left control hint is gone, from both scenes and from GameController. #82 - a chaser is destroyed by the impact when it reaches a vessel. It used to pass through the wreck untouched and line up another pass, which made a ramming enemy strictly better than any other. Data-driven per enemy (dies_on_contact), because a sniper that happens to drift into a ship has not spent itself doing it - and routed through take_damage, so it dies exactly as it dies to gunfire. The enemy is told about the impact BEFORE the ship resolves its own damage, since resolving it can free the ship. #83 - the research tree's buy button is gone; tapping a node twice buys it. Deliberately "the same node twice" rather than a timed double-tap: no window to miss on a slow phone, no accidental purchase while browsing, and the first tap always does something visible, so the second is never a blind commitment. The status line now says "Tap again to research" - with the button gone it is the only thing distinguishing an affordable node from an unaffordable one. test_enemy_collision asserted the exact behaviour #82 reversed, and now checks the ram costs both. Suite 117/117. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
[gd_scene load_steps=31 format=3]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
#84: move 215 root files into a folder hierarchy 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>
2026-08-21 19:44:14 +02:00
[ext_resource type="Script" path="res://world/Starfield.gd" id="1"]
[ext_resource type="Script" path="res://vessels/Fleet.gd" id="2"]
[ext_resource type="Script" path="res://controllers/GameController.gd" id="3"]
[ext_resource type="Script" path="res://enemies/EnemySpawner.gd" id="4"]
[ext_resource type="Shader" path="res://shaders/starfield.gdshader" id="5"]
[ext_resource type="Script" path="res://world/ExplorationTracker.gd" id="6"]
[ext_resource type="Script" path="res://world/AsteroidField.gd" id="7"]
[ext_resource type="Script" path="res://world/WorldMap.gd" id="8"]
[ext_resource type="Script" path="res://world/WorldMapContent.gd" id="9"]
[ext_resource type="Script" path="res://ui/IconButton.gd" id="10"]
[ext_resource type="Script" path="res://planets/PlanetField.gd" id="11"]
[ext_resource type="Script" path="res://planets/PlanetAtmosphereController.gd" id="12"]
[ext_resource type="Script" path="res://ui/TouchJoystick.gd" id="13"]
[ext_resource type="Script" path="res://buildings/BuildingField.gd" id="14"]
[ext_resource type="Script" path="res://controllers/BuildController.gd" id="15"]
[ext_resource type="Script" path="res://ui/ResourceReadout.gd" id="16"]
[ext_resource type="Script" path="res://ui/FormationEditor.gd" id="17"]
[ext_resource type="Script" path="res://ui/NeonNumber.gd" id="19"]
[ext_resource type="Script" path="res://ui/NeonPanel.gd" id="20"]
[ext_resource type="Script" path="res://ui/SkillTreeView.gd" id="21"]
#100 (#97b): waves replace the roaming enemy spawner The old spawner put one enemy on the map every 3-6 seconds for ever. There was no rhythm to the danger and nothing to prepare for. Enemies now arrive in waves: a long quiet, a warning, an attack, and quiet again once the wave is dead. The clock lives in GameState, because Main.tscn is destroyed on every trip to a planet surface and a wave must not be cancelled, nor restarted from zero, by a landing. The spawning does not: GameState cannot see the world, so EnemySpawner reads the phase and puts the enemies in it. That also settles what happens when a wave turns while the player is on a surface - the wave is waiting in space when they come back. EnemySpawner keeps its name deliberately. It is still the thing that puts enemies in the world, and 88 test files already say `get_node("EnemySpawner").set_process(false)` to ask for a quiet map. Strength is a function of the FLEET, per the ticket, with the wave number as a slower second term so a player who never grows still meets escalation. The budget is spent most-expensive-first, so a large wave is heavier rather than merely longer, and min_strength keeps the first waves to chasers whatever the arithmetic says. "No timer should be visible" is enforced rather than merely observed: GameState offers wave_warning_pulse(), a 0..1 throb, and no remaining-seconds accessor at all, so the alert cannot drift into being a countdown. The test pins both - that no such accessor exists, and that the alert's own text contains no digits. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 13:37:42 +02:00
[ext_resource type="Script" path="res://ui/WaveAlert.gd" id="32"]
#84: move 215 root files into a folder hierarchy 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>
2026-08-21 19:44:14 +02:00
[ext_resource type="Script" path="res://logistics/TransporterField.gd" id="23"]
[ext_resource type="Script" path="res://ui/ResourceBar.gd" id="24"]
[ext_resource type="Script" path="res://logistics/VesselDeliveryField.gd" id="26"]
[ext_resource type="Script" path="res://ui/ResourceTransferList.gd" id="27"]
[ext_resource type="Script" path="res://controllers/MouseCombatController.gd" id="mouse_ctrl"]
[ext_resource type="Script" path="res://controllers/FireStickController.gd" id="fire_ctrl"]
[ext_resource type="Script" path="res://controllers/GasBombController.gd" id="29"]
[ext_resource type="Script" path="res://controllers/LaserController.gd" id="30"]
[ext_resource type="Script" path="res://ui/SpeedFader.gd" id="31"]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[sub_resource type="ShaderMaterial" id="1"]
shader = ExtResource("5")
shader_parameter/camera_pos = Vector2(0, 0)
shader_parameter/camera_zoom = 1.0
shader_parameter/viewport_size = Vector2(720, 1280)
shader_parameter/cell_size = 60.0
shader_parameter/bg_color = Color(0.02, 0.02, 0.08, 1)
[node name="Main" type="Node2D"]
script = ExtResource("3")
[node name="BackgroundLayer" type="CanvasLayer" parent="."]
layer = -10
[node name="Starfield" type="ColorRect" parent="BackgroundLayer"]
material = SubResource("1")
mouse_filter = 2
anchors_preset = 15
anchor_right = 1.0
anchor_bottom = 1.0
grow_horizontal = 2
grow_vertical = 2
script = ExtResource("1")
[node name="Fleet" type="Node2D" parent="."]
script = ExtResource("2")
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
[node name="GasBombController" type="Node2D" parent="."]
script = ExtResource("29")
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
[node name="FireStickController" type="Node2D" parent="."]
script = ExtResource("fire_ctrl")
Implement #80, #81, #82 and #83 #80 - desktop combat. The mouse aims, the left button fires, and the number keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin sticks are built for thumbs; on a desktop they mean dragging a virtual stick with a pointer that could simply BE the crosshair. The pointer path hands its heading to FireStickController rather than driving weapons itself, so exactly one thing in the scene aims a gun, and a held stick wins - a finger on it is a deliberate act, a mouse resting somewhere is not. Abilities gained fire_at(), which aims and fires in one call instead of pretending to be a press-drag-release touch. It is gated on the absence of a touchscreen, because Godot emulates a mouse button from every touch and without that a tap on a phone would fire the guns. The gate has an explicit override, and not for tidiness: headless reports a touchscreen, so with the automatic answer alone the aiming could never be exercised by a test and the only covered behaviour would be the guard. #81 - the bottom-left control hint is gone, from both scenes and from GameController. #82 - a chaser is destroyed by the impact when it reaches a vessel. It used to pass through the wreck untouched and line up another pass, which made a ramming enemy strictly better than any other. Data-driven per enemy (dies_on_contact), because a sniper that happens to drift into a ship has not spent itself doing it - and routed through take_damage, so it dies exactly as it dies to gunfire. The enemy is told about the impact BEFORE the ship resolves its own damage, since resolving it can free the ship. #83 - the research tree's buy button is gone; tapping a node twice buys it. Deliberately "the same node twice" rather than a timed double-tap: no window to miss on a slow phone, no accidental purchase while browsing, and the first tap always does something visible, so the second is never a blind commitment. The status line now says "Tap again to research" - with the button gone it is the only thing distinguishing an affordable node from an unaffordable one. test_enemy_collision asserted the exact behaviour #82 reversed, and now checks the ram costs both. Suite 117/117. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
[node name="MouseCombatController" type="Node2D" parent="."]
script = ExtResource("mouse_ctrl")
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
[node name="LaserController" type="Node2D" parent="."]
script = ExtResource("30")
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="Camera2D" type="Camera2D" parent="."]
position = Vector2(0, 0)
zoom = Vector2(1, 1)
[node name="EnemySpawner" type="Node2D" parent="."]
script = ExtResource("4")
[node name="ExplorationTracker" type="Node2D" parent="."]
script = ExtResource("6")
[node name="AsteroidField" type="Node2D" parent="."]
script = ExtResource("7")
[node name="PlanetField" type="Node2D" parent="."]
script = ExtResource("11")
[node name="BuildingField" type="Node2D" parent="."]
script = ExtResource("14")
Transporter vessels, an explicit store button, and bottom-anchored menus Forgejo #19, part 6 of #12. Transporters are built at the ship crafter, fly themselves to the nearest hub and wait there. When a building is short of what its queue needs, the nearest idle transporter runs hub -> mothership -> building -> hub. Ore leaves the bank when it is loaded and lands in the building's stock on arrival, so what is drawn and what happens are the same event - the extractor hauler's rule. Production orders are now TYPED (interceptor / transporter) rather than a bare count, since the crafter builds two different things. One at a time is dispatched per building: without that, every idle transporter chases the same shortfall and they all arrive carrying ore nobody needs. Three fixes from play-testing feedback: - Storing ore into a building is now a deliberate button press, not a side effect of opening the menu. - The mothership's load-ore controls were positioned from the TOP of the screen, so on any viewport shorter than ~1300px the label fell off the bottom. They are anchored to the bottom edge now, and the label had no explicit font size so it inherited the theme's 78px and wrapped off screen. Checked at 720x960 and 720x1280. - The craft button looked live and did nothing. It was not the transport work: BASE_FLEET_SIZE is 5 and a new game starts with exactly 5 ships, so the fleet is at its cap from the first frame and every interceptor order was refused. The button is now visibly disabled and says why. The underlying balance (crafter useless until Wing Doctrine) is left alone - that is a design call, not a bug to quietly change. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 19:14:27 +02:00
[node name="TransporterField" type="Node2D" parent="."]
script = ExtResource("23")
Animate ship crafter deliveries
2026-08-13 21:39:05 +02:00
[node name="VesselDeliveryField" type="Node2D" parent="."]
script = ExtResource("26")
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="BuildController" type="Node2D" parent="."]
script = ExtResource("15")
[node name="LandingController" type="Node2D" parent="."]
script = ExtResource("12")
[node name="UI" type="CanvasLayer" parent="."]
layer = 1
Generalize the resource HUD readouts (#49) Replaces ResourceCounter/GasCounter/CargoCounter/GasCargoCounter - one hardcoded node plus one script per resource, times two scenes - with a single ResourceReadout.gd that builds one banked + one fleet-hold row per GameState.resource_types() entry at _ready(). A new resource added to ResourceDefinitions gets a HUD row with no scene edit and no new script, matching how ResourceBar and ResourceTransferList already generalize over resources. Preserves the existing visual layout (BANKED left, FLEET HOLD right), the ore-on-bright-surface contrast (via a bright_background flag replacing PlanetSurface's per-node color overrides), and the amber fleet-in-transit color convention. Reuses the already-generic ResourceGlyph for icons instead of NeonNumber's hardcoded ore hexagon. Uncovered and fixed a second bug along the way: test_cargo_readout.gd looked up its NeonNumber nodes immediately after add_child() in _initialize(), but ResourceReadout builds its rows in _ready(), which for a -s entry-point script does not fire synchronously during that add_child() - it's deferred to the first frame. Moved the lookup to after the existing elapsed wait in _process(), which is also what tests/test_resource_readout.gd's setup does from the start. Repo notes for the next agent, confirmed empirically this session: - A -s entry-point script can only reach an autoload's CONSTANTS via the bare identifier (GameState.RESOURCE_ORE works everywhere). Calling any of its METHODS that way (GameState.resource_types()) fails to compile with "Identifier not found: GameState", even from _initialize(). Route method calls through the actual instance (root.get_node("GameState")) instead, as the rest of the suite already does. - `git status --short | awk '{print $2}' | xargs touch` recreates deleted files as empty stubs, since touch on a missing path creates it. Filter out D-status paths before touching, or touch only the paths you know still exist. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 08:30:10 +02:00
[node name="ResourceReadout" type="Control" parent="UI"]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
mouse_filter = 2
offset_left = 28
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_top = 38
Generalize the resource HUD readouts (#49) Replaces ResourceCounter/GasCounter/CargoCounter/GasCargoCounter - one hardcoded node plus one script per resource, times two scenes - with a single ResourceReadout.gd that builds one banked + one fleet-hold row per GameState.resource_types() entry at _ready(). A new resource added to ResourceDefinitions gets a HUD row with no scene edit and no new script, matching how ResourceBar and ResourceTransferList already generalize over resources. Preserves the existing visual layout (BANKED left, FLEET HOLD right), the ore-on-bright-surface contrast (via a bright_background flag replacing PlanetSurface's per-node color overrides), and the amber fleet-in-transit color convention. Reuses the already-generic ResourceGlyph for icons instead of NeonNumber's hardcoded ore hexagon. Uncovered and fixed a second bug along the way: test_cargo_readout.gd looked up its NeonNumber nodes immediately after add_child() in _initialize(), but ResourceReadout builds its rows in _ready(), which for a -s entry-point script does not fire synchronously during that add_child() - it's deferred to the first frame. Moved the lookup to after the existing elapsed wait in _process(), which is also what tests/test_resource_readout.gd's setup does from the start. Repo notes for the next agent, confirmed empirically this session: - A -s entry-point script can only reach an autoload's CONSTANTS via the bare identifier (GameState.RESOURCE_ORE works everywhere). Calling any of its METHODS that way (GameState.resource_types()) fails to compile with "Identifier not found: GameState", even from _initialize(). Route method calls through the actual instance (root.get_node("GameState")) instead, as the rest of the suite already does. - `git status --short | awk '{print $2}' | xargs touch` recreates deleted files as empty stubs, since touch on a missing path creates it. Filter out D-status paths before touching, or touch only the paths you know still exist. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 08:30:10 +02:00
offset_right = 696
offset_bottom = 154
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("16")
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
digit_height = 38.0
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
Generalize the resource HUD readouts (#49) Replaces ResourceCounter/GasCounter/CargoCounter/GasCargoCounter - one hardcoded node plus one script per resource, times two scenes - with a single ResourceReadout.gd that builds one banked + one fleet-hold row per GameState.resource_types() entry at _ready(). A new resource added to ResourceDefinitions gets a HUD row with no scene edit and no new script, matching how ResourceBar and ResourceTransferList already generalize over resources. Preserves the existing visual layout (BANKED left, FLEET HOLD right), the ore-on-bright-surface contrast (via a bright_background flag replacing PlanetSurface's per-node color overrides), and the amber fleet-in-transit color convention. Reuses the already-generic ResourceGlyph for icons instead of NeonNumber's hardcoded ore hexagon. Uncovered and fixed a second bug along the way: test_cargo_readout.gd looked up its NeonNumber nodes immediately after add_child() in _initialize(), but ResourceReadout builds its rows in _ready(), which for a -s entry-point script does not fire synchronously during that add_child() - it's deferred to the first frame. Moved the lookup to after the existing elapsed wait in _process(), which is also what tests/test_resource_readout.gd's setup does from the start. Repo notes for the next agent, confirmed empirically this session: - A -s entry-point script can only reach an autoload's CONSTANTS via the bare identifier (GameState.RESOURCE_ORE works everywhere). Calling any of its METHODS that way (GameState.resource_types()) fails to compile with "Identifier not found: GameState", even from _initialize(). Route method calls through the actual instance (root.get_node("GameState")) instead, as the rest of the suite already does. - `git status --short | awk '{print $2}' | xargs touch` recreates deleted files as empty stubs, since touch on a missing path creates it. Filter out D-status paths before touching, or touch only the paths you know still exist. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 08:30:10 +02:00
[node name="BankCaption" type="Label" parent="UI"]
Add gas giant resource system
2026-08-13 21:07:35 +02:00
mouse_filter = 2
offset_left = 28
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_top = 6
offset_right = 220
offset_bottom = 34
Add gas giant resource system
2026-08-13 21:07:35 +02:00
theme_override_font_sizes/font_size = 18
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
theme_override_colors/font_color = Color(0.55, 0.78, 0.86, 1)
text = "BANKED"
Add gas giant resource system
2026-08-13 21:07:35 +02:00
Generalize the resource HUD readouts (#49) Replaces ResourceCounter/GasCounter/CargoCounter/GasCargoCounter - one hardcoded node plus one script per resource, times two scenes - with a single ResourceReadout.gd that builds one banked + one fleet-hold row per GameState.resource_types() entry at _ready(). A new resource added to ResourceDefinitions gets a HUD row with no scene edit and no new script, matching how ResourceBar and ResourceTransferList already generalize over resources. Preserves the existing visual layout (BANKED left, FLEET HOLD right), the ore-on-bright-surface contrast (via a bright_background flag replacing PlanetSurface's per-node color overrides), and the amber fleet-in-transit color convention. Reuses the already-generic ResourceGlyph for icons instead of NeonNumber's hardcoded ore hexagon. Uncovered and fixed a second bug along the way: test_cargo_readout.gd looked up its NeonNumber nodes immediately after add_child() in _initialize(), but ResourceReadout builds its rows in _ready(), which for a -s entry-point script does not fire synchronously during that add_child() - it's deferred to the first frame. Moved the lookup to after the existing elapsed wait in _process(), which is also what tests/test_resource_readout.gd's setup does from the start. Repo notes for the next agent, confirmed empirically this session: - A -s entry-point script can only reach an autoload's CONSTANTS via the bare identifier (GameState.RESOURCE_ORE works everywhere). Calling any of its METHODS that way (GameState.resource_types()) fails to compile with "Identifier not found: GameState", even from _initialize(). Route method calls through the actual instance (root.get_node("GameState")) instead, as the rest of the suite already does. - `git status --short | awk '{print $2}' | xargs touch` recreates deleted files as empty stubs, since touch on a missing path creates it. Filter out D-status paths before touching, or touch only the paths you know still exist. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 08:30:10 +02:00
[node name="FleetCaption" type="Label" parent="UI"]
Add gas giant resource system
2026-08-13 21:07:35 +02:00
mouse_filter = 2
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_left = 356
offset_top = 6
offset_right = 620
offset_bottom = 34
Add gas giant resource system
2026-08-13 21:07:35 +02:00
theme_override_font_sizes/font_size = 18
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
theme_override_colors/font_color = Color(1, 0.78, 0.25, 1)
text = "FLEET HOLD"
Add gas giant resource system
2026-08-13 21:07:35 +02:00
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="PlanetNameLabel" type="Label" parent="UI"]
visible = false
offset_left = 24
Refine context actions and preserve fleet landings
2026-08-14 23:15:12 +02:00
offset_top = 480
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
offset_right = 696
Refine context actions and preserve fleet landings
2026-08-14 23:15:12 +02:00
offset_bottom = 532
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
text = ""
horizontal_alignment = 1
Refine context actions and preserve fleet landings
2026-08-14 23:15:12 +02:00
theme_override_font_sizes/font_size = 32
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="EnterAtmosphereButton" type="Control" parent="UI"]
visible = false
Refine context actions and preserve fleet landings
2026-08-14 23:15:12 +02:00
offset_left = 188
offset_top = 324
offset_right = 336
offset_bottom = 472
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 3
[node name="BuildButton" type="Control" parent="UI"]
offset_left = 24
offset_right = 172
Collapse contextual building actions
2026-08-13 20:49:15 +02:00
offset_top = 160
offset_bottom = 308
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 5
[node name="BuildActionButton" type="Control" parent="UI"]
visible = false
offset_left = 24
offset_right = 172
Collapse contextual building actions
2026-08-13 20:49:15 +02:00
offset_top = 324
offset_bottom = 472
script = ExtResource("10")
icon = 2
[node name="BuildingActionButton" type="Control" parent="UI"]
visible = false
offset_left = 24
offset_right = 172
offset_top = 488
offset_bottom = 636
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 2
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
[node name="HangarButton" type="Control" parent="UI"]
visible = false
offset_left = 24
offset_right = 172
Collapse contextual building actions
2026-08-13 20:49:15 +02:00
offset_top = 488
offset_bottom = 636
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
script = ExtResource("10")
icon = 2
glow_color = Color(0.45, 0.9, 0.55, 1)
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
[node name="TransferButton" type="Control" parent="UI"]
visible = false
Refine context actions and preserve fleet landings
2026-08-14 23:15:12 +02:00
offset_left = 188
offset_top = 160
offset_right = 336
offset_bottom = 308
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
script = ExtResource("10")
icon = 14
glow_color = Color(1, 0.78, 0.25, 1)
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="MapButton" type="Control" parent="UI"]
anchor_left = 1.0
anchor_right = 1.0
offset_left = -172
offset_right = -24
offset_top = 24
offset_bottom = 172
script = ExtResource("10")
icon = 0
#100 (#97b): waves replace the roaming enemy spawner The old spawner put one enemy on the map every 3-6 seconds for ever. There was no rhythm to the danger and nothing to prepare for. Enemies now arrive in waves: a long quiet, a warning, an attack, and quiet again once the wave is dead. The clock lives in GameState, because Main.tscn is destroyed on every trip to a planet surface and a wave must not be cancelled, nor restarted from zero, by a landing. The spawning does not: GameState cannot see the world, so EnemySpawner reads the phase and puts the enemies in it. That also settles what happens when a wave turns while the player is on a surface - the wave is waiting in space when they come back. EnemySpawner keeps its name deliberately. It is still the thing that puts enemies in the world, and 88 test files already say `get_node("EnemySpawner").set_process(false)` to ask for a quiet map. Strength is a function of the FLEET, per the ticket, with the wave number as a slower second term so a player who never grows still meets escalation. The budget is spent most-expensive-first, so a large wave is heavier rather than merely longer, and min_strength keeps the first waves to chasers whatever the arithmetic says. "No timer should be visible" is enforced rather than merely observed: GameState offers wave_warning_pulse(), a 0..1 throb, and no remaining-seconds accessor at all, so the alert cannot drift into being a countdown. The test pins both - that no such accessor exists, and that the alert's own text contains no digits. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 13:37:42 +02:00
[node name="WaveAlert" type="Control" parent="UI"]
visible = false
mouse_filter = 2
anchor_left = 1.0
anchor_right = 1.0
offset_left = -300.0
offset_right = -24.0
offset_top = 188.0
offset_bottom = 252.0
script = ExtResource("32")
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="Joystick" type="Control" parent="UI"]
mouse_filter = 2
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
script = ExtResource("13")
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
anchor_top = 1.0
anchor_bottom = 1.0
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_left = 12
offset_right = 252
offset_top = -330
offset_bottom = -80
[node name="FireStick" type="Control" parent="UI"]
mouse_filter = 2
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("13")
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
glow_color = Color(1, 0.45, 0.3, 1)
core_color = Color(1, 1, 1, 1)
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -252
offset_right = -12
offset_top = -330
offset_bottom = -80
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
[node name="SpeedFader" type="Control" parent="UI"]
visible = false
mouse_filter = 2
anchor_left = 1.0
anchor_right = 1.0
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
anchor_top = 1.0
anchor_bottom = 1.0
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -94
offset_right = -24
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_top = -720
offset_bottom = -560
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
script = ExtResource("31")
[node name="Label" type="Label" parent="UI/SpeedFader"]
mouse_filter = 2
offset_left = -20
offset_right = 90
offset_top = -32
offset_bottom = -4
theme_override_font_sizes/font_size = 20
theme_override_colors/font_color = Color(0.7, 0.3, 1, 1)
horizontal_alignment = 1
text = "x1.0"
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
[node name="LaserButton" type="Control" parent="UI"]
visible = false
mouse_filter = 2
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
script = ExtResource("10")
round_frame = true
icon = 36
glow_color = Color(0.3, 0.9, 1, 1)
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_left = -196
offset_right = -100
offset_top = -492
offset_bottom = -396
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="PivotCCWButton" type="Control" parent="UI"]
mouse_filter = 2
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
script = ExtResource("10")
round_frame = true
icon = 7
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_left = -468
offset_right = -364
offset_top = -130
offset_bottom = -26
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
[node name="GasBombButton" type="Control" parent="UI"]
visible = false
mouse_filter = 2
script = ExtResource("10")
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
round_frame = true
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
icon = 32
glow_color = Color(0.96, 0.22, 0.72, 1)
Gas bombers consume gas from the fleet hold when firing (#60) Shots cost GAS_PER_SHOT (5) from GameState.fleet_inventory, not the bank - the fleet has to be carrying its own ammunition. The button's enabled rule now also requires affordability, and a press on a ready- but-unaffordable bomber still consumes the touch to explain itself via a new status label (GasBombStatus, IconButton's own "greyed but still pressable" convention) rather than either silently doing nothing or consuming the bomber's cooldown for a shot that never fires. Also documents a real, reproducible GDScript trap hit while writing tests/test_gas_bomber_ammo.gd: a bare `ClassName.SOME_CONST` reference anywhere in a -s entry test script can corrupt method resolution for the WHOLE script, making an unrelated, earlier `some_node._process()` call fail with "Nonexistent function '_process' in base 'Nil'" despite the node being valid and the method existing (confirmed via has_method()). Root cause unconfirmed; fixed by mirroring the constant 's value into a local const instead of referencing the class directly, in all three gas-bomber tests. tests/test_gas_bomber.gd and test_gas_bomber_cooldowns.gd updated to stock fleet gas first, since shots are no longer free.
2026-08-16 18:54:44 +02:00
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_left = -324
offset_right = -228
offset_top = -424
offset_bottom = -328
[node name="GasBombStatus" type="Label" parent="UI"]
mouse_filter = 2
Gas bombers consume gas from the fleet hold when firing (#60) Shots cost GAS_PER_SHOT (5) from GameState.fleet_inventory, not the bank - the fleet has to be carrying its own ammunition. The button's enabled rule now also requires affordability, and a press on a ready- but-unaffordable bomber still consumes the touch to explain itself via a new status label (GasBombStatus, IconButton's own "greyed but still pressable" convention) rather than either silently doing nothing or consuming the bomber's cooldown for a shot that never fires. Also documents a real, reproducible GDScript trap hit while writing tests/test_gas_bomber_ammo.gd: a bare `ClassName.SOME_CONST` reference anywhere in a -s entry test script can corrupt method resolution for the WHOLE script, making an unrelated, earlier `some_node._process()` call fail with "Nonexistent function '_process' in base 'Nil'" despite the node being valid and the method existing (confirmed via has_method()). Root cause unconfirmed; fixed by mirroring the constant 's value into a local const instead of referencing the class directly, in all three gas-bomber tests. tests/test_gas_bomber.gd and test_gas_bomber_cooldowns.gd updated to stock fleet gas first, since shots are no longer free.
2026-08-16 18:54:44 +02:00
theme_override_font_sizes/font_size = 18
theme_override_colors/font_color = Color(0.96, 0.22, 0.72, 1)
autowrap_mode = 2
horizontal_alignment = 1
text = ""
Laser shooters consume energy from the fleet hold when firing (#61) Mirrors #60's gas bomber ammunition exactly: ENERGY_PER_SHOT (8) drawn from GameState.fleet_inventory before consuming the firing ship's cooldown, the button's enabled rule requires affordability too, and an unaffordable-but-otherwise-ready press still explains itself through a new LaserStatus label rather than silently doing nothing. Added two small generic GameState helpers this needed: deposit_fleet_resource()/deposit_bank_resource(), counterparts to #60's withdraw_fleet_resource() for resources (energy) with no dedicated fleet_cargo/fleet_gas_cargo-style property. Along the way, confirmed deposit_resource_to_building() on a "bank" building deposits into that building's own per-record inventory, NOT bank_inventory itself - only building_resource()/building_inventory() special-case the "bank" capability to redirect there. test_laser_vessel.gd (#58) updated to stock fleet energy first, since shots are no longer free - same fix #60 required for the gas bomber's own pre-existing tests. Also fixed test_laser_vessel.gd's own instance of the bare-ClassName.CONST script-corruption trap (documented in #60's commit): var skill: LaserController and a bare LaserController.BEAM_HALF_WIDTH reference, mirrored into a local const instead.
2026-08-16 19:11:31 +02:00
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_left = -420
Laser shooters consume energy from the fleet hold when firing (#61) Mirrors #60's gas bomber ammunition exactly: ENERGY_PER_SHOT (8) drawn from GameState.fleet_inventory before consuming the firing ship's cooldown, the button's enabled rule requires affordability too, and an unaffordable-but-otherwise-ready press still explains itself through a new LaserStatus label rather than silently doing nothing. Added two small generic GameState helpers this needed: deposit_fleet_resource()/deposit_bank_resource(), counterparts to #60's withdraw_fleet_resource() for resources (energy) with no dedicated fleet_cargo/fleet_gas_cargo-style property. Along the way, confirmed deposit_resource_to_building() on a "bank" building deposits into that building's own per-record inventory, NOT bank_inventory itself - only building_resource()/building_inventory() special-case the "bank" capability to redirect there. test_laser_vessel.gd (#58) updated to stock fleet energy first, since shots are no longer free - same fix #60 required for the gas bomber's own pre-existing tests. Also fixed test_laser_vessel.gd's own instance of the bare-ClassName.CONST script-corruption trap (documented in #60's commit): var skill: LaserController and a bare LaserController.BEAM_HALF_WIDTH reference, mirrored into a local const instead.
2026-08-16 19:11:31 +02:00
offset_right = -24
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_top = -560
offset_bottom = -512
[node name="LaserStatus" type="Label" parent="UI"]
mouse_filter = 2
Laser shooters consume energy from the fleet hold when firing (#61) Mirrors #60's gas bomber ammunition exactly: ENERGY_PER_SHOT (8) drawn from GameState.fleet_inventory before consuming the firing ship's cooldown, the button's enabled rule requires affordability too, and an unaffordable-but-otherwise-ready press still explains itself through a new LaserStatus label rather than silently doing nothing. Added two small generic GameState helpers this needed: deposit_fleet_resource()/deposit_bank_resource(), counterparts to #60's withdraw_fleet_resource() for resources (energy) with no dedicated fleet_cargo/fleet_gas_cargo-style property. Along the way, confirmed deposit_resource_to_building() on a "bank" building deposits into that building's own per-record inventory, NOT bank_inventory itself - only building_resource()/building_inventory() special-case the "bank" capability to redirect there. test_laser_vessel.gd (#58) updated to stock fleet energy first, since shots are no longer free - same fix #60 required for the gas bomber's own pre-existing tests. Also fixed test_laser_vessel.gd's own instance of the bare-ClassName.CONST script-corruption trap (documented in #60's commit): var skill: LaserController and a bare LaserController.BEAM_HALF_WIDTH reference, mirrored into a local const instead.
2026-08-16 19:11:31 +02:00
theme_override_font_sizes/font_size = 18
theme_override_colors/font_color = Color(0.3, 0.9, 1, 1)
autowrap_mode = 2
horizontal_alignment = 1
text = ""
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_left = -420
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
offset_right = -24
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
offset_top = -616
offset_bottom = -568
[node name="PivotCWButton" type="Control" parent="UI"]
mouse_filter = 2
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
round_frame = true
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
icon = 6
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring The fleet's guns picked their own targets and fired on their own, so combat happened whether or not the player did anything - there was nothing to aim and nothing to decide, and the right half of the screen held nothing at all. Firing is now an action. VesselWeaponComponent no longer seeks a target; it shoots along a heading, and the only thing that supplies one is the new right-hand stick via FireStickController. A fleet arriving from another scene starts with its guns silent, which is the correct resting state. A subtle dashed guide runs from the fleet along the aimed heading while the stick is held, out to the guns' OWN range - read from a weapon that is actually aboard, so the line can never promise reach the fleet does not have. Layout: the two sticks take the bottom corners, the pivot pair is centred between them at the bottom edge, and the laser and gas bomb sit on an arc up and left of the fire stick where a thumb already is. Those four are now round - IconButton grew a round_frame mode, and the in-world action controls use it while panel and menu buttons stay square, so the two kinds of button read as different kinds of thing. Worth recording, because it cost a screenshot to find: a script-declared property set BEFORE the `script = ExtResource(...)` line in a .tscn is silently dropped. Godot's parser has no idea the property exists yet. The round frames were all correctly set in both scenes and none of them applied. Also fixed researtch_lab_garrison.tres, which was authored under the void profile - that is the black hole surface, so a lab garrison was spawning on black holes. Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds the real stick toward the enemy rather than poking weapon components, so it exercises the path the player uses. test_fire_stick is new and covers the change itself: an idle stick leaves a target parked well inside range untouched, which is precisely what the old gun would never have done. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -356
offset_right = -252
offset_top = -130
offset_bottom = -26
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
[node name="WorldMap" type="Control" parent="UI" groups=["modal_menus"]]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
visible = false
anchor_right = 1.0
anchor_bottom = 1.0
script = ExtResource("8")
[node name="Backdrop" type="ColorRect" parent="UI/WorldMap"]
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.96)
[node name="MapContent" type="Node2D" parent="UI/WorldMap"]
script = ExtResource("9")
[node name="RecenterButton" type="Control" parent="UI/WorldMap"]
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 24
offset_right = 172
offset_top = -620
offset_bottom = -472
script = ExtResource("10")
icon = 2
[node name="CloseButton" type="Control" parent="UI/WorldMap"]
anchor_left = 1.0
anchor_right = 1.0
offset_left = -172
offset_right = -24
offset_top = 24
offset_bottom = 172
script = ExtResource("10")
icon = 1
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
[node name="BuildMenu" type="Control" parent="UI" groups=["modal_menus"]]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
visible = false
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Backdrop" type="ColorRect" parent="UI/BuildMenu"]
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.94)
[node name="TitleLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
offset_top = 70
offset_right = -24
offset_bottom = 196
text = "Build"
horizontal_alignment = 1
[node name="StatusLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
offset_top = 206
offset_right = -24
offset_bottom = 330
theme_override_font_sizes/font_size = 40
autowrap_mode = 2
text = ""
horizontal_alignment = 1
[node name="MothershipButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = -204
offset_right = -76
offset_top = -300
offset_bottom = -172
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 8
glow_color = Color(0.45, 0.9, 0.55, 1)
[node name="MothershipLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -290
offset_right = 10
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_top = -166
offset_bottom = -100
theme_override_font_sizes/font_size = 32
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
autowrap_mode = 2
text = "Mothership"
horizontal_alignment = 1
[node name="MothershipCost" type="Control" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = -200
offset_right = -80
offset_top = -96
offset_bottom = -44
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("19")
amount = 20
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
digit_height = 40.0
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="CrafterButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = 76
offset_right = 204
offset_top = -300
offset_bottom = -172
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 9
glow_color = Color(1, 0.72, 0.25, 1)
[node name="CrafterLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -10
offset_right = 290
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_top = -166
offset_bottom = -100
theme_override_font_sizes/font_size = 32
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
autowrap_mode = 2
text = "Ship Crafter"
horizontal_alignment = 1
[node name="CrafterCost" type="Control" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = 80
offset_right = 200
offset_top = -96
offset_bottom = -44
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("19")
amount = 12
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
digit_height = 40.0
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="CommandButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = -204
offset_right = -76
offset_top = -10
offset_bottom = 118
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 10
glow_color = Color(0.55, 0.6, 1, 1)
[node name="CommandLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -290
offset_right = 10
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_top = 124
offset_bottom = 190
theme_override_font_sizes/font_size = 32
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
autowrap_mode = 2
text = "Command Center"
horizontal_alignment = 1
[node name="CommandCost" type="Control" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = -200
offset_right = -80
offset_top = 194
offset_bottom = 246
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("19")
amount = 15
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
digit_height = 40.0
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="ExtractorButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = 76
offset_right = 204
offset_top = -10
offset_bottom = 118
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 11
glow_color = Color(0, 0.62, 0.7, 1)
[node name="ExtractorLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -10
offset_right = 290
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_top = 124
offset_bottom = 190
theme_override_font_sizes/font_size = 32
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
autowrap_mode = 2
text = "Extractor"
horizontal_alignment = 1
[node name="ExtractorCost" type="Control" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
offset_left = 80
offset_right = 200
offset_top = 194
offset_bottom = 246
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("19")
amount = 25
Transport Hub building Forgejo #18, part 5 of #12. The building only - the vessels that do the hauling are #19. Placeable, costed at 30, gated behind a new "Freight Handling" research node hanging off Logistics, with its own info popup, build-menu glyph and map marker. Drawn as an octagonal dock ring with berth arms and a squared-off freight core: deliberately radial-but-flat so it does not read as a small mothership, which is the only structure with swept arms. Its stationed transports are NeonPiece children of one rotating holder, per #10 - the geometry is rasterised once and only the holder's rotation changes, so the traffic costs no redraws. Building._draw()'s match has a catch-all that renders anything unrecognised as a ship crafter, so a missing case is silent and looks almost right. The test checks for the hub's own _hub_traffic holder rather than trusting that something plausible appeared - which caught exactly that: a _ready() patch had silently not applied and the hub was rendering through the crafter branch. The build menu grew a third row. Every button, label and price moved: the old row occupied 332px against a 372px pitch, and three of those do not fit above a 1280px screen. Rows are now shorter (128px buttons, 40px price digits) at a 290px pitch, ending at y=1176. Rendered and looked at - the first attempt tightened the pitch alone and left every price overlapping the row beneath it, which no headless test would have seen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 17:45:07 +02:00
digit_height = 40.0
[node name="TransportHubButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -64
offset_right = 64
offset_top = 280
offset_bottom = 408
script = ExtResource("10")
icon = 12
glow_color = Color(0.95, 0.55, 0.85, 1)
[node name="TransportHubLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -150
offset_right = 150
offset_top = 414
offset_bottom = 480
theme_override_font_sizes/font_size = 32
autowrap_mode = 2
text = "Transport Hub"
horizontal_alignment = 1
[node name="TransportHubCost" type="Control" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -60
offset_right = 60
offset_top = 484
offset_bottom = 536
script = ExtResource("19")
amount = 30
digit_height = 40.0
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
[node name="ShipLabButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = 76
offset_right = 204
offset_top = 280
offset_bottom = 408
script = ExtResource("10")
icon = 13
glow_color = Color(0.55, 0.95, 0.9, 1)
[node name="ShipLabLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -10
offset_right = 290
offset_top = 414
offset_bottom = 480
theme_override_font_sizes/font_size = 32
autowrap_mode = 2
text = "Ship Lab"
horizontal_alignment = 1
[node name="ShipLabCost" type="Control" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = 80
offset_right = 200
offset_top = 484
offset_bottom = 536
script = ExtResource("19")
amount = 35
digit_height = 40.0
Gas burner building and the energy resource (#54) A new building that consumes gas to produce energy, a new resource stored and moved exactly like ore and gas. The resource: EnergyResourceGlyph (a cell/bolt mark) + energy's own warm yellow-green ResourceDefinition, registered in ResourceDefinitions.ORDER/DEFINITIONS and GameState.RESOURCE_ENERGY. Inventory/ResourceBar/ResourceTransferList needed no changes - #49 already made them resource-agnostic, confirmed structurally in the test rather than touched. The building: GasBurnerBuildingVisual (a hexagonal chamber with intake vents in gas's colour and output ports in energy's, so the silhouette itself reads "gas in, energy out"), GasBurnerBuildingDefinition (capabilities=["gas_burner"], its own build-menu icon appended to IconButton.Icon rather than inserted, per the ticket's own warning about renumbering stored scene values), and the matching UI/BuildMenu/GasBurner* nodes in Main.tscn. Gated behind a new "Power Systems" skill-tree node, mirroring how "freight" unlocks the transport hub. Conversion: _advance_gas_burners(), simulated in GameState alongside _advance_production/extractor mining so it keeps running while the player is elsewhere. Withdraws gas and deposits energy in the building's OWN inventory only - never the bank - so it stalls with no local gas exactly like a lab waiting on materials. Logistics: a gas burner's ongoing gas deficit is folded into the existing queued-building-supply dispatch path (same "needs resource X" loop production/research orders already use, extended with gas_burner_gas_deficit()), and a new TO_BUILDING_PICKUP/ TO_MOTHERSHIP_FROM_BUILDING transporter state pair collects its energy to the bank, mirroring the extractor pickup path per the ticket. The existing f5c60f8 priority (queued deliveries outrank collection) holds: the pickup dispatch loop runs last. Tests: new tests/test_gas_burner.gd (resource genericity, stall semantics, research gate, and full delivery+pickup logistics via a real hub), run_tests transporter/resource regressions, and screenshots of the build menu (all 7 buildings) and transfer menu (all 3 resources). Full suite: 81/81. Two real bugs found and fixed along the way, neither gas-burner- specific: - _transporter_inbound_to() matched ANY non-idle transporter with a matching target_id, regardless of purpose. Once pickup states shared target_id with delivery states (both address a building, not an extractor), a transporter delivering gas made the SAME building look "busy" to the unrelated energy-pickup dispatch, starving it even with a second, genuinely free transporter sitting idle at the hub. Split into _transporter_inbound_to() (delivery states only) and a new _transporter_inbound_for_pickup() (pickup states only). - The build menu's 3-row/6-slot layout (MENU_ROW_TOPS + row content sizing) had no room for a 7th building - despite the ticket's own note that no layout changes should be needed. A naive 4th row ran off the bottom of a 720x1280 viewport; fitting one meant both adding a 4th row top AND shrinking the shared button/label/cost sizing so each row's content no longer taller than the compressed row spacing. Caught only by actually screenshotting it - a real build menu, not headless, since --headless renders nothing. 🤖 Generated with Claude Code Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-16 12:10:31 +02:00
[node name="GasBurnerButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -64
offset_right = 64
offset_top = 570
offset_bottom = 698
script = ExtResource("10")
icon = 33
glow_color = Color(0.95, 0.35, 0.15, 1)
[node name="GasBurnerLabel" type="Label" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -150
offset_right = 150
offset_top = 704
offset_bottom = 770
theme_override_font_sizes/font_size = 32
autowrap_mode = 2
text = "Gas Burner"
horizontal_alignment = 1
[node name="GasBurnerCost" type="Control" parent="UI/BuildMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -60
offset_right = 60
offset_top = 774
offset_bottom = 826
script = ExtResource("19")
amount = 30
digit_height = 40.0
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="CloseButton" type="Control" parent="UI/BuildMenu"]
anchor_left = 1.0
anchor_right = 1.0
offset_left = -172
offset_right = -24
offset_top = 24
offset_bottom = 172
script = ExtResource("10")
icon = 1
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
[node name="InfoPopup" type="Control" parent="UI/BuildMenu" groups=["modal_menus"]]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
visible = false
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Dim" type="ColorRect" parent="UI/BuildMenu/InfoPopup"]
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.01, 0.01, 0.03, 0.55)
[node name="Panel" type="Control" parent="UI/BuildMenu/InfoPopup"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -352
offset_right = 352
offset_top = -600
offset_bottom = 600
script = ExtResource("20")
glow_color = Color(0, 0.62, 0.7, 1)
[node name="TitleLabel" type="Label" parent="UI/BuildMenu/InfoPopup/Panel"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 44
offset_right = -44
offset_top = 30
offset_bottom = 150
text = ""
horizontal_alignment = 1
[node name="MessageLabel" type="Label" parent="UI/BuildMenu/InfoPopup/Panel"]
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
offset_left = 44
offset_right = -44
offset_top = 160
offset_bottom = -440
theme_override_font_sizes/font_size = 48
text = ""
horizontal_alignment = 1
vertical_alignment = 1
autowrap_mode = 2
[node name="CostNumber" type="Control" parent="UI/BuildMenu/InfoPopup/Panel"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -70
offset_right = 90
offset_top = -424
offset_bottom = -334
script = ExtResource("19")
amount = 0
digit_height = 78.0
[node name="BuildButton" type="Control" parent="UI/BuildMenu/InfoPopup/Panel"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -200
offset_right = -40
offset_top = -300
offset_bottom = -140
script = ExtResource("10")
icon = 5
glow_color = Color(0.45, 0.9, 0.55, 1)
[node name="CloseButton" type="Control" parent="UI/BuildMenu/InfoPopup/Panel"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 40
offset_right = 200
offset_top = -300
offset_bottom = -140
script = ExtResource("10")
icon = 1
glow_color = Color(0, 0.62, 0.7, 1)
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
[node name="HangarMenu" type="Control" parent="UI" groups=["modal_menus"]]
visible = false
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Backdrop" type="ColorRect" parent="UI/HangarMenu"]
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.94)
[node name="TitleLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
offset_top = 60
offset_right = -210
offset_bottom = 170
text = "Hangar"
horizontal_alignment = 1
[node name="ListLabel" type="Label" parent="UI/HangarMenu"]
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
visible = false
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
offset_left = 32
offset_top = 200
offset_right = -32
offset_bottom = -420
theme_override_font_sizes/font_size = 30
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="StatusLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 32
offset_top = -410
offset_right = -32
offset_bottom = -300
theme_override_font_sizes/font_size = 30
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="NextButton" type="Control" parent="UI/HangarMenu"]
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
visible = false
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
anchor_left = 0.5
anchor_top = 1.0
anchor_right = 0.5
anchor_bottom = 1.0
offset_left = -230
offset_right = -110
offset_top = -280
offset_bottom = -160
script = ExtResource("10")
icon = 6
glow_color = Color(0.55, 0.95, 0.9, 1)
[node name="CrewButton" type="Control" parent="UI/HangarMenu"]
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
visible = false
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
anchor_left = 0.5
anchor_top = 1.0
anchor_right = 0.5
anchor_bottom = 1.0
offset_left = 110
offset_right = 230
offset_top = -280
offset_bottom = -160
script = ExtResource("10")
icon = 2
glow_color = Color(0.45, 0.9, 0.55, 1)
[node name="HintLabel" type="Label" parent="UI/HangarMenu"]
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
visible = false
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
mouse_filter = 2
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 24
offset_top = -150
offset_right = -24
offset_bottom = -60
theme_override_font_sizes/font_size = 28
autowrap_mode = 2
horizontal_alignment = 1
text = "Next Crew"
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
[node name="AvailableTitle" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_top = 190
offset_bottom = 240
theme_override_font_sizes/font_size = 28
text = "AVAILABLE — TAP TO CREW"
horizontal_alignment = 1
[node name="AvailableInterceptor" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_left = -290
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_right = -215
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 255
offset_bottom = 375
script = ExtResource("10")
icon = 2
[node name="AvailableInterceptorLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_left = -330
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_right = -175
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 380
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="AvailableShield" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -189
offset_right = -114
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 255
offset_bottom = 375
script = ExtResource("10")
icon = 2
glow_color = Color(0.45, 0.8, 1, 1)
[node name="AvailableShieldLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -229
offset_right = -74
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = 380
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="AvailableGasBomber" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -88
offset_right = -13
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = 255
offset_bottom = 375
script = ExtResource("10")
icon = 31
glow_color = Color(0.96, 0.32, 0.78, 1)
[node name="AvailableGasBomberLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -128
offset_right = 27
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
offset_top = 380
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="AvailableCarrier" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 13
offset_right = 88
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
offset_top = 255
offset_bottom = 375
script = ExtResource("10")
icon = 34
glow_color = Color(1, 0.78, 0.3, 1)
[node name="AvailableCarrierLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -27
offset_right = 128
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
offset_top = 380
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="AvailableLaser" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 114
offset_right = 189
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
offset_top = 255
offset_bottom = 375
script = ExtResource("10")
icon = 35
glow_color = Color(0.3, 0.9, 1, 1)
[node name="AvailableLaserLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 74
offset_right = 229
offset_top = 380
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="AvailableDistorder" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
offset_left = 215
offset_right = 290
offset_top = 255
offset_bottom = 375
script = ExtResource("10")
icon = 37
glow_color = Color(0.7, 0.3, 1, 1)
[node name="AvailableDistorderLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
offset_left = 175
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_right = 330
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 380
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="FleetTitle" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_top = 500
offset_bottom = 550
theme_override_font_sizes/font_size = 28
text = "FLEET — TAP TO STORE"
horizontal_alignment = 1
[node name="FleetInterceptor" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_left = -290
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_right = -215
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 565
offset_bottom = 685
script = ExtResource("10")
icon = 2
[node name="FleetInterceptorLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_left = -330
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_right = -175
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 690
offset_bottom = 770
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="FleetShield" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -189
offset_right = -114
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 565
offset_bottom = 685
script = ExtResource("10")
icon = 2
glow_color = Color(0.45, 0.8, 1, 1)
[node name="FleetShieldLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -229
offset_right = -74
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = 690
offset_bottom = 770
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="FleetGasBomber" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -88
offset_right = -13
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = 565
offset_bottom = 685
script = ExtResource("10")
icon = 31
glow_color = Color(0.96, 0.32, 0.78, 1)
[node name="FleetGasBomberLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -128
offset_right = 27
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
offset_top = 690
offset_bottom = 770
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="FleetCarrier" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 13
offset_right = 88
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
offset_top = 565
offset_bottom = 685
script = ExtResource("10")
icon = 34
glow_color = Color(1, 0.78, 0.3, 1)
[node name="FleetCarrierLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -27
offset_right = 128
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
offset_top = 690
offset_bottom = 770
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="FleetLaser" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 114
offset_right = 189
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
offset_top = 565
offset_bottom = 685
script = ExtResource("10")
icon = 35
glow_color = Color(0.3, 0.9, 1, 1)
[node name="FleetLaserLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 74
offset_right = 229
offset_top = 690
offset_bottom = 770
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
[node name="FleetDistorder" type="Control" parent="UI/HangarMenu"]
anchor_left = 0.5
anchor_right = 0.5
offset_left = 215
offset_right = 290
offset_top = 565
offset_bottom = 685
script = ExtResource("10")
icon = 37
glow_color = Color(0.7, 0.3, 1, 1)
[node name="FleetDistorderLabel" type="Label" parent="UI/HangarMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
offset_left = 175
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_right = 330
Improve ship crafter and hangar controls
2026-08-12 23:08:43 +02:00
offset_top = 690
offset_bottom = 770
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
[node name="CloseButton" type="Control" parent="UI/HangarMenu"]
anchor_left = 1.0
anchor_right = 1.0
offset_left = -172
offset_top = 24
offset_right = -24
offset_bottom = 172
script = ExtResource("10")
icon = 1
glow_color = Color(0.45, 0.9, 0.55, 1)
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
[node name="LabMenu" type="Control" parent="UI" groups=["modal_menus"]]
visible = false
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Backdrop" type="ColorRect" parent="UI/LabMenu"]
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.94)
[node name="TitleLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 20
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
offset_right = -200
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 82
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
text = "Ship Lab"
horizontal_alignment = 1
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
[node name="Bar" type="Control" parent="UI/LabMenu"]
mouse_filter = 2
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
anchor_right = 1.0
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
offset_left = 24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 148
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_right = -24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 284
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
script = ExtResource("24")
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
[node name="VesselA" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_left = -300
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_right = -240
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
offset_bottom = 420
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
script = ExtResource("10")
icon = 2
glow_color = Color(0.25, 0.85, 1, 1)
[node name="VesselB" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -210
offset_right = -150
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
offset_bottom = 420
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
script = ExtResource("10")
icon = 2
glow_color = Color(0.45, 0.8, 1, 1)
[node name="VesselC" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -120
offset_right = -60
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
offset_bottom = 420
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
script = ExtResource("10")
icon = 31
glow_color = Color(0.96, 0.32, 0.78, 1)
[node name="VesselD" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -30
offset_right = 30
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
offset_bottom = 420
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
script = ExtResource("10")
icon = 12
glow_color = Color(0.95, 0.55, 0.85, 1)
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
[node name="VesselE" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 60
offset_right = 120
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
offset_bottom = 420
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
script = ExtResource("10")
icon = 34
glow_color = Color(1, 0.78, 0.3, 1)
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
[node name="VesselF" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 150
offset_right = 210
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
offset_bottom = 420
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
script = ExtResource("10")
icon = 35
glow_color = Color(0.3, 0.9, 1, 1)
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
[node name="VesselG" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
offset_left = 240
offset_right = 300
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
offset_bottom = 420
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
script = ExtResource("10")
icon = 37
glow_color = Color(0.7, 0.3, 1, 1)
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
[node name="VesselLabel" type="Label" parent="UI/LabMenu"]
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
visible = false
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
offset_right = -24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 482
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
theme_override_font_sizes/font_size = 34
horizontal_alignment = 1
text = ""
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
[node name="VesselALabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_left = -310
offset_right = -230
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
offset_bottom = 496
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
theme_override_font_sizes/font_size = 15
autowrap_mode = 2
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
horizontal_alignment = 1
text = "Interceptor"
[node name="VesselBLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_left = -220
offset_right = -140
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
offset_bottom = 496
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
theme_override_font_sizes/font_size = 15
autowrap_mode = 2
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
horizontal_alignment = 1
text = "Shield"
[node name="VesselCLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_left = -130
offset_right = -50
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
offset_bottom = 496
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
theme_override_font_sizes/font_size = 15
autowrap_mode = 2
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
horizontal_alignment = 1
text = "Gas Bomber"
[node name="VesselDLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_left = -40
offset_right = 40
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
offset_bottom = 496
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
theme_override_font_sizes/font_size = 15
autowrap_mode = 2
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
horizontal_alignment = 1
text = "Transporter"
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
[node name="VesselELabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_left = 50
offset_right = 130
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
offset_bottom = 496
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
theme_override_font_sizes/font_size = 15
autowrap_mode = 2
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
horizontal_alignment = 1
text = "Carrier"
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
[node name="VesselFLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_left = 140
offset_right = 220
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
offset_bottom = 496
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
theme_override_font_sizes/font_size = 15
autowrap_mode = 2
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
horizontal_alignment = 1
text = "Laser Ship"
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
[node name="VesselGLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
offset_left = 230
offset_right = 310
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 424
offset_bottom = 496
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71) SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a 720x1280 viewport both landed in the same screen region, directly on top of each other. Properly bottom-anchored SpeedFader now, positioned above both status labels instead. Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the roster from 4 to 7 without widening their row) were laid out 120px wide on only a 90px pitch - a fixed 30px overlap between adjacent labels regardless of text length, worse for genuinely long names like "Interceptor"/"Transporter". Narrowed each label to fit its own lane with real gaps, dropped the font size, and enabled word-wrap; shifted the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
theme_override_font_sizes/font_size = 15
autowrap_mode = 2
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
horizontal_alignment = 1
text = "Distorder"
Differentiate ship lab upgrade icons
2026-08-13 20:13:32 +02:00
[node name="VesselUpgradeSeparator" type="ColorRect" parent="UI/LabMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 48
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 502
Differentiate ship lab upgrade icons
2026-08-13 20:13:32 +02:00
offset_right = -48
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 506
Differentiate ship lab upgrade icons
2026-08-13 20:13:32 +02:00
color = Color(0.25, 0.85, 1, 0.6)
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
[node name="UpgradeList" type="Label" parent="UI/LabMenu"]
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
visible = false
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
offset_left = 32
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 514
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
offset_right = -32
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = -390
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
theme_override_font_sizes/font_size = 30
autowrap_mode = 2
text = ""
[node name="DetailLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 32
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = -380
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
offset_right = -32
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = -280
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
theme_override_font_sizes/font_size = 32
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="StatusLabel" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 32
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = -274
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
offset_right = -32
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = -226
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
theme_override_font_sizes/font_size = 30
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="NextButton" type="Control" parent="UI/LabMenu"]
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
visible = false
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
anchor_left = 0.5
anchor_top = 1.0
anchor_right = 0.5
anchor_bottom = 1.0
offset_left = -230
offset_right = -110
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = -218
offset_bottom = -108
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
script = ExtResource("10")
icon = 6
glow_color = Color(0.55, 0.95, 0.9, 1)
[node name="BuyButton" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_top = 1.0
anchor_right = 0.5
anchor_bottom = 1.0
offset_left = 110
offset_right = 230
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = -218
offset_bottom = -108
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
script = ExtResource("10")
icon = 4
glow_color = Color(0.45, 0.9, 0.55, 1)
[node name="HintLabel" type="Label" parent="UI/LabMenu"]
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
visible = false
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
mouse_filter = 2
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = -102
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
offset_right = -24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = -22
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
theme_override_font_sizes/font_size = 28
autowrap_mode = 2
horizontal_alignment = 1
text = "Next upgrade Buy"
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
[node name="Upgrade0" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
offset_left = -240
offset_right = -120
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 514
offset_bottom = 624
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
script = ExtResource("10")
icon = 13
glow_color = Color(0.25, 0.85, 1, 1)
[node name="Upgrade0Label" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
offset_left = -310
offset_right = -50
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 628
offset_bottom = 698
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
theme_override_font_sizes/font_size = 22
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="Upgrade1" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
offset_left = 120
offset_right = 240
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 514
offset_bottom = 624
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
script = ExtResource("10")
icon = 13
glow_color = Color(0.25, 0.85, 1, 1)
[node name="Upgrade1Label" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
offset_left = 50
offset_right = 310
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 628
offset_bottom = 698
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
theme_override_font_sizes/font_size = 22
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="Upgrade2" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
offset_left = -240
offset_right = -120
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 706
offset_bottom = 816
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
script = ExtResource("10")
icon = 13
glow_color = Color(0.25, 0.85, 1, 1)
[node name="Upgrade2Label" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
offset_left = -310
offset_right = -50
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 820
offset_bottom = 890
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
theme_override_font_sizes/font_size = 22
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="Upgrade3" type="Control" parent="UI/LabMenu"]
anchor_left = 0.5
anchor_right = 0.5
offset_left = 120
offset_right = 240
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 706
offset_bottom = 816
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
script = ExtResource("10")
icon = 13
glow_color = Color(0.25, 0.85, 1, 1)
[node name="Upgrade3Label" type="Label" parent="UI/LabMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
offset_left = 50
offset_right = 310
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 820
offset_bottom = 890
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
theme_override_font_sizes/font_size = 22
autowrap_mode = 2
horizontal_alignment = 1
text = ""
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
[node name="CloseButton" type="Control" parent="UI/LabMenu"]
anchor_left = 1.0
anchor_right = 1.0
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_left = -140
offset_top = 20
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
offset_right = -24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 136
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
script = ExtResource("10")
icon = 1
glow_color = Color(0.55, 0.95, 0.9, 1)
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
[node name="CraftMenu" type="Control" parent="UI" groups=["modal_menus"]]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
visible = false
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Backdrop" type="ColorRect" parent="UI/CraftMenu"]
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.94)
[node name="TitleLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 20
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
offset_right = -200
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 82
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
text = "Build a ship"
horizontal_alignment = 1
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
[node name="Bar" type="Control" parent="UI/CraftMenu"]
mouse_filter = 2
offset_left = 24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 148
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
offset_right = 520
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 284
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
script = ExtResource("24")
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
[node name="StatusLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 300
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
offset_right = -200
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_bottom = 446
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
theme_override_font_sizes/font_size = 36
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
autowrap_mode = 2
text = ""
horizontal_alignment = 1
[node name="InterceptorButton" type="Control" parent="UI/CraftMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_left = -310
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_right = -245
Provision transporters with hubs
2026-08-15 00:09:10 +02:00
offset_top = -100
offset_bottom = 48
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
script = ExtResource("10")
icon = 2
[node name="InterceptorLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_left = -330
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_right = -225
Provision transporters with hubs
2026-08-15 00:09:10 +02:00
offset_top = 56
offset_bottom = 136
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
theme_override_font_sizes/font_size = 24
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
text = "Interceptor"
horizontal_alignment = 1
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
[node name="ShieldButton" type="Control" parent="UI/CraftMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -221
offset_right = -156
Provision transporters with hubs
2026-08-15 00:09:10 +02:00
offset_top = -100
offset_bottom = 48
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
script = ExtResource("10")
icon = 2
glow_color = Color(0.45, 0.8, 1, 1)
[node name="ShieldLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -241
offset_right = -136
Provision transporters with hubs
2026-08-15 00:09:10 +02:00
offset_top = 56
offset_bottom = 136
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
theme_override_font_sizes/font_size = 24
Ship Lab: per-vessel research, and the shield vessel Forgejo #5. A new building gated behind a "Vessel Science" research node. Its own screen upgrades each vessel type - weapon, movement, shield and freight - and unlocks the shield vessel, which the ship crafter can then build. Vessel research is deliberately NOT more nodes in the mothership tree: that tree gates what may be built at all and is a strategic spine, while these are repeatable tuning on vessels already owned. Levels cost base * (level + 1), so the third point in something is not the price of the first. Upgrades are read live rather than baked in at build time, so researching one improves the ships already flying. The shield is personal, not a bubble: it absorbs a hit that would destroy the vessel - ships have no health, contact kills - and is then down until it cycles. Its ring is a NeonPiece child toggled with `visible` per #10, not a redraw of the hull. The build menu now holds six entries across three rows, which the #21 repacking already handles. Enemies still have no weapon, so "blocks shots" has nothing to block yet; that is filed separately rather than widened into this ticket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
autowrap_mode = 2
text = "Shield Vessel"
horizontal_alignment = 1
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
[node name="GasBomberButton" type="Control" parent="UI/CraftMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -132
offset_right = -67
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = -100
offset_bottom = 28
script = ExtResource("10")
icon = 31
glow_color = Color(0.96, 0.32, 0.78, 1)
[node name="GasBomberLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -152
offset_right = -47
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = 56
offset_bottom = 150
theme_override_font_sizes/font_size = 24
autowrap_mode = 2
text = "Gas Bomber"
horizontal_alignment = 1
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
[node name="CarrierButton" type="Control" parent="UI/CraftMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -43
offset_right = 22
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
offset_top = -100
offset_bottom = 48
script = ExtResource("10")
icon = 34
glow_color = Color(1, 0.78, 0.3, 1)
[node name="CarrierLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = -63
offset_right = 42
Add carrier vessel (#57) An unarmed hauler with no weapon component - only VesselCargoComponent, so it structurally cannot fire, the same pattern that already made the shield vessel weaponless after #35. Its cargo_capacity (120, six interceptors' worth) makes it the first real payoff for #56's fleet hold cap. Wired into the crafter, hangar and ship lab menus, all of which were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so this repacks those three button rows to 4/4/5 columns and extends BuildController's matching onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size (3 -> 4) now that a fourth vessel is fleet-eligible.
2026-08-16 16:20:39 +02:00
offset_top = 56
offset_bottom = 136
theme_override_font_sizes/font_size = 24
autowrap_mode = 2
text = "Carrier"
horizontal_alignment = 1
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
[node name="LaserButton" type="Control" parent="UI/CraftMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 46
offset_right = 111
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
offset_top = -100
offset_bottom = 48
script = ExtResource("10")
icon = 35
glow_color = Color(0.3, 0.9, 1, 1)
[node name="LaserLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
offset_left = 26
offset_right = 131
Add laser ship vessel and its skill shot (#58) A manually aimed instant beam, modelled on the gas bomber's press-drag- release aiming (GasBombController/VesselGasBomberComponent) but firing the moment the touch releases - no projectile travel time. Damage, beam_range and cooldown are resolved per ship from base_stats/upgrades (VesselLaserComponent.apply_stats(), the same pattern VesselWeaponComponent uses) rather than hardcoded in the controller, so the new damage/range/cooldown ship-lab upgrades actually reach them. Cooldown lives on the component (per ship), not the controller (per fleet) - two laser ships give two shots, the exact bug already fixed for bombers in eb79efd. LaserController.gd is reused unmodified by both Main.tscn and PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton paths, matching GasBombController), so it works identically in space and on a landed surface. Wired into GameController's touch/drag first-refusal chain alongside the bomb controller. The crafter, hangar and ship-lab menus were already generic over VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes are hand-placed, not the logic - so this repacks those rows to 5/5/6 columns and extends BuildController's onready arrays. No new signal handlers were needed. Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth fleet-eligible vessel. Note for later tickets: a brand-new class_name script (LaserController) resolves fine as a static type when its own file is the godot -s entry point, but the identical type hint fails to parse ("Could not find type") when the script holding it is only reached indirectly - e.g. Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped Node + duck-typed calls sidesteps it; GameController.gd's laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
offset_top = 56
offset_bottom = 136
theme_override_font_sizes/font_size = 24
autowrap_mode = 2
text = "Laser Ship"
horizontal_alignment = 1
Add space-time distorder vessel and fleet speed fader (#59) GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of use - Fleet's cruise anchor and Ship's own max_speed/acceleration - rather than baked into stored stats, so a stat upgrade researched mid-boost can't corrupt the base value and the fader takes effect immediately with no re-apply step. Ship.arrive_radius is scaled by the same multiplier: at higher speeds each physics tick covers a proportionally larger step, and once that step outgrows a fixed arrive_radius the ship can overshoot its snap-to-target zone every tick while chasing a target that's now also receding faster - visible as the fleet stretching apart under boost. Scaling it preserves the same "snaps onto its slot" tightness at any boost level that 1.0x already has. SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's raw-touch idiom, not _gui_input) that writes straight to the autoload rather than reporting a value for something else to apply. It also resets the multiplier to 1.0 the instant fleet.has_capability("distorder") goes false, so a fleet can never be left permanently boosted by a vessel it no longer has. VesselDistorderComponent carries no per-shot behaviour (energy drain while boosted is #62) - its presence is what matters. Registered in VesselDefinitions, wired into the crafter/hangar/ship-lab menus per #57's note (5/5/6 -> 6/6/7 columns).
2026-08-16 17:59:04 +02:00
[node name="DistorderButton" type="Control" parent="UI/CraftMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = 135
offset_right = 200
offset_top = -100
offset_bottom = 48
script = ExtResource("10")
icon = 37
glow_color = Color(0.7, 0.3, 1, 1)
[node name="DistorderLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = 115
offset_right = 220
offset_top = 56
offset_bottom = 136
theme_override_font_sizes/font_size = 24
autowrap_mode = 2
text = "Distorder"
horizontal_alignment = 1
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
[node name="QueueLabel" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_left = 1.0
anchor_top = 0.5
anchor_right = 1.0
anchor_bottom = 0.5
offset_left = -200
offset_right = -10
offset_top = -450
offset_bottom = -390
theme_override_font_sizes/font_size = 26
autowrap_mode = 2
horizontal_alignment = 1
text = "Queue"
[node name="QueueDetail" type="Label" parent="UI/CraftMenu"]
mouse_filter = 2
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 24
offset_right = -24
offset_top = -150
offset_bottom = -30
theme_override_font_sizes/font_size = 26
autowrap_mode = 2
horizontal_alignment = 1
text = ""
[node name="QueueSlot0" type="Control" parent="UI/CraftMenu"]
visible = false
anchor_left = 1.0
anchor_top = 0.5
anchor_right = 1.0
anchor_bottom = 0.5
offset_left = -140
offset_right = -30
offset_top = -380
offset_bottom = -270
script = ExtResource("10")
icon = 2
glow_color = Color(0.25, 0.85, 1, 1)
[node name="QueueSlot1" type="Control" parent="UI/CraftMenu"]
visible = false
anchor_left = 1.0
anchor_top = 0.5
anchor_right = 1.0
anchor_bottom = 0.5
offset_left = -140
offset_right = -30
offset_top = -262
offset_bottom = -152
script = ExtResource("10")
icon = 2
glow_color = Color(0.25, 0.85, 1, 1)
[node name="QueueSlot2" type="Control" parent="UI/CraftMenu"]
visible = false
anchor_left = 1.0
anchor_top = 0.5
anchor_right = 1.0
anchor_bottom = 0.5
offset_left = -140
offset_right = -30
offset_top = -144
offset_bottom = -34
script = ExtResource("10")
icon = 2
glow_color = Color(0.25, 0.85, 1, 1)
[node name="QueueSlot3" type="Control" parent="UI/CraftMenu"]
visible = false
anchor_left = 1.0
anchor_top = 0.5
anchor_right = 1.0
anchor_bottom = 0.5
offset_left = -140
offset_right = -30
offset_top = -26
offset_bottom = 84
script = ExtResource("10")
icon = 2
glow_color = Color(0.25, 0.85, 1, 1)
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
[node name="CloseButton" type="Control" parent="UI/CraftMenu"]
anchor_left = 1.0
anchor_right = 1.0
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_left = -140
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
offset_right = -24
Recentre a released stick, slow extractors again, and unbreak the lab layout Both sticks float - the base jumps to wherever the finger lands, so a player does not have to hit an exact spot on a screen they cannot feel. Releasing put only the KNOB back onto the base and left the base parked wherever that touch had been, so an idle stick sat off-centre in a different place every time and read as a control still in use. Release now returns base and knob to the middle of the rect. Extractors produce at 0.5 ore per second, halved again: at 1.0 they still outran the rest of the economy. An extractor now pays back its 25-ore cost in fifty seconds rather than twelve. The ship lab and the crafter were both overlapping themselves. Enlarging the shared resource table to 136px (so it could breathe and show bigger type) pushed its bottom edge 34px into the vessel row beneath it in one and the status text in the other - my regression, visible immediately on a real screen and not at all in any test. The lab's second row of upgrade cards was also already running into the detail text below it, by 13px, before any of this. Both menus are re-spaced end to end rather than nudged, since moving one collision into another is how the second one got there. Two tests carried waits tuned to an extraction rate that has now changed twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass does not report a broken extractor that is working perfectly - the same fix test_extractor_income already needed one round ago, in the file next to it. Suite 112/112. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
offset_top = 20
offset_bottom = 136
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
script = ExtResource("10")
icon = 1
[node name="TransferMenu" type="Control" parent="UI" groups=["modal_menus"]]
visible = false
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Backdrop" type="ColorRect" parent="UI/TransferMenu"]
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.94)
[node name="TitleLabel" type="Label" parent="UI/TransferMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
offset_top = 36
offset_right = -200
offset_bottom = 166
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
text = "Transfer cargo"
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
horizontal_alignment = 1
Stacking distorders, menu layouts, lab rewards, enemy detail, artillery cross DISTORDER STACKING. Each space-time distorder vessel past the first raises the fleet's speed ceiling by 1.0, so a second one is worth crewing instead of being dead weight. GameState gains max_fleet_speed_multiplier, pushed by Fleet whenever composition changes - the same direction as every other fleet-derived figure, since GameState does not reach into the scene tree to count ships. The energy drain is normalised against the CURRENT ceiling, so full boost costs the same per second however wide it is: extra vessels buy more speed, not cheaper speed. Losing one re-clamps an over-ceiling boost rather than leaving the fleet travelling faster than its crew can sustain. TRANSFER MENU. Rows overlapped, and the last one ran into the hint text. row_height is divided from the available space, but each row's contents used a fixed pixel ladder - glyph at +10, buttons at +88, selector at +142 - which needs about 244px. Three resources fit; the fourth cut rows to 180 and every one spilled 64px into the next. Every offset is now a fraction of the row, so it cannot overflow. Also dropped the per-row AMOUNT caption (four copies of a word the footer hint already explains) and moved each glyph and name to the TOP of its row, where they read as its heading rather than the next row's. HANGAR. Six vessel types in one row gave each about 100px for a 155px label, so the names ran together. Now a 3x2 grid per section, sized from the space between the first heading and the status line, using the empty lower half. LAB RESEARCH REWARD. A harder enemy lab is worth more research points, and how hard a lab is depends on the layout authored for it - how many capture points, how many defenders - which the planet TYPE cannot know. PlanetSetup carries research_point_reward, set in the map editor, overriding the planet type's flat rate. 0 means "no opinion", so every map authored before this keeps its old value. RESEARCH LAB BACKGROUND. Its own shader instead of the crater field with a red tint, which read as "rocky planet, tinted" rather than someone's facility: plated floor, seams, service conduits, lit junctions. Loop-free by construction (#68's lesson applied up front) - conduits stay continuous across cells by keying a horizontal run to cell.y and a vertical to cell.x, so neighbouring cells agree without any cell scanning its neighbours. ENEMY DETAIL. Every enemy was a single flat outline, which left the artillery and the turret spawner as the same octagon at two sizes - the silhouette carried no information about what the thing did. EnemyDefinition gains detail_lines and detail_rings as DATA, so adding an enemy still means adding a definition rather than editing Enemy.gd, and the four non-default hulls are redrawn: a long-barrelled sniper, a squat mortar, a hive with launch bays, a capital ship with spine and ribs. Three things drew an enemy from its definition - the enemy, the map editor's markers, and the palette buttons - each reimplementing it from hull_points alone, so the new detail appeared in the game and nowhere else and an editor marker stopped matching what it placed. They now share EnemyDefinitions.draw_definition(). ARTILLERY. The 1.8s charge-up before the tower fired arrived long before the threat was legible and mostly read as the tower being stuck. It fires immediately now; the warning is the shell you can see in the air plus a small cross on the ground at the impact point. Deliberately not a blast-radius ring - a large translucent area was easy to read as the explosion having already happened, where the cross says "move off this spot". MAIN MENU. No Quit in any build (a web build has nothing to quit to, and Android's back gesture already does it), a plain black background, and the game is "Spaceship" - in the title and in config/name, which is what drives the browser tab for the web export. change_scene_to_file() returns an error and otherwise fails silently, leaving the menu up, which is indistinguishable from an unpressed button; it is now checked and reported on screen. Full suite green at 99/99. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 16:54:46 +02:00
vertical_alignment = 1
autowrap_mode = 2
theme_override_font_sizes/font_size = 44
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
[node name="StatusLabel" type="Label" parent="UI/TransferMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_top = 184
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
offset_right = -24
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_bottom = 284
Scale transfer UI for phones
2026-08-14 15:45:08 +02:00
theme_override_font_sizes/font_size = 32
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
autowrap_mode = 2
text = ""
horizontal_alignment = 1
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
[node name="ResourceList" type="Control" parent="UI/TransferMenu"]
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
mouse_filter = 2
anchor_right = 1.0
Scale transfer UI for phones
2026-08-14 15:45:08 +02:00
offset_left = 16
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_top = 294
Scale transfer UI for phones
2026-08-14 15:45:08 +02:00
offset_right = -16
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_bottom = 1080
script = ExtResource("27")
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
[node name="CloseButton" type="Control" parent="UI/TransferMenu"]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
anchor_left = 1.0
anchor_right = 1.0
offset_left = -172
offset_right = -24
offset_top = 24
offset_bottom = 172
script = ExtResource("10")
icon = 1
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
glow_color = Color(1, 0.78, 0.25, 1)
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
[node name="HintLabel" type="Label" parent="UI/TransferMenu"]
Support gas cargo transfers
2026-08-13 22:17:24 +02:00
mouse_filter = 2
anchor_right = 1.0
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_left = 24
offset_top = 1092
offset_right = -24
offset_bottom = 1150
Add transfer amounts and active gas vents
2026-08-14 13:44:10 +02:00
text = "Arrows move the selected amount from that side"
Support gas cargo transfers
2026-08-13 22:17:24 +02:00
horizontal_alignment = 1
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
theme_override_colors/font_color = Color(0.55, 0.7, 0.78, 1)
Scale transfer UI for phones
2026-08-14 15:45:08 +02:00
theme_override_font_sizes/font_size = 23
Support gas cargo transfers
2026-08-13 22:17:24 +02:00
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
[node name="FormationMenu" type="Control" parent="UI" groups=["modal_menus"]]
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1 A fleet of neon-outlined ships explores a procedurally generated, seeded infinite world: tap/joystick steering, pinch zoom, formation pivoting, planet landings, an ore economy with extractors and haulers, and player built structures (mothership, ship crafter, command centre). All art is hand-drawn with draw_* calls rather than textures, and the backgrounds are camera-relative shaders so they stay precise at large world coordinates. Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot tooling that renders real frames through Xvfb and Mesa softpipe, since --headless has no GPU. Excluded from version control: .godot/ (import cache, and it holds export credentials), builds/, android/build/ and packaged APKs - all regenerable, and ~325 MB combined. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
visible = false
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Backdrop" type="ColorRect" parent="UI/FormationMenu"]
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.94)
[node name="TitleLabel" type="Label" parent="UI/FormationMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24
offset_top = 70
offset_right = -24
offset_bottom = 220
theme_override_font_sizes/font_size = 44
autowrap_mode = 2
text = "Fleet formation - drag to arrange"
horizontal_alignment = 1
[node name="Editor" type="Control" parent="UI/FormationMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 0.5
anchor_bottom = 0.5
offset_left = -300
offset_right = 300
offset_top = -300
offset_bottom = 300
script = ExtResource("17")
[node name="ResetButton" type="Control" parent="UI/FormationMenu"]
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -74
offset_right = 74
offset_top = -270
offset_bottom = -122
script = ExtResource("10")
icon = 3
[node name="ResetLabel" type="Label" parent="UI/FormationMenu"]
mouse_filter = 2
anchor_left = 0.5
anchor_right = 0.5
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -180
offset_right = 180
offset_top = -114
offset_bottom = -8
theme_override_font_sizes/font_size = 60
text = "Reset"
horizontal_alignment = 1
[node name="CloseButton" type="Control" parent="UI/FormationMenu"]
anchor_left = 1.0
anchor_right = 1.0
offset_left = -172
offset_right = -24
offset_top = 24
offset_bottom = 172
script = ExtResource("10")
icon = 1
[node name="FadeOverlay" type="CanvasLayer" parent="."]
layer = 10
[node name="FadeRect" type="ColorRect" parent="FadeOverlay"]
mouse_filter = 2
anchors_preset = 15
anchor_right = 1.0
anchor_bottom = 1.0
grow_horizontal = 2
grow_vertical = 2
color = Color(0, 0, 0, 0)
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
[node name="SkillMenu" type="Control" parent="UI" groups=["modal_menus"]]
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
visible = false
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
[node name="Backdrop" type="ColorRect" parent="UI/SkillMenu"]
mouse_filter = 2
anchor_right = 1.0
anchor_bottom = 1.0
color = Color(0.03, 0.03, 0.08, 0.94)
#95: stop printing the bank twice in the research menu The research table's LOCAL column was not merely equal to BANKED, it was the same store: research lives on the mothership, the mothership is also the bank, and building_inventory() redirects any bank-capable building to bank_inventory itself. ResourceBar now drops LOCAL wherever it resolves to the bank and lets the remaining two columns share the width. Anywhere else - a crafter, a lab, the transfer panel - the column is untouched. The "Research" heading went with it. It named a panel you can only reach by pressing the research button, and it cost the tree canvas 128px, which the table and the tree have now taken back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 11:35:01 +02:00
[node name="Bar" type="Control" parent="UI/SkillMenu"]
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
mouse_filter = 2
anchor_right = 1.0
offset_left = 24.0
Sharpen fleet handling, widen the laser, and fix the map editor's file identity The fleet had a second of inertia in it: every vessel's acceleration sat at roughly its own top speed, so flipping the stick while cruising took 0.58s to take effect and let go coasted 222 units, while the formation anchor the ships chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring rather than taste - past 3x the reversal time stops improving because max_speed becomes the limit. Measured after: 0.18s and 23 units. test_fleet_agility guards all three numbers and proves the bounds discriminate by re-running the same measurement at the old value. The laser reaches 1450 instead of 950 and strikes 38 units either side instead of 22. Its drawn width is now derived from the hit width: the two were independent numbers that had drifted, so the beam killed things it visibly missed. LaserController's aim range also stopped hardcoding a second copy of 950. Tapping the laser button without dragging used to do nothing at all - the press was claimed, the aim begun, then thrown away on release. It now fires at the nearest enemy in range; dragging still aims precisely. That lives in the shared aimed-ability controller, so the gas bomb gains it too. Planets sat one per ~29 chunks - some 35,000 units of nothing between them. Now one per ~12, measured over 14,641 chunks. The two thresholds moved by different amounts deliberately: every SPACE-biome planet is a gas giant, so lowering both equally would have tripled the gas-giant share as well. This changes how often you find a planet, not what you find. Extractors produce half as fast to match, so expanding is what grows the economy. The research screen gave its tree 386px of 1280 and the text below it 520. The text is now at the bottom, the tree has 550, and the resource table has room and legible type - and its LOCAL column is no longer hidden behind the close button. Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME are not the same thing, and both save and delete rebuilt the path from the id. ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked for a file that does not exist and silently refused - which read as "the first item in the list cannot be deleted" - while saving it wrote a second file under the derived name and left the original behind, so the pool served the stale twin. A third bug hid behind those: rescan() re-read through Godot's resource cache and handed back pre-save values even when the file on disk was correct. All three present to a player as "my change was not saved". Research labs no longer grant a point of their own; what conquering one is worth comes entirely from its authored map, as asked. The shipped lab map carries 1 so the balance is unchanged - only where it is configured moved. Suite 109/109. Four tests changed because the behaviour they pinned changed: the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather than a constant tuned to one acceleration; the extractor wait derives from EXTRACTOR_RATE; the research-point test asserts the delegation; and the black hole test no longer assumes nobody will ever author a void-profile map. test_planet_setups and test_planet_map_assignment stopped depending on which maps happen to be in the content folder, which was making them fail when maps were added or deleted elsewhere. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:11 +02:00
offset_top = 20.0
offset_right = -160.0
#95: stop printing the bank twice in the research menu The research table's LOCAL column was not merely equal to BANKED, it was the same store: research lives on the mothership, the mothership is also the bank, and building_inventory() redirects any bank-capable building to bank_inventory itself. ResourceBar now drops LOCAL wherever it resolves to the bank and lets the remaining two columns share the width. Anywhere else - a crafter, a lab, the transfer panel - the column is untouched. The "Research" heading went with it. It named a panel you can only reach by pressing the research button, and it cost the tree canvas 128px, which the table and the tree have now taken back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 11:35:01 +02:00
offset_bottom = 156.0
Remove the one-way ore API superseded by the transfer menu 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>
2026-08-12 13:07:52 +02:00
script = ExtResource("24")
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
[node name="Tree" type="Control" parent="UI/SkillMenu"]
mouse_filter = 2
Make research tree vertically scrollable
2026-08-13 16:25:41 +02:00
clip_contents = true
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
anchor_right = 1.0
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
anchor_bottom = 1.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_left = 24.0
#95: stop printing the bank twice in the research menu The research table's LOCAL column was not merely equal to BANKED, it was the same store: research lives on the mothership, the mothership is also the bank, and building_inventory() redirects any bank-capable building to bank_inventory itself. ResourceBar now drops LOCAL wherever it resolves to the bank and lets the remaining two columns share the width. Anywhere else - a crafter, a lab, the transfer panel - the column is untouched. The "Research" heading went with it. It named a panel you can only reach by pressing the research button, and it cost the tree canvas 128px, which the table and the tree have now taken back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 11:35:01 +02:00
offset_top = 168.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_right = -24.0
#93: drive the research menu with a mouse, and close the hole under it Two separate faults, both reported on the same ticket. The menu was inert under a mouse. Input reaches the tree as raw events through BuildController._unhandled_input, because a Control that consumes them through the GUI system swallows the drag, and the tree only ever read touch events. That was invisible while the project set emulate_touch_from_mouse and every click arrived as a synthetic touch; with that setting gone, nothing selects and nothing scrolls, and there is no other way to research anything on a desktop. The press and the pan are now the behaviour, with touch and mouse as two ways in to them. Motion pans only while the button is held - a hovering pointer must not drag the tree out from under the reader - and the wheel scrolls, which is the first thing a desktop player reaches for. The panel also still had the buy button's hole in it. That button went away in #83 and nothing moved down into the space, leaving ~180px of dead panel below the readout while the tree above it stayed cramped. The readout moves down 154px and the canvas takes the height: 1190px to 1344px. The test drives clicks through BuildController rather than into the view, since the missing piece was the routing - calling the view directly would have passed against the bug as reported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
offset_bottom = -280.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
script = ExtResource("21")
[node name="DetailLabel" type="Label" parent="UI/SkillMenu"]
mouse_filter = 2
anchor_right = 1.0
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
anchor_top = 1.0
anchor_bottom = 1.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_left = 32.0
#93: drive the research menu with a mouse, and close the hole under it Two separate faults, both reported on the same ticket. The menu was inert under a mouse. Input reaches the tree as raw events through BuildController._unhandled_input, because a Control that consumes them through the GUI system swallows the drag, and the tree only ever read touch events. That was invisible while the project set emulate_touch_from_mouse and every click arrived as a synthetic touch; with that setting gone, nothing selects and nothing scrolls, and there is no other way to research anything on a desktop. The press and the pan are now the behaviour, with touch and mouse as two ways in to them. Motion pans only while the button is held - a hovering pointer must not drag the tree out from under the reader - and the wheel scrolls, which is the first thing a desktop player reaches for. The panel also still had the buy button's hole in it. That button went away in #83 and nothing moved down into the space, leaving ~180px of dead panel below the readout while the tree above it stayed cramped. The readout moves down 154px and the canvas takes the height: 1190px to 1344px. The test drives clicks through BuildController rather than into the view, since the missing piece was the routing - calling the view directly would have passed against the bug as reported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
offset_top = -272.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_right = -32.0
#93: drive the research menu with a mouse, and close the hole under it Two separate faults, both reported on the same ticket. The menu was inert under a mouse. Input reaches the tree as raw events through BuildController._unhandled_input, because a Control that consumes them through the GUI system swallows the drag, and the tree only ever read touch events. That was invisible while the project set emulate_touch_from_mouse and every click arrived as a synthetic touch; with that setting gone, nothing selects and nothing scrolls, and there is no other way to research anything on a desktop. The press and the pan are now the behaviour, with touch and mouse as two ways in to them. Motion pans only while the button is held - a hovering pointer must not drag the tree out from under the reader - and the wheel scrolls, which is the first thing a desktop player reaches for. The panel also still had the buy button's hole in it. That button went away in #83 and nothing moved down into the space, leaving ~180px of dead panel below the readout while the tree above it stayed cramped. The readout moves down 154px and the canvas takes the height: 1190px to 1344px. The test drives clicks through BuildController rather than into the view, since the missing piece was the routing - calling the view directly would have passed against the bug as reported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
offset_bottom = -152.0
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
theme_override_font_sizes/font_size = 34
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
autowrap_mode = 2
horizontal_alignment = 1
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
text = ""
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
[node name="CostNumber" type="Control" parent="UI/SkillMenu"]
mouse_filter = 2
anchor_left = 0.5
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
anchor_top = 1.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
anchor_right = 0.5
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
anchor_bottom = 1.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_left = -64.0
#93: drive the research menu with a mouse, and close the hole under it Two separate faults, both reported on the same ticket. The menu was inert under a mouse. Input reaches the tree as raw events through BuildController._unhandled_input, because a Control that consumes them through the GUI system swallows the drag, and the tree only ever read touch events. That was invisible while the project set emulate_touch_from_mouse and every click arrived as a synthetic touch; with that setting gone, nothing selects and nothing scrolls, and there is no other way to research anything on a desktop. The press and the pan are now the behaviour, with touch and mouse as two ways in to them. Motion pans only while the button is held - a hovering pointer must not drag the tree out from under the reader - and the wheel scrolls, which is the first thing a desktop player reaches for. The panel also still had the buy button's hole in it. That button went away in #83 and nothing moved down into the space, leaving ~180px of dead panel below the readout while the tree above it stayed cramped. The readout moves down 154px and the canvas takes the height: 1190px to 1344px. The test drives clicks through BuildController rather than into the view, since the missing piece was the routing - calling the view directly would have passed against the bug as reported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
offset_top = -146.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_right = 76.0
#93: drive the research menu with a mouse, and close the hole under it Two separate faults, both reported on the same ticket. The menu was inert under a mouse. Input reaches the tree as raw events through BuildController._unhandled_input, because a Control that consumes them through the GUI system swallows the drag, and the tree only ever read touch events. That was invisible while the project set emulate_touch_from_mouse and every click arrived as a synthetic touch; with that setting gone, nothing selects and nothing scrolls, and there is no other way to research anything on a desktop. The press and the pan are now the behaviour, with touch and mouse as two ways in to them. Motion pans only while the button is held - a hovering pointer must not drag the tree out from under the reader - and the wheel scrolls, which is the first thing a desktop player reaches for. The panel also still had the buy button's hole in it. That button went away in #83 and nothing moved down into the space, leaving ~180px of dead panel below the readout while the tree above it stayed cramped. The readout moves down 154px and the canvas takes the height: 1190px to 1344px. The test drives clicks through BuildController rather than into the view, since the missing piece was the routing - calling the view directly would have passed against the bug as reported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
offset_bottom = -82.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
script = ExtResource("19")
digit_height = 52.0
[node name="StatusLabel" type="Label" parent="UI/SkillMenu"]
mouse_filter = 2
anchor_right = 1.0
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
anchor_top = 1.0
anchor_bottom = 1.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_left = 32.0
#93: drive the research menu with a mouse, and close the hole under it Two separate faults, both reported on the same ticket. The menu was inert under a mouse. Input reaches the tree as raw events through BuildController._unhandled_input, because a Control that consumes them through the GUI system swallows the drag, and the tree only ever read touch events. That was invisible while the project set emulate_touch_from_mouse and every click arrived as a synthetic touch; with that setting gone, nothing selects and nothing scrolls, and there is no other way to research anything on a desktop. The press and the pan are now the behaviour, with touch and mouse as two ways in to them. Motion pans only while the button is held - a hovering pointer must not drag the tree out from under the reader - and the wheel scrolls, which is the first thing a desktop player reaches for. The panel also still had the buy button's hole in it. That button went away in #83 and nothing moved down into the space, leaving ~180px of dead panel below the readout while the tree above it stayed cramped. The readout moves down 154px and the canvas takes the height: 1190px to 1344px. The test drives clicks through BuildController rather than into the view, since the missing piece was the routing - calling the view directly would have passed against the bug as reported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
offset_top = -76.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_right = -32.0
#93: drive the research menu with a mouse, and close the hole under it Two separate faults, both reported on the same ticket. The menu was inert under a mouse. Input reaches the tree as raw events through BuildController._unhandled_input, because a Control that consumes them through the GUI system swallows the drag, and the tree only ever read touch events. That was invisible while the project set emulate_touch_from_mouse and every click arrived as a synthetic touch; with that setting gone, nothing selects and nothing scrolls, and there is no other way to research anything on a desktop. The press and the pan are now the behaviour, with touch and mouse as two ways in to them. Motion pans only while the button is held - a hovering pointer must not drag the tree out from under the reader - and the wheel scrolls, which is the first thing a desktop player reaches for. The panel also still had the buy button's hole in it. That button went away in #83 and nothing moved down into the space, leaving ~180px of dead panel below the readout while the tree above it stayed cramped. The readout moves down 154px and the canvas takes the height: 1190px to 1344px. The test drives clicks through BuildController rather than into the view, since the missing piece was the routing - calling the view directly would have passed against the bug as reported. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
offset_bottom = -24.0
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
theme_override_font_sizes/font_size = 32
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
autowrap_mode = 2
horizontal_alignment = 1
Block input behind open panels; keep craft-menu messages on screen 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>
2026-08-11 20:17:58 +02:00
text = ""
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
[node name="CloseButton" type="Control" parent="UI/SkillMenu"]
anchor_left = 1.0
anchor_right = 1.0
Sharpen fleet handling, widen the laser, and fix the map editor's file identity The fleet had a second of inertia in it: every vessel's acceleration sat at roughly its own top speed, so flipping the stick while cruising took 0.58s to take effect and let go coasted 222 units, while the formation anchor the ships chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring rather than taste - past 3x the reversal time stops improving because max_speed becomes the limit. Measured after: 0.18s and 23 units. test_fleet_agility guards all three numbers and proves the bounds discriminate by re-running the same measurement at the old value. The laser reaches 1450 instead of 950 and strikes 38 units either side instead of 22. Its drawn width is now derived from the hit width: the two were independent numbers that had drifted, so the beam killed things it visibly missed. LaserController's aim range also stopped hardcoding a second copy of 950. Tapping the laser button without dragging used to do nothing at all - the press was claimed, the aim begun, then thrown away on release. It now fires at the nearest enemy in range; dragging still aims precisely. That lives in the shared aimed-ability controller, so the gas bomb gains it too. Planets sat one per ~29 chunks - some 35,000 units of nothing between them. Now one per ~12, measured over 14,641 chunks. The two thresholds moved by different amounts deliberately: every SPACE-biome planet is a gas giant, so lowering both equally would have tripled the gas-giant share as well. This changes how often you find a planet, not what you find. Extractors produce half as fast to match, so expanding is what grows the economy. The research screen gave its tree 386px of 1280 and the text below it 520. The text is now at the bottom, the tree has 550, and the resource table has room and legible type - and its LOCAL column is no longer hidden behind the close button. Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME are not the same thing, and both save and delete rebuilt the path from the id. ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked for a file that does not exist and silently refused - which read as "the first item in the list cannot be deleted" - while saving it wrote a second file under the derived name and left the original behind, so the pool served the stale twin. A third bug hid behind those: rescan() re-read through Godot's resource cache and handed back pre-save values even when the file on disk was correct. All three present to a player as "my change was not saved". Research labs no longer grant a point of their own; what conquering one is worth comes entirely from its authored map, as asked. The shipped lab map carries 1 so the balance is unchanged - only where it is configured moved. Suite 109/109. Four tests changed because the behaviour they pinned changed: the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather than a constant tuned to one acceleration; the extractor wait derives from EXTRACTOR_RATE; the research-point test asserts the delegation; and the black hole test no longer assumes nobody will ever author a void-profile map. test_planet_setups and test_planet_map_assignment stopped depending on which maps happen to be in the content folder, which was making them fail when maps were added or deleted elsewhere. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:11 +02:00
offset_left = -140.0
offset_top = 20.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
offset_right = -24.0
Sharpen fleet handling, widen the laser, and fix the map editor's file identity The fleet had a second of inertia in it: every vessel's acceleration sat at roughly its own top speed, so flipping the stick while cruising took 0.58s to take effect and let go coasted 222 units, while the formation anchor the ships chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring rather than taste - past 3x the reversal time stops improving because max_speed becomes the limit. Measured after: 0.18s and 23 units. test_fleet_agility guards all three numbers and proves the bounds discriminate by re-running the same measurement at the old value. The laser reaches 1450 instead of 950 and strikes 38 units either side instead of 22. Its drawn width is now derived from the hit width: the two were independent numbers that had drifted, so the beam killed things it visibly missed. LaserController's aim range also stopped hardcoding a second copy of 950. Tapping the laser button without dragging used to do nothing at all - the press was claimed, the aim begun, then thrown away on release. It now fires at the nearest enemy in range; dragging still aims precisely. That lives in the shared aimed-ability controller, so the gas bomb gains it too. Planets sat one per ~29 chunks - some 35,000 units of nothing between them. Now one per ~12, measured over 14,641 chunks. The two thresholds moved by different amounts deliberately: every SPACE-biome planet is a gas giant, so lowering both equally would have tripled the gas-giant share as well. This changes how often you find a planet, not what you find. Extractors produce half as fast to match, so expanding is what grows the economy. The research screen gave its tree 386px of 1280 and the text below it 520. The text is now at the bottom, the tree has 550, and the resource table has room and legible type - and its LOCAL column is no longer hidden behind the close button. Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME are not the same thing, and both save and delete rebuilt the path from the id. ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked for a file that does not exist and silently refused - which read as "the first item in the list cannot be deleted" - while saving it wrote a second file under the derived name and left the original behind, so the pool served the stale twin. A third bug hid behind those: rescan() re-read through Godot's resource cache and handed back pre-save values even when the file on disk was correct. All three present to a player as "my change was not saved". Research labs no longer grant a point of their own; what conquering one is worth comes entirely from its authored map, as asked. The shipped lab map carries 1 so the balance is unchanged - only where it is configured moved. Suite 109/109. Four tests changed because the behaviour they pinned changed: the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather than a constant tuned to one acceleration; the extractor wait derives from EXTRACTOR_RATE; the research-point test asserts the delegation; and the black hole test no longer assumes nobody will ever author a void-profile map. test_planet_setups and test_planet_map_assignment stopped depending on which maps happen to be in the content folder, which was making them fail when maps were added or deleted elsewhere. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:11 +02:00
offset_bottom = 136.0
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite Gameplay and UI - Research tree at the mothership gates which structures can be built and grants permanent fleet-capacity upgrades (GameState.SKILL_TREE, SkillTreeView). Node depth is derived from prerequisites, so the layout cannot drift out of step with the dependencies. - Building info popup before committing to a build, with per-building cost and description. - Ship crafter redrawn as a space factory with an assembly animation; mothership redrawn as a radial flagship; command centre as a plotting hub. - Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build. - UI and font scaled up for phone use, via a custom Theme resource - gui/theme/default_font_size does not reach the default theme. - Asteroids no longer spawn on top of the fleet's start position. - Fleet formation origin derived from the layout's own offsets rather than the centroid, fixing the lurch when a lopsided formation started moving. - Fleet.stop() brakes from the ship's TRUE motion (velocity + fleet_velocity). Ship zeroes its velocity when seated in its slot even while the anchor drags that slot forward, so braking from velocity alone stopped the fleet dead instead of coasting - and whether it did depended on the frame rate. Animation architecture (issue #10) - Buildings, projectiles and explosion VFX no longer animate by redrawing. Static geometry is rasterised once in _draw(); moving parts are NeonPiece children animated through node properties, which reuse the cached geometry. Every NeonDraw call expands into four antialiased polylines, so redrawing to move something re-tessellated all of it. Test suite (issue #8): 1075s -> ~55s - Runs from a copy on Termux's own filesystem. The project lives on Android's FUSE bridge, read through proot, where load("res://Main.tscn") alone cost 8.5s per test against ~2s natively - and nearly every test loads it. - Runs 6 tests at a time, in a single proot-distro login, with output buffered per test and printed only on failure. - --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's result no longer depends on how busy the machine is. Without it, parallelism made two tests fail on 2 of 3 runs. - A test passes only if it both exits 0 and prints ": PASS". - 38 tests, green on three consecutive runs. Bundles Carrois Gothic SC (Apache 2.0) with its licence text. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
script = ExtResource("10")
icon = 1
glow_color = Color(0.55, 0.6, 1, 1)
Reference in a new issue Copy permalink