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
|
2026-08-16 21:38:07 +02:00
|
|
|
extends "res://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
|
|
|
|
|
|
|
|
const BEAM_COLOR := Color(0.3, 0.9, 1.0)
|
|
|
|
|
const TARGET_COLOR := Color(0.6, 0.95, 1.0)
|
Sharpen fleet handling, widen the laser, and fix the map editor's file identity
The fleet had a second of inertia in it: every vessel's acceleration sat at
roughly its own top speed, so flipping the stick while cruising took 0.58s to
take effect and let go coasted 222 units, while the formation anchor the ships
chase turns instantly. Acceleration is now ~3x top speed, chosen by measuring
rather than taste - past 3x the reversal time stops improving because
max_speed becomes the limit. Measured after: 0.18s and 23 units.
test_fleet_agility guards all three numbers and proves the bounds discriminate
by re-running the same measurement at the old value.
The laser reaches 1450 instead of 950 and strikes 38 units either side instead
of 22. Its drawn width is now derived from the hit width: the two were
independent numbers that had drifted, so the beam killed things it visibly
missed. LaserController's aim range also stopped hardcoding a second copy of
950. Tapping the laser button without dragging used to do nothing at all - the
press was claimed, the aim begun, then thrown away on release. It now fires at
the nearest enemy in range; dragging still aims precisely. That lives in the
shared aimed-ability controller, so the gas bomb gains it too.
Planets sat one per ~29 chunks - some 35,000 units of nothing between them.
Now one per ~12, measured over 14,641 chunks. The two thresholds moved by
different amounts deliberately: every SPACE-biome planet is a gas giant, so
lowering both equally would have tripled the gas-giant share as well. This
changes how often you find a planet, not what you find. Extractors produce
half as fast to match, so expanding is what grows the economy.
The research screen gave its tree 386px of 1280 and the text below it 520.
The text is now at the bottom, the tree has 550, and the resource table has
room and legible type - and its LOCAL column is no longer hidden behind the
close button.
Two map-editor bugs turned out to be one cause: a setup's id and its FILENAME
are not the same thing, and both save and delete rebuilt the path from the id.
ResearchLabSetup.tres holds setup_id "research_lab_1", so deleting it looked
for a file that does not exist and silently refused - which read as "the first
item in the list cannot be deleted" - while saving it wrote a second file
under the derived name and left the original behind, so the pool served the
stale twin. A third bug hid behind those: rescan() re-read through Godot's
resource cache and handed back pre-save values even when the file on disk was
correct. All three present to a player as "my change was not saved".
Research labs no longer grant a point of their own; what conquering one is
worth comes entirely from its authored map, as asked. The shipped lab map
carries 1 so the balance is unchanged - only where it is configured moved.
Suite 109/109. Four tests changed because the behaviour they pinned changed:
the joystick coast is now derived from cruise_speed^2/(2*acceleration) rather
than a constant tuned to one acceleration; the extractor wait derives from
EXTRACTOR_RATE; the research-point test asserts the delegation; and the black
hole test no longer assumes nobody will ever author a void-profile map.
test_planet_setups and test_planet_map_assignment stopped depending on which
maps happen to be in the content folder, which was making them fail when maps
were added or deleted elsewhere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:11 +02:00
|
|
|
const BEAM_HALF_WIDTH := 38.0
|
|
|
|
|
# The DRAWN beam is scaled from the hit width rather than tuned separately.
|
|
|
|
|
# The two were independent numbers and had drifted apart: the beam struck
|
|
|
|
|
# anything within 22 units of the line while its outer glow spanned about 11,
|
|
|
|
|
# so it killed things it visibly missed. NeonDraw's widest layer is 18px at
|
|
|
|
|
# scale 1, so this makes the glow span exactly what the beam hits.
|
|
|
|
|
const BEAM_WIDTH_SCALE := BEAM_HALF_WIDTH * 2.0 / 18.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
|
|
|
const FLASH_DURATION := 0.22
|
2026-08-16 19:11:31 +02:00
|
|
|
const ENERGY_PER_SHOT: int = 8
|
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 = []
|
2026-08-16 21:38:07 +02:00
|
|
|
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
|
|
|
|
|
|
|
|
|
2026-08-16 21:38:07 +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 BEAM_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
|
|
|
|
|
|
|
|
|
2026-08-16 21:38:07 +02:00
|
|
|
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.
|
2026-08-16 21:38:07 +02:00
|
|
|
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")
|
2026-08-16 19:11:31 +02:00
|
|
|
|
|
|
|
|
|
2026-08-16 21:38:07 +02:00
|
|
|
func _calculate_aim_target(drag: Vector2, origin: Vector2) -> Vector2:
|
|
|
|
|
# A beam always reaches full range; dragging chooses its direction only.
|
|
|
|
|
var direction: Vector2 = drag.normalized() if drag.length() > 0.001 else Vector2.UP
|
|
|
|
|
return origin + direction * _aim_max_range()
|
|
|
|
|
|
2026-08-16 19:11:31 +02:00
|
|
|
|
2026-08-16 21:38:07 +02:00
|
|
|
func _consume_shot(component: Node) -> bool:
|
|
|
|
|
return component.consume_shot()
|
2026-08-16 19:11:31 +02:00
|
|
|
|
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
|
|
|
|
2026-08-16 21:38:07 +02:00
|
|
|
func _perform_shot(ship: Node2D, component: Node) -> void:
|
|
|
|
|
var direction: Vector2 = aim_target - _aim_origin()
|
|
|
|
|
direction = direction.normalized() if direction.length() > 0.001 else Vector2.UP
|
|
|
|
|
var beam_to: Vector2 = ship.global_position + direction * component.beam_range
|
|
|
|
|
_strike(ship.global_position, beam_to, direction, int(component.damage))
|
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
|
|
|
|
2026-08-16 21:38:07 +02:00
|
|
|
|
|
|
|
|
func _next_ready_laser_ship() -> Node2D:
|
|
|
|
|
return _next_ready_ship()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _advance_effects(delta: float) -> void:
|
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
|
|
|
for i in range(beams.size() - 1, -1, -1):
|
|
|
|
|
var beam: Dictionary = beams[i]
|
|
|
|
|
beam.time = maxf(float(beam.time) - delta, 0.0)
|
|
|
|
|
if float(beam.time) <= 0.0:
|
|
|
|
|
beams.remove_at(i)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _strike(from: Vector2, to: Vector2, direction: Vector2, damage: int) -> void:
|
|
|
|
|
beams.append({"from": from, "to": to, "time": FLASH_DURATION})
|
|
|
|
|
last_hit_count = 0
|
|
|
|
|
var range_along: float = from.distance_to(to)
|
Asteroids can be shot apart for the ore inside them
Asteroids were pure hazard: the only thing one could ever do was cost you a
ship. They now take damage like anything else and break open, dropping ore the
fleet can fly over and collect - the one resource reachable in open space
without conquering anything, and something for the new fire stick to do out
there.
Two ways to destroy one, deliberately not equivalent. Shot apart yields the
ore; flown into does not - the rock shatters against a hull rather than being
mined, and a ship or a shield charge has just been spent on it. Without that
split a shield vessel could farm asteroids by ramming them.
Asteroid.take_damage() matches Enemy's contract exactly, so every weapon that
already knew how to hurt an enemy hurts an asteroid through the same branch
rather than a second special case: bolts, the laser sweep, and the gas bomb's
blast all pick both groups up together.
Dropped ore carries the asteroid's own drift, so it reads as debris rather
than as a spawned pickup, and it expires after a minute. Rock grew an optional
lifetime for that, defaulting to 0 (never) so hand-placed surface rocks are
unchanged - a planet surface is bounded and authored, open space is not, and a
field shot up and abandoned would otherwise leak nodes for the session. Rock's
header note that asteroids and rocks are never on screen together is no longer
true and now says so; the hexagon-versus-lump shape language matters more now
that they sit side by side, not less.
Five weapon tests silenced the asteroid field but never cleared what it had
already placed. That was harmless while asteroids were untouchable and is not
any more - two of them assert exact hit counts, and a drifting rock in the
beam would have made those fail intermittently.
Suite 111/111.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 10:27:40 +02:00
|
|
|
# Asteroids share the enemies' take_damage() contract, so the beam sweeps
|
|
|
|
|
# both groups in one pass. Shooting a path clear through a field is a
|
|
|
|
|
# perfectly good use of a laser, and the ore it leaves behind is the point.
|
|
|
|
|
for enemy in get_tree().get_nodes_in_group("enemies") \
|
|
|
|
|
+ get_tree().get_nodes_in_group("asteroids"):
|
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
|
|
|
if not is_instance_valid(enemy) or not (enemy is Node2D):
|
|
|
|
|
continue
|
|
|
|
|
var to_enemy: Vector2 = enemy.global_position - from
|
|
|
|
|
var along: float = to_enemy.dot(direction)
|
|
|
|
|
if along < 0.0 or along > range_along:
|
|
|
|
|
continue
|
|
|
|
|
var perpendicular: float = (to_enemy - direction * along).length()
|
|
|
|
|
if perpendicular <= BEAM_HALF_WIDTH:
|
|
|
|
|
enemy.take_damage(damage)
|
|
|
|
|
last_hit_count += 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _draw() -> void:
|
|
|
|
|
if aiming:
|
2026-08-16 21:38:07 +02:00
|
|
|
NeonDraw.draw_glowing_line(self, _aim_origin(), aim_target,
|
|
|
|
|
TARGET_COLOR, 0.7, 0.6)
|
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
|
|
|
for beam in beams:
|
|
|
|
|
var progress: float = 1.0 - float(beam.time) / FLASH_DURATION
|
|
|
|
|
var alpha: float = 1.0 - progress
|
2026-08-16 21:38:07 +02:00
|
|
|
NeonDraw.draw_glowing_line(self, beam.from, beam.to,
|
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
|
|
|
BEAM_COLOR, alpha, BEAM_WIDTH_SCALE * (1.0 - progress * 0.45))
|