Every button in the web build was dead - reported as "Play does nothing".
Diagnosed on the deployed build with a temporary on-screen input probe,
because none of it reproduces here: the suite passes, and pressing Play under
the real gl_compatibility renderer (the same path WebGL2 takes) reaches
Main.tscn fine. The probe reported, from a phone browser:
#6 touch down @ 362,781
play rect 296,725 128x128
hit=YES
Three taps, six events, every one a DOWN and not a single UP - and the button
left drawn in its bright held state, pressed_down stuck true because nothing
ever came to clear it. So touches arrive, their coordinates are correct, and
they land inside the button; the browser simply never delivers the release,
in _gui_input or in raw _input.
IconButton emits `pressed` only on release, deliberately, so that dragging
off a button cancels it. With no release that means it never emits at all -
on every button in the game, not just Play. Which also explains why the
earlier suspects went nowhere: the scene change was never reached, so it was
never the scene change, and hit=YES ruled out coordinate mapping.
fire_on_press defaults to OS.has_feature("web"). There, a press completes the
tap itself and does NOT latch, since nothing is coming to unlatch it. Every
other platform is untouched and keeps drag-off-to-cancel.
The cost, stated plainly: a web tap can no longer be cancelled by sliding off
before lifting, and that applies to destructive buttons too. The alternative -
keeping release-firing and treating a new press as completing the previous
one - preserves cancellation but leaves the very first tap dead, which is
worse.
tests/test_icon_button_press_fires.gd drives the flag directly, since a
headless Linux run cannot BE a web build: one tap emits exactly once, a late
release does not emit again, the button does not latch, and with the flag off
the release still drives the press and dragging off still cancels.
MainMenu keeps the load/start bisection introduced while chasing this - a
failed change_scene_to_packed otherwise leaves the menu up, which looks
exactly like an unpressed button.
Full suite green at 100/100.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Adds a Dev Mode entry to the main menu and takes the play-testing
conveniences out of a normal game, which turn out to be the same change
from two directions.
DEV MODE. Banks 2000 of every resource, grants 500 research points, and
plants one of each planet type in the chunks around the spawn. Built ON TOP
of reset_new_game() rather than beside it, so a dev game is a normal game
plus a stock rather than a second definition of "fresh game" to keep in
sync. Offered only when running from Godot - OS.has_feature("editor"), the
tag an export clears - as is the map editor. Hidden AND guarded: pressing
either anyway is refused, because visibility is presentation and the rule is
the rule.
The menu now lays its stack out in code. Hiding two of four entries with
scene-authored offsets would leave holes in a shipped build - the same
failure the HUD columns had - so it measures the entries that actually exist
and centres on them.
A NORMAL GAME NOW HANDS OVER NOTHING. No 500 banked ore (removed from both
reset_new_game and the autoload's own default, so the two cannot disagree),
and no gas giant guaranteed in the origin chunk. Both were play-testing
conveniences that had become part of the real world's shape: every player
got the same landmark in the same place. Play-testing wanted all four planet
types anyway, and a normal game wanted none of them - different needs, now
different mechanisms.
WorldGen cannot read GameState back (an autoload is not resolvable as a
global identifier that early, the hazard PlanetSetups.gd already works
around), so GameState.dev_mode's setter PUSHES the flag down. World
generation stays static and dependency-free, GameState stays the single
source of truth, and dev planting is applied after every rng draw so a dev
world and a normal one differ only in those four chunks.
FLEET SIZE. BASE_FLEET_SIZE was doing two jobs - how many slots exist AND
how many ships you start with - which forced a new game to open with a full
fleet, leaving the first ship crafter nothing to do. Split into
BASE_FLEET_SIZE (3 slots) and STARTING_SHIP_COUNT (1 vessel), so the opening
has two empty slots to fill. A third copy of the old value turned up in
PlanetAtmosphereController, hardcoded as spawn_ships(5) and silently
degraded into "however many slots exist" once max_fleet_size() clamped it.
The doctrine branch now runs 3 -> 10 slots. Wing (30 -> 15) and Squadron
(70 -> 35, 2 -> 1 points) are cut hardest: they are no longer a mid-game
luxury but the ordinary way out of the opening, and pricing them as a luxury
made the early game feel stuck. Armada follows at 90/2. Two new tiers,
Battlegroup and Grand Fleet, grant +2 each - seven single-vessel nodes in
one lane would be a long monotonous chain for a branch that only ever does
one thing. DEFAULT_FORMATION grows to 10 slots, because max_fleet_size()
clamps to its length and a doctrine past that would charge real resources
for nothing; test_fleet_growth.gd asserts that invariant directly.
TEST FALLOUT, all of it from the deliberate change rather than a defect:
- Tests that silently inherited the old 5-ship default now ask for the fleet
they need. Several had to crew it from their first frame rather than
_initialize(), where the engine's deferred tree-entry finalization undoes
it - the same hazard those tests already documented for set_process(false).
- test_planet_landing_proximity and test_return_position_matches_planet take
the FIRST chunk holding a planet and land there. The guaranteed gas giant
had been masking that this can now be a black hole, which destroys ships on
contact. They exclude it, and clear the asteroids the field already placed.
- test_pivot_controls measured rotation with angle_difference, which wraps at
+/-pi, so a hold that turned a full circle read as no rotation. Latent
flakiness that only ever showed under load; it now reads the controller's
unwrapped pivot_hold_amount.
- test_research_points was failing on ore, not points: can_unlock() checks
the ore price too, and a fresh game banks nothing now.
- test_gas_system's "a reachable gas source near the spawn" premise moved to
dev mode, which is where that guarantee now lives.
Full suite green at 97/97.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seating the HUD columns below the resource readout moved the build button
from the scene-authored 160 to 288. _layout_context_buttons() then wrote the
action row straight back to a hardcoded 324 on the next context change - and
it runs on the first frame, so the action button overlapped the build button
immediately.
Same shape of bug as the overlap that seating fixed: a literal coordinate
that meant "directly below the thing above me" and silently stopped being
true when that thing moved. It now measures instead:
row_top = build_button.position.y + build_button.size.y + HUD_ROW_GAP
Both the action button and the expanded context row derive from that, so
wherever the build button ends up, the row below follows.
tests/test_hud_layout.gd asserts the RELATIONSHIP rather than any
coordinate, so a freshly hardcoded y fails whatever value someone picks:
every HUD button clears the readout's real bottom, and no two
simultaneously-usable buttons overlap - checked at load, collapsed and
expanded, which is the path that broke. BuildingActionButton and
HangarButton are excluded as a deliberately exclusive pair.
Verified to fail against the previous code with the reported symptom:
build_button y288..436 overlapping action_button y324.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The build button overlapped the resource list. ResourceReadout builds one
row per resource type AT RUNTIME (58px each), so how far down it reaches is
not knowable when the scene is authored: PlanetSurface/Main declared
offset_bottom 154, four resources actually reach 270, and BuildButton sat
at a hardcoded 160. A 110px collision that grew with every resource type
added. Because the readout spans the full width - the fleet hold column is
at x 356 - it hit both button columns, TransferButton and
EnterAtmosphereButton as well as the left one.
Rather than nudge the offsets, the layout now derives from the readout:
ResourceReadout.rows_height()/content_bottom() report the real extent and
_ready() stops the node understating its own size, and
BuildController._seat_hud_columns() seats both columns below that at load.
Adding a fifth resource type pushes the buttons down on its own, so the
overlap cannot come back.
Two details worth keeping: the height is derived from the live resource
list rather than cached in _ready(), because BuildController readies before
UI's children in scene-tree order and a cached value would answer zero. And
it translates the block rather than re-flowing it, since
BuildingActionButton and HangarButton deliberately share a row as mutually
exclusive options.
The planet name moved from the centre - where it sat across resource rows
3 and 4 - to the top-right corner, right-aligned. Right alignment is what
keeps it clear: short names sit against the right edge, well clear of the
fleet hold column, and long ones wrap downward into empty space rather than
growing left into it. That scene edit rode along in the #68 commit, both
being changes to PlanetSurface.tscn.
Also adds three .uid files orphaned by earlier commits this session; the
repo tracks them for every other script.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Rotating the fleet and spamming a direction let vessels fall out of sync
and fly at wildly high speeds. The pivot cooldown added earlier throttled
how often the exploit could be triggered; it never touched the cause.
Fleet.stop() did `ship.velocity = ship.velocity + ship.fleet_velocity`,
compensating for the fact that Ship.velocity read zero during cruise. The
next steer refilled fleet_velocity, so every press-release cycle added a
whole cruise velocity to the ship's own, decaying only at `acceleration` in
between. Tapping faster than that bled it off stacked them without limit,
and ships desynced because each bled off at a rate set by its own distance
to its slot. Measured before this change: spamming a direction while
pivoting flew the fleet 32737 units in 3s against 784 for simply holding
the stick, with a vessel reaching 48x its own top speed.
The compensation existed because `velocity` was not the ship's real motion:
Ship snapped to its slot every tick and zeroed it, so the truth lived in a
second field and anything wanting it had to add the two together. Fixed at
that root rather than by clamping the symptom:
- fleet_velocity is now fed FORWARD into the steering instead of carried
alongside it. The ship aims to travel at its slot's velocity plus a
correction closing the gap, so holding formation costs no error and
`velocity` is always true world motion.
- The snap only applies when the slot is standing still, which is the one
case where converging asymptotically would leave a residue. While the
slot moves the ship steers continuously - a snap there was the teleport
that made `velocity` lie in the first place.
- A hard bound on the INTEGRATED result every tick, not merely on the
request, so no sequence of commands can leave a vessel over its own top
speed.
- Fleet.stop() injects nothing; it reports that the slot has halted.
tests/test_fleet_speed_bounded.gd covers it, and fails against the previous
code with the numbers above: no vessel exceeds its own top speed however
hard the direction is spammed, spamming cannot cover more ground than
holding the stick, both hold while the formation is pivoting, and the fleet
stays together.
test_space_time_distorder.gd now clears the asteroid and enemy groups at
setup, the same clean-slate idiom test_ship_lab.gd uses. Silencing the
spawners was never enough - what Main.tscn had already placed kept moving,
and losing the distorder vessel to a rock resets the multiplier correctly,
which the test then reported three stages later as a failed scene swap. It
also checks it still crews a distorder vessel before relying on that.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The crater shader ran on every pixel of a fullscreen rect every frame and
was by far the most expensive thing in the surface scene. Nothing else came
close: RockField keeps 14 rocks alive, Rock/Ship/Enemy already avoid
per-frame queue_redraw() for transform-only changes, and LunarBackground.gd
is a handful of scalar ops.
Three reductions to the field itself:
- 5x5 -> 3x3 neighbour scan. That width was never the geometric answer;
it was insurance against craters seen clipping at cell boundaries
on-device, i.e. a crater reaching past its nominal radius because a hash
returned a value outside [0,1] and extrapolated mix(). Clamping the
crater CENTRE into its own cell, alongside the radius clamp already
there, bounds the reach whatever the hash returns - so a crater two cells
out is >= 1.0 cells away, a normalized distance of >= 2.63, past every
threshold the shading reacts to (the last saturates at 1.15). The outer
ring provably cannot change a pixel. This removes the clipping bug's
cause instead of hiding it behind 16 extra samples.
- One hash42 per cell instead of hash21 twice plus hash22, decorrelating
on output lanes rather than input offsets.
- Squared distances in the loop, square-rooted twice at the end rather
than once per sample.
Measured with the new tests/profile_shader.sh, above softpipe's own ~657ms
fullscreen floor: 9482ms -> 405ms of shader work, a 23x reduction.
Then the larger change: the field is a fixed function of world position, so
every frame recomputed an identical answer. It is now made periodic (the
cell index is wrapped before hashing, which makes a Worley field tile
exactly rather than merely blend), baked once at load into one tile, and
scrolled with repeat wrapping by lunar_tiled.gdshader - one texture fetch
per pixel. Two honest costs: the field repeats every 7040 world units, and
a fixed-resolution tile softens when zoomed past 1:1. Lunar regolith is
forgiving of both, having no landmarks and being smooth gradients already.
The bake waits a frame and asks the material whether it actually samples a
field_texture, so a gas giant - which swaps in its own background shader
(#51) - does not pay for a 2048-square tile it will never read. Headless
runs skip it entirely, having nothing to rasterize.
tests/test_lunar_field.gd guards the reasoning, since a fragment shader
cannot be asserted on directly: the premises are still in the source, the
worst-case ring-2 geometry stays clear of every threshold independent of
the hash, a 3x3 and a 5x5 scan render identically over 4000 sampled points,
the field repeats exactly in both axes, and the miss sentinel still cannot
overflow mediump into +Inf and then NaN.
test_surface_profiles.gd asserted "a rocky landing leaves the background
alone" by naming lunar_surface.gdshader; it now reads the shader from the
scene, which is the property it actually cares about.
PlanetSurface.tscn's edit also carries the planet-name relocation described
in the HUD commit - same scene file, so the two cannot be split.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Strayed 2.6x over its old allowance (77.7 vs 30.0) under one heavily
loaded JOBS=1 full-suite run, then passed cleanly in isolation
immediately afterward - device jitter, not a regression. The wider
margin still leaves orders-of-magnitude headroom below what a real
formation-desync bug (#72) would actually produce.
#64: Load used to blindly cycle to "the next" saved setup with no way
to see what existed or jump straight to one by name. It now opens a
real selectable ItemList of every saved setup (name + surface profile),
tap one to load it.
#65: a single-finger drag over empty canvas could never pan - the
touch handler placed an item on PRESS, before a drag had any chance to
happen, so the "pan" branch below it was unreachable dead code (it only
fired when selected_palette == "", which nothing in the UI can ever
produce). Placement now waits for release: released within
PAN_DEADZONE of where the finger went down is a tap (place), crossing
it partway through is a pan - the same tap-vs-drag deadzone idiom
GasBombController already uses for its own aim gesture.
#66: added a persistent "Selected: <kind> #<n>" label, refreshed
wherever selected_item changes (touch-select, new/load a setup,
delete), so a tap actually confirms what got picked instead of the
player inferring it from which dot on screen turned white.
Also widened test_space_time_distorder.gd's formation-lag margin after
it strayed 2.6x over its old allowance under one heavily loaded
JOBS=1 full-suite run and passed cleanly in isolation immediately
after - device jitter, not a regression; the wider margin still leaves
orders-of-magnitude headroom below a real desync bug's stray distance.
#74: RESEARCH_LAB_CHANCE raised from 0.08 to 0.16 - research points
gate mid/late skill-tree nodes and vessel/lab research now (#63), so
0.08 was too scarce for how central they'd become to progression.
#75: an extractor placed on a research_lab planet would sit on an
empty resource id forever, since it yields nothing by design. Refused
in BuildController's placement confirm, with the same "explain the
refusal" idiom every other build gate uses. register_capture_points()
gained an optional definition_id parameter so the refusal/reward logic
can tell a research_lab planet apart without threading an extra
argument through every existing caller.
#76: conquering a research_lab awarded a research point with no
on-screen acknowledgement beyond a HUD number the player has no reason
to be watching at that exact moment. CaptureLabel's existing
"CONQUERED" flash now names the reward directly on a research_lab.
test_extractor_building.gd and test_planet_conquest_gate.gd both use a
"first planet chunk found" scan with no regard for definition_id; in
this world's fixed seed that chunk happens to be a research_lab, so
#75's new gate started refusing their otherwise-unrelated extractor
placement checks. Both now skip a research_lab chunk when picking
their target, same as test_research_lab_extractor_gate.gd does on
purpose for its own dedicated coverage of that refusal.
_finish_pivot_tap() granted a full PIVOT_MIN_STEP rotation on every
button/key release with no rate limit, so tapping fast enough rotated
the formation far beyond PIVOT_SPEED's smooth held-rate cap - well
above what holding the button down can ever produce. Each of those
artificially-frequent re-seats (Fleet.apply_formation()) forced every
ship into a fresh max-speed catch-up dash toward its new slot with no
time to settle between dashes, and since outer-wedge ships swing
further per pivot than inner ones, spamming made them visibly diverge
in speed while each ship's own bounded max_speed made the fleet read
as constantly pinned at its speed ceiling.
Added a per-direction cooldown (the time a genuine hold needs to reach
PIVOT_MIN_STEP on its own) so tap-spam can't out-pace holding the
button. Deliberately NOT shared between CW/CCW: a quick correction tap
the other way right after an overshoot is normal play, and
test_keyboard_input.gd already covers Q and E each independently
producing their own minimum step back-to-back - only repeatedly
re-tapping the SAME direction needed capping.
Chasers (EnemyPursuitComponent) and snipers (EnemyStandoffComponent)
used to beeline/close in from anywhere on the map the instant they
spawned - no matter how far the fleet was, which read as omniscient
rather than alert. Both now sit idle until the fleet is within their
own detection_range. Artillery's slow drift is gated the same way, but
reuses its own existing fire_range rather than a new tunable - outside
its firing envelope it has nothing to be drifting toward yet.
The enemy mothership deliberately keeps the opposite behaviour: it is
meant to read as a persistent, unavoidable stalking threat, not a
local sentry, so it gets its own EnemyPursuitComponentMothership.tscn
variant with an effectively unlimited detection_range - the same
scene-variant pattern EnemySpawnerComponentChaser/Artillery already
use for per-definition property overrides on a shared component script.
int_speed/shd_speed granted +max_speed/+acceleration per level to a
single vessel, which is redundant now that #59/#62 gave the whole
fleet a shared speed fader instead - a per-ship speed stat has nothing
left to meaningfully affect since #59's multiplier is applied at the
point of use in Ship.gd regardless of the ship's own base stats.
Deleted both upgrade resources and their vessel-definition references
outright rather than leaving them unused.
test_ship_lab.gd's per-vessel-type isolation check used int_speed as
an arbitrary interceptor-only upgrade to prove it doesn't leak into
transporter stats - swapped to int_range, which still exists. Its
upgrade-card-count assertion updated for 3 remaining interceptor
upgrades instead of 4.
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.
Squadron Doctrine and Power Systems both sat at depth 3, x=0.50,
landing on the exact same screen position - Squadron's own
prerequisite chain (coordination -> wing -> squadron -> armada) zigzags
x from 0.50 to 0.82 back to 0.50, colliding with Freight's branch at
that depth. Kept the whole fleet-size doctrine branch at x=0.82 (wing's
own lane) instead, so it runs straight.
Added a structural regression test: no two SKILL_TREE nodes may share
the same (skill_depth, x), computed the same way SkillTreeView itself
places nodes.
GameState._advance_distorder_drain() runs in GameState._process() -
not the distorder component's tick() - alongside extractor mining and
production, so it (and the fleet's travel) keeps working across the
space<->surface scene swap. Drain scales with how far above 1.0 the
multiplier is: (fleet_speed_multiplier - 1.0) / (MAX - 1.0) *
ENERGY_DRAIN_PER_SECOND (2.0 at full boost), accumulated fractionally
the same way extractor mining_progress is so small multipliers still
drain a nonzero amount instead of rounding to zero every frame.
Running the fleet hold's energy to exactly zero force-resets
fleet_speed_multiplier to 1.0 and raises a one-shot
boost_depleted_notice flag, since GameState can't reach into whichever
scene's SpeedFader may or may not currently exist. SpeedFader.gd
consumes the flag on its next _process(), snaps its knob down (it was
already reading the multiplier live, so this falls out for free) and
shows "Out of energy!" - also clearing active_touch_index so a
still-held drag can't immediately re-boost from the position the
finger never moved away from.
test_space_time_distorder.gd (#59) updated to stock fleet energy
first, for the same reason #60/#61 needed it: boosting is no longer
free, and that test's own multi-second boosted phases would otherwise
get cut short mid-measurement by running out.
Mirrors #60's gas bomber ammunition exactly: ENERGY_PER_SHOT (8) drawn
from GameState.fleet_inventory before consuming the firing ship's
cooldown, the button's enabled rule requires affordability too, and an
unaffordable-but-otherwise-ready press still explains itself through a
new LaserStatus label rather than silently doing nothing.
Added two small generic GameState helpers this needed:
deposit_fleet_resource()/deposit_bank_resource(), counterparts to
#60's withdraw_fleet_resource() for resources (energy) with no
dedicated fleet_cargo/fleet_gas_cargo-style property. Along the way,
confirmed deposit_resource_to_building() on a "bank" building deposits
into that building's own per-record inventory, NOT bank_inventory
itself - only building_resource()/building_inventory() special-case
the "bank" capability to redirect there.
test_laser_vessel.gd (#58) updated to stock fleet energy first, since
shots are no longer free - same fix#60 required for the gas bomber's
own pre-existing tests. Also fixed test_laser_vessel.gd's own instance
of the bare-ClassName.CONST script-corruption trap (documented in
#60's commit): var skill: LaserController and a bare
LaserController.BEAM_HALF_WIDTH reference, mirrored into a local const
instead.
Shots cost GAS_PER_SHOT (5) from GameState.fleet_inventory, not the
bank - the fleet has to be carrying its own ammunition. The button's
enabled rule now also requires affordability, and a press on a ready-
but-unaffordable bomber still consumes the touch to explain itself via
a new status label (GasBombStatus, IconButton's own "greyed but still
pressable" convention) rather than either silently doing nothing or
consuming the bomber's cooldown for a shot that never fires.
Also documents a real, reproducible GDScript trap hit while writing
tests/test_gas_bomber_ammo.gd: a bare `ClassName.SOME_CONST` reference
anywhere in a -s entry test script can corrupt method resolution for
the WHOLE script, making an unrelated, earlier `some_node._process()`
call fail with "Nonexistent function '_process' in base 'Nil'" despite
the node being valid and the method existing (confirmed via
has_method()). Root cause unconfirmed; fixed by mirroring the constant
's value into a local const instead of referencing the class directly,
in all three gas-bomber tests.
tests/test_gas_bomber.gd and test_gas_bomber_cooldowns.gd updated to
stock fleet gas first, since shots are no longer free.
GameState.fleet_speed_multiplier (1.0-3.0) is applied at the point of
use - Fleet's cruise anchor and Ship's own max_speed/acceleration -
rather than baked into stored stats, so a stat upgrade researched
mid-boost can't corrupt the base value and the fader takes effect
immediately with no re-apply step.
Ship.arrive_radius is scaled by the same multiplier: at higher speeds
each physics tick covers a proportionally larger step, and once that
step outgrows a fixed arrive_radius the ship can overshoot its
snap-to-target zone every tick while chasing a target that's now also
receding faster - visible as the fleet stretching apart under boost.
Scaling it preserves the same "snaps onto its slot" tightness at any
boost level that 1.0x already has.
SpeedFader.gd is a self-contained vertical drag control (TouchJoystick's
raw-touch idiom, not _gui_input) that writes straight to the autoload
rather than reporting a value for something else to apply. It also
resets the multiplier to 1.0 the instant fleet.has_capability("distorder")
goes false, so a fleet can never be left permanently boosted by a vessel
it no longer has.
VesselDistorderComponent carries no per-shot behaviour (energy drain
while boosted is #62) - its presence is what matters. Registered in
VesselDefinitions, wired into the crafter/hangar/ship-lab menus per
#57's note (5/5/6 -> 6/6/7 columns).
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.
An unarmed hauler with no weapon component - only VesselCargoComponent,
so it structurally cannot fire, the same pattern that already made the
shield vessel weaponless after #35. Its cargo_capacity (120, six
interceptors' worth) makes it the first real payoff for #56's fleet
hold cap.
Wired into the crafter, hangar and ship lab menus, all of which were
already generic over VesselDefinitions.fleet()/.all() - only the
per-vessel UI *nodes* are hand-placed (Main.tscn), not the logic, so
this repacks those three button rows to 4/4/5 columns and extends
BuildController's matching onready arrays. No new signal handlers were
needed.
Also fixes test_vessel_composition.gd's hardcoded fleet-catalog size
(3 -> 4) now that a fourth vessel is fleet-eligible.
The fleet hold was unbounded - GameState.fleet_inventory had no
total_capacity, so a lone ship could carry unlimited resources. Capacity
is now data-driven: only vessels declaring the "cargo" capability
contribute their cargo_capacity stat (interceptor: 20; shield vessel and
gas bomber: 0, unarmed transporters are never in the fleet at all).
Fleet.gd recomputes it in the one place composition can change
(spawn_ships/add_ship/store_ship/_on_ship_destroyed), which also covers
the space<->surface scene-swap restore since that goes through
spawn_ships().
Rock.gd and GasVentField.gd (the two "fly over it to collect" pickup
paths) now check what collect_cargo()/collect_gas_cargo() actually
accepted before consuming their source, instead of assuming an
unlimited hold. The HUD's FLEET HOLD caption shows the live total/cap.
Also fixes test_resource_transfer.gd, which pushed more ore through a
2-ship fleet than the new cap allows - it now spawns the largest fleet
every unlocked doctrine permits, since that test is about the transfer
UI rather than the cap itself (test_fleet_cargo_limit.gd owns that).
A rare, deterministically-seeded landable body yielding a fourth
resource, dark matter, obtainable only through an extractor - never a
surface pickup. Reuses every existing generic system (resource/planet
definitions, surface profiles, extractor/transporter pipeline) with no
type-switch branching.
Also fixes a latent conquest-gating gap: a surface profile with no
authored PlanetSetup (like the black hole's "void") never registered
capture points at all, permanently blocking extractor placement.
register_capture_points() now treats zero required points as vacuously
conquered, and PlanetSurfaceController registers that zero-point state
explicitly when no setup exists.
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>
A large, slow capital enemy that periodically launches chasers and
artillery on their own intervals and fires a heavily telegraphed line
beam capable of killing several player vessels at once.
Spawning reuses #52's EnemySpawnerComponent as-is via two preset
scenes (EnemySpawnerComponentChaser.tscn: 5s/chaser,
EnemySpawnerComponentArtillery.tscn: 18s/max 2/artillery) rather than
adding multi-type support to the component - two instances of a
single-purpose component is the composition this codebase already
uses everywhere ("enemy bomber" in the original request is read here
as the existing artillery enemy's slow telegraphed AOE, not a new
enemy type - flagged as a judgment call in the ticket).
New EnemyBigLaserComponent.gd ("big_laser") fires a standalone
EnemyBigLaserBeam on a long cooldown - the beam owns its whole charge/
fire/flash sequence once launched, so the mothership dying mid-charge
doesn't cancel an already-telegraphed shot, same design as
EnemyArtilleryComponent/ArtilleryShell. The aim direction is locked
once in launch() and never re-read - nothing in the charging phase
touches the fleet's position again, which is what makes it dodgeable.
Damage is a line-segment check (projection + perpendicular distance)
against every player_ships member; Ship.take_damage() already handles
shield absorption per-ship.
MothershipEnemyDefinition.tres: max_hp 60, speed 35 (slow), a ~96-unit
hull, pursuit + two spawners + big_laser, no type switch anywhere -
every stat from the definition, every behaviour from a component.
Tests: new tests/test_enemy_mothership.gd, split into beam mechanics
(tested directly, not through the component's own cooldown timing,
which would make the geometry assertions timing-fragile) and the
composed definition (tested through a real Enemy.tscn instance).
Screenshot of the charge telegraph mid-countdown. Full suite: 80/80.
Found and fixed a real bug along the way, in EnemySpawnerComponent.gd
(#52): its `enemy_scene: PackedScene = preload("res://Enemy.tscn")`
member-level preload could get permanently baked in as a broken,
empty PackedScene when a definition's component_scenes chain led back
to Enemy.tscn while it was still mid-load - confirmed empirically via
ResourceLoader.has_cached() being true (a good copy existed) while the
preloaded reference's own resource_path was empty. This only
surfaces when a SINGLE definition composes two instances of a script
carrying such a preload (the mothership's chaser/artillery spawner
presets; #52's single-spawner turret never hit it). Fixed by
resolving enemy_scene lazily via load() on first use instead of at
compile time, and additionally made a fresh spawner count down from a
full interval before its first spawn rather than firing on tick one,
which also happens to keep two sibling spawners with different
intervals from ever landing their first attempt on the same frame.
🤖 Generated with Claude Code
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New EnemySpawnerComponent.gd (capability_id "spawner"): continuously
instantiates another enemy type beside its host at a fixed interval,
capped at max_alive concurrently, refilling as spawns die. Spawned
enemies are parented under the SPAWNER'S OWN PARENT rather than the
spawner itself, so they are siblings, not descendants - killing the
spawner can't free them, and a surface-hosted spawner (under
PlanetSetupHost) keeps its spawns under the same host instead of
leaking them to a hardcoded path, the same hazard #44 already closed
for pursuit/standoff/ranged-weapon components.
TurretSpawnerEnemyDefinition.tres: stationary (speed 0, no pursuit or
standoff component), max_hp 20 (~7x a chaser), a bulky octagon hull,
and its own acid-green glow distinct from chaser/sniper/artillery.
Registered in EnemyDefinitions.ORDER/DEFINITIONS - the map editor
palette (#48) picks it up with no editor code change.
Tests: new tests/test_turret_spawner_enemy.gd covers registration and
real definition defaults, no spawns without a fleet, spawning capped
at max_alive, a dead spawn's slot refilling, never moving, surviving
19 damage and dying on the 20th, and its spawns surviving its death
with their pursuit component intact. Screenshot beside a chaser
confirms the two read as visually distinct enemies. Full suite: 79/79.
Repo notes for the next agent, confirmed empirically this session:
- A node's set_process(false) call made before it has fully finished
entering the tree doesn't reliably stick (already documented in
tests/test_planet_atmosphere_transition.gd, and it bit this test
too): BuildController._check_fleet_wipe() kept rebuilding a ship
during an intended "empty fleet" test window even after disabling it
in _initialize(). Do it in _process()'s first real tick instead,
once _ready() cascades are confirmed complete.
- Overriding an @export interval (like spawn_interval) on an
already-running component does NOT reset its own in-progress
countdown timer - only changes what it resets TO on its next expiry.
If the countdown already started at the OLD value before your
override lands, reset the timer variable itself too, or the first
real interval after the override silently uses the stale value.
- A capped spawner's freed-slot refill can land within a couple of
frames once its interval is short - don't assert on an intermediate
"just dropped by one" count that a fast interval can blow straight
through before your next check runs. Assert the net effect instead
(the specific killed instance is gone AND a replacement filled the
slot) rather than an exact mid-transition snapshot.
🤖 Generated with Claude Code
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
lunar_surface.gdshader recoloured was the whole gas surface backdrop,
so a landed gas giant read as regolith - the crater field never went
away, just changed colour. New gas_surface.gdshader replaces it for
gas profiles only: a nearest-row-wins horizontal band field (same
single-scalar discipline as lunar's nearest-crater field), with
drifting per-row turbulence so the bands ripple instead of reading as
ruled lines. Keeps the exact same uniform interface as lunar
(camera_cell/camera_frac/camera_zoom/viewport_size/cell_size/
base_color/crater_color/highlight_color), so LunarBackground.gd needs
no changes at all.
PlanetSurfaceProfile gains background_shader (default null = keep the
scene's existing lunar shader); PlanetSurfaceController._compose_surface()
swaps the background material's shader in only when a profile names one.
GasSurfaceProfile.tres points at the new shader and retunes its palette
to a deep-atmosphere/shadowed-band/lit-crest read; RockySurfaceProfile.tres
is untouched, so the rocky surface renders exactly as before.
Precision: every hash input is either an exact integer cell/row index or
a bounded [0,1) local fraction, same split as lunar_surface.gdshader and
Starfield.gd use for the same reason (world coordinates reach the tens of
thousands, where mobile float precision collapses). TIME-based lateral
drift is folded into the lattice coordinate via the same floor/remainder
trick rather than ever being added to a large cell index directly - see
combine_lattice()'s header note.
Tests: new tests/test_surface_profiles.gd (rocky resolves no
background_shader and keeps the lunar shader; gas resolves and applies
its own, different from lunar's). Full suite: 78/78 passed. Screenshot
of the gas surface confirms drifting bands with no craters, rendered
well inside the softpipe performance budget (20 frames in ~2m40s,
against lunar's "minutes per frame" baseline the ticket warns about).
Repo notes for the next agent, confirmed empirically this session:
- Never reference a plain (non-autoload) class_name class by its bare
global name from a -s entry-point test script - `load()` it by path
into a local var instead, same as PlanetSurfaceController.gd and
PlanetSetups.gd already do for exactly this reason. Doing it the
unsafe way here didn't fail to compile - it corrupted something in
the resource-loading state badly enough that an UNRELATED scene's
Rock.tscn lost its script attachment and RockField's rock-spawning
loop exhausted the physics server's entire RID pool. If a test's
crash trace implicates code you never touched, check every bare
global class_name reference in the test first.
- Running a `tests/screenshot.sh` render (Mesa softpipe, genuinely
minutes for a crater-shader scene) at the same time as a
`run_tests.sh` full-suite run starves both for CPU on this device -
kill one before waiting on the other rather than running them
concurrently.
🤖 Generated with Claude Code
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
CapturePoint.gd left z_index at its default 0, the same layer Ship
draws on, so a ship parked inside a ring was partly swallowed by the
ring fill - exactly where the player most needs to see their own
vessels. Set z_index = -1, matching the convention every other world
object already follows (Planet, Rock, Building, Hauler, Transporter,
VesselDelivery).
Verified with a ship placed directly on a capture point in the
preview screenshot, and asserted in test_capture_points.gd.
PlanetSetupEditor authors PlanetSetup resources: pick a surface
profile (drives the real lunar_surface background, not a blank
sheet), place/move/delete capture points and enemies from a palette
generated straight off EnemyDefinitions.all() (a new enemy definition
shows up with no editor change), pan/pinch-zoom the canvas with the
same touch idiom as GameController, then save to
res://PlanetSetups/<id>.tres via ResourceSaver - reachable now from
the main menu's Map Editor button. The mutation methods
(new_setup/load_setup/add_*/move_*/remove_*/save_setup) are the whole
model and work standalone, which is what lets
tests/test_setup_editor.gd drive placement/move/delete/save/reload
directly without simulating touch input.
Every cross-file reference is a preloaded script const rather than a
bare global class name, matching #42/#44's load-order notes - this
file is instantiated from other scripts' function bodies, never as a
script-mode test entry point itself, so it wasn't at risk the same way
the test files were, but the pattern is kept consistent throughout.
Part of the #40 conquest-mechanic breakdown. This closes out the
breakdown: #41-#48 are now all implemented, tested, and merged.
EnemyArtilleryComponent is a stationary siege piece (slow drift toward
the fleet, deliberately no pursuit component) that fires at the fleet
centroid on a long cooldown via a standalone ArtilleryShell -
telegraph ring (~1.8s, growing radius plus a filling countdown arc) ->
slow visible travel -> AOE explosion via Ship.take_damage() on every
player_ships node inside, same all-or-nothing shield absorption as
every other damage source. The shell is independent of the enemy that
fired it (added to the tree root, like EnemyProjectile/Projectile) so
the shooter dying mid-flight doesn't cancel an already-telegraphed
shot, and the impact point is fixed at fire time - never re-aimed at
where the fleet moves to afterward.
Part of the #40 conquest-mechanic breakdown.
EnemyStandoffComponent holds a preferred distance from the nearest
player ship instead of ramming (advance beyond it, retreat inside
retreat_range_factor of it, drift laterally in the comfortable band
between) - never paired with a pursuit component. EnemyRangedWeaponComponent
mirrors VesselWeaponComponent for an enemy: fires an EnemyProjectile
aimed at the target's CURRENT position rather than led, so a moving
ship can dodge it (projectile_speed 260 vs the interceptor's 460
max_speed). Registered in EnemyDefinitions so it's placeable from a
planet setup by enemy_id.
test_sniper_enemy.gd went through a few iterations to get its own
timing right: physics ticks can run ahead of a SceneTree test's own
_process() clock under this device's load, so the cooldown-violation
check reads the component's own fire_timer directly (a rising value
means it refired) instead of comparing projectile counts against a
wall-clock wait, and manually repositioned ships need their
move_target re-pinned or Ship's own steering silently drives them back
to the stale target.
Part of the #40 conquest-mechanic breakdown.
CapturePoint tracks neutral/blocked/capturing/captured state by polling
proximity each frame (a ship in capture_radius, no enemy within
enemy_clear_radius), draining gradually rather than resetting when
interrupted, and calling GameState.mark_point_captured() on completion.
PlanetSetupHost now instantiates the real CapturePoint scene per
authored point (restoring already-captured state immediately on
re-landing) and spawns each setup's authored enemies, replacing the
placeholder markers from #42. CaptureLabel is a small self-polling HUD
(same convention as ResourceCounter) showing "CAPTURED n/m" or
"CONQUERED" with a one-shot fade on completion, themed per surface
profile alongside the existing bank/fleet captions.
test_planet_atmosphere_transition.gd's "no enemies on a landed
surface" assumption no longer holds now that setups can place guard
enemies by design - narrowed the check to what it actually needs to
prove: no space-side EnemySpawner/AsteroidField node leaks across the
scene swap.
Part of the #40 conquest-mechanic breakdown.
Unrelated pre-existing gap: 11 scripts never got a committed .uid,
exposed by running a full --headless --import pass while working on
#40's sub-tickets. Godot generates these deterministically from the
script path, so this is a no-op for behavior.
MainMenu.tscn is now project.godot's entry point: Play / Map Editor
(disabled, explains itself - #48 wires it up) / Quit (hidden in web
builds), styled like the rest of the game's menus and reusing the
starfield shader for its background.
Play calls GameState.reset_new_game(), so a second playthrough in the
same process starts fresh instead of inheriting whatever the previous
run left in the autoload - existing tests still load Main.tscn
directly and are unaffected.
Part of the #40 conquest-mechanic breakdown.
Enemy.gd now resolves stats/hull/color from EnemyDefinition resources
and composes behaviour from capability components (EnemyPursuitComponent
holds today's chase-the-nearest-ship logic), the same shape Ship.gd
already uses for vessels. Fleet lookups go through a "player_fleet"
group instead of a hardcoded ../Fleet sibling path, so an enemy parented
anywhere (e.g. under a planet surface's SurfaceFeatures) still finds it.
Also closes a real gap: enemies previously had no way to damage the
fleet at range at all (Ship only reacted to physical contact,
Projectile.gd was player-only). Ship.take_damage() is now a proper
entry point - contact damage routes through it unchanged - and
EnemyProjectile lets an enemy component fire at player_ships. Both
ranged enemy archetypes in #45/#46 build on this.
Part of the #40 conquest-mechanic breakdown.
PlanetSetup/PlanetSetupSpawn define a curated capture-point/enemy
layout for a surface profile; PlanetSetups scans res://PlanetSetups/
at first use (not a hardcoded preload table) so dropping in a new
.tres is the only step needed to add one, and resolves the same
setup for the same planet deterministically, same pattern as
WorldGen.planet_data_at_chunk. PlanetSurfaceController composes a
PlanetSetupHost onto the landed surface alongside the existing
resource-provider feature scene.
Ships two starter setups (rocky_default, gas_default) with
placeholder capture-point markers; #43 replaces the markers with the
real CapturePoint scene through the same apply_setup() entry point.
Part of the #40 conquest-mechanic breakdown.
Planets now need every capture point held before an extractor can go
up there: GameState tracks per-planet capture progress keyed by the
same stable planet_id as extractors, and BuildController's four
extractor placement checks (menu enable, status text, info popup,
confirm) all re-check conquest, not just proximity/duplication.
Part of the #40 conquest-mechanic breakdown.
