spaceship/controllers/LaserController.gd

189 lines
8.6 KiB
GDScript3
Raw Permalink Normal View History

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
class_name LaserController
#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
extends "res://controllers/AimedFleetAbilityController.gd"
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
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
# The player's end of the laser: the button, the aim, the fleet's magazine.
# The SHOT itself is a LaserBeamEffect in the world (see that file) - it was
# lifted out of here so a garrisoned laser vessel could fire the same beam
# from a different trigger without this controller being involved at all.
#
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
# What is left here is everything that is genuinely about the player firing:
# where they aimed, what it costs the fleet hold, and the guide line drawn
# while they aim it.
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
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
const BEAM_EFFECT = preload("res://vfx/LaserBeamEffect.gd")
# #201: the beam borrows the fire stick's aim helper, so it is loaded here
# for its static assist rather than for anything a laser hull carries.
const WEAPON_COMPONENT = preload("res://vessels/VesselWeaponComponent.gd")
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
const BEAM_COLOR := BEAM_EFFECT.BEAM_COLOR
const TARGET_COLOR := Color(0.6, 0.95, 1.0)
# #203's range mark and the assist's target ring, in screen pixels.
const END_TICK_PIXELS: float = 17.0
const TARGET_RING_PIXELS: float = 15.0
# How far the thumb travels to walk the aim point out to the beam's full
# reach. The same idiom the gas bomb uses for its throw distance.
const DRAG_RADIUS: float = 260.0
# The aim view frames twice the distance to the chosen target, so there is as
# much space beyond it as in front of it. Framing the target itself would put
# it on the edge of the screen, which is the half that matters when the point
# of dragging further is to reach past what is already close.
const FRAMING_FACTOR: float = 2.0
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
const FLASH_DURATION := BEAM_EFFECT.FLASH_DURATION
const ENERGY_PER_SHOT: int = VesselLaserComponent.ENERGY_PER_SHOT
# The beams this controller has fired and that are still alive. Kept so the
# fleet's own shots can be reasoned about - "is anything still on screen" for
# the redraw, and the tests' view of what a shot did - without this becoming
# the owner of them again.
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
var beams: Array = []
var last_hit_count: int = 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
func _button_path() -> NodePath: return "../UI/LaserButton"
func _status_path() -> NodePath: return "../UI/LaserStatus"
func _component_id() -> String: return "laser"
func _ammo_resource() -> String: return GameState.RESOURCE_ENERGY
func _ammo_cost() -> int: return ENERGY_PER_SHOT
func _aim_padding() -> float: return _aim_half_width()
func _has_effect_visuals() -> bool: return not beams.is_empty()
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
# The width the next shot will cut, off the hull that will cut it. Same shape
# and same reason as _aim_max_range() below: #204 made this upgradeable, so a
# constant here would draw last research's beam.
func _aim_half_width() -> float:
var ship: Node2D = _next_ready_ship()
if ship != null:
var component: Node = ship.get_component(_component_id())
if component != null:
return component.beam_half_width
return GameState.vessel_stat(GameState.VESSEL_LASER, "beam_half_width")
func _aim_max_range() -> float:
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
# Falls back to the VESSEL DEFINITION's own beam_range, not to a copy of
# the number. This used to hardcode 950.0 in both branches, which silently
# became a lie the moment the definition's range changed - the aim line
# would have been drawn to a different distance than the beam actually
# reaches, and only in the cases where the fallback fires.
var ship: Node2D = _next_ready_ship()
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
if ship != null:
var component: Node = ship.get_component(_component_id())
if component != null:
return component.beam_range
return GameState.vessel_stat(GameState.VESSEL_LASER, "beam_range")
func _calculate_aim_target(drag: Vector2, origin: Vector2) -> Vector2:
# The shot always reaches full range; the drag chooses a direction AND a
# depth along it. Depth is what lets the helper reach a target standing
# behind a nearer one: the assist looks for something near the point the
# thumb actually named, and only falls back to the nearest thing in the
# cone when the player has named no place in particular.
var direction: Vector2 = drag.normalized() if drag.length() > 0.001 else Vector2.UP
var reach: float = _aim_max_range()
var depth: float = minf(drag.length() / DRAG_RADIUS, 1.0) * reach
return _assisted_target(origin, origin + direction * maxf(depth, 1.0))
# The mouse path (#80) names a world point directly instead of dragging one
# into existence. It has a real cursor, so it is assisted from that rather
# than from a virtual one at the end of the beam - otherwise the crosshair
# would be the only aim in the game the helper does not touch.
func fire_at(world_target: Vector2) -> bool:
return super(_assisted_target(_aim_origin(), world_target))
# #201: ordinary fire's aim helper, applied to the beam. It answers with a
# PLACE, not a heading - the same thing the fire stick resolves and every
# hull then converges on - so a drag that ends near an enemy, or merely
# inside the assist cone, passes through that enemy instead of a few degrees
# past it. The beam still runs on to its full range from there.
func _assisted_target(origin: Vector2, point: Vector2) -> Vector2:
return WEAPON_COMPONENT.assisted_point(get_tree(), origin, point,
_aim_max_range())
func _consume_shot(component: Node) -> bool:
return component.consume_shot()
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
func _perform_shot(ship: Node2D, component: Node) -> void:
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
# The cooldown was already spent by _consume_shot() above, so this fires
# the effect directly rather than going through fire_ability() and
# spending it twice.
# Aimed from the HULL, not from the fleet centre. aim_target is a place
# now that the assist can move it onto an enemy (#201), and ordinary fire
# converges on such a place by letting each hull find its own heading to
# it - a shared heading measured at the centroid would walk this beam off
# the very target the assist just picked, by the ship's formation offset.
var direction: Vector2 = aim_target - ship.global_position
direction = direction.normalized() if direction.length() > 0.001 else Vector2.UP
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
var effect: Node2D = BEAM_EFFECT.fire(get_tree().root, ship.global_position,
direction, component.beam_range, int(component.damage),
component.beam_half_width)
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
beams.append(effect)
last_hit_count = int(effect.hit_count)
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
func _next_ready_laser_ship() -> Node2D:
return _next_ready_ship()
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
func _advance_effects(_delta: float) -> void:
# The effects animate and free themselves; this only forgets the ones that
# have gone.
beams = beams.filter(func(beam): return is_instance_valid(beam))
func beam_extension(beam: Node2D) -> float:
return beam.extension()
func beam_tip(beam: Node2D) -> Vector2:
return beam.tip()
# #203: framed around the chosen target rather than around the fleet. The
# inherited floor on the zoom was sized for the gas bomb's 950 units and left
# most of a 2900-unit aim off screen; the laser's own floor lets this fit.
# Twice the target's distance, so what lies beyond it is on screen too - that
# is the half the player is reaching into when they drag further out.
func _update_aim_zoom(origin: Vector2, target: Vector2) -> void:
super(origin, origin + (target - origin) * FRAMING_FACTOR)
func _aim_heading(origin: Vector2, target: Vector2) -> Vector2:
var direction: Vector2 = target - origin
return direction.normalized() if direction.length() > 0.001 else Vector2.UP
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
func _draw() -> void:
Garrison laser vessels and gas bombers, on a shared ability seam #105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 19:23:35 +02:00
# Only the aim guide. Each beam draws itself, in its own node.
if not aiming:
return
var origin: Vector2 = _aim_origin()
var reach: float = _aim_max_range()
var far_end: Vector2 = origin + _aim_heading(origin, aim_target) * reach
# Drawn to the far end rather than to aim_target, for the same reason the
# camera frames it: this is the line the beam will occupy (#203).
NeonDraw.draw_glowing_line(self, origin, far_end, TARGET_COLOR, 0.7, 0.6)
# A cross-tick where it stops, so the reach is a mark on the screen rather
# than a line that merely runs out. Sized in SCREEN pixels: framing 2900
# units puts the camera far enough out that a mark measured in world units
# would be a few pixels of nothing at the moment it matters most.
var across: Vector2 = far_end.direction_to(origin).orthogonal() \
* maxf(_aim_half_width(), _screen_units(END_TICK_PIXELS))
NeonDraw.draw_glowing_line(self, far_end - across, far_end + across,
TARGET_COLOR, 0.7, 0.5)
# What the assist picked, when that is nearer than the far end. The line
# still runs past it - everything behind it on the same line is hit too.
if origin.distance_to(aim_target) < reach - 1.0:
NeonDraw.draw_glowing_circle(self, aim_target,
maxf(_aim_half_width(), _screen_units(TARGET_RING_PIXELS)),
TARGET_COLOR, 0.7)
# World units that cover a given number of screen pixels at the camera's
# current zoom.
func _screen_units(pixels: float) -> float:
return pixels / maxf(camera.zoom.x, 0.001)