Implement #80, #81, #82 and #83
#80 - desktop combat. The mouse aims, the left button fires, and the number
keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin
sticks are built for thumbs; on a desktop they mean dragging a virtual stick
with a pointer that could simply BE the crosshair.
The pointer path hands its heading to FireStickController rather than driving
weapons itself, so exactly one thing in the scene aims a gun, and a held stick
wins - a finger on it is a deliberate act, a mouse resting somewhere is not.
Abilities gained fire_at(), which aims and fires in one call instead of
pretending to be a press-drag-release touch.
It is gated on the absence of a touchscreen, because Godot emulates a mouse
button from every touch and without that a tap on a phone would fire the guns.
The gate has an explicit override, and not for tidiness: headless reports a
touchscreen, so with the automatic answer alone the aiming could never be
exercised by a test and the only covered behaviour would be the guard.
#81 - the bottom-left control hint is gone, from both scenes and from
GameController.
#82 - a chaser is destroyed by the impact when it reaches a vessel. It used to
pass through the wreck untouched and line up another pass, which made a
ramming enemy strictly better than any other. Data-driven per enemy
(dies_on_contact), because a sniper that happens to drift into a ship has not
spent itself doing it - and routed through take_damage, so it dies exactly as
it dies to gunfire. The enemy is told about the impact BEFORE the ship
resolves its own damage, since resolving it can free the ship.
#83 - the research tree's buy button is gone; tapping a node twice buys it.
Deliberately "the same node twice" rather than a timed double-tap: no window
to miss on a slow phone, no accidental purchase while browsing, and the first
tap always does something visible, so the second is never a blind commitment.
The status line now says "Tap again to research" - with the button gone it is
the only thing distinguishing an affordable node from an unaffordable one.
test_enemy_collision asserted the exact behaviour #82 reversed, and now checks
the ram costs both. Suite 117/117.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
|
|
|
[gd_scene load_steps=31 format=3]
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
|
#84: move 215 root files into a folder hierarchy
Everything lived in one flat directory, so a diff gave no clue what area it
touched and finding the file you wanted meant knowing its exact name. Twelve
folders now, grouped by what a thing IS rather than what type it is - a
vessel's definition, its component scenes and its upgrade resources sit
together, because that is the set you read when you change one of them.
buildings core controllers enemies logistics planets
resources shaders surface ui vessels vfx world
332 files moved and every res:// reference rewritten - 306 files touched,
including the autoload and main-scene paths in project.godot. Nothing renamed:
this is purely where files sit, so the diff is a pile of pure moves and no
behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at
the root, where Godot and the export preset expect them.
Verified three ways, because a suite alone would not have caught all of it:
the full 117 pass, the web export builds clean, and the game renders.
The export is why that matters. The FIRST export after the move failed with
"Attempt to open script 'res://GameState.gd'" - the old path - while
project.godot on disk plainly said res://core/GameState.gd. That is this
project's documented Android FUSE mtime trap: Godot served a cached copy of a
file whose content had changed. A `touch` fixed it. Nothing in the test suite
would have found that, because the suite runs from a copy on a native
filesystem - the one place the bug cannot happen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
|
|
|
[ext_resource type="Script" path="res://world/Starfield.gd" id="1"]
|
|
|
|
|
[ext_resource type="Script" path="res://vessels/Fleet.gd" id="2"]
|
|
|
|
|
[ext_resource type="Script" path="res://controllers/GameController.gd" id="3"]
|
|
|
|
|
[ext_resource type="Script" path="res://enemies/EnemySpawner.gd" id="4"]
|
|
|
|
|
[ext_resource type="Shader" path="res://shaders/starfield.gdshader" id="5"]
|
|
|
|
|
[ext_resource type="Script" path="res://world/ExplorationTracker.gd" id="6"]
|
|
|
|
|
[ext_resource type="Script" path="res://world/AsteroidField.gd" id="7"]
|
|
|
|
|
[ext_resource type="Script" path="res://world/WorldMap.gd" id="8"]
|
|
|
|
|
[ext_resource type="Script" path="res://world/WorldMapContent.gd" id="9"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/IconButton.gd" id="10"]
|
|
|
|
|
[ext_resource type="Script" path="res://planets/PlanetField.gd" id="11"]
|
|
|
|
|
[ext_resource type="Script" path="res://planets/PlanetAtmosphereController.gd" id="12"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/TouchJoystick.gd" id="13"]
|
|
|
|
|
[ext_resource type="Script" path="res://buildings/BuildingField.gd" id="14"]
|
|
|
|
|
[ext_resource type="Script" path="res://controllers/BuildController.gd" id="15"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/ResourceReadout.gd" id="16"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/FormationEditor.gd" id="17"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/NeonNumber.gd" id="19"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/NeonPanel.gd" id="20"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/SkillTreeView.gd" id="21"]
|
#100 (#97b): waves replace the roaming enemy spawner
The old spawner put one enemy on the map every 3-6 seconds for ever. There
was no rhythm to the danger and nothing to prepare for. Enemies now arrive
in waves: a long quiet, a warning, an attack, and quiet again once the wave
is dead.
The clock lives in GameState, because Main.tscn is destroyed on every trip
to a planet surface and a wave must not be cancelled, nor restarted from
zero, by a landing. The spawning does not: GameState cannot see the world,
so EnemySpawner reads the phase and puts the enemies in it. That also
settles what happens when a wave turns while the player is on a surface -
the wave is waiting in space when they come back.
EnemySpawner keeps its name deliberately. It is still the thing that puts
enemies in the world, and 88 test files already say
`get_node("EnemySpawner").set_process(false)` to ask for a quiet map.
Strength is a function of the FLEET, per the ticket, with the wave number as
a slower second term so a player who never grows still meets escalation. The
budget is spent most-expensive-first, so a large wave is heavier rather than
merely longer, and min_strength keeps the first waves to chasers whatever
the arithmetic says.
"No timer should be visible" is enforced rather than merely observed:
GameState offers wave_warning_pulse(), a 0..1 throb, and no
remaining-seconds accessor at all, so the alert cannot drift into being a
countdown. The test pins both - that no such accessor exists, and that the
alert's own text contains no digits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 13:37:42 +02:00
|
|
|
[ext_resource type="Script" path="res://ui/WaveAlert.gd" id="32"]
|
#102/#103 (#97d/#97e): the outpost, and the garrison you compose for it
Landed together because an outpost you cannot crew is decoration, and a
garrison menu with no building to hang it off is nothing at all.
#102, the building. Researched at "Forward Bases", two prerequisites deep
and cheaper than any mid-game structure - the ticket asks for early, and the
answer to waves attacking your buildings should arrive at about the time the
waves can hurt them. It is drawn as a watch mast on a tripod with two open
berths, deliberately the least machinery of any structure here: it makes
nothing and refines nothing, it holds a position. 120hp, more than a
crafter, because being shot at is its job.
#103, the garrison. Two separate things live on its record, and conflating
them was the first thing to get wrong: the ORDER, what the player asked for,
and the CREW, who is actually there. This menu edits the order only; #104
fills the crew. Keeping the order as a wish is what lets an outpost ask for
a hull nobody has built yet and wait for it, rather than the request
evaporating - and it is why the panel shows "here / ordered" instead of one
number.
"Only ships that attack can be assigned" is expressed as capabilities rather
than a list of types, so a new armed vessel is eligible the day it is added
and an unarmed one never is by accident. Today that means the interceptor
and the laser vessel; a shield, a hauler and an engine block cannot hold a
position however much one might want them to.
Two berths by default, and Garrison Bays raises it at outposts ALREADY
standing - the same shape as freight_yards for hubs, because a bonus that
only reached new buildings would mean demolishing and rebuilding to collect
it.
The panel builds its own rows from the catalog rather than from nodes placed
in the scene, so adding an armed vessel later needs no scene surgery.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:02:20 +02:00
|
|
|
[ext_resource type="Script" path="res://ui/GarrisonPanel.gd" id="33"]
|
#105 (#97g): garrison vessels patrol and defend their outpost
A garrisoned vessel circles its post, engages what comes into range, and
goes back to circling. It steers by writing move_target and lets Ship's own
steering fly it, so it accelerates, banks and brakes exactly like a vessel
in the formation.
It is not in Fleet.ships. It does not follow the formation, does not count
against max_fleet_size(), and does not move when the player flies away -
which is the whole point of stationing it. A garrison that ate a fleet slot
would mean stationing a vessel cost the player a place in their own wedge.
The leash is the load-bearing part. Enemies are judged from the POST rather
than from the vessel, so a garrison that has drifted out to its leash cannot
see further still and be walked away from its outpost one enemy at a time,
and an engagement is clamped to a circle around the post rather than to a
straight line, so it still manoeuvres while pinned.
The orbit starts from where the vessel actually is rather than a random
bearing. A random one makes the first move_target a point on the far side of
the circle, and the vessel flies straight across the middle - through the
outpost it is guarding.
EnemyTargets.nearest_ship now searches the player_ships GROUP instead of
Fleet.ships: an enemy that ignored the guns shooting at it, because they
were not in the player's formation, would let a garrison hold a position
without ever being fought back.
The laser vessel is deliberately not garrisonable. Firing the laser lives in
LaserController, a fleet ability driven by the laser button, rather than in
VesselLaserComponent - so a garrisoned laser would hold its position and
never shoot, and offering a vessel that cannot fight is worse than a short
list.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:13:47 +02:00
|
|
|
[ext_resource type="Script" path="res://vessels/GarrisonField.gd" id="34"]
|
#106/#107 (#98a/#98b): the Planning Center
Landed together: a board of standing orders nothing acts on is a notepad,
and a planner with nowhere to read the plan from has nothing to do.
The targets are GLOBAL, not per building. There is one plan for the whole
game, and a second planning centre is another place to read and edit it
rather than a competing one - per-building targets would let two centres
hold contradictory orders and tell the crafters to satisfy both.
The census is the harder half. Every vessel is counted exactly once wherever
it happens to be: flying in the fleet, parked in the hangar, stationed at an
outpost, or in the air between any two of those. Miss the in-flight ones and
the planner queues a replacement for a vessel that is merely en route. The
fleet is the one place GameState cannot see, so Fleet pushes its composition
on every change, alongside the cargo capacity and distorder count that
already went that way.
Three rules keep the planner from fighting the player. It tops up and never
rewrites, so an order placed by hand stays exactly where it is. Everything
counts, including what is already queued, or it re-queues the same shortfall
every tick and buries the player in hulls. And nothing happens without a
planning centre - though the plan is remembered when one is destroyed, so
rebuilding picks up where it left off.
Vessels on order are counted separately from the census on purpose: they do
not exist yet, so the readout can say "4 of 6, 2 building" rather than
claiming six. The per-row note says where the vessels actually are, because
a plan can look unmet while everything it asked for is sitting at an
outpost.
The build menu goes to three columns past eight entries. #54 already
tightened its rows to 223px to fit a fourth, explicitly to avoid a
scrollable menu, and a ninth structure needs a fifth row that will not fit
at any spacing a button, a label and a cost can share. Three columns take
nine into three rows - fewer than it uses today, not more.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:21:52 +02:00
|
|
|
[ext_resource type="Script" path="res://ui/PlanningPanel.gd" id="35"]
|
#108: the prologue - the convoy, the ambush, and the breach
Landed as one piece across #122, #123 and #124: the frame is useless without
a script, and the script has nowhere to run without the frame.
The director drives the REAL scene rather than being a scene of its own. It
wants the real fleet, the real enemies and the real asteroid field, and it
makes "then the game starts" cost nothing - the director stops steering,
clears the flag, and what is left running is the ordinary game.
The script is a list of beats, each with a deadline as well as its own
completion test, so a beat whose condition is never met - a player who
refuses to fly at the ambush - runs out rather than wedging the prologue.
skip() ends the whole thing at any point and lands in exactly the state
playing it through does, so the game has one way to start rather than two
that have to be kept in step. The test pins that equivalence.
"No action button available, only movements" is enforced where the buttons
are decided, not by the director reaching in: the ability controllers set
their own visibility every frame and would have put them straight back, and
the map button belongs to the map. The joystick, the pivot and the fader
stay.
The convoy is ten hulls where a new game's fleet is one, so it needs an
explicit fleet-size override - a plain number rather than a fake doctrine,
because nothing about the player's own progression should be bent to fit a
cutscene. It is carriers rather than transporters: transporters belong to
hubs and are not fleet-eligible, so a convoy of them would be silently
filtered down to its escorts.
The ambush is chasers and only chasers. "Easy enough" is the requirement,
and a sniper against a convoy the player cannot yet fight properly is
neither easy nor a good first impression.
The breach takes the wheel through one check in GameController, covering the
stick, the keyboard and the released-again path together - three separate
gates would be three chances for one of them to keep steering. The shake is
written to camera.offset, never to its position, because GameController owns
where the camera is and would smooth a shake away.
The vessel that survives is chosen as the interceptor rather than whichever
happened to be first in the list, and the prologue ends on exactly a new
game's opening position.
Also: PlanetAtmosphereController no longer spawns the opening fleet while
the prologue is arming, and the tests that are about what the GAME starts
from now say so by turning the prologue off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 20:59:12 +02:00
|
|
|
[ext_resource type="Script" path="res://ui/NarrationBanner.gd" id="36"]
|
|
|
|
|
[ext_resource type="Script" path="res://world/IntroDirector.gd" id="37"]
|
2026-08-23 21:58:58 +02:00
|
|
|
[ext_resource type="Script" path="res://ui/DevWaveButton.gd" id="38"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/HangarMenuPanel.gd" id="39"]
|
|
|
|
|
[ext_resource type="Script" path="res://logistics/RepairDroneField.gd" id="40"]
|
#125: slow the prologue down, and give the breach a real black hole
Five things, all of them "this happens too fast or looks too thin".
PACING. Every beat had a completion test that could be satisfied while the
guide was still mid-sentence, which is why everything landed seconds after
the thing before it. Beats now have a FLOOR as well as a deadline - a
minimum length - and a beat whose point is the guide talking will not end
while a line is still on screen. One rule in one place rather than tuning
each condition. The run is 3400px instead of 1500, which at cruise was about
four seconds, and a held line is 6.5s instead of 4.5.
THE CONVOY. Escorts at the four corners of a box, holds packed in the middle
of it, roughly three times the spread of the fleet's own wedge - this is
freight under guard, not a fighting formation. CONVOY and CONVOY_FORMATION
pair index-for-index, which is all it takes for spawn_ships to seat the guns
on the outside, and the test pins that every hold sits further in than the
furthest-out escort.
THE DIALOG. Cut corners, brackets holding the short edges open, a tick strip
along the bottom and a caret in the corner - geometry rather than art, so it
scales with the banner and costs nothing.
THE BREACH. It was a few lines turning around a point. It is now two halves
driven by one number: DimensionalBreach, a growing black hole out in the
world built on BlackHoleVisual's idiom - empty core, counter-rotating arc
segments hotter toward the centre - with infalling streamers it does not
have, because a planet's disc is steady and this one has to say "now"; and
breach.gdshader over the top, bending the ACTUAL SCENE around it. Ships,
rocks and the starfield all get dragged in, which is most of what makes a
hole in space read as a hole rather than as a decal drawn on one.
Inside the horizon the shader samples nothing at all - the same decision
BlackHoleVisual makes, for the same reason: a black hole with something
visible in the middle stops being one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 13:25:10 +02:00
|
|
|
[ext_resource type="Script" path="res://ui/BreachOverlay.gd" id="41"]
|
#84: move 215 root files into a folder hierarchy
Everything lived in one flat directory, so a diff gave no clue what area it
touched and finding the file you wanted meant knowing its exact name. Twelve
folders now, grouped by what a thing IS rather than what type it is - a
vessel's definition, its component scenes and its upgrade resources sit
together, because that is the set you read when you change one of them.
buildings core controllers enemies logistics planets
resources shaders surface ui vessels vfx world
332 files moved and every res:// reference rewritten - 306 files touched,
including the autoload and main-scene paths in project.godot. Nothing renamed:
this is purely where files sit, so the diff is a pile of pure moves and no
behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at
the root, where Godot and the export preset expect them.
Verified three ways, because a suite alone would not have caught all of it:
the full 117 pass, the web export builds clean, and the game renders.
The export is why that matters. The FIRST export after the move failed with
"Attempt to open script 'res://GameState.gd'" - the old path - while
project.godot on disk plainly said res://core/GameState.gd. That is this
project's documented Android FUSE mtime trap: Godot served a cached copy of a
file whose content had changed. A `touch` fixed it. Nothing in the test suite
would have found that, because the suite runs from a copy on a native
filesystem - the one place the bug cannot happen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
|
|
|
[ext_resource type="Script" path="res://logistics/TransporterField.gd" id="23"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/ResourceBar.gd" id="24"]
|
|
|
|
|
[ext_resource type="Script" path="res://logistics/VesselDeliveryField.gd" id="26"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/ResourceTransferList.gd" id="27"]
|
|
|
|
|
[ext_resource type="Script" path="res://controllers/MouseCombatController.gd" id="mouse_ctrl"]
|
|
|
|
|
[ext_resource type="Script" path="res://controllers/FireStickController.gd" id="fire_ctrl"]
|
|
|
|
|
[ext_resource type="Script" path="res://controllers/GasBombController.gd" id="29"]
|
|
|
|
|
[ext_resource type="Script" path="res://controllers/LaserController.gd" id="30"]
|
|
|
|
|
[ext_resource type="Script" path="res://ui/SpeedFader.gd" id="31"]
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
|
|
|
|
|
[sub_resource type="ShaderMaterial" id="1"]
|
|
|
|
|
shader = ExtResource("5")
|
|
|
|
|
shader_parameter/camera_pos = Vector2(0, 0)
|
|
|
|
|
shader_parameter/camera_zoom = 1.0
|
|
|
|
|
shader_parameter/viewport_size = Vector2(720, 1280)
|
|
|
|
|
shader_parameter/cell_size = 60.0
|
|
|
|
|
shader_parameter/bg_color = Color(0.02, 0.02, 0.08, 1)
|
|
|
|
|
|
|
|
|
|
[node name="Main" type="Node2D"]
|
|
|
|
|
script = ExtResource("3")
|
|
|
|
|
|
|
|
|
|
[node name="BackgroundLayer" type="CanvasLayer" parent="."]
|
|
|
|
|
layer = -10
|
|
|
|
|
|
|
|
|
|
[node name="Starfield" type="ColorRect" parent="BackgroundLayer"]
|
|
|
|
|
material = SubResource("1")
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchors_preset = 15
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
grow_horizontal = 2
|
|
|
|
|
grow_vertical = 2
|
|
|
|
|
script = ExtResource("1")
|
|
|
|
|
|
|
|
|
|
[node name="Fleet" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("2")
|
|
|
|
|
|
2026-08-15 04:45:15 +02:00
|
|
|
[node name="GasBombController" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("29")
|
|
|
|
|
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
[node name="FireStickController" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("fire_ctrl")
|
|
|
|
|
|
Implement #80, #81, #82 and #83
#80 - desktop combat. The mouse aims, the left button fires, and the number
keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin
sticks are built for thumbs; on a desktop they mean dragging a virtual stick
with a pointer that could simply BE the crosshair.
The pointer path hands its heading to FireStickController rather than driving
weapons itself, so exactly one thing in the scene aims a gun, and a held stick
wins - a finger on it is a deliberate act, a mouse resting somewhere is not.
Abilities gained fire_at(), which aims and fires in one call instead of
pretending to be a press-drag-release touch.
It is gated on the absence of a touchscreen, because Godot emulates a mouse
button from every touch and without that a tap on a phone would fire the guns.
The gate has an explicit override, and not for tidiness: headless reports a
touchscreen, so with the automatic answer alone the aiming could never be
exercised by a test and the only covered behaviour would be the guard.
#81 - the bottom-left control hint is gone, from both scenes and from
GameController.
#82 - a chaser is destroyed by the impact when it reaches a vessel. It used to
pass through the wreck untouched and line up another pass, which made a
ramming enemy strictly better than any other. Data-driven per enemy
(dies_on_contact), because a sniper that happens to drift into a ship has not
spent itself doing it - and routed through take_damage, so it dies exactly as
it dies to gunfire. The enemy is told about the impact BEFORE the ship
resolves its own damage, since resolving it can free the ship.
#83 - the research tree's buy button is gone; tapping a node twice buys it.
Deliberately "the same node twice" rather than a timed double-tap: no window
to miss on a slow phone, no accidental purchase while browsing, and the first
tap always does something visible, so the second is never a blind commitment.
The status line now says "Tap again to research" - with the button gone it is
the only thing distinguishing an affordable node from an unaffordable one.
test_enemy_collision asserted the exact behaviour #82 reversed, and now checks
the ram costs both. Suite 117/117.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
|
|
|
[node name="MouseCombatController" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("mouse_ctrl")
|
|
|
|
|
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
[node name="LaserController" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("30")
|
|
|
|
|
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
[node name="Camera2D" type="Camera2D" parent="."]
|
|
|
|
|
position = Vector2(0, 0)
|
|
|
|
|
zoom = Vector2(1, 1)
|
|
|
|
|
|
|
|
|
|
[node name="EnemySpawner" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("4")
|
|
|
|
|
|
|
|
|
|
[node name="ExplorationTracker" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("6")
|
|
|
|
|
|
|
|
|
|
[node name="AsteroidField" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("7")
|
|
|
|
|
|
|
|
|
|
[node name="PlanetField" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("11")
|
|
|
|
|
|
|
|
|
|
[node name="BuildingField" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("14")
|
|
|
|
|
|
#108: the prologue - the convoy, the ambush, and the breach
Landed as one piece across #122, #123 and #124: the frame is useless without
a script, and the script has nowhere to run without the frame.
The director drives the REAL scene rather than being a scene of its own. It
wants the real fleet, the real enemies and the real asteroid field, and it
makes "then the game starts" cost nothing - the director stops steering,
clears the flag, and what is left running is the ordinary game.
The script is a list of beats, each with a deadline as well as its own
completion test, so a beat whose condition is never met - a player who
refuses to fly at the ambush - runs out rather than wedging the prologue.
skip() ends the whole thing at any point and lands in exactly the state
playing it through does, so the game has one way to start rather than two
that have to be kept in step. The test pins that equivalence.
"No action button available, only movements" is enforced where the buttons
are decided, not by the director reaching in: the ability controllers set
their own visibility every frame and would have put them straight back, and
the map button belongs to the map. The joystick, the pivot and the fader
stay.
The convoy is ten hulls where a new game's fleet is one, so it needs an
explicit fleet-size override - a plain number rather than a fake doctrine,
because nothing about the player's own progression should be bent to fit a
cutscene. It is carriers rather than transporters: transporters belong to
hubs and are not fleet-eligible, so a convoy of them would be silently
filtered down to its escorts.
The ambush is chasers and only chasers. "Easy enough" is the requirement,
and a sniper against a convoy the player cannot yet fight properly is
neither easy nor a good first impression.
The breach takes the wheel through one check in GameController, covering the
stick, the keyboard and the released-again path together - three separate
gates would be three chances for one of them to keep steering. The shake is
written to camera.offset, never to its position, because GameController owns
where the camera is and would smooth a shake away.
The vessel that survives is chosen as the interceptor rather than whichever
happened to be first in the list, and the prologue ends on exactly a new
game's opening position.
Also: PlanetAtmosphereController no longer spawns the opening fleet while
the prologue is arming, and the tests that are about what the GAME starts
from now say so by turning the prologue off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 20:59:12 +02:00
|
|
|
[node name="IntroDirector" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("37")
|
|
|
|
|
|
#105 (#97g): garrison vessels patrol and defend their outpost
A garrisoned vessel circles its post, engages what comes into range, and
goes back to circling. It steers by writing move_target and lets Ship's own
steering fly it, so it accelerates, banks and brakes exactly like a vessel
in the formation.
It is not in Fleet.ships. It does not follow the formation, does not count
against max_fleet_size(), and does not move when the player flies away -
which is the whole point of stationing it. A garrison that ate a fleet slot
would mean stationing a vessel cost the player a place in their own wedge.
The leash is the load-bearing part. Enemies are judged from the POST rather
than from the vessel, so a garrison that has drifted out to its leash cannot
see further still and be walked away from its outpost one enemy at a time,
and an engagement is clamped to a circle around the post rather than to a
straight line, so it still manoeuvres while pinned.
The orbit starts from where the vessel actually is rather than a random
bearing. A random one makes the first move_target a point on the far side of
the circle, and the vessel flies straight across the middle - through the
outpost it is guarding.
EnemyTargets.nearest_ship now searches the player_ships GROUP instead of
Fleet.ships: an enemy that ignored the guns shooting at it, because they
were not in the player's formation, would let a garrison hold a position
without ever being fought back.
The laser vessel is deliberately not garrisonable. Firing the laser lives in
LaserController, a fleet ability driven by the laser button, rather than in
VesselLaserComponent - so a garrisoned laser would hold its position and
never shoot, and offering a vessel that cannot fight is worse than a short
list.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:13:47 +02:00
|
|
|
[node name="GarrisonField" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("34")
|
|
|
|
|
|
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")
|
|
|
|
|
|
2026-08-23 21:58:58 +02:00
|
|
|
[node name="RepairDroneField" type="Node2D" parent="."]
|
|
|
|
|
script = ExtResource("40")
|
|
|
|
|
|
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
|
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")
|
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"]
|
2026-08-13 21:07:35 +02:00
|
|
|
mouse_filter = 2
|
|
|
|
|
offset_left = 28
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_top = 6
|
|
|
|
|
offset_right = 220
|
|
|
|
|
offset_bottom = 34
|
2026-08-13 21:07:35 +02:00
|
|
|
theme_override_font_sizes/font_size = 18
|
2026-08-14 11:54:31 +02:00
|
|
|
theme_override_colors/font_color = Color(0.55, 0.78, 0.86, 1)
|
|
|
|
|
text = "BANKED"
|
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"]
|
2026-08-13 21:07:35 +02:00
|
|
|
mouse_filter = 2
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_left = 356
|
|
|
|
|
offset_top = 6
|
|
|
|
|
offset_right = 620
|
|
|
|
|
offset_bottom = 34
|
2026-08-13 21:07:35 +02:00
|
|
|
theme_override_font_sizes/font_size = 18
|
2026-08-14 11:54:31 +02:00
|
|
|
theme_override_colors/font_color = Color(1, 0.78, 0.25, 1)
|
|
|
|
|
text = "FLEET HOLD"
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
|
|
|
|
|
2026-08-12 22:47:46 +02:00
|
|
|
[node name="HangarButton" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
offset_left = 24
|
|
|
|
|
offset_right = 172
|
2026-08-13 20:49:15 +02:00
|
|
|
offset_top = 488
|
|
|
|
|
offset_bottom = 636
|
2026-08-12 22:47:46 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 2
|
|
|
|
|
glow_color = Color(0.45, 0.9, 0.55, 1)
|
|
|
|
|
|
2026-08-12 13:07:52 +02:00
|
|
|
[node name="TransferButton" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
2026-08-14 23:15:12 +02:00
|
|
|
offset_left = 188
|
|
|
|
|
offset_top = 160
|
|
|
|
|
offset_right = 336
|
|
|
|
|
offset_bottom = 308
|
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
|
|
|
|
|
|
2026-08-23 21:58:58 +02:00
|
|
|
[node name="DevWaveButton" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = -140.0
|
|
|
|
|
offset_right = -24.0
|
|
|
|
|
offset_top = 268.0
|
|
|
|
|
offset_bottom = 384.0
|
|
|
|
|
script = ExtResource("38")
|
|
|
|
|
|
|
|
|
|
[node name="Button" type="Control" parent="UI/DevWaveButton"]
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 5
|
|
|
|
|
glow_color = Color(1, 0.45, 0.2, 1)
|
|
|
|
|
|
#125: slow the prologue down, and give the breach a real black hole
Five things, all of them "this happens too fast or looks too thin".
PACING. Every beat had a completion test that could be satisfied while the
guide was still mid-sentence, which is why everything landed seconds after
the thing before it. Beats now have a FLOOR as well as a deadline - a
minimum length - and a beat whose point is the guide talking will not end
while a line is still on screen. One rule in one place rather than tuning
each condition. The run is 3400px instead of 1500, which at cruise was about
four seconds, and a held line is 6.5s instead of 4.5.
THE CONVOY. Escorts at the four corners of a box, holds packed in the middle
of it, roughly three times the spread of the fleet's own wedge - this is
freight under guard, not a fighting formation. CONVOY and CONVOY_FORMATION
pair index-for-index, which is all it takes for spawn_ships to seat the guns
on the outside, and the test pins that every hold sits further in than the
furthest-out escort.
THE DIALOG. Cut corners, brackets holding the short edges open, a tick strip
along the bottom and a caret in the corner - geometry rather than art, so it
scales with the banner and costs nothing.
THE BREACH. It was a few lines turning around a point. It is now two halves
driven by one number: DimensionalBreach, a growing black hole out in the
world built on BlackHoleVisual's idiom - empty core, counter-rotating arc
segments hotter toward the centre - with infalling streamers it does not
have, because a planet's disc is steady and this one has to say "now"; and
breach.gdshader over the top, bending the ACTUAL SCENE around it. Ships,
rocks and the starfield all get dragged in, which is most of what makes a
hole in space read as a hole rather than as a decal drawn on one.
Inside the horizon the shader samples nothing at all - the same decision
BlackHoleVisual makes, for the same reason: a black hole with something
visible in the middle stops being one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 13:25:10 +02:00
|
|
|
[node name="BreachOverlay" type="ColorRect" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
color = Color(1, 1, 1, 1)
|
|
|
|
|
script = ExtResource("41")
|
|
|
|
|
|
#108: the prologue - the convoy, the ambush, and the breach
Landed as one piece across #122, #123 and #124: the frame is useless without
a script, and the script has nowhere to run without the frame.
The director drives the REAL scene rather than being a scene of its own. It
wants the real fleet, the real enemies and the real asteroid field, and it
makes "then the game starts" cost nothing - the director stops steering,
clears the flag, and what is left running is the ordinary game.
The script is a list of beats, each with a deadline as well as its own
completion test, so a beat whose condition is never met - a player who
refuses to fly at the ambush - runs out rather than wedging the prologue.
skip() ends the whole thing at any point and lands in exactly the state
playing it through does, so the game has one way to start rather than two
that have to be kept in step. The test pins that equivalence.
"No action button available, only movements" is enforced where the buttons
are decided, not by the director reaching in: the ability controllers set
their own visibility every frame and would have put them straight back, and
the map button belongs to the map. The joystick, the pivot and the fader
stay.
The convoy is ten hulls where a new game's fleet is one, so it needs an
explicit fleet-size override - a plain number rather than a fake doctrine,
because nothing about the player's own progression should be bent to fit a
cutscene. It is carriers rather than transporters: transporters belong to
hubs and are not fleet-eligible, so a convoy of them would be silently
filtered down to its escorts.
The ambush is chasers and only chasers. "Easy enough" is the requirement,
and a sniper against a convoy the player cannot yet fight properly is
neither easy nor a good first impression.
The breach takes the wheel through one check in GameController, covering the
stick, the keyboard and the released-again path together - three separate
gates would be three chances for one of them to keep steering. The shake is
written to camera.offset, never to its position, because GameController owns
where the camera is and would smooth a shake away.
The vessel that survives is chosen as the interceptor rather than whichever
happened to be first in the list, and the prologue ends on exactly a new
game's opening position.
Also: PlanetAtmosphereController no longer spawns the opening fleet while
the prologue is arming, and the tests that are about what the GAME starts
from now say so by turning the prologue off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 20:59:12 +02:00
|
|
|
[node name="NarrationBanner" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 60.0
|
|
|
|
|
offset_right = -60.0
|
|
|
|
|
offset_top = 300.0
|
|
|
|
|
offset_bottom = 428.0
|
|
|
|
|
script = ExtResource("36")
|
|
|
|
|
|
#100 (#97b): waves replace the roaming enemy spawner
The old spawner put one enemy on the map every 3-6 seconds for ever. There
was no rhythm to the danger and nothing to prepare for. Enemies now arrive
in waves: a long quiet, a warning, an attack, and quiet again once the wave
is dead.
The clock lives in GameState, because Main.tscn is destroyed on every trip
to a planet surface and a wave must not be cancelled, nor restarted from
zero, by a landing. The spawning does not: GameState cannot see the world,
so EnemySpawner reads the phase and puts the enemies in it. That also
settles what happens when a wave turns while the player is on a surface -
the wave is waiting in space when they come back.
EnemySpawner keeps its name deliberately. It is still the thing that puts
enemies in the world, and 88 test files already say
`get_node("EnemySpawner").set_process(false)` to ask for a quiet map.
Strength is a function of the FLEET, per the ticket, with the wave number as
a slower second term so a player who never grows still meets escalation. The
budget is spent most-expensive-first, so a large wave is heavier rather than
merely longer, and min_strength keeps the first waves to chasers whatever
the arithmetic says.
"No timer should be visible" is enforced rather than merely observed:
GameState offers wave_warning_pulse(), a 0..1 throb, and no
remaining-seconds accessor at all, so the alert cannot drift into being a
countdown. The test pins both - that no such accessor exists, and that the
alert's own text contains no digits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 13:37:42 +02:00
|
|
|
[node name="WaveAlert" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = -300.0
|
|
|
|
|
offset_right = -24.0
|
|
|
|
|
offset_top = 188.0
|
|
|
|
|
offset_bottom = 252.0
|
|
|
|
|
script = ExtResource("32")
|
|
|
|
|
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
[node name="Joystick" type="Control" parent="UI"]
|
|
|
|
|
mouse_filter = 2
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
script = ExtResource("13")
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_left = 12
|
|
|
|
|
offset_right = 252
|
|
|
|
|
offset_top = -330
|
|
|
|
|
offset_bottom = -80
|
|
|
|
|
|
|
|
|
|
[node name="FireStick" type="Control" parent="UI"]
|
|
|
|
|
mouse_filter = 2
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
script = ExtResource("13")
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
glow_color = Color(1, 0.45, 0.3, 1)
|
|
|
|
|
core_color = Color(1, 1, 1, 1)
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = -252
|
|
|
|
|
offset_right = -12
|
|
|
|
|
offset_top = -330
|
|
|
|
|
offset_bottom = -80
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
|
2026-08-16 17:59:04 +02:00
|
|
|
[node name="SpeedFader" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -94
|
|
|
|
|
offset_right = -24
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_top = -720
|
|
|
|
|
offset_bottom = -560
|
2026-08-16 17:59:04 +02:00
|
|
|
script = ExtResource("31")
|
|
|
|
|
|
|
|
|
|
[node name="Label" type="Label" parent="UI/SpeedFader"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
offset_left = -20
|
|
|
|
|
offset_right = 90
|
|
|
|
|
offset_top = -32
|
|
|
|
|
offset_bottom = -4
|
|
|
|
|
theme_override_font_sizes/font_size = 20
|
|
|
|
|
theme_override_colors/font_color = Color(0.7, 0.3, 1, 1)
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "x1.0"
|
|
|
|
|
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
[node name="LaserButton" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
round_frame = true
|
|
|
|
|
icon = 36
|
|
|
|
|
glow_color = Color(0.3, 0.9, 1, 1)
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_left = -196
|
|
|
|
|
offset_right = -100
|
|
|
|
|
offset_top = -492
|
|
|
|
|
offset_bottom = -396
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
[node name="PivotCCWButton" type="Control" parent="UI"]
|
|
|
|
|
mouse_filter = 2
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
round_frame = true
|
|
|
|
|
icon = 7
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_left = -468
|
|
|
|
|
offset_right = -364
|
|
|
|
|
offset_top = -130
|
|
|
|
|
offset_bottom = -26
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
|
2026-08-15 04:45:15 +02:00
|
|
|
[node name="GasBombButton" type="Control" parent="UI"]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
script = ExtResource("10")
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
round_frame = true
|
2026-08-15 04:45:15 +02:00
|
|
|
icon = 32
|
|
|
|
|
glow_color = Color(0.96, 0.22, 0.72, 1)
|
2026-08-16 18:54:44 +02:00
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_left = -324
|
|
|
|
|
offset_right = -228
|
|
|
|
|
offset_top = -424
|
|
|
|
|
offset_bottom = -328
|
|
|
|
|
|
|
|
|
|
[node name="GasBombStatus" type="Label" parent="UI"]
|
|
|
|
|
mouse_filter = 2
|
2026-08-16 18:54:44 +02:00
|
|
|
theme_override_font_sizes/font_size = 18
|
|
|
|
|
theme_override_colors/font_color = Color(0.96, 0.22, 0.72, 1)
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
2026-08-16 19:11:31 +02:00
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_left = -420
|
2026-08-16 19:11:31 +02:00
|
|
|
offset_right = -24
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_top = -560
|
|
|
|
|
offset_bottom = -512
|
|
|
|
|
|
|
|
|
|
[node name="LaserStatus" type="Label" parent="UI"]
|
|
|
|
|
mouse_filter = 2
|
2026-08-16 19:11:31 +02:00
|
|
|
theme_override_font_sizes/font_size = 18
|
|
|
|
|
theme_override_colors/font_color = Color(0.3, 0.9, 1, 1)
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_left = -420
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
offset_right = -24
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
offset_top = -616
|
|
|
|
|
offset_bottom = -568
|
|
|
|
|
|
|
|
|
|
[node name="PivotCWButton" type="Control" parent="UI"]
|
|
|
|
|
mouse_filter = 2
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
script = ExtResource("10")
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
round_frame = true
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
icon = 6
|
Twin-stick combat: aim and fire with a second stick, MOBA-style ability ring
The fleet's guns picked their own targets and fired on their own, so combat
happened whether or not the player did anything - there was nothing to aim and
nothing to decide, and the right half of the screen held nothing at all.
Firing is now an action. VesselWeaponComponent no longer seeks a target; it
shoots along a heading, and the only thing that supplies one is the new
right-hand stick via FireStickController. A fleet arriving from another scene
starts with its guns silent, which is the correct resting state.
A subtle dashed guide runs from the fleet along the aimed heading while the
stick is held, out to the guns' OWN range - read from a weapon that is
actually aboard, so the line can never promise reach the fleet does not have.
Layout: the two sticks take the bottom corners, the pivot pair is centred
between them at the bottom edge, and the laser and gas bomb sit on an arc up
and left of the fire stick where a thumb already is. Those four are now round
- IconButton grew a round_frame mode, and the in-world action controls use it
while panel and menu buttons stay square, so the two kinds of button read as
different kinds of thing.
Worth recording, because it cost a screenshot to find: a script-declared
property set BEFORE the `script = ExtResource(...)` line in a .tscn is
silently dropped. Godot's parser has no idea the property exists yet. The
round frames were all correctly set in both scenes and none of them applied.
Also fixed researtch_lab_garrison.tres, which was authored under the void
profile - that is the black hole surface, so a lab garrison was spawning on
black holes.
Suite 110/110. test_enemy_combat's whole premise was auto-fire; it now holds
the real stick toward the enemy rather than poking weapon components, so it
exercises the path the player uses. test_fire_stick is new and covers the
change itself: an idle stick leaves a target parked well inside range
untouched, which is precisely what the old gun would never have done.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 01:29:21 +02:00
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = -356
|
|
|
|
|
offset_right = -252
|
|
|
|
|
offset_top = -130
|
|
|
|
|
offset_bottom = -26
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
#102/#103 (#97d/#97e): the outpost, and the garrison you compose for it
Landed together because an outpost you cannot crew is decoration, and a
garrison menu with no building to hang it off is nothing at all.
#102, the building. Researched at "Forward Bases", two prerequisites deep
and cheaper than any mid-game structure - the ticket asks for early, and the
answer to waves attacking your buildings should arrive at about the time the
waves can hurt them. It is drawn as a watch mast on a tripod with two open
berths, deliberately the least machinery of any structure here: it makes
nothing and refines nothing, it holds a position. 120hp, more than a
crafter, because being shot at is its job.
#103, the garrison. Two separate things live on its record, and conflating
them was the first thing to get wrong: the ORDER, what the player asked for,
and the CREW, who is actually there. This menu edits the order only; #104
fills the crew. Keeping the order as a wish is what lets an outpost ask for
a hull nobody has built yet and wait for it, rather than the request
evaporating - and it is why the panel shows "here / ordered" instead of one
number.
"Only ships that attack can be assigned" is expressed as capabilities rather
than a list of types, so a new armed vessel is eligible the day it is added
and an unarmed one never is by accident. Today that means the interceptor
and the laser vessel; a shield, a hauler and an engine block cannot hold a
position however much one might want them to.
Two berths by default, and Garrison Bays raises it at outposts ALREADY
standing - the same shape as freight_yards for hubs, because a bonus that
only reached new buildings would mean demolishing and rebuilding to collect
it.
The panel builds its own rows from the catalog rather than from nodes placed
in the scene, so adding an armed vessel later needs no scene surgery.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:02:20 +02:00
|
|
|
[node name="OutpostButton" 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 = 830
|
|
|
|
|
offset_bottom = 958
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 40
|
|
|
|
|
glow_color = Color(0.72, 0.86, 0.45, 1)
|
|
|
|
|
|
|
|
|
|
[node name="OutpostLabel" 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 = 964
|
|
|
|
|
offset_bottom = 1030
|
|
|
|
|
theme_override_font_sizes/font_size = 32
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
text = "Outpost"
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
|
|
|
|
[node name="OutpostCost" 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 = 1034
|
|
|
|
|
offset_bottom = 1086
|
|
|
|
|
script = ExtResource("19")
|
|
|
|
|
amount = 30
|
|
|
|
|
digit_height = 40.0
|
|
|
|
|
|
#106/#107 (#98a/#98b): the Planning Center
Landed together: a board of standing orders nothing acts on is a notepad,
and a planner with nowhere to read the plan from has nothing to do.
The targets are GLOBAL, not per building. There is one plan for the whole
game, and a second planning centre is another place to read and edit it
rather than a competing one - per-building targets would let two centres
hold contradictory orders and tell the crafters to satisfy both.
The census is the harder half. Every vessel is counted exactly once wherever
it happens to be: flying in the fleet, parked in the hangar, stationed at an
outpost, or in the air between any two of those. Miss the in-flight ones and
the planner queues a replacement for a vessel that is merely en route. The
fleet is the one place GameState cannot see, so Fleet pushes its composition
on every change, alongside the cargo capacity and distorder count that
already went that way.
Three rules keep the planner from fighting the player. It tops up and never
rewrites, so an order placed by hand stays exactly where it is. Everything
counts, including what is already queued, or it re-queues the same shortfall
every tick and buries the player in hulls. And nothing happens without a
planning centre - though the plan is remembered when one is destroyed, so
rebuilding picks up where it left off.
Vessels on order are counted separately from the census on purpose: they do
not exist yet, so the readout can say "4 of 6, 2 building" rather than
claiming six. The per-row note says where the vessels actually are, because
a plan can look unmet while everything it asked for is sitting at an
outpost.
The build menu goes to three columns past eight entries. #54 already
tightened its rows to 223px to fit a fourth, explicitly to avoid a
scrollable menu, and a ninth structure needs a fifth row that will not fit
at any spacing a button, a label and a cost can share. Three columns take
nine into three rows - fewer than it uses today, not more.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:21:52 +02:00
|
|
|
[node name="PlanningButton" 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 = 1090
|
|
|
|
|
offset_bottom = 1218
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 41
|
|
|
|
|
glow_color = Color(0.62, 0.74, 0.92, 1)
|
|
|
|
|
|
|
|
|
|
[node name="PlanningLabel" 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 = 1224
|
|
|
|
|
offset_bottom = 1290
|
|
|
|
|
theme_override_font_sizes/font_size = 32
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
text = "Planning Center"
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
|
|
|
|
[node name="PlanningCost" 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 = 1294
|
|
|
|
|
offset_bottom = 1346
|
|
|
|
|
script = ExtResource("19")
|
|
|
|
|
amount = 70
|
|
|
|
|
digit_height = 40.0
|
|
|
|
|
|
2026-08-23 21:58:58 +02:00
|
|
|
[node name="WorkshopButton" 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 = 1350
|
|
|
|
|
offset_bottom = 1478
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 42
|
|
|
|
|
glow_color = Color(0.5, 0.95, 0.8, 1)
|
|
|
|
|
|
|
|
|
|
[node name="WorkshopLabel" 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 = 1484
|
|
|
|
|
offset_bottom = 1550
|
|
|
|
|
theme_override_font_sizes/font_size = 32
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
text = "Spacial Workshop"
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
|
|
|
|
[node name="WorkshopCost" 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 = 1554
|
|
|
|
|
offset_bottom = 1606
|
|
|
|
|
script = ExtResource("19")
|
|
|
|
|
amount = 55
|
|
|
|
|
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
|
|
|
|
|
|
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)
|
|
|
|
|
|
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
|
2026-08-23 21:58:58 +02:00
|
|
|
script = ExtResource("39")
|
2026-08-12 22:47:46 +02:00
|
|
|
|
|
|
|
|
[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"]
|
2026-08-12 23:08:43 +02:00
|
|
|
visible = false
|
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"]
|
2026-08-12 23:08:43 +02:00
|
|
|
visible = false
|
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"]
|
2026-08-12 23:08:43 +02:00
|
|
|
visible = false
|
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"]
|
2026-08-12 23:08:43 +02:00
|
|
|
visible = false
|
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"
|
|
|
|
|
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_left = -290
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_right = -215
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_left = -330
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_right = -175
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -189
|
|
|
|
|
offset_right = -114
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -229
|
|
|
|
|
offset_right = -74
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -88
|
|
|
|
|
offset_right = -13
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -128
|
|
|
|
|
offset_right = 27
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = 13
|
|
|
|
|
offset_right = 88
|
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
|
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
|
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
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_right = 330
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_left = -290
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_right = -215
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_left = -330
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_right = -175
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -189
|
|
|
|
|
offset_right = -114
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -229
|
|
|
|
|
offset_right = -74
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -88
|
|
|
|
|
offset_right = -13
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -128
|
|
|
|
|
offset_right = 27
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = 13
|
|
|
|
|
offset_right = 88
|
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
|
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
|
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
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_right = 330
|
2026-08-12 23:08:43 +02:00
|
|
|
offset_top = 690
|
|
|
|
|
offset_bottom = 770
|
|
|
|
|
theme_override_font_sizes/font_size = 22
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
2026-08-12 22:47:46 +02:00
|
|
|
[node name="CloseButton" type="Control" parent="UI/HangarMenu"]
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = -172
|
|
|
|
|
offset_top = 24
|
|
|
|
|
offset_right = -24
|
|
|
|
|
offset_bottom = 172
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 1
|
|
|
|
|
glow_color = Color(0.45, 0.9, 0.55, 1)
|
|
|
|
|
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
[node name="LabMenu" type="Control" parent="UI" groups=["modal_menus"]]
|
|
|
|
|
visible = false
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
|
|
|
|
|
[node name="Backdrop" type="ColorRect" parent="UI/LabMenu"]
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
color = Color(0.03, 0.03, 0.08, 0.94)
|
|
|
|
|
|
|
|
|
|
[node name="TitleLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 20
|
2026-08-12 13:07:52 +02:00
|
|
|
offset_right = -200
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 82
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
text = "Ship Lab"
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
2026-08-12 13:07:52 +02:00
|
|
|
[node name="Bar" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
2026-08-14 11:54:31 +02:00
|
|
|
anchor_right = 1.0
|
2026-08-12 13:07:52 +02:00
|
|
|
offset_left = 24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 148
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_right = -24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 284
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_left = -300
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_right = -240
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 2
|
|
|
|
|
glow_color = Color(0.25, 0.85, 1, 1)
|
|
|
|
|
|
|
|
|
|
[node name="VesselB" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -210
|
|
|
|
|
offset_right = -150
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 2
|
|
|
|
|
glow_color = Color(0.45, 0.8, 1, 1)
|
|
|
|
|
|
|
|
|
|
[node name="VesselC" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -120
|
|
|
|
|
offset_right = -60
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
2026-08-15 04:45:15 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 31
|
|
|
|
|
glow_color = Color(0.96, 0.32, 0.78, 1)
|
|
|
|
|
|
|
|
|
|
[node name="VesselD" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -30
|
|
|
|
|
offset_right = 30
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 12
|
|
|
|
|
glow_color = Color(0.95, 0.55, 0.85, 1)
|
|
|
|
|
|
2026-08-16 16:20:39 +02:00
|
|
|
[node name="VesselE" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = 60
|
|
|
|
|
offset_right = 120
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
2026-08-16 16:20:39 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 34
|
|
|
|
|
glow_color = Color(1, 0.78, 0.3, 1)
|
|
|
|
|
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
[node name="VesselF" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = 150
|
|
|
|
|
offset_right = 210
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 35
|
|
|
|
|
glow_color = Color(0.3, 0.9, 1, 1)
|
|
|
|
|
|
2026-08-16 17:59:04 +02:00
|
|
|
[node name="VesselG" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = 240
|
|
|
|
|
offset_right = 300
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
2026-08-16 17:59:04 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 37
|
|
|
|
|
glow_color = Color(0.7, 0.3, 1, 1)
|
|
|
|
|
|
2026-08-23 21:58:58 +02:00
|
|
|
[node name="VesselH" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = 320
|
|
|
|
|
offset_right = 380
|
|
|
|
|
offset_top = 300
|
|
|
|
|
offset_bottom = 420
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 43
|
|
|
|
|
glow_color = Color(0.5, 0.95, 0.8, 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"]
|
2026-08-13 16:45:08 +02:00
|
|
|
visible = false
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
offset_right = -24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 482
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
theme_override_font_sizes/font_size = 34
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
2026-08-13 16:45:08 +02:00
|
|
|
[node name="VesselALabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_left = -310
|
|
|
|
|
offset_right = -230
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
2026-08-13 16:45:08 +02:00
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Interceptor"
|
|
|
|
|
|
|
|
|
|
[node name="VesselBLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_left = -220
|
|
|
|
|
offset_right = -140
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
2026-08-13 16:45:08 +02:00
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Shield"
|
|
|
|
|
|
|
|
|
|
[node name="VesselCLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_left = -130
|
|
|
|
|
offset_right = -50
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
2026-08-15 04:45:15 +02:00
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Gas Bomber"
|
|
|
|
|
|
|
|
|
|
[node name="VesselDLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_left = -40
|
|
|
|
|
offset_right = 40
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
2026-08-13 16:45:08 +02:00
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Transporter"
|
|
|
|
|
|
2026-08-16 16:20:39 +02:00
|
|
|
[node name="VesselELabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_left = 50
|
|
|
|
|
offset_right = 130
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
2026-08-16 16:20:39 +02:00
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Carrier"
|
|
|
|
|
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
[node name="VesselFLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_left = 140
|
|
|
|
|
offset_right = 220
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
Add laser ship vessel and its skill shot (#58)
A manually aimed instant beam, modelled on the gas bomber's press-drag-
release aiming (GasBombController/VesselGasBomberComponent) but firing
the moment the touch releases - no projectile travel time. Damage,
beam_range and cooldown are resolved per ship from base_stats/upgrades
(VesselLaserComponent.apply_stats(), the same pattern
VesselWeaponComponent uses) rather than hardcoded in the controller, so
the new damage/range/cooldown ship-lab upgrades actually reach them.
Cooldown lives on the component (per ship), not the controller (per
fleet) - two laser ships give two shots, the exact bug already fixed
for bombers in eb79efd.
LaserController.gd is reused unmodified by both Main.tscn and
PlanetSurface.tscn (relative ../Fleet, ../Camera2D, ../UI/LaserButton
paths, matching GasBombController), so it works identically in space
and on a landed surface. Wired into GameController's touch/drag
first-refusal chain alongside the bomb controller.
The crafter, hangar and ship-lab menus were already generic over
VesselDefinitions.fleet()/.all() - only the per-vessel Main.tscn nodes
are hand-placed, not the logic - so this repacks those rows to
5/5/6 columns and extends BuildController's onready arrays. No new
signal handlers were needed. Also fixes test_vessel_composition.gd's
hardcoded fleet-catalog size again (4 -> 5) now that laser is a fifth
fleet-eligible vessel.
Note for later tickets: a brand-new class_name script (LaserController)
resolves fine as a static type when its own file is the godot -s entry
point, but the identical type hint fails to parse ("Could not find
type") when the script holding it is only reached indirectly - e.g.
Main.tscn loaded from inside a _screenshot_tool.gd preview. Untyped
Node + duck-typed calls sidesteps it; GameController.gd's
laser_controller field documents this in place.
2026-08-16 17:29:53 +02:00
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Laser Ship"
|
|
|
|
|
|
2026-08-16 17:59:04 +02:00
|
|
|
[node name="VesselGLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
offset_left = 230
|
|
|
|
|
offset_right = 310
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
Fix UI overlaps: SpeedFader vs status labels, packed ship lab layout (#67, #71)
SpeedFader was missing anchor_top/anchor_bottom = 1.0 in both Main.tscn
and PlanetSurface.tscn, so it rendered TOP-anchored at a fixed y while
its siblings (LaserStatus, GasBombStatus) are bottom-anchored - on a
720x1280 viewport both landed in the same screen region, directly on
top of each other. Properly bottom-anchored SpeedFader now, positioned
above both status labels instead.
Separately, the ship lab's 7 vessel-name labels (#57-#59 grew the
roster from 4 to 7 without widening their row) were laid out 120px wide
on only a 90px pitch - a fixed 30px overlap between adjacent labels
regardless of text length, worse for genuinely long names like
"Interceptor"/"Transporter". Narrowed each label to fit its own lane
with real gaps, dropped the font size, and enabled word-wrap; shifted
the upgrade-card rows below down to give the now-taller label row room.
2026-08-17 19:47:09 +02:00
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
2026-08-16 17:59:04 +02:00
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Distorder"
|
|
|
|
|
|
2026-08-23 21:58:58 +02:00
|
|
|
[node name="VesselHLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = 310
|
|
|
|
|
offset_right = 390
|
|
|
|
|
offset_top = 424
|
|
|
|
|
offset_bottom = 496
|
|
|
|
|
theme_override_font_sizes/font_size = 15
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Repair Drone"
|
|
|
|
|
|
2026-08-13 20:13:32 +02:00
|
|
|
[node name="VesselUpgradeSeparator" type="ColorRect" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 48
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 502
|
2026-08-13 20:13:32 +02:00
|
|
|
offset_right = -48
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 506
|
2026-08-13 20:13:32 +02:00
|
|
|
color = Color(0.25, 0.85, 1, 0.6)
|
|
|
|
|
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
[node name="UpgradeList" type="Label" parent="UI/LabMenu"]
|
2026-08-13 16:45:08 +02:00
|
|
|
visible = false
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = 32
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 514
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
offset_right = -32
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = -390
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
theme_override_font_sizes/font_size = 30
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="DetailLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = 32
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = -380
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
offset_right = -32
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = -280
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
theme_override_font_sizes/font_size = 32
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="StatusLabel" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = 32
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = -274
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
offset_right = -32
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = -226
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
theme_override_font_sizes/font_size = 30
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="NextButton" type="Control" parent="UI/LabMenu"]
|
2026-08-13 16:45:08 +02:00
|
|
|
visible = false
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = -230
|
|
|
|
|
offset_right = -110
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = -218
|
|
|
|
|
offset_bottom = -108
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 6
|
|
|
|
|
glow_color = Color(0.55, 0.95, 0.9, 1)
|
|
|
|
|
|
|
|
|
|
[node name="BuyButton" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = 110
|
|
|
|
|
offset_right = 230
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = -218
|
|
|
|
|
offset_bottom = -108
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 4
|
|
|
|
|
glow_color = Color(0.45, 0.9, 0.55, 1)
|
|
|
|
|
|
|
|
|
|
[node name="HintLabel" type="Label" parent="UI/LabMenu"]
|
2026-08-13 16:45:08 +02:00
|
|
|
visible = false
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = 24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = -102
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
offset_right = -24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = -22
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
theme_override_font_sizes/font_size = 28
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = "Next upgrade Buy"
|
|
|
|
|
|
2026-08-13 16:45:08 +02:00
|
|
|
[node name="Upgrade0" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = -240
|
|
|
|
|
offset_right = -120
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 514
|
|
|
|
|
offset_bottom = 624
|
2026-08-13 16:45:08 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 13
|
|
|
|
|
glow_color = Color(0.25, 0.85, 1, 1)
|
|
|
|
|
|
|
|
|
|
[node name="Upgrade0Label" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = -310
|
|
|
|
|
offset_right = -50
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 628
|
|
|
|
|
offset_bottom = 698
|
2026-08-13 16:45:08 +02:00
|
|
|
theme_override_font_sizes/font_size = 22
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="Upgrade1" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = 120
|
|
|
|
|
offset_right = 240
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 514
|
|
|
|
|
offset_bottom = 624
|
2026-08-13 16:45:08 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 13
|
|
|
|
|
glow_color = Color(0.25, 0.85, 1, 1)
|
|
|
|
|
|
|
|
|
|
[node name="Upgrade1Label" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = 50
|
|
|
|
|
offset_right = 310
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 628
|
|
|
|
|
offset_bottom = 698
|
2026-08-13 16:45:08 +02:00
|
|
|
theme_override_font_sizes/font_size = 22
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="Upgrade2" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = -240
|
|
|
|
|
offset_right = -120
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 706
|
|
|
|
|
offset_bottom = 816
|
2026-08-13 16:45:08 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 13
|
|
|
|
|
glow_color = Color(0.25, 0.85, 1, 1)
|
|
|
|
|
|
|
|
|
|
[node name="Upgrade2Label" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = -310
|
|
|
|
|
offset_right = -50
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 820
|
|
|
|
|
offset_bottom = 890
|
2026-08-13 16:45:08 +02:00
|
|
|
theme_override_font_sizes/font_size = 22
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="Upgrade3" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = 120
|
|
|
|
|
offset_right = 240
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 706
|
|
|
|
|
offset_bottom = 816
|
2026-08-13 16:45:08 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 13
|
|
|
|
|
glow_color = Color(0.25, 0.85, 1, 1)
|
|
|
|
|
|
|
|
|
|
[node name="Upgrade3Label" type="Label" parent="UI/LabMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
offset_left = 50
|
|
|
|
|
offset_right = 310
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 820
|
|
|
|
|
offset_bottom = 890
|
2026-08-13 16:45:08 +02:00
|
|
|
theme_override_font_sizes/font_size = 22
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
[node name="CloseButton" type="Control" parent="UI/LabMenu"]
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_left = -140
|
|
|
|
|
offset_top = 20
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
offset_right = -24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 136
|
Ship Lab: per-vessel research, and the shield vessel
Forgejo #5. A new building gated behind a "Vessel Science" research
node. Its own screen upgrades each vessel type - weapon, movement,
shield and freight - and unlocks the shield vessel, which the ship
crafter can then build.
Vessel research is deliberately NOT more nodes in the mothership tree:
that tree gates what may be built at all and is a strategic spine, while
these are repeatable tuning on vessels already owned. Levels cost
base * (level + 1), so the third point in something is not the price of
the first. Upgrades are read live rather than baked in at build time, so
researching one improves the ships already flying.
The shield is personal, not a bubble: it absorbs a hit that would
destroy the vessel - ships have no health, contact kills - and is then
down until it cycles. Its ring is a NeonPiece child toggled with
`visible` per #10, not a redraw of the hull.
The build menu now holds six entries across three rows, which the #21
repacking already handles.
Enemies still have no weapon, so "blocks shots" has nothing to block
yet; that is filed separately rather than widened into this ticket.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 23:31:49 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 1
|
|
|
|
|
glow_color = Color(0.55, 0.95, 0.9, 1)
|
|
|
|
|
|
2026-08-11 20:17:58 +02:00
|
|
|
[node name="CraftMenu" type="Control" parent="UI" groups=["modal_menus"]]
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
visible = false
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
|
|
|
|
|
[node name="Backdrop" type="ColorRect" parent="UI/CraftMenu"]
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
color = Color(0.03, 0.03, 0.08, 0.94)
|
|
|
|
|
|
|
|
|
|
[node name="TitleLabel" type="Label" parent="UI/CraftMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 20
|
2026-08-12 13:07:52 +02:00
|
|
|
offset_right = -200
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 82
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
text = "Build a ship"
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
2026-08-12 13:07:52 +02:00
|
|
|
[node name="Bar" type="Control" parent="UI/CraftMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
offset_left = 24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 148
|
2026-08-12 13:07:52 +02:00
|
|
|
offset_right = 520
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 284
|
2026-08-12 13:07:52 +02:00
|
|
|
script = ExtResource("24")
|
|
|
|
|
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
[node name="StatusLabel" type="Label" parent="UI/CraftMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 300
|
2026-08-12 22:47:46 +02:00
|
|
|
offset_right = -200
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_bottom = 446
|
2026-08-12 13:07:52 +02:00
|
|
|
theme_override_font_sizes/font_size = 36
|
Initial commit: SpaceshipTest, a top-down space RTS in Godot 4.7.1
A fleet of neon-outlined ships explores a procedurally generated, seeded
infinite world: tap/joystick steering, pinch zoom, formation pivoting,
planet landings, an ore economy with extractors and haulers, and player
built structures (mothership, ship crafter, command centre).
All art is hand-drawn with draw_* calls rather than textures, and the
backgrounds are camera-relative shaders so they stay precise at large
world coordinates.
Includes a 35-test headless suite (tests/run_tests.sh) plus screenshot
tooling that renders real frames through Xvfb and Mesa softpipe, since
--headless has no GPU.
Excluded from version control: .godot/ (import cache, and it holds
export credentials), builds/, android/build/ and packaged APKs - all
regenerable, and ~325 MB combined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 18:41:58 +02:00
|
|
|
autowrap_mode = 2
|
|
|
|
|
text = ""
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
|
|
|
|
[node name="InterceptorButton" type="Control" parent="UI/CraftMenu"]
|
|
|
|
|
anchor_left = 0.5
|
|
|
|
|
anchor_right = 0.5
|
|
|
|
|
anchor_top = 0.5
|
|
|
|
|
anchor_bottom = 0.5
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_left = -310
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_right = -245
|
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
|
2026-08-15 04:45:15 +02:00
|
|
|
offset_left = -330
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_right = -225
|
2026-08-15 00:09:10 +02:00
|
|
|
offset_top = 56
|
|
|
|
|
offset_bottom = 136
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -221
|
|
|
|
|
offset_right = -156
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -241
|
|
|
|
|
offset_right = -136
|
2026-08-15 00:09:10 +02:00
|
|
|
offset_top = 56
|
|
|
|
|
offset_bottom = 136
|
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
|
|
|
|
|
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -132
|
|
|
|
|
offset_right = -67
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -152
|
|
|
|
|
offset_right = -47
|
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
|
|
|
|
|
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -43
|
|
|
|
|
offset_right = 22
|
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
|
2026-08-16 17:59:04 +02:00
|
|
|
offset_left = -63
|
|
|
|
|
offset_right = 42
|
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
|
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
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
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)
|
|
|
|
|
|
2026-08-12 13:07:52 +02:00
|
|
|
[node name="CloseButton" type="Control" parent="UI/CraftMenu"]
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_left = -140
|
2026-08-12 13:07:52 +02:00
|
|
|
offset_right = -24
|
Recentre a released stick, slow extractors again, and unbreak the lab layout
Both sticks float - the base jumps to wherever the finger lands, so a player
does not have to hit an exact spot on a screen they cannot feel. Releasing put
only the KNOB back onto the base and left the base parked wherever that touch
had been, so an idle stick sat off-centre in a different place every time and
read as a control still in use. Release now returns base and knob to the
middle of the rect.
Extractors produce at 0.5 ore per second, halved again: at 1.0 they still
outran the rest of the economy. An extractor now pays back its 25-ore cost in
fifty seconds rather than twelve.
The ship lab and the crafter were both overlapping themselves. Enlarging the
shared resource table to 136px (so it could breathe and show bigger type)
pushed its bottom edge 34px into the vessel row beneath it in one and the
status text in the other - my regression, visible immediately on a real
screen and not at all in any test. The lab's second row of upgrade cards was
also already running into the detail text below it, by 13px, before any of
this. Both menus are re-spaced end to end rather than nudged, since moving one
collision into another is how the second one got there.
Two tests carried waits tuned to an extraction rate that has now changed
twice. Both derive them from EXTRACTOR_RATE instead, so the next balance pass
does not report a broken extractor that is working perfectly - the same fix
test_extractor_income already needed one round ago, in the file next to it.
Suite 112/112.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 13:31:46 +02:00
|
|
|
offset_top = 20
|
|
|
|
|
offset_bottom = 136
|
2026-08-12 13:07:52 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 1
|
|
|
|
|
|
|
|
|
|
[node name="TransferMenu" type="Control" parent="UI" groups=["modal_menus"]]
|
|
|
|
|
visible = false
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
|
|
|
|
|
[node name="Backdrop" type="ColorRect" parent="UI/TransferMenu"]
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
color = Color(0.03, 0.03, 0.08, 0.94)
|
|
|
|
|
|
|
|
|
|
[node name="TitleLabel" type="Label" parent="UI/TransferMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24
|
|
|
|
|
offset_top = 36
|
|
|
|
|
offset_right = -200
|
|
|
|
|
offset_bottom = 166
|
2026-08-14 11:54:31 +02:00
|
|
|
text = "Transfer cargo"
|
2026-08-12 13:07:52 +02:00
|
|
|
horizontal_alignment = 1
|
Stacking distorders, menu layouts, lab rewards, enemy detail, artillery cross
DISTORDER STACKING. Each space-time distorder vessel past the first raises
the fleet's speed ceiling by 1.0, so a second one is worth crewing instead of
being dead weight. GameState gains max_fleet_speed_multiplier, pushed by
Fleet whenever composition changes - the same direction as every other
fleet-derived figure, since GameState does not reach into the scene tree to
count ships. The energy drain is normalised against the CURRENT ceiling, so
full boost costs the same per second however wide it is: extra vessels buy
more speed, not cheaper speed. Losing one re-clamps an over-ceiling boost
rather than leaving the fleet travelling faster than its crew can sustain.
TRANSFER MENU. Rows overlapped, and the last one ran into the hint text.
row_height is divided from the available space, but each row's contents used
a fixed pixel ladder - glyph at +10, buttons at +88, selector at +142 - which
needs about 244px. Three resources fit; the fourth cut rows to 180 and every
one spilled 64px into the next. Every offset is now a fraction of the row, so
it cannot overflow. Also dropped the per-row AMOUNT caption (four copies of a
word the footer hint already explains) and moved each glyph and name to the
TOP of its row, where they read as its heading rather than the next row's.
HANGAR. Six vessel types in one row gave each about 100px for a 155px label,
so the names ran together. Now a 3x2 grid per section, sized from the space
between the first heading and the status line, using the empty lower half.
LAB RESEARCH REWARD. A harder enemy lab is worth more research points, and
how hard a lab is depends on the layout authored for it - how many capture
points, how many defenders - which the planet TYPE cannot know. PlanetSetup
carries research_point_reward, set in the map editor, overriding the planet
type's flat rate. 0 means "no opinion", so every map authored before this
keeps its old value.
RESEARCH LAB BACKGROUND. Its own shader instead of the crater field with a
red tint, which read as "rocky planet, tinted" rather than someone's
facility: plated floor, seams, service conduits, lit junctions. Loop-free by
construction (#68's lesson applied up front) - conduits stay continuous
across cells by keying a horizontal run to cell.y and a vertical to cell.x,
so neighbouring cells agree without any cell scanning its neighbours.
ENEMY DETAIL. Every enemy was a single flat outline, which left the artillery
and the turret spawner as the same octagon at two sizes - the silhouette
carried no information about what the thing did. EnemyDefinition gains
detail_lines and detail_rings as DATA, so adding an enemy still means adding
a definition rather than editing Enemy.gd, and the four non-default hulls are
redrawn: a long-barrelled sniper, a squat mortar, a hive with launch bays, a
capital ship with spine and ribs.
Three things drew an enemy from its definition - the enemy, the map editor's
markers, and the palette buttons - each reimplementing it from hull_points
alone, so the new detail appeared in the game and nowhere else and an editor
marker stopped matching what it placed. They now share
EnemyDefinitions.draw_definition().
ARTILLERY. The 1.8s charge-up before the tower fired arrived long before the
threat was legible and mostly read as the tower being stuck. It fires
immediately now; the warning is the shell you can see in the air plus a small
cross on the ground at the impact point. Deliberately not a blast-radius ring
- a large translucent area was easy to read as the explosion having already
happened, where the cross says "move off this spot".
MAIN MENU. No Quit in any build (a web build has nothing to quit to, and
Android's back gesture already does it), a plain black background, and the
game is "Spaceship" - in the title and in config/name, which is what drives
the browser tab for the web export. change_scene_to_file() returns an error
and otherwise fails silently, leaving the menu up, which is indistinguishable
from an unpressed button; it is now checked and reported on screen.
Full suite green at 99/99.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 16:54:46 +02:00
|
|
|
vertical_alignment = 1
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
theme_override_font_sizes/font_size = 44
|
2026-08-12 13:07:52 +02:00
|
|
|
|
|
|
|
|
[node name="StatusLabel" type="Label" parent="UI/TransferMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_top = 184
|
2026-08-12 13:07:52 +02:00
|
|
|
offset_right = -24
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_bottom = 284
|
2026-08-14 15:45:08 +02:00
|
|
|
theme_override_font_sizes/font_size = 32
|
2026-08-12 13:07:52 +02:00
|
|
|
autowrap_mode = 2
|
|
|
|
|
text = ""
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
2026-08-14 11:54:31 +02:00
|
|
|
[node name="ResourceList" type="Control" parent="UI/TransferMenu"]
|
2026-08-12 13:07:52 +02:00
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
2026-08-14 15:45:08 +02:00
|
|
|
offset_left = 16
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_top = 294
|
2026-08-14 15:45:08 +02:00
|
|
|
offset_right = -16
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_bottom = 1080
|
|
|
|
|
script = ExtResource("27")
|
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
|
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
|
|
|
|
2026-08-14 11:54:31 +02:00
|
|
|
[node name="HintLabel" type="Label" parent="UI/TransferMenu"]
|
2026-08-13 22:17:24 +02:00
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
2026-08-14 11:54:31 +02:00
|
|
|
offset_left = 24
|
|
|
|
|
offset_top = 1092
|
|
|
|
|
offset_right = -24
|
|
|
|
|
offset_bottom = 1150
|
2026-08-14 13:44:10 +02:00
|
|
|
text = "Arrows move the selected amount from that side"
|
2026-08-13 22:17:24 +02:00
|
|
|
horizontal_alignment = 1
|
2026-08-14 11:54:31 +02:00
|
|
|
theme_override_colors/font_color = Color(0.55, 0.7, 0.78, 1)
|
2026-08-14 15:45:08 +02:00
|
|
|
theme_override_font_sizes/font_size = 23
|
2026-08-13 22:17:24 +02:00
|
|
|
|
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
|
|
|
|
#106/#107 (#98a/#98b): the Planning Center
Landed together: a board of standing orders nothing acts on is a notepad,
and a planner with nowhere to read the plan from has nothing to do.
The targets are GLOBAL, not per building. There is one plan for the whole
game, and a second planning centre is another place to read and edit it
rather than a competing one - per-building targets would let two centres
hold contradictory orders and tell the crafters to satisfy both.
The census is the harder half. Every vessel is counted exactly once wherever
it happens to be: flying in the fleet, parked in the hangar, stationed at an
outpost, or in the air between any two of those. Miss the in-flight ones and
the planner queues a replacement for a vessel that is merely en route. The
fleet is the one place GameState cannot see, so Fleet pushes its composition
on every change, alongside the cargo capacity and distorder count that
already went that way.
Three rules keep the planner from fighting the player. It tops up and never
rewrites, so an order placed by hand stays exactly where it is. Everything
counts, including what is already queued, or it re-queues the same shortfall
every tick and buries the player in hulls. And nothing happens without a
planning centre - though the plan is remembered when one is destroyed, so
rebuilding picks up where it left off.
Vessels on order are counted separately from the census on purpose: they do
not exist yet, so the readout can say "4 of 6, 2 building" rather than
claiming six. The per-row note says where the vessels actually are, because
a plan can look unmet while everything it asked for is sitting at an
outpost.
The build menu goes to three columns past eight entries. #54 already
tightened its rows to 223px to fit a fourth, explicitly to avoid a
scrollable menu, and a ninth structure needs a fifth row that will not fit
at any spacing a button, a label and a cost can share. Three columns take
nine into three rows - fewer than it uses today, not more.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:21:52 +02:00
|
|
|
[node name="PlanningMenu" 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/PlanningMenu"]
|
|
|
|
|
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/PlanningMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24.0
|
|
|
|
|
offset_top = 20.0
|
|
|
|
|
offset_right = -200.0
|
|
|
|
|
offset_bottom = 82.0
|
|
|
|
|
text = "Planning Center"
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
|
|
|
|
[node name="Panel" type="Control" parent="UI/PlanningMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 40.0
|
|
|
|
|
offset_top = 120.0
|
|
|
|
|
offset_right = -40.0
|
|
|
|
|
offset_bottom = -180.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
script = ExtResource("35")
|
|
|
|
|
|
|
|
|
|
[node name="StatusLabel" type="Label" parent="UI/PlanningMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = 32.0
|
|
|
|
|
offset_top = -160.0
|
|
|
|
|
offset_right = -32.0
|
|
|
|
|
offset_bottom = -24.0
|
|
|
|
|
theme_override_font_sizes/font_size = 28
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="CloseButton" type="Control" parent="UI/PlanningMenu"]
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = -140.0
|
|
|
|
|
offset_top = 20.0
|
|
|
|
|
offset_right = -24.0
|
|
|
|
|
offset_bottom = 136.0
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 1
|
|
|
|
|
glow_color = Color(0.62, 0.74, 0.92, 1)
|
|
|
|
|
|
#102/#103 (#97d/#97e): the outpost, and the garrison you compose for it
Landed together because an outpost you cannot crew is decoration, and a
garrison menu with no building to hang it off is nothing at all.
#102, the building. Researched at "Forward Bases", two prerequisites deep
and cheaper than any mid-game structure - the ticket asks for early, and the
answer to waves attacking your buildings should arrive at about the time the
waves can hurt them. It is drawn as a watch mast on a tripod with two open
berths, deliberately the least machinery of any structure here: it makes
nothing and refines nothing, it holds a position. 120hp, more than a
crafter, because being shot at is its job.
#103, the garrison. Two separate things live on its record, and conflating
them was the first thing to get wrong: the ORDER, what the player asked for,
and the CREW, who is actually there. This menu edits the order only; #104
fills the crew. Keeping the order as a wish is what lets an outpost ask for
a hull nobody has built yet and wait for it, rather than the request
evaporating - and it is why the panel shows "here / ordered" instead of one
number.
"Only ships that attack can be assigned" is expressed as capabilities rather
than a list of types, so a new armed vessel is eligible the day it is added
and an unarmed one never is by accident. Today that means the interceptor
and the laser vessel; a shield, a hauler and an engine block cannot hold a
position however much one might want them to.
Two berths by default, and Garrison Bays raises it at outposts ALREADY
standing - the same shape as freight_yards for hubs, because a bonus that
only reached new buildings would mean demolishing and rebuilding to collect
it.
The panel builds its own rows from the catalog rather than from nodes placed
in the scene, so adding an armed vessel later needs no scene surgery.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:02:20 +02:00
|
|
|
[node name="GarrisonMenu" 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/GarrisonMenu"]
|
|
|
|
|
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/GarrisonMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24.0
|
|
|
|
|
offset_top = 20.0
|
|
|
|
|
offset_right = -200.0
|
|
|
|
|
offset_bottom = 82.0
|
|
|
|
|
text = "Outpost Garrison"
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
|
|
|
|
|
[node name="Panel" type="Control" parent="UI/GarrisonMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 40.0
|
|
|
|
|
offset_top = 120.0
|
|
|
|
|
offset_right = -40.0
|
|
|
|
|
offset_bottom = 620.0
|
|
|
|
|
script = ExtResource("33")
|
|
|
|
|
|
|
|
|
|
[node name="StatusLabel" type="Label" parent="UI/GarrisonMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
|
|
|
|
offset_left = 32.0
|
|
|
|
|
offset_top = -160.0
|
|
|
|
|
offset_right = -32.0
|
|
|
|
|
offset_bottom = -24.0
|
|
|
|
|
theme_override_font_sizes/font_size = 30
|
|
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
|
|
|
|
text = ""
|
|
|
|
|
|
|
|
|
|
[node name="CloseButton" type="Control" parent="UI/GarrisonMenu"]
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = -140.0
|
|
|
|
|
offset_top = 20.0
|
|
|
|
|
offset_right = -24.0
|
|
|
|
|
offset_bottom = 136.0
|
|
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 1
|
|
|
|
|
glow_color = Color(0.72, 0.86, 0.45, 1)
|
|
|
|
|
|
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)
|
|
|
|
|
|
2026-08-23 11:35:01 +02:00
|
|
|
[node name="Bar" type="Control" parent="UI/SkillMenu"]
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
|
|
|
|
offset_left = 24.0
|
Sharpen fleet handling, widen the laser, and fix the map editor's file identity
The fleet had a second of inertia in it: every vessel's acceleration sat at
roughly its own top speed, so flipping the stick while cruising took 0.58s to
take effect and let go coasted 222 units, while the formation anchor the ships
chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring
rather than taste - past 3x the reversal time stops improving because
max_speed becomes the limit. Measured after: 0.18s and 23 units.
test_fleet_agility guards all three numbers and proves the bounds discriminate
by re-running the same measurement at the old value.
The laser reaches 1450 instead of 950 and strikes 38 units either side instead
of 22. Its drawn width is now derived from the hit width: the two were
independent numbers that had drifted, so the beam killed things it visibly
missed. LaserController's aim range also stopped hardcoding a second copy of
950. Tapping the laser button without dragging used to do nothing at all - the
press was claimed, the aim begun, then thrown away on release. It now fires at
the nearest enemy in range; dragging still aims precisely. That lives in the
shared aimed-ability controller, so the gas bomb gains it too.
Planets sat one per ~29 chunks - some 35,000 units of nothing between them.
Now one per ~12, measured over 14,641 chunks. The two thresholds moved by
different amounts deliberately: every SPACE-biome planet is a gas giant, so
lowering both equally would have tripled the gas-giant share as well. This
changes how often you find a planet, not what you find. Extractors produce
half as fast to match, so expanding is what grows the economy.
The research screen gave its tree 386px of 1280 and the text below it 520.
The text is now at the bottom, the tree has 550, and the resource table has
room and legible type - and its LOCAL column is no longer hidden behind the
close button.
Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME
are not the same thing, and both save and delete rebuilt the path from the id.
ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked
for a file that does not exist and silently refused - which read as "the first
item in the list cannot be deleted" - while saving it wrote a second file
under the derived name and left the original behind, so the pool served the
stale twin. A third bug hid behind those: rescan() re-read through Godot's
resource cache and handed back pre-save values even when the file on disk was
correct. All three present to a player as "my change was not saved".
Research labs no longer grant a point of their own; what conquering one is
worth comes entirely from its authored map, as asked. The shipped lab map
carries 1 so the balance is unchanged - only where it is configured moved.
Suite 109/109. Four tests changed because the behaviour they pinned changed:
the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather
than a constant tuned to one acceleration; the extractor wait derives from
EXTRACTOR_RATE; the research-point test asserts the delegation; and the black
hole test no longer assumes nobody will ever author a void-profile map.
test_planet_setups and test_planet_map_assignment stopped depending on which
maps happen to be in the content folder, which was making them fail when maps
were added or deleted elsewhere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:11 +02:00
|
|
|
offset_top = 20.0
|
|
|
|
|
offset_right = -160.0
|
2026-08-23 11:35:01 +02:00
|
|
|
offset_bottom = 156.0
|
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
|
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
|
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
|
2026-08-23 11:35:01 +02:00
|
|
|
offset_top = 168.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_right = -24.0
|
#93: drive the research menu with a mouse, and close the hole under it
Two separate faults, both reported on the same ticket.
The menu was inert under a mouse. Input reaches the tree as raw events
through BuildController._unhandled_input, because a Control that consumes
them through the GUI system swallows the drag, and the tree only ever read
touch events. That was invisible while the project set
emulate_touch_from_mouse and every click arrived as a synthetic touch; with
that setting gone, nothing selects and nothing scrolls, and there is no
other way to research anything on a desktop. The press and the pan are now
the behaviour, with touch and mouse as two ways in to them. Motion pans only
while the button is held - a hovering pointer must not drag the tree out
from under the reader - and the wheel scrolls, which is the first thing a
desktop player reaches for.
The panel also still had the buy button's hole in it. That button went away
in #83 and nothing moved down into the space, leaving ~180px of dead panel
below the readout while the tree above it stayed cramped. The readout moves
down 154px and the canvas takes the height: 1190px to 1344px.
The test drives clicks through BuildController rather than into the view,
since the missing piece was the routing - calling the view directly would
have passed against the bug as reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
|
|
|
offset_bottom = -280.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
script = ExtResource("21")
|
|
|
|
|
|
|
|
|
|
[node name="DetailLabel" type="Label" parent="UI/SkillMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
2026-08-11 20:17:58 +02:00
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_left = 32.0
|
#93: drive the research menu with a mouse, and close the hole under it
Two separate faults, both reported on the same ticket.
The menu was inert under a mouse. Input reaches the tree as raw events
through BuildController._unhandled_input, because a Control that consumes
them through the GUI system swallows the drag, and the tree only ever read
touch events. That was invisible while the project set
emulate_touch_from_mouse and every click arrived as a synthetic touch; with
that setting gone, nothing selects and nothing scrolls, and there is no
other way to research anything on a desktop. The press and the pan are now
the behaviour, with touch and mouse as two ways in to them. Motion pans only
while the button is held - a hovering pointer must not drag the tree out
from under the reader - and the wheel scrolls, which is the first thing a
desktop player reaches for.
The panel also still had the buy button's hole in it. That button went away
in #83 and nothing moved down into the space, leaving ~180px of dead panel
below the readout while the tree above it stayed cramped. The readout moves
down 154px and the canvas takes the height: 1190px to 1344px.
The test drives clicks through BuildController rather than into the view,
since the missing piece was the routing - calling the view directly would
have passed against the bug as reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
|
|
|
offset_top = -272.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_right = -32.0
|
#93: drive the research menu with a mouse, and close the hole under it
Two separate faults, both reported on the same ticket.
The menu was inert under a mouse. Input reaches the tree as raw events
through BuildController._unhandled_input, because a Control that consumes
them through the GUI system swallows the drag, and the tree only ever read
touch events. That was invisible while the project set
emulate_touch_from_mouse and every click arrived as a synthetic touch; with
that setting gone, nothing selects and nothing scrolls, and there is no
other way to research anything on a desktop. The press and the pan are now
the behaviour, with touch and mouse as two ways in to them. Motion pans only
while the button is held - a hovering pointer must not drag the tree out
from under the reader - and the wheel scrolls, which is the first thing a
desktop player reaches for.
The panel also still had the buy button's hole in it. That button went away
in #83 and nothing moved down into the space, leaving ~180px of dead panel
below the readout while the tree above it stayed cramped. The readout moves
down 154px and the canvas takes the height: 1190px to 1344px.
The test drives clicks through BuildController rather than into the view,
since the missing piece was the routing - calling the view directly would
have passed against the bug as reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
|
|
|
offset_bottom = -152.0
|
2026-08-11 20:17:58 +02:00
|
|
|
theme_override_font_sizes/font_size = 34
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
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
|
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
|
2026-08-11 20:17:58 +02:00
|
|
|
anchor_bottom = 1.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_left = -64.0
|
#93: drive the research menu with a mouse, and close the hole under it
Two separate faults, both reported on the same ticket.
The menu was inert under a mouse. Input reaches the tree as raw events
through BuildController._unhandled_input, because a Control that consumes
them through the GUI system swallows the drag, and the tree only ever read
touch events. That was invisible while the project set
emulate_touch_from_mouse and every click arrived as a synthetic touch; with
that setting gone, nothing selects and nothing scrolls, and there is no
other way to research anything on a desktop. The press and the pan are now
the behaviour, with touch and mouse as two ways in to them. Motion pans only
while the button is held - a hovering pointer must not drag the tree out
from under the reader - and the wheel scrolls, which is the first thing a
desktop player reaches for.
The panel also still had the buy button's hole in it. That button went away
in #83 and nothing moved down into the space, leaving ~180px of dead panel
below the readout while the tree above it stayed cramped. The readout moves
down 154px and the canvas takes the height: 1190px to 1344px.
The test drives clicks through BuildController rather than into the view,
since the missing piece was the routing - calling the view directly would
have passed against the bug as reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
|
|
|
offset_top = -146.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_right = 76.0
|
#93: drive the research menu with a mouse, and close the hole under it
Two separate faults, both reported on the same ticket.
The menu was inert under a mouse. Input reaches the tree as raw events
through BuildController._unhandled_input, because a Control that consumes
them through the GUI system swallows the drag, and the tree only ever read
touch events. That was invisible while the project set
emulate_touch_from_mouse and every click arrived as a synthetic touch; with
that setting gone, nothing selects and nothing scrolls, and there is no
other way to research anything on a desktop. The press and the pan are now
the behaviour, with touch and mouse as two ways in to them. Motion pans only
while the button is held - a hovering pointer must not drag the tree out
from under the reader - and the wheel scrolls, which is the first thing a
desktop player reaches for.
The panel also still had the buy button's hole in it. That button went away
in #83 and nothing moved down into the space, leaving ~180px of dead panel
below the readout while the tree above it stayed cramped. The readout moves
down 154px and the canvas takes the height: 1190px to 1344px.
The test drives clicks through BuildController rather than into the view,
since the missing piece was the routing - calling the view directly would
have passed against the bug as reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
|
|
|
offset_bottom = -82.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
script = ExtResource("19")
|
|
|
|
|
digit_height = 52.0
|
|
|
|
|
|
|
|
|
|
[node name="StatusLabel" type="Label" parent="UI/SkillMenu"]
|
|
|
|
|
mouse_filter = 2
|
|
|
|
|
anchor_right = 1.0
|
2026-08-11 20:17:58 +02:00
|
|
|
anchor_top = 1.0
|
|
|
|
|
anchor_bottom = 1.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_left = 32.0
|
#93: drive the research menu with a mouse, and close the hole under it
Two separate faults, both reported on the same ticket.
The menu was inert under a mouse. Input reaches the tree as raw events
through BuildController._unhandled_input, because a Control that consumes
them through the GUI system swallows the drag, and the tree only ever read
touch events. That was invisible while the project set
emulate_touch_from_mouse and every click arrived as a synthetic touch; with
that setting gone, nothing selects and nothing scrolls, and there is no
other way to research anything on a desktop. The press and the pan are now
the behaviour, with touch and mouse as two ways in to them. Motion pans only
while the button is held - a hovering pointer must not drag the tree out
from under the reader - and the wheel scrolls, which is the first thing a
desktop player reaches for.
The panel also still had the buy button's hole in it. That button went away
in #83 and nothing moved down into the space, leaving ~180px of dead panel
below the readout while the tree above it stayed cramped. The readout moves
down 154px and the canvas takes the height: 1190px to 1344px.
The test drives clicks through BuildController rather than into the view,
since the missing piece was the routing - calling the view directly would
have passed against the bug as reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
|
|
|
offset_top = -76.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_right = -32.0
|
#93: drive the research menu with a mouse, and close the hole under it
Two separate faults, both reported on the same ticket.
The menu was inert under a mouse. Input reaches the tree as raw events
through BuildController._unhandled_input, because a Control that consumes
them through the GUI system swallows the drag, and the tree only ever read
touch events. That was invisible while the project set
emulate_touch_from_mouse and every click arrived as a synthetic touch; with
that setting gone, nothing selects and nothing scrolls, and there is no
other way to research anything on a desktop. The press and the pan are now
the behaviour, with touch and mouse as two ways in to them. Motion pans only
while the button is held - a hovering pointer must not drag the tree out
from under the reader - and the wheel scrolls, which is the first thing a
desktop player reaches for.
The panel also still had the buy button's hole in it. That button went away
in #83 and nothing moved down into the space, leaving ~180px of dead panel
below the readout while the tree above it stayed cramped. The readout moves
down 154px and the canvas takes the height: 1190px to 1344px.
The test drives clicks through BuildController rather than into the view,
since the missing piece was the routing - calling the view directly would
have passed against the bug as reported.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 23:29:34 +02:00
|
|
|
offset_bottom = -24.0
|
2026-08-11 20:17:58 +02:00
|
|
|
theme_override_font_sizes/font_size = 32
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
autowrap_mode = 2
|
|
|
|
|
horizontal_alignment = 1
|
2026-08-11 20:17:58 +02:00
|
|
|
text = ""
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
|
|
|
|
|
[node name="CloseButton" type="Control" parent="UI/SkillMenu"]
|
|
|
|
|
anchor_left = 1.0
|
|
|
|
|
anchor_right = 1.0
|
Sharpen fleet handling, widen the laser, and fix the map editor's file identity
The fleet had a second of inertia in it: every vessel's acceleration sat at
roughly its own top speed, so flipping the stick while cruising took 0.58s to
take effect and let go coasted 222 units, while the formation anchor the ships
chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring
rather than taste - past 3x the reversal time stops improving because
max_speed becomes the limit. Measured after: 0.18s and 23 units.
test_fleet_agility guards all three numbers and proves the bounds discriminate
by re-running the same measurement at the old value.
The laser reaches 1450 instead of 950 and strikes 38 units either side instead
of 22. Its drawn width is now derived from the hit width: the two were
independent numbers that had drifted, so the beam killed things it visibly
missed. LaserController's aim range also stopped hardcoding a second copy of
950. Tapping the laser button without dragging used to do nothing at all - the
press was claimed, the aim begun, then thrown away on release. It now fires at
the nearest enemy in range; dragging still aims precisely. That lives in the
shared aimed-ability controller, so the gas bomb gains it too.
Planets sat one per ~29 chunks - some 35,000 units of nothing between them.
Now one per ~12, measured over 14,641 chunks. The two thresholds moved by
different amounts deliberately: every SPACE-biome planet is a gas giant, so
lowering both equally would have tripled the gas-giant share as well. This
changes how often you find a planet, not what you find. Extractors produce
half as fast to match, so expanding is what grows the economy.
The research screen gave its tree 386px of 1280 and the text below it 520.
The text is now at the bottom, the tree has 550, and the resource table has
room and legible type - and its LOCAL column is no longer hidden behind the
close button.
Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME
are not the same thing, and both save and delete rebuilt the path from the id.
ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked
for a file that does not exist and silently refused - which read as "the first
item in the list cannot be deleted" - while saving it wrote a second file
under the derived name and left the original behind, so the pool served the
stale twin. A third bug hid behind those: rescan() re-read through Godot's
resource cache and handed back pre-save values even when the file on disk was
correct. All three present to a player as "my change was not saved".
Research labs no longer grant a point of their own; what conquering one is
worth comes entirely from its authored map, as asked. The shipped lab map
carries 1 so the balance is unchanged - only where it is configured moved.
Suite 109/109. Four tests changed because the behaviour they pinned changed:
the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather
than a constant tuned to one acceleration; the extractor wait derives from
EXTRACTOR_RATE; the research-point test asserts the delegation; and the black
hole test no longer assumes nobody will ever author a void-profile map.
test_planet_setups and test_planet_map_assignment stopped depending on which
maps happen to be in the content folder, which was making them fail when maps
were added or deleted elsewhere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:11 +02:00
|
|
|
offset_left = -140.0
|
|
|
|
|
offset_top = 20.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
offset_right = -24.0
|
Sharpen fleet handling, widen the laser, and fix the map editor's file identity
The fleet had a second of inertia in it: every vessel's acceleration sat at
roughly its own top speed, so flipping the stick while cruising took 0.58s to
take effect and let go coasted 222 units, while the formation anchor the ships
chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring
rather than taste - past 3x the reversal time stops improving because
max_speed becomes the limit. Measured after: 0.18s and 23 units.
test_fleet_agility guards all three numbers and proves the bounds discriminate
by re-running the same measurement at the old value.
The laser reaches 1450 instead of 950 and strikes 38 units either side instead
of 22. Its drawn width is now derived from the hit width: the two were
independent numbers that had drifted, so the beam killed things it visibly
missed. LaserController's aim range also stopped hardcoding a second copy of
950. Tapping the laser button without dragging used to do nothing at all - the
press was claimed, the aim begun, then thrown away on release. It now fires at
the nearest enemy in range; dragging still aims precisely. That lives in the
shared aimed-ability controller, so the gas bomb gains it too.
Planets sat one per ~29 chunks - some 35,000 units of nothing between them.
Now one per ~12, measured over 14,641 chunks. The two thresholds moved by
different amounts deliberately: every SPACE-biome planet is a gas giant, so
lowering both equally would have tripled the gas-giant share as well. This
changes how often you find a planet, not what you find. Extractors produce
half as fast to match, so expanding is what grows the economy.
The research screen gave its tree 386px of 1280 and the text below it 520.
The text is now at the bottom, the tree has 550, and the resource table has
room and legible type - and its LOCAL column is no longer hidden behind the
close button.
Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME
are not the same thing, and both save and delete rebuilt the path from the id.
ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked
for a file that does not exist and silently refused - which read as "the first
item in the list cannot be deleted" - while saving it wrote a second file
under the derived name and left the original behind, so the pool served the
stale twin. A third bug hid behind those: rescan() re-read through Godot's
resource cache and handed back pre-save values even when the file on disk was
correct. All three present to a player as "my change was not saved".
Research labs no longer grant a point of their own; what conquering one is
worth comes entirely from its authored map, as asked. The shipped lab map
carries 1 so the balance is unchanged - only where it is configured moved.
Suite 109/109. Four tests changed because the behaviour they pinned changed:
the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather
than a constant tuned to one acceleration; the extractor wait derives from
EXTRACTOR_RATE; the research-point test asserts the delegation; and the black
hole test no longer assumes nobody will ever author a void-profile map.
test_planet_setups and test_planet_map_assignment stopped depending on which
maps happen to be in the content folder, which was making them fail when maps
were added or deleted elsewhere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:11 +02:00
|
|
|
offset_bottom = 136.0
|
Skill tree, node-based building animation, bigger UI, and a 19x faster test suite
Gameplay and UI
- Research tree at the mothership gates which structures can be built and
grants permanent fleet-capacity upgrades (GameState.SKILL_TREE,
SkillTreeView). Node depth is derived from prerequisites, so the layout
cannot drift out of step with the dependencies.
- Building info popup before committing to a build, with per-building cost
and description.
- Ship crafter redrawn as a space factory with an assembly animation;
mothership redrawn as a radial flagship; command centre as a plotting hub.
- Keyboard and mouse support (WASD, Q/E pivot, wheel zoom) for the web build.
- UI and font scaled up for phone use, via a custom Theme resource -
gui/theme/default_font_size does not reach the default theme.
- Asteroids no longer spawn on top of the fleet's start position.
- Fleet formation origin derived from the layout's own offsets rather than
the centroid, fixing the lurch when a lopsided formation started moving.
- Fleet.stop() brakes from the ship's TRUE motion (velocity +
fleet_velocity). Ship zeroes its velocity when seated in its slot even
while the anchor drags that slot forward, so braking from velocity alone
stopped the fleet dead instead of coasting - and whether it did depended
on the frame rate.
Animation architecture (issue #10)
- Buildings, projectiles and explosion VFX no longer animate by redrawing.
Static geometry is rasterised once in _draw(); moving parts are NeonPiece
children animated through node properties, which reuse the cached
geometry. Every NeonDraw call expands into four antialiased polylines, so
redrawing to move something re-tessellated all of it.
Test suite (issue #8): 1075s -> ~55s
- Runs from a copy on Termux's own filesystem. The project lives on
Android's FUSE bridge, read through proot, where load("res://Main.tscn")
alone cost 8.5s per test against ~2s natively - and nearly every test
loads it.
- Runs 6 tests at a time, in a single proot-distro login, with output
buffered per test and printed only on failure.
- --fixed-fps 60 pins delta instead of measuring the wall clock, so a test's
result no longer depends on how busy the machine is. Without it,
parallelism made two tests fail on 2 of 3 runs.
- A test passes only if it both exits 0 and prints ": PASS".
- 38 tests, green on three consecutive runs.
Bundles Carrois Gothic SC (Apache 2.0) with its licence text.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 15:00:41 +02:00
|
|
|
script = ExtResource("10")
|
|
|
|
|
icon = 1
|
|
|
|
|
glow_color = Color(0.55, 0.6, 1, 1)
|