2026-08-14 22:12:57 +02:00
|
|
|
class_name VesselDefinitions
|
|
|
|
|
extends RefCounted
|
|
|
|
|
|
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 ORDER: PackedStringArray = ["interceptor", "shield", "gas_bomber", "transporter", "carrier", "laser"]
|
2026-08-14 22:12:57 +02:00
|
|
|
const DEFINITIONS: Dictionary = {
|
|
|
|
|
"interceptor": preload("res://InterceptorVesselDefinition.tres"),
|
|
|
|
|
"shield": preload("res://ShieldVesselDefinition.tres"),
|
2026-08-15 04:45:15 +02:00
|
|
|
"gas_bomber": preload("res://GasBomberVesselDefinition.tres"),
|
2026-08-14 22:12:57 +02:00
|
|
|
"transporter": preload("res://TransporterVesselDefinition.tres"),
|
2026-08-16 16:20:39 +02:00
|
|
|
"carrier": preload("res://CarrierVesselDefinition.tres"),
|
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
|
|
|
"laser": preload("res://LaserVesselDefinition.tres"),
|
2026-08-14 22:12:57 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static func get_definition(definition_id: String) -> Resource:
|
|
|
|
|
return DEFINITIONS.get(definition_id)
|
|
|
|
|
|
|
|
|
|
static func all() -> Array:
|
|
|
|
|
var result: Array = []
|
|
|
|
|
for definition_id in ORDER:
|
|
|
|
|
result.append(DEFINITIONS[definition_id])
|
|
|
|
|
return result
|
|
|
|
|
|
2026-08-15 00:09:10 +02:00
|
|
|
|
|
|
|
|
static func fleet() -> Array:
|
|
|
|
|
var result: Array = []
|
|
|
|
|
for definition in all():
|
|
|
|
|
if definition.fleet_eligible:
|
|
|
|
|
result.append(definition)
|
|
|
|
|
return result
|
|
|
|
|
|
2026-08-14 22:12:57 +02:00
|
|
|
static func with_capability(capability: String) -> Resource:
|
|
|
|
|
for definition in all():
|
|
|
|
|
if definition.has_capability(capability):
|
|
|
|
|
return definition
|
|
|
|
|
return null
|