spaceship/tests/test_modal_blocks_input.gd

162 lines
5.9 KiB
GDScript3
Raw Permalink Normal View History

Block input behind open panels; keep craft-menu messages on screen Three play-testing reports. 1. Buttons behind an open panel were still clickable. There are two input paths and both leaked. GUI clicks: the research and formation panels cannot block with mouse_filter = STOP, because their contents are driven from raw _unhandled_input and a Control consuming touches through the GUI system swallows them first - so the panels stay transparent and IconButton now checks whether it is behind one, via a "modal_menus" group. Raw input: a touch landing on the research panel but missing a node was left unhandled, so it fell through to GameController - which sits on the ROOT node and sees whatever its children ignore - and moved the fleet or pinch-zoomed the world. 2. "Store ore here" looked dead. It was working: the confirmation was overwritten one frame later by the per-frame status refresh added in #16, so it flashed for a single frame. Craft-panel messages now outlive a refresh (3s), and the button stays ENABLED with an empty hold so pressing it can say why - a greyed button that cannot explain itself is the same dead-button problem. 3. The mothership's description could overlap the button below it. The description block was positioned from the TOP while the buttons were anchored to the BOTTOM, so the gap between them was whatever the screen height left over - overlapping at 1280 and separating at 960. It is one bottom-anchored stack now, checked at both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 20:17:58 +02:00
extends SceneTree
# Headless gameplay test: run with
# godot --headless -s res://tests/test_modal_blocks_input.gd
# With a panel open, nothing behind it may react to a touch.
#
# Two separate leaks, because there are two separate input paths:
#
# 1. GUI clicks. The skill and formation panels cannot block these the
# normal way (mouse_filter = STOP), because the skill tree and the
# formation editor are driven from raw _unhandled_input, and a Control
# that consumes touches through the GUI system swallows them before
# they ever get there. So the panels stay transparent and the buttons
# check whether they are behind one.
# 2. Raw input. A touch landing on the panel but missing a skill node was
# left unhandled, so it fell through to GameController - which sits on
# the ROOT node and therefore sees everything its children ignore - and
# moved the fleet or pinch-zoomed the world behind the menu.
#
# Verifies:
# 1. a button outside an open panel does not fire
# 2. a button INSIDE the open panel still does (or the panel is unusable)
# 3. with every panel closed, that same outside button fires normally, so
# a pass cannot just mean "the button never works"
# 4. a touch on an open panel does not reach the world behind it
var scene: Node
var game_state: Node
var fleet: Node
var skill_menu: Control
var map_button: Control
var skill_close: Control
var stage: int = 0
var elapsed: float = 0.0
var outside_fired: bool = false
var inside_fired: bool = false
func _initialize() -> void:
game_state = root.get_node("GameState")
game_state.buildings.clear()
game_state.extractors.clear()
game_state.transporters.clear()
#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
scene = load("res://world/Main.tscn").instantiate()
Block input behind open panels; keep craft-menu messages on screen Three play-testing reports. 1. Buttons behind an open panel were still clickable. There are two input paths and both leaked. GUI clicks: the research and formation panels cannot block with mouse_filter = STOP, because their contents are driven from raw _unhandled_input and a Control consuming touches through the GUI system swallows them first - so the panels stay transparent and IconButton now checks whether it is behind one, via a "modal_menus" group. Raw input: a touch landing on the research panel but missing a node was left unhandled, so it fell through to GameController - which sits on the ROOT node and sees whatever its children ignore - and moved the fleet or pinch-zoomed the world. 2. "Store ore here" looked dead. It was working: the confirmation was overwritten one frame later by the per-frame status refresh added in #16, so it flashed for a single frame. Craft-panel messages now outlive a refresh (3s), and the button stays ENABLED with an empty hold so pressing it can say why - a greyed button that cannot explain itself is the same dead-button problem. 3. The mothership's description could overlap the button below it. The description block was positioned from the TOP while the buttons were anchored to the BOTTOM, so the gap between them was whatever the screen height left over - overlapping at 1280 and separating at 960. It is one bottom-anchored stack now, checked at both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 20:17:58 +02:00
root.add_child(scene)
fleet = scene.get_node("Fleet")
skill_menu = scene.get_node("UI/SkillMenu")
map_button = scene.get_node("UI/MapButton")
skill_close = scene.get_node("UI/SkillMenu/CloseButton")
map_button.pressed.connect(func(): outside_fired = true)
skill_close.pressed.connect(func(): inside_fired = true)
func _tap(button: Control) -> void:
# Straight at the button's own _gui_input, which is where a real tap
# lands once Godot has routed it.
var centre: Vector2 = button.size / 2.0
for pressed in [true, false]:
var ev: InputEventScreenTouch = InputEventScreenTouch.new()
ev.pressed = pressed
ev.position = centre
button._gui_input(ev)
func _process(delta: float) -> bool:
elapsed += delta
match stage:
0:
if elapsed < 0.2:
return false
scene.get_node("AsteroidField").set_process(false)
scene.get_node("EnemySpawner").set_process(false)
# --- 3. baseline: it works with nothing open ----------------
outside_fired = false
_tap(map_button)
if not outside_fired:
print("TEST_MODAL_BLOCKS_INPUT: FAIL (the button never fires even with no panel open - the test proves nothing)")
quit(1)
return true
print("no panel open -> outside button fires")
# That tap actually OPENED the world map, which is itself a modal
# panel - leave it open and it correctly blocks the research
# panel's own buttons, which is a true result but not the one
# being measured here.
scene.get_node("UI/WorldMap").visible = false
skill_menu.visible = true
elapsed = 0.0
stage = 1
return false
1:
if elapsed < 0.2:
return false
# --- 1. behind an open panel --------------------------------
outside_fired = false
_tap(map_button)
if outside_fired:
print("TEST_MODAL_BLOCKS_INPUT: FAIL (a button behind the open research panel still fired)")
quit(1)
return true
print("research panel open -> button behind it is inert")
# --- 2. inside it ------------------------------------------
inside_fired = false
_tap(skill_close)
if not inside_fired:
print("TEST_MODAL_BLOCKS_INPUT: FAIL (the panel's own close button stopped working)")
quit(1)
return true
print("panel's own button still works")
elapsed = 0.0
stage = 2
return false
2:
if elapsed < 0.2:
return false
# --- 4. raw input must not reach the world ------------------
skill_menu.visible = true
var before: Vector2 = fleet.fleet_target
var controller: Node = scene.get_node("BuildController")
var ev: InputEventScreenTouch = InputEventScreenTouch.new()
ev.pressed = true
ev.position = Vector2(360.0, 900.0)
controller._unhandled_input(ev)
if not root.get_viewport().is_input_handled():
print("TEST_MODAL_BLOCKS_INPUT: FAIL (a touch on the open panel was left unhandled - it falls through to the world behind)")
quit(1)
return true
if fleet.fleet_target != before:
print("TEST_MODAL_BLOCKS_INPUT: FAIL (the fleet moved from a touch on the panel)")
quit(1)
return true
print("touch on the panel consumed, fleet target unchanged")
# --- 5. a hidden parent must not leave a panel "open" -------
# The build menu's info popup is itself a modal panel. Hiding the
# build menu leaves the popup's own `visible` flag true, so a
# guard testing `visible` rather than `is_visible_in_tree()`
# blocked EVERY button in the game from then on - with no way for
# a player to get out of it. Reported three times as "the buttons
# do nothing".
skill_menu.visible = false
var controller2: Node = scene.get_node("BuildController")
controller2._on_build_pressed()
controller2._show_building_info(GameState.BUILDING_SHIP_CRAFTER)
scene.get_node("UI/BuildMenu").visible = false
var info: Control = scene.get_node("UI/BuildMenu/InfoPopup")
print("popup after hiding its parent: visible=%s in_tree=%s" % [
info.visible, info.is_visible_in_tree()
])
outside_fired = false
_tap(map_button)
if not outside_fired:
print("TEST_MODAL_BLOCKS_INPUT: FAIL (a panel hidden with its parent still blocks every button)")
quit(1)
return true
print("hidden-with-parent panel no longer blocks anything")
Block input behind open panels; keep craft-menu messages on screen Three play-testing reports. 1. Buttons behind an open panel were still clickable. There are two input paths and both leaked. GUI clicks: the research and formation panels cannot block with mouse_filter = STOP, because their contents are driven from raw _unhandled_input and a Control consuming touches through the GUI system swallows them first - so the panels stay transparent and IconButton now checks whether it is behind one, via a "modal_menus" group. Raw input: a touch landing on the research panel but missing a node was left unhandled, so it fell through to GameController - which sits on the ROOT node and sees whatever its children ignore - and moved the fleet or pinch-zoomed the world. 2. "Store ore here" looked dead. It was working: the confirmation was overwritten one frame later by the per-frame status refresh added in #16, so it flashed for a single frame. Craft-panel messages now outlive a refresh (3s), and the button stays ENABLED with an empty hold so pressing it can say why - a greyed button that cannot explain itself is the same dead-button problem. 3. The mothership's description could overlap the button below it. The description block was positioned from the TOP while the buttons were anchored to the BOTTOM, so the gap between them was whatever the screen height left over - overlapping at 1280 and separating at 960. It is one bottom-anchored stack now, checked at both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 20:17:58 +02:00
print("TEST_MODAL_BLOCKS_INPUT: PASS")
quit(0)
return true
return false