spaceship/tests/test_laser_vessel.gd

339 lines
15 KiB
GDScript3
Raw 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
extends SceneTree
# Headless gameplay test: run with
# godot --headless -s res://tests/test_laser_vessel.gd
# Forgejo #58: a manually aimed instant beam, modelled closely on the gas
# bomber's press-drag-release skill shot (GasBombController/
# VesselGasBomberComponent) but firing the instant the touch releases -
# there is no projectile travel time to wait out.
#
# Covers:
# A. the control is absent with no laser ship in the fleet, and appears
# the moment one joins
# B. the beam damages every enemy along its line, within beam_half_width,
# and nothing off it or beyond its range
# C. cooldown is per SHIP, not per fleet: two laser ships fire two shots
# before the control disables (the exact bug fixed in eb79efd for
# bombers)
# D. the camera zooms out while aiming and restores afterward
var game_state: Node
var main: Node
var fleet: Node
var skill: Node
# Mirrors LaserController.BEAM_HALF_WIDTH's value rather than referencing
# the class constant directly - a bare ClassName.CONST reference elsewhere
# in a test script has been observed to corrupt method resolution for the
# WHOLE script. See tests/test_gas_bomber_cooldowns.gd's identical fix (#60).
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: float = 38.0
# Mirrored for the same reason, and it bites exactly as documented: a bare
# DRAG_RADIUS here made every method call in this script
# resolve against a plain Node2D.
const DRAG_RADIUS: float = 260.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
var on_line_enemies: Array = []
var off_line_enemy: Node
var beyond_range_enemy: Node
var first_shooter: Node2D
var second_shooter: Node2D
var stage: int = 0
var elapsed: float = 0.0
var original_zoom: float = 2.5
func _initialize() -> void:
game_state = root.get_node("GameState")
game_state.buildings.clear()
game_state.extractors.clear()
game_state.transporters.clear()
game_state.stored_vessels.clear()
game_state.reset_progression()
# Direct unlock, same shortcut unlock_vessel() itself uses internally -
# this ticket is about the laser's own behaviour, not re-proving the
# ship-lab research flow (already covered generically elsewhere).
game_state.vessel_levels["unlock_laser"] = 1
# #61: shots draw energy from the fleet hold now - stock enough for two
# fires. Set BEFORE the first spawn_ships() call (inside Main.tscn's own
# _ready(), triggered by instantiate() below): the fleet hold has no
# capacity cap yet at this point (#56's cap is only computed once a
# fleet composition exists), so this deposit can't be clamped by the
# soon-to-exist all-laser fleet having zero "cargo" capability.
game_state.deposit_fleet_resource(GameState.RESOURCE_ENERGY, 20)
# #219: fleet capacity is built now - one berth free, one per Fleet
# Office. This test flies more than one vessel, so it needs the offices
# standing before the fleet spawns into them.
load("res://tests/_berths.gd").grant(root.get_node("GameState"), 6)
#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
main = load("res://world/Main.tscn").instantiate()
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
root.add_child(main)
fleet = main.get_node("Fleet")
skill = main.get_node("LaserController")
func _process(delta: float) -> bool:
elapsed += delta
match stage:
0:
if elapsed < 0.2:
return false
main.get_node("EnemySpawner").set_process(false)
main.get_node("AsteroidField").set_process(false)
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 are shootable now, and the laser and the bomb both
# sweep them alongside enemies - so whatever the field already
# spawned would be counted as a hit. Silencing the spawner is not
# enough; what it placed before that has to go too. Same
# clean-slate idiom as test_ship_lab.gd.
for hazard in get_nodes_in_group("asteroids"):
if is_instance_valid(hazard):
hazard.free()
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
# --- A. absent, then appears -------------------------------------
if main.get_node("UI/LaserButton").visible:
return _fail_now("laser control appeared without a laser ship")
fleet.spawn_ships(2, Vector2.ZERO, PackedStringArray([
GameState.VESSEL_LASER, GameState.VESSEL_LASER]))
main.get_node("Camera2D").zoom = Vector2(original_zoom, original_zoom)
skill._process(0.0)
if not main.get_node("UI/LaserButton").visible:
return _fail_now("a laser ship in the fleet did not reveal the laser control")
print("control hidden with no laser ship, visible once one joins")
# The beam fires FROM the specific ship LaserController picks, not
# the fleet centroid (same discrepancy GasBombController already
# has) - enemies are placed relative to that ship's own position,
# not the centroid, so a non-zero formation offset can't put them
# off the real beam line.
first_shooter = skill._next_ready_laser_ship()
if first_shooter == null:
return _fail_now("no laser ship is ready right after spawning")
if absf(first_shooter.get_component("laser").beam_range - 2900.0) > 0.1:
return _fail_now("laser ship beam range was not doubled to 2900")
# #201 tripled the beam's damage. Read off the COMPONENT rather
# than off the definition, so a stat that stops reaching the hull
# fails here instead of passing on the strength of its own file.
if first_shooter.get_component("laser").damage != 6:
return _fail_now("laser damage is %d, expected the tripled 6" \
% first_shooter.get_component("laser").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
var press := InputEventScreenTouch.new()
press.index = 7
var laser_button: Control = main.get_node("UI/LaserButton")
press.position = laser_button.global_position + laser_button.size * 0.5
press.pressed = true
main._handle_touch(press)
if not skill.aiming:
return _fail_now("laser control did not begin aiming")
# --- D. zoom-out while aiming --------------------------------
var drag := InputEventScreenDrag.new()
drag.index = 7
drag.position = press.position + Vector2(300.0, 0.0)
main._handle_drag(drag)
# The aim view eases to its framing rather than cutting to it, so
# the drag alone has not moved the camera yet.
if not is_equal_approx(main.get_node("Camera2D").zoom.x, original_zoom):
return _fail_now("the aim zoom jumped instead of easing")
for _step in range(40):
skill._process(0.05)
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 main.get_node("Camera2D").zoom.x >= original_zoom:
return _fail_now("aiming did not zoom out")
print("aiming eased the camera out instead of cutting to 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
# #203: framed to twice the distance of the chosen target, so what
# stands behind it is on screen too. The drag above is horizontal,
# so the screen's narrow half is the binding one.
var half_screen: Vector2 = skill.get_viewport_rect().size * 0.5 \
- Vector2(54.0, 54.0)
var aimed_distance: float = skill._aim_origin().distance_to(skill.aim_target)
var framed: float = (aimed_distance * 2.0 + BEAM_HALF_WIDTH) \
* main.get_node("Camera2D").zoom.x
if framed > half_screen.x + 1.0:
return _fail_now("framed %.0fpx of aim on %.0fpx of screen" \
% [framed, half_screen.x])
print("aiming framed twice the distance to the target")
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
# --- B. targets: two on the line, one off it, one past range ---
for offset in [Vector2(200.0, 0.0), Vector2(500.0, 0.0)]:
#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
var enemy: Node = load("res://enemies/Enemy.tscn").instantiate()
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
enemy.position = first_shooter.global_position + offset
main.add_child(enemy)
enemy.speed = 0.0
on_line_enemies.append(enemy)
#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
off_line_enemy = load("res://enemies/Enemy.tscn").instantiate()
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
off_line_enemy.position = first_shooter.global_position \
+ Vector2(200.0, BEAM_HALF_WIDTH + 60.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
main.add_child(off_line_enemy)
off_line_enemy.speed = 0.0
#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
beyond_range_enemy = load("res://enemies/Enemy.tscn").instantiate()
beyond_range_enemy.position = first_shooter.global_position + Vector2(3400.0, 0.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
main.add_child(beyond_range_enemy)
beyond_range_enemy.speed = 0.0
var release := InputEventScreenTouch.new()
release.index = 7
release.position = drag.position
release.pressed = false
main._handle_touch(release)
# Instant beam: the hit already landed by the time _handle_touch
# returns, no travel time to wait out like the bomb's projectile.
if skill.last_hit_count != 2:
return _fail_now("beam hit %d enemies, expected 2" % skill.last_hit_count)
for enemy in on_line_enemies:
if not is_instance_valid(enemy) or enemy.hp >= enemy.max_hp:
return _fail_now("an enemy on the beam line was not damaged")
if not is_instance_valid(off_line_enemy) or off_line_enemy.hp != off_line_enemy.max_hp:
return _fail_now("the beam damaged an enemy off its line")
if not is_instance_valid(beyond_range_enemy) or beyond_range_enemy.hp != beyond_range_enemy.max_hp:
return _fail_now("the beam damaged an enemy beyond its range")
print("beam damaged exactly the 2 enemies on its line within range")
# --- C. cooldown is per ship, not per fleet ---------------------
if not main.get_node("UI/LaserButton").enabled:
return _fail_now("firing one laser ship disabled the control with a second ship still ready")
print("one ship fired; control stays enabled with the second ready")
stage = 1
elapsed = 0.0
return false
1:
if elapsed < 0.3:
return false
second_shooter = skill._next_ready_laser_ship()
if second_shooter == null or second_shooter == first_shooter:
return _fail_now("the second shot was not offered to the other ship")
var press2 := InputEventScreenTouch.new()
press2.index = 8
var laser_button: Control = main.get_node("UI/LaserButton")
press2.position = laser_button.global_position + laser_button.size * 0.5
press2.pressed = true
main._handle_touch(press2)
if not skill.aiming:
return _fail_now("laser control did not re-open aiming for the second shot")
var drag2 := InputEventScreenDrag.new()
drag2.index = 8
drag2.position = press2.position + Vector2(0.0, 300.0)
main._handle_drag(drag2)
var release2 := InputEventScreenTouch.new()
release2.index = 8
release2.position = drag2.position
release2.pressed = false
main._handle_touch(release2)
if main.get_node("UI/LaserButton").enabled:
return _fail_now("both laser ships fired but the control is still enabled")
print("second shot fired from the other ship - two ships, two shots, now disabled")
stage = 2
elapsed = 0.0
return false
2:
# --- D continued: zoom restores after aiming ends ---------------
if elapsed < 1.0:
return false
if absf(main.get_node("Camera2D").zoom.x - original_zoom) > 0.03:
return _fail_now("camera did not restore its pre-aim zoom")
print("camera zoom restored")
# --- E. #201: the beam gets ordinary fire's aim helper ----------
# Checked on the resolution itself rather than by firing again:
# both hulls are still cooling down, and what the ticket asks for
# is exactly that a drag resolves onto a nearby enemy.
for spent in on_line_enemies + [off_line_enemy, beyond_range_enemy]:
if is_instance_valid(spent):
spent.free()
var origin: Vector2 = skill._aim_origin()
var in_cone: Node = load("res://enemies/Enemy.tscn").instantiate()
in_cone.position = origin + Vector2(800.0, 0.0).rotated(deg_to_rad(20.0))
main.add_child(in_cone)
in_cone.speed = 0.0
# Nearer than the one in the cone, and deliberately outside it:
# the assist must not treat "closest" as "aimed at".
var out_of_cone: Node = load("res://enemies/Enemy.tscn").instantiate()
out_of_cone.position = origin + Vector2(600.0, 0.0).rotated(deg_to_rad(60.0))
main.add_child(out_of_cone)
out_of_cone.speed = 0.0
var assisted: Vector2 = skill._calculate_aim_target(Vector2(300.0, 0.0), origin)
if assisted.distance_to(in_cone.global_position) > 1.0:
return _fail_now("a drag past an enemy inside the assist cone did not snap onto it")
print("aiming snapped onto the enemy inside the assist cone")
in_cone.free()
var unassisted: Vector2 = skill._calculate_aim_target(Vector2(300.0, 0.0), origin)
if unassisted.distance_to(origin + Vector2(2900.0, 0.0)) > 1.0:
return _fail_now("the aim bent toward an enemy outside the assist cone")
print("an enemy outside the cone left the aim where it was pointed")
# --- F. the drag names a DEPTH, so the aim can reach past a
# nearer target instead of always settling on the closest one.
var near_enemy: Node = load("res://enemies/Enemy.tscn").instantiate()
near_enemy.position = origin + Vector2(700.0, 0.0)
main.add_child(near_enemy)
near_enemy.speed = 0.0
# Further out and off to one side, but still inside the assist
# cone: without depth this one is unreachable, because the nearer
# enemy wins the cone every time.
var far_enemy: Node = load("res://enemies/Enemy.tscn").instantiate()
far_enemy.position = origin + Vector2(2000.0, 0.0).rotated(deg_to_rad(10.0))
main.add_child(far_enemy)
far_enemy.speed = 0.0
var near_drag := Vector2(700.0 / 2900.0 * DRAG_RADIUS, 0.0)
var near_pick: Vector2 = skill._calculate_aim_target(near_drag, origin)
if near_pick.distance_to(near_enemy.global_position) > 1.0:
return _fail_now("a short drag did not settle on the nearer enemy")
var far_drag := Vector2(2000.0 / 2900.0 * DRAG_RADIUS, 0.0) \
.rotated(deg_to_rad(10.0))
var far_pick: Vector2 = skill._calculate_aim_target(far_drag, origin)
if far_pick.distance_to(far_enemy.global_position) > 1.0:
return _fail_now("dragging further did not reach past the nearer enemy")
print("drag depth selects between a near and a far target in the same cone")
# --- G. #204: the Collimator widens what one shot catches -------
# The upgrade used to add range to a beam that already crossed the
# screen; it adds WIDTH now, so this checks the thing it widens is
# the hit test and not only the picture.
for placed in [near_enemy, far_enemy, out_of_cone]:
if is_instance_valid(placed):
placed.free()
var laser: Node = first_shooter.get_component("laser")
var narrow_width: float = laser.beam_half_width
game_state.vessel_levels["lsr_width"] = 3
laser.apply_stats()
if not is_equal_approx(laser.beam_half_width, narrow_width + 66.0):
return _fail_now("three Collimators gave a half-width of %.0f, expected %.0f" \
% [laser.beam_half_width, narrow_width + 66.0])
# Off the line by more than the base beam covers and less than the
# researched one does, so the same shot answers differently.
var flanker: Node = load("res://enemies/Enemy.tscn").instantiate()
flanker.position = first_shooter.global_position \
+ Vector2(600.0, narrow_width + 60.0)
main.add_child(flanker)
flanker.speed = 0.0
var beam_script: Resource = load("res://vfx/LaserBeamEffect.gd")
var narrow_shot: Node2D = beam_script.fire(root, first_shooter.global_position,
Vector2.RIGHT, 2900.0, 1, narrow_width)
if narrow_shot.hit_count != 0:
return _fail_now("the unresearched beam already reached the flanking enemy")
var wide_shot: Node2D = beam_script.fire(root, first_shooter.global_position,
Vector2.RIGHT, 2900.0, 1, laser.beam_half_width)
if wide_shot.hit_count != 1:
return _fail_now("the widened beam hit %d enemies, expected the flanker" \
% wide_shot.hit_count)
print("Beam Collimator: %.0f -> %.0f half-width, and the wider beam catches what the narrow one missed" \
% [narrow_width, laser.beam_half_width])
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
print("TEST_LASER_VESSEL: PASS")
quit(0)
return true
return false
func _fail_now(message: String) -> bool:
print("TEST_LASER_VESSEL: FAIL (%s)" % message)
quit(1)
return true