Implement #80, #81, #82 and #83
#80 - desktop combat. The mouse aims, the left button fires, and the number
keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin
sticks are built for thumbs; on a desktop they mean dragging a virtual stick
with a pointer that could simply BE the crosshair.
The pointer path hands its heading to FireStickController rather than driving
weapons itself, so exactly one thing in the scene aims a gun, and a held stick
wins - a finger on it is a deliberate act, a mouse resting somewhere is not.
Abilities gained fire_at(), which aims and fires in one call instead of
pretending to be a press-drag-release touch.
It is gated on the absence of a touchscreen, because Godot emulates a mouse
button from every touch and without that a tap on a phone would fire the guns.
The gate has an explicit override, and not for tidiness: headless reports a
touchscreen, so with the automatic answer alone the aiming could never be
exercised by a test and the only covered behaviour would be the guard.
#81 - the bottom-left control hint is gone, from both scenes and from
GameController.
#82 - a chaser is destroyed by the impact when it reaches a vessel. It used to
pass through the wreck untouched and line up another pass, which made a
ramming enemy strictly better than any other. Data-driven per enemy
(dies_on_contact), because a sniper that happens to drift into a ship has not
spent itself doing it - and routed through take_damage, so it dies exactly as
it dies to gunfire. The enemy is told about the impact BEFORE the ship
resolves its own damage, since resolving it can free the ship.
#83 - the research tree's buy button is gone; tapping a node twice buys it.
Deliberately "the same node twice" rather than a timed double-tap: no window
to miss on a slow phone, no accidental purchase while browsing, and the first
tap always does something visible, so the second is never a blind commitment.
The status line now says "Tap again to research" - with the button gone it is
the only thing distinguishing an affordable node from an unaffordable one.
test_enemy_collision asserted the exact behaviour #82 reversed, and now checks
the ram costs both. Suite 117/117.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
|
|
|
extends SceneTree
|
|
|
|
|
|
|
|
|
|
# Headless gameplay test: run with
|
|
|
|
|
# godot --headless -s res://tests/test_desktop_combat.gd
|
|
|
|
|
# Forgejo #80: on a computer the mouse aims and the left button fires, and the
|
|
|
|
|
# number keys pick the weapon - 1 the fleet's guns, 2 and up the abilities.
|
|
|
|
|
#
|
|
|
|
|
# Covers:
|
|
|
|
|
# A. the weapon numbering is FIXED and named, so "2" is the gas bomb in
|
|
|
|
|
# every scene rather than whatever node order happens to produce
|
|
|
|
|
# B. holding the button with weapon 1 selected points the fleet's guns at
|
|
|
|
|
# the cursor, through the same controller the stick uses - not a second
|
|
|
|
|
# thing that aims
|
|
|
|
|
# C. releasing stops it
|
|
|
|
|
# D. the stick WINS while it is held, so a mouse resting somewhere cannot
|
|
|
|
|
# override a finger
|
|
|
|
|
# E. selecting an ability highlights its button, so what a click will do is
|
|
|
|
|
# on screen rather than remembered
|
|
|
|
|
# F. it is inert on a touch device. Godot emulates a mouse button from every
|
|
|
|
|
# touch, so without that guard a tap on a phone would fire the guns
|
|
|
|
|
|
|
|
|
|
var game_state: Node
|
|
|
|
|
var main: Node
|
|
|
|
|
var fleet: Node
|
|
|
|
|
var mouse: Node
|
|
|
|
|
var fire_stick: Node
|
|
|
|
|
var stick: Control
|
|
|
|
|
var stage: int = 0
|
|
|
|
|
var elapsed: float = 0.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _initialize() -> void:
|
|
|
|
|
game_state = root.get_node("GameState")
|
|
|
|
|
game_state.buildings.clear()
|
|
|
|
|
game_state.extractors.clear()
|
|
|
|
|
game_state.reset_progression()
|
#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()
|
Implement #80, #81, #82 and #83
#80 - desktop combat. The mouse aims, the left button fires, and the number
keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin
sticks are built for thumbs; on a desktop they mean dragging a virtual stick
with a pointer that could simply BE the crosshair.
The pointer path hands its heading to FireStickController rather than driving
weapons itself, so exactly one thing in the scene aims a gun, and a held stick
wins - a finger on it is a deliberate act, a mouse resting somewhere is not.
Abilities gained fire_at(), which aims and fires in one call instead of
pretending to be a press-drag-release touch.
It is gated on the absence of a touchscreen, because Godot emulates a mouse
button from every touch and without that a tap on a phone would fire the guns.
The gate has an explicit override, and not for tidiness: headless reports a
touchscreen, so with the automatic answer alone the aiming could never be
exercised by a test and the only covered behaviour would be the guard.
#81 - the bottom-left control hint is gone, from both scenes and from
GameController.
#82 - a chaser is destroyed by the impact when it reaches a vessel. It used to
pass through the wreck untouched and line up another pass, which made a
ramming enemy strictly better than any other. Data-driven per enemy
(dies_on_contact), because a sniper that happens to drift into a ship has not
spent itself doing it - and routed through take_damage, so it dies exactly as
it dies to gunfire. The enemy is told about the impact BEFORE the ship
resolves its own damage, since resolving it can free the ship.
#83 - the research tree's buy button is gone; tapping a node twice buys it.
Deliberately "the same node twice" rather than a timed double-tap: no window
to miss on a slow phone, no accidental purchase while browsing, and the first
tap always does something visible, so the second is never a blind commitment.
The status line now says "Tap again to research" - with the button gone it is
the only thing distinguishing an affordable node from an unaffordable one.
test_enemy_collision asserted the exact behaviour #82 reversed, and now checks
the ram costs both. Suite 117/117.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
|
|
|
root.add_child(main)
|
|
|
|
|
current_scene = main
|
|
|
|
|
fleet = main.get_node("Fleet")
|
|
|
|
|
mouse = main.get_node("MouseCombatController")
|
|
|
|
|
# Checked here rather than at first use: a script that fails to PARSE
|
|
|
|
|
# leaves a bare Node2D in the scene, and every call against it becomes a
|
|
|
|
|
# per-frame "nonexistent function" error that runs until the harness
|
|
|
|
|
# times the test out three minutes later instead of failing in one line.
|
|
|
|
|
if not mouse.has_method("weapon_count"):
|
|
|
|
|
print("TEST_DESKTOP_COMBAT: FAIL (MouseCombatController.gd did not load - see the parse error above)")
|
|
|
|
|
quit(1)
|
|
|
|
|
return
|
|
|
|
|
fire_stick = main.get_node("FireStickController")
|
|
|
|
|
stick = main.get_node("UI/FireStick")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _weapon_heading() -> Vector2:
|
|
|
|
|
return fire_stick.aim_direction
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _process(delta: float) -> bool:
|
|
|
|
|
elapsed += delta
|
|
|
|
|
match stage:
|
|
|
|
|
0:
|
|
|
|
|
if elapsed < 0.3:
|
|
|
|
|
return false
|
|
|
|
|
main.get_node("EnemySpawner").set_process(false)
|
|
|
|
|
main.get_node("AsteroidField").set_process(false)
|
|
|
|
|
for hazard in get_nodes_in_group("asteroids") + get_nodes_in_group("enemies"):
|
|
|
|
|
if is_instance_valid(hazard):
|
|
|
|
|
hazard.queue_free()
|
|
|
|
|
fleet.spawn_ships(1, Vector2.ZERO, PackedStringArray([GameState.VESSEL_INTERCEPTOR]))
|
|
|
|
|
|
|
|
|
|
# --- A. fixed, named ordering ---------------------------------
|
|
|
|
|
if mouse.weapon_count() != mouse.abilities.size() + 1:
|
|
|
|
|
return _fail("weapon count %d does not match 1 + %d abilities" \
|
|
|
|
|
% [mouse.weapon_count(), mouse.abilities.size()])
|
|
|
|
|
if mouse.abilities.is_empty():
|
|
|
|
|
return _fail("no ability controllers were resolved, so the number keys address nothing")
|
|
|
|
|
if mouse.abilities[0] != main.get_node("GasBombController"):
|
|
|
|
|
return _fail("weapon 2 is not the gas bomb - the ticket names it explicitly")
|
|
|
|
|
if not mouse.select_weapon(0):
|
|
|
|
|
return _fail("could not select the default weapon")
|
|
|
|
|
if mouse.select_weapon(mouse.weapon_count()):
|
|
|
|
|
return _fail("selecting a weapon past the end was accepted")
|
|
|
|
|
print("weapon 1 is the fleet's guns, weapon 2 is the gas bomb, %d in total" \
|
|
|
|
|
% mouse.weapon_count())
|
|
|
|
|
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
# --- F. inert while the player is using touch ------------------
|
|
|
|
|
# #171: the gate used to be "does this machine have a
|
|
|
|
|
# touchscreen", which is a capability rather than a fact and is
|
|
|
|
|
# answered wrongly by every browser on a touch-capable laptop. It
|
|
|
|
|
# is now the last input actually used - which, unlike the display
|
|
|
|
|
# query, can be driven here, so both branches are exercised
|
|
|
|
|
# instead of whichever one this machine happens to report.
|
Implement #80, #81, #82 and #83
#80 - desktop combat. The mouse aims, the left button fires, and the number
keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin
sticks are built for thumbs; on a desktop they mean dragging a virtual stick
with a pointer that could simply BE the crosshair.
The pointer path hands its heading to FireStickController rather than driving
weapons itself, so exactly one thing in the scene aims a gun, and a held stick
wins - a finger on it is a deliberate act, a mouse resting somewhere is not.
Abilities gained fire_at(), which aims and fires in one call instead of
pretending to be a press-drag-release touch.
It is gated on the absence of a touchscreen, because Godot emulates a mouse
button from every touch and without that a tap on a phone would fire the guns.
The gate has an explicit override, and not for tidiness: headless reports a
touchscreen, so with the automatic answer alone the aiming could never be
exercised by a test and the only covered behaviour would be the guard.
#81 - the bottom-left control hint is gone, from both scenes and from
GameController.
#82 - a chaser is destroyed by the impact when it reaches a vessel. It used to
pass through the wreck untouched and line up another pass, which made a
ramming enemy strictly better than any other. Data-driven per enemy
(dies_on_contact), because a sniper that happens to drift into a ship has not
spent itself doing it - and routed through take_damage, so it dies exactly as
it dies to gunfire. The enemy is told about the impact BEFORE the ship
resolves its own damage, since resolving it can free the ship.
#83 - the research tree's buy button is gone; tapping a node twice buys it.
Deliberately "the same node twice" rather than a timed double-tap: no window
to miss on a slow phone, no accidental purchase while browsing, and the first
tap always does something visible, so the second is never a blind commitment.
The status line now says "Tap again to research" - with the button gone it is
the only thing distinguishing an affordable node from an unaffordable one.
test_enemy_collision asserted the exact behaviour #82 reversed, and now checks
the ram costs both. Suite 117/117.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
|
|
|
if mouse.pointer_mode != mouse.PointerMode.AUTO:
|
|
|
|
|
return _fail("the scene ships with an overridden pointer mode, so what a real device does is not what was tested")
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
game_state.note_touch_input()
|
|
|
|
|
if mouse.is_enabled():
|
|
|
|
|
return _fail("mouse combat is armed while the player is using touch - a tap would fire the guns")
|
|
|
|
|
game_state.last_touch_msec = -1
|
|
|
|
|
game_state.note_pointer_input()
|
|
|
|
|
if not mouse.is_enabled():
|
|
|
|
|
return _fail("mouse combat is off for a player using a mouse")
|
|
|
|
|
print("gated on the last input used: off under touch, on under a mouse")
|
Implement #80, #81, #82 and #83
#80 - desktop combat. The mouse aims, the left button fires, and the number
keys pick the weapon: 1 the fleet's guns, 2 and up the abilities. The twin
sticks are built for thumbs; on a desktop they mean dragging a virtual stick
with a pointer that could simply BE the crosshair.
The pointer path hands its heading to FireStickController rather than driving
weapons itself, so exactly one thing in the scene aims a gun, and a held stick
wins - a finger on it is a deliberate act, a mouse resting somewhere is not.
Abilities gained fire_at(), which aims and fires in one call instead of
pretending to be a press-drag-release touch.
It is gated on the absence of a touchscreen, because Godot emulates a mouse
button from every touch and without that a tap on a phone would fire the guns.
The gate has an explicit override, and not for tidiness: headless reports a
touchscreen, so with the automatic answer alone the aiming could never be
exercised by a test and the only covered behaviour would be the guard.
#81 - the bottom-left control hint is gone, from both scenes and from
GameController.
#82 - a chaser is destroyed by the impact when it reaches a vessel. It used to
pass through the wreck untouched and line up another pass, which made a
ramming enemy strictly better than any other. Data-driven per enemy
(dies_on_contact), because a sniper that happens to drift into a ship has not
spent itself doing it - and routed through take_damage, so it dies exactly as
it dies to gunfire. The enemy is told about the impact BEFORE the ship
resolves its own damage, since resolving it can free the ship.
#83 - the research tree's buy button is gone; tapping a node twice buys it.
Deliberately "the same node twice" rather than a timed double-tap: no window
to miss on a slow phone, no accidental purchase while browsing, and the first
tap always does something visible, so the second is never a blind commitment.
The status line now says "Tap again to research" - with the button gone it is
the only thing distinguishing an affordable node from an unaffordable one.
test_enemy_collision asserted the exact behaviour #82 reversed, and now checks
the ram costs both. Suite 117/117.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 18:49:47 +02:00
|
|
|
|
|
|
|
|
# Everything below is about the AIMING, not the guard. Headless
|
|
|
|
|
# reports a touchscreen, so the mode is forced on here - otherwise
|
|
|
|
|
# these cases would silently never run and this file would test
|
|
|
|
|
# nothing but the line above.
|
|
|
|
|
mouse.pointer_mode = mouse.PointerMode.ON
|
|
|
|
|
if not mouse.is_enabled():
|
|
|
|
|
return _fail("forcing the pointer mode on did not enable it")
|
|
|
|
|
stage = 1
|
|
|
|
|
elapsed = 0.0
|
|
|
|
|
return false
|
|
|
|
|
1:
|
|
|
|
|
if elapsed < 0.1:
|
|
|
|
|
return false
|
|
|
|
|
# --- B. holding the button aims the guns at the cursor ---------
|
|
|
|
|
mouse.select_weapon(0)
|
|
|
|
|
mouse.aim_world = fleet.get_centroid() + Vector2(0.0, -500.0)
|
|
|
|
|
mouse.firing = true
|
|
|
|
|
mouse._process(0.0)
|
|
|
|
|
fire_stick._process(0.0)
|
|
|
|
|
var heading: Vector2 = _weapon_heading().normalized()
|
|
|
|
|
if heading.distance_to(Vector2(0.0, -1.0)) > 0.05:
|
|
|
|
|
return _fail("holding the button aimed along %s, but the cursor was straight up" % heading)
|
|
|
|
|
print("holding the button aims the guns at the cursor")
|
|
|
|
|
|
|
|
|
|
# --- C. releasing stops -----------------------------------------
|
|
|
|
|
mouse.firing = false
|
|
|
|
|
mouse._process(0.0)
|
|
|
|
|
fire_stick._process(0.0)
|
|
|
|
|
if _weapon_heading() != Vector2.ZERO:
|
|
|
|
|
return _fail("releasing the button left the guns aimed at %s" % _weapon_heading())
|
|
|
|
|
print("releasing stops the guns")
|
|
|
|
|
|
|
|
|
|
# --- D. a held stick wins ---------------------------------------
|
|
|
|
|
var centre: Vector2 = stick.global_position + stick.size * 0.5
|
|
|
|
|
var press := InputEventScreenTouch.new()
|
|
|
|
|
press.index = 9
|
|
|
|
|
press.pressed = true
|
|
|
|
|
press.position = centre
|
|
|
|
|
stick.handle_touch(press)
|
|
|
|
|
var drag := InputEventScreenDrag.new()
|
|
|
|
|
drag.index = 9
|
|
|
|
|
drag.position = centre + Vector2(stick.max_radius, 0.0)
|
|
|
|
|
stick.handle_drag(drag)
|
|
|
|
|
mouse.aim_world = fleet.get_centroid() + Vector2(0.0, -500.0)
|
|
|
|
|
mouse.firing = true
|
|
|
|
|
mouse._process(0.0)
|
|
|
|
|
fire_stick._process(0.0)
|
|
|
|
|
var contested: Vector2 = _weapon_heading().normalized()
|
|
|
|
|
if contested.distance_to(Vector2(1.0, 0.0)) > 0.05:
|
|
|
|
|
return _fail("with the stick pushed right and the mouse aiming up, the guns went %s - the stick must win" % contested)
|
|
|
|
|
print("a held stick overrides the mouse")
|
|
|
|
|
var release := InputEventScreenTouch.new()
|
|
|
|
|
release.index = 9
|
|
|
|
|
release.pressed = false
|
|
|
|
|
release.position = centre
|
|
|
|
|
stick.handle_touch(release)
|
|
|
|
|
mouse.firing = false
|
|
|
|
|
|
|
|
|
|
# --- E. the chosen ability is shown ----------------------------
|
|
|
|
|
mouse.select_weapon(1)
|
|
|
|
|
var bomb_button: Node = mouse.abilities[0].button
|
|
|
|
|
if not bomb_button.highlighted:
|
|
|
|
|
return _fail("selecting the gas bomb did not highlight its button")
|
|
|
|
|
mouse.select_weapon(0)
|
|
|
|
|
if bomb_button.highlighted:
|
|
|
|
|
return _fail("going back to the guns left the gas bomb still highlighted")
|
|
|
|
|
print("the selected ability's own button carries the selection")
|
|
|
|
|
|
|
|
|
|
print("TEST_DESKTOP_COMBAT: PASS")
|
|
|
|
|
quit(0)
|
|
|
|
|
return true
|
|
|
|
|
return false
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _fail(message: String) -> bool:
|
|
|
|
|
print("TEST_DESKTOP_COMBAT: FAIL (%s)" % message)
|
|
|
|
|
quit(1)
|
|
|
|
|
return true
|