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

2115 lines
48 KiB
Text
Raw Normal View History

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
[gd_scene load_steps=29 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
[ext_resource type="Script" path="res://Starfield.gd" id="1"]
[ext_resource type="Script" path="res://Fleet.gd" id="2"]
[ext_resource type="Script" path="res://GameController.gd" id="3"]
[ext_resource type="Script" path="res://EnemySpawner.gd" id="4"]
[ext_resource type="Shader" path="res://starfield.gdshader" id="5"]
[ext_resource type="Script" path="res://ExplorationTracker.gd" id="6"]
[ext_resource type="Script" path="res://AsteroidField.gd" id="7"]
[ext_resource type="Script" path="res://WorldMap.gd" id="8"]
[ext_resource type="Script" path="res://WorldMapContent.gd" id="9"]
[ext_resource type="Script" path="res://IconButton.gd" id="10"]
[ext_resource type="Script" path="res://PlanetField.gd" id="11"]
[ext_resource type="Script" path="res://PlanetAtmosphereController.gd" id="12"]
[ext_resource type="Script" path="res://TouchJoystick.gd" id="13"]
[ext_resource type="Script" path="res://BuildingField.gd" id="14"]
[ext_resource type="Script" path="res://BuildController.gd" id="15"]
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
[ext_resource type="Script" path="res://ResourceReadout.gd" id="16"]
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
[ext_resource type="Script" path="res://FormationEditor.gd" id="17"]
[ext_resource type="Script" path="res://NeonNumber.gd" id="19"]
[ext_resource type="Script" path="res://NeonPanel.gd" id="20"]
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
[ext_resource type="Script" path="res://SkillTreeView.gd" id="21"]
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
[ext_resource type="Script" path="res://TransporterField.gd" id="23"]
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
[ext_resource type="Script" path="res://ResourceBar.gd" id="24"]
Animate ship crafter deliveries
2026-08-13 21:39:05 +02:00
[ext_resource type="Script" path="res://VesselDeliveryField.gd" id="26"]
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
[ext_resource type="Script" path="res://ResourceTransferList.gd" id="27"]
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
[ext_resource type="Script" path="res://GasBombController.gd" id="29"]
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
[ext_resource type="Script" path="res://LaserController.gd" id="30"]
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
[ext_resource type="Script" path="res://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")
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
[node name="KeyboardHintLabel" type="Label" parent="UI"]
visible = false
mouse_filter = 2
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 28
offset_right = 360
offset_top = -300
offset_bottom = -120
theme_override_font_sizes/font_size = 36
autowrap_mode = 2
text = "WASD / arrows move Q / E pivot wheel zoom"
[node name="Joystick" type="Control" parent="UI"]
mouse_filter = 2
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = 24
offset_right = 424
offset_top = -424
offset_bottom = -24
script = ExtResource("13")
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
offset_left = -94
offset_right = -24
offset_top = 740
offset_bottom = 920
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
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -344
offset_right = -196
offset_top = -344
offset_bottom = -196
script = ExtResource("10")
icon = 36
glow_color = Color(0.3, 0.9, 1, 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="PivotCCWButton" type="Control" parent="UI"]
mouse_filter = 2
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -344
offset_right = -196
offset_top = -172
offset_bottom = -24
script = ExtResource("10")
icon = 7
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
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -172
offset_right = -24
offset_top = -344
offset_bottom = -196
script = ExtResource("10")
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
[node name="GasBombStatus" type="Label" parent="UI"]
mouse_filter = 2
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -344
offset_right = -24
offset_top = -480
offset_bottom = -430
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 = ""
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="PivotCWButton" type="Control" parent="UI"]
mouse_filter = 2
anchor_left = 1.0
anchor_right = 1.0
anchor_top = 1.0
anchor_bottom = 1.0
offset_left = -172
offset_right = -24
offset_top = -172
offset_bottom = -24
script = ExtResource("10")
icon = 6
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
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_top = 36
offset_right = -200
offset_bottom = 166
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
offset_top = 180
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_right = -24
offset_bottom = 264
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
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_top = 274
offset_bottom = 394
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
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_top = 274
offset_bottom = 394
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
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = 274
offset_bottom = 394
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
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_top = 274
offset_bottom = 394
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
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 = 274
offset_bottom = 394
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
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 = 274
offset_bottom = 394
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
offset_top = 274
offset_bottom = 394
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
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_top = 402
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
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_bottom = 460
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
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 = -210
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_top = 400
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
text = "Interceptor"
[node name="VesselBLabel" type="Label" parent="UI/LabMenu"]
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 = -240
offset_right = -120
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
offset_top = 400
offset_bottom = 460
theme_override_font_sizes/font_size = 22
horizontal_alignment = 1
text = "Shield"
[node name="VesselCLabel" type="Label" parent="UI/LabMenu"]
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 = -150
offset_right = -30
Add gas bomber skill-shot vessel
2026-08-15 04:45:15 +02:00
offset_top = 400
offset_bottom = 460
theme_override_font_sizes/font_size = 22
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
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 = 60
Improve ship lab upgrade selection
2026-08-13 16:45:08 +02:00
offset_top = 400
offset_bottom = 460
theme_override_font_sizes/font_size = 22
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
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 = 150
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 = 400
offset_bottom = 460
theme_override_font_sizes/font_size = 22
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
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 = 240
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 = 400
offset_bottom = 460
theme_override_font_sizes/font_size = 22
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
offset_left = 210
offset_right = 330
offset_top = 400
offset_bottom = 460
theme_override_font_sizes/font_size = 22
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
offset_top = 462
offset_right = -48
offset_bottom = 466
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
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_top = 470
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
offset_bottom = -470
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
offset_top = -460
offset_right = -32
offset_bottom = -330
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
offset_top = -324
offset_right = -32
offset_bottom = -256
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
offset_top = -240
offset_bottom = -120
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
offset_top = -240
offset_bottom = -120
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
offset_top = -110
offset_right = -24
offset_bottom = -20
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
offset_top = 470
offset_bottom = 580
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
offset_top = 585
offset_bottom = 655
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
offset_top = 470
offset_bottom = 580
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
offset_top = 585
offset_bottom = 655
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
offset_top = 660
offset_bottom = 765
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
offset_top = 770
offset_bottom = 815
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
offset_top = 660
offset_bottom = 765
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
offset_top = 770
offset_bottom = 815
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
offset_left = -172
offset_top = 24
offset_right = -24
offset_bottom = 172
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
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_top = 36
offset_right = -200
offset_bottom = 166
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
offset_top = 180
offset_right = 520
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_bottom = 264
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
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_top = 274
Add timed craft queue and hangar
2026-08-12 22:47:46 +02:00
offset_right = -200
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_bottom = 420
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
offset_left = -172
offset_right = -24
offset_top = 24
offset_bottom = 172
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
[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)
[node name="TitleLabel" type="Label" parent="UI/SkillMenu"]
mouse_filter = 2
anchor_right = 1.0
offset_left = 24.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_top = 36.0
offset_right = -200.0
offset_bottom = 166.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
text = "Research"
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/SkillMenu"]
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.0
offset_top = 180.0
Refactor multi-resource UI and transfers
2026-08-14 11:54:31 +02:00
offset_right = -24.0
offset_bottom = 264.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
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_top = 274.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
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
offset_bottom = -620.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
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
offset_top = -610.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
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
offset_bottom = -462.0
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
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
offset_top = -456.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
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
offset_bottom = -392.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
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
offset_top = -386.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
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
offset_bottom = -318.0
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="UnlockButton" type="Control" parent="UI/SkillMenu"]
anchor_left = 0.5
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
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
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
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 = -74.0
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
offset_top = -304.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 = 74.0
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
offset_bottom = -156.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 = 5
glow_color = Color(0.45, 0.9, 0.55, 1)
[node name="CloseButton" type="Control" parent="UI/SkillMenu"]
anchor_left = 1.0
anchor_right = 1.0
offset_left = -172.0
offset_top = 24.0
offset_right = -24.0
offset_bottom = 172.0
script = ExtResource("10")
icon = 1
glow_color = Color(0.55, 0.6, 1, 1)
Reference in a new issue Copy permalink