spaceship/tests/test_dialog_typing.gd

188 lines
7.3 KiB
GDScript3
Raw Normal View History

#149, #153, #154: dialogs arrive, sit on top, and give the keyboard back #149 - a line is typed out at about three and a half words a second, with a scan sweep running down the panel and faint rules across it while it decodes. The frame carries the charge while it works and settles when the line lands; the caret is a solid write-head during the decode and only starts blinking once it is waiting on the reader. Two implementation notes worth keeping. The full text is set and then REVEALED with visible_characters rather than the string being grown - a growing string re-wraps on nearly every frame, so words jump between rows as they are typed. And a press on a line still arriving FINISHES it instead of dismissing it: without that, a player clicking at their usual pace skips the second line having never seen a word of it, which is the exact thing #127 exists to prevent. #153 - "after a dialog popup the input system is lost on keypress". Nothing was lost; it was never delivered. A dialog stops the tree (#128), a paused node receives no input, so a key RELEASED while the line was up never reached the controller - keys_down kept it and the fleet flew on in that direction once the game restarted. NOTIFICATION_UNPAUSED arrives whatever a node's process mode is, which makes it the one moment the question can be asked, and the physical keyboard is the authority on what is actually held. That fixes anything that stops the tree, not only dialogs, and the test checks it that way. #154 - the banner was the ninth child of the UI layer and every panel came after it, so all twelve of them drew over the top. It is the last child now, in both scenes. Input order was never the problem and does not change: the UI layer already sees unhandled input before the controllers do.
2026-08-29 14:39:07 +02:00
extends SceneTree
# Headless test: run with
# godot --headless -s res://tests/test_dialog_typing.gd
# Forgejo #149: "les dialogues doivent arriver petit a petit, avec un VFX
# associe a des dialogues de science fiction" - dialogs should arrive bit by
# bit, with an effect that reads as science fiction.
#
# The failure worth guarding against is not "it does not type" - it is the
# one that comes with typing: a player clicking at their usual pace skips
# the second line entirely, having never seen a word of it. #127 exists to
# stop exactly that, so a press on a line still arriving has to finish it
# rather than dismiss it.
#
# Covers:
# A. a line arrives a character at a time rather than all at once
# B. the text itself is set whole and REVEALED - growing the string would
# re-wrap the line every frame and make words jump between rows
# C. a press on a line still arriving finishes it and does not dismiss it
# D. a press on a finished line dismisses it, as it always did
# E. it types while the game is stopped, being the one node still running
# F. the sci-fi part: the panel is drawn differently while decoding, and
# settles when the line is complete
2026-09-02 13:43:56 +02:00
# G. #175 - keyboard presses do not finish or dismiss a dialog; only a
# deliberate tap/click advances it
# H. #178 - revealed text is seated at the left edge rather than growing
# outward from the middle
#149, #153, #154: dialogs arrive, sit on top, and give the keyboard back #149 - a line is typed out at about three and a half words a second, with a scan sweep running down the panel and faint rules across it while it decodes. The frame carries the charge while it works and settles when the line lands; the caret is a solid write-head during the decode and only starts blinking once it is waiting on the reader. Two implementation notes worth keeping. The full text is set and then REVEALED with visible_characters rather than the string being grown - a growing string re-wraps on nearly every frame, so words jump between rows as they are typed. And a press on a line still arriving FINISHES it instead of dismissing it: without that, a player clicking at their usual pace skips the second line having never seen a word of it, which is the exact thing #127 exists to prevent. #153 - "after a dialog popup the input system is lost on keypress". Nothing was lost; it was never delivered. A dialog stops the tree (#128), a paused node receives no input, so a key RELEASED while the line was up never reached the controller - keys_down kept it and the fleet flew on in that direction once the game restarted. NOTIFICATION_UNPAUSED arrives whatever a node's process mode is, which makes it the one moment the question can be asked, and the physical keyboard is the authority on what is actually held. That fixes anything that stops the tree, not only dialogs, and the test checks it that way. #154 - the banner was the ninth child of the UI layer and every panel came after it, so all twelve of them drew over the top. It is the last child now, in both scenes. Input order was never the problem and does not change: the UI layer already sees unhandled input before the controllers do.
2026-08-29 14:39:07 +02:00
var game_state: Node
var scene: Node
var narration: Control
var stage: int = 0
var elapsed: float = 0.0
var first_line: String = ""
var seen: Array = []
func _initialize() -> void:
# GameState is an autoload: a bare GameState.<instance member> does not
# compile in a SceneTree script, so the node is fetched by name instead.
game_state = root.get_node("GameState")
game_state.reset_new_game()
game_state.intro_active = false
game_state.reset_quests()
func _fail(message: String) -> bool:
print("TEST_DIALOG_TYPING: FAIL (%s)" % message)
quit(1)
return true
func _click() -> void:
var press: InputEventMouseButton = InputEventMouseButton.new()
press.button_index = MOUSE_BUTTON_LEFT
press.pressed = true
narration._unhandled_input(press)
#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
func _key(keycode: int, echo: bool = false) -> void:
var press: InputEventKey = InputEventKey.new()
press.keycode = keycode
press.pressed = true
press.echo = echo
narration._unhandled_input(press)
#149, #153, #154: dialogs arrive, sit on top, and give the keyboard back #149 - a line is typed out at about three and a half words a second, with a scan sweep running down the panel and faint rules across it while it decodes. The frame carries the charge while it works and settles when the line lands; the caret is a solid write-head during the decode and only starts blinking once it is waiting on the reader. Two implementation notes worth keeping. The full text is set and then REVEALED with visible_characters rather than the string being grown - a growing string re-wraps on nearly every frame, so words jump between rows as they are typed. And a press on a line still arriving FINISHES it instead of dismissing it: without that, a player clicking at their usual pace skips the second line having never seen a word of it, which is the exact thing #127 exists to prevent. #153 - "after a dialog popup the input system is lost on keypress". Nothing was lost; it was never delivered. A dialog stops the tree (#128), a paused node receives no input, so a key RELEASED while the line was up never reached the controller - keys_down kept it and the fleet flew on in that direction once the game restarted. NOTIFICATION_UNPAUSED arrives whatever a node's process mode is, which makes it the one moment the question can be asked, and the physical keyboard is the authority on what is actually held. That fixes anything that stops the tree, not only dialogs, and the test checks it that way. #154 - the banner was the ninth child of the UI layer and every panel came after it, so all twelve of them drew over the top. It is the last child now, in both scenes. Input order was never the problem and does not change: the UI layer already sees unhandled input before the controllers do.
2026-08-29 14:39:07 +02:00
func _process(delta: float) -> bool:
elapsed += delta
match stage:
0:
scene = load("res://world/Main.tscn").instantiate()
root.add_child(scene)
current_scene = scene
narration = scene.get_node("UI/NarrationBanner")
elapsed = 0.0
stage = 1
return false
1:
if elapsed < 0.3:
return false
first_line = "Convoy Kestrel, this is a long enough line that decoding it takes a moment."
narration.say(first_line, "TEST")
narration.say("And a second one behind it.", "TEST")
# --- A and B. it arrives, and the text is whole ----------
if not narration.is_typing():
return _fail("the line was complete the instant it was said")
if narration.label.text != first_line:
return _fail("the label holds a partial string - the line will re-wrap as it types")
if narration.label.visible_characters < 0:
return _fail("the whole line is visible already")
2026-09-02 13:43:56 +02:00
if narration.label.horizontal_alignment != HORIZONTAL_ALIGNMENT_LEFT:
return _fail("dialog text is not left-aligned - partial text will grow from the middle")
#149, #153, #154: dialogs arrive, sit on top, and give the keyboard back #149 - a line is typed out at about three and a half words a second, with a scan sweep running down the panel and faint rules across it while it decodes. The frame carries the charge while it works and settles when the line lands; the caret is a solid write-head during the decode and only starts blinking once it is waiting on the reader. Two implementation notes worth keeping. The full text is set and then REVEALED with visible_characters rather than the string being grown - a growing string re-wraps on nearly every frame, so words jump between rows as they are typed. And a press on a line still arriving FINISHES it instead of dismissing it: without that, a player clicking at their usual pace skips the second line having never seen a word of it, which is the exact thing #127 exists to prevent. #153 - "after a dialog popup the input system is lost on keypress". Nothing was lost; it was never delivered. A dialog stops the tree (#128), a paused node receives no input, so a key RELEASED while the line was up never reached the controller - keys_down kept it and the fleet flew on in that direction once the game restarted. NOTIFICATION_UNPAUSED arrives whatever a node's process mode is, which makes it the one moment the question can be asked, and the physical keyboard is the authority on what is actually held. That fixes anything that stops the tree, not only dialogs, and the test checks it that way. #154 - the banner was the ninth child of the UI layer and every panel came after it, so all twelve of them drew over the top. It is the last child now, in both scenes. Input order was never the problem and does not change: the UI layer already sees unhandled input before the controllers do.
2026-08-29 14:39:07 +02:00
seen.append(narration.label.visible_characters)
# Hand-ticked, so the reveal is measured rather than raced. The
# banner processes while the tree is stopped (#128), which is E.
if not paused:
return _fail("a dialog did not stop the game")
for i in range(12):
narration._process(1.0 / 60.0)
seen.append(narration.label.visible_characters)
var rising: int = 0
for i in range(1, seen.size()):
if int(seen[i]) > int(seen[i - 1]):
rising += 1
if rising < 6:
return _fail("the reveal advanced on only %d of %d frames" % [rising, seen.size() - 1])
if int(seen[-1]) >= first_line.length():
return _fail("the whole line decoded within 12 frames - that is not arriving")
print("typed while the game was stopped: %d -> %d of %d characters over 12 frames" \
% [seen[0], seen[-1], first_line.length()])
# --- F. and it looks like it is working ------------------
# is_typing() is the flag _draw() branches on for the sweep, the
# write-head caret and the frame's charge, so its transition IS
# the effect changing. Checked rather than calling _draw() by
# hand, which Godot refuses outside a paint.
if not narration.is_typing():
return _fail("the test's own ticking finished the line")
narration.queue_redraw()
narration.finish_typing()
if narration.is_typing():
return _fail("finish_typing() left the line still arriving")
if narration.label.visible_characters != -1:
return _fail("a finished line is still hiding characters")
if narration.SWEEP_SECONDS <= 0.0 or narration.CHARS_PER_SECOND <= 0.0:
return _fail("the decode has no rate to run at")
print("decoding while arriving, settled when it lands (%.0f chars/s, %.1fs sweep)" \
% [narration.CHARS_PER_SECOND, narration.SWEEP_SECONDS])
# --- C. a press finishes rather than dismisses -----------
narration.say(first_line, "TEST")
# say() queues behind the current line, so start it cleanly.
narration.clear()
narration.say(first_line, "TEST")
narration.say("Second.", "TEST")
if not narration.is_typing():
return _fail("the fresh line was not arriving")
_click()
if narration.is_typing():
return _fail("a press did not finish a line that was still arriving")
if narration.current != first_line:
return _fail("a press on an arriving line dismissed it - the next line would be skipped unread")
print("a press on an arriving line finishes it, and does not move on")
# --- D. and the next press does move on ------------------
_click()
if narration.current == first_line:
return _fail("a press on a finished line did not dismiss it")
if narration.current != "Second.":
return _fail("dismissing landed on \"%s\"" % narration.current)
print("the press after that moves on to \"%s\"" % narration.current)
2026-09-02 13:43:56 +02:00
# --- G. #175: keys never advance a dialog ----------------
#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
narration.clear()
narration.say(first_line, "TEST")
narration.say("Second.", "TEST")
if not narration.is_typing():
return _fail("the fresh line was not arriving")
_key(KEY_SHIFT)
_key(KEY_SPACE, true)
_key(KEY_SPACE)
_key(KEY_W)
_key(KEY_ENTER)
2026-09-02 13:43:56 +02:00
if not narration.is_typing() or narration.current != first_line:
return _fail("a keyboard press changed a dialog that was still arriving")
narration.finish_typing()
_key(KEY_W)
_key(KEY_ENTER)
if narration.current != first_line or narration.is_typing():
return _fail("a keyboard press dismissed a complete dialog")
_click()
if narration.current != "Second.":
return _fail("clicking after ignored keys did not reach the second line")
narration.finish_typing()
_click()
#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
if narration.is_speaking():
2026-09-02 13:43:56 +02:00
return _fail("clicking the last complete line did not close the dialog")
#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
if paused:
2026-09-02 13:43:56 +02:00
return _fail("clicking through every line left the game stopped")
print("space, W and enter leave dialogs untouched; clicks still finish and advance")
#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
#149, #153, #154: dialogs arrive, sit on top, and give the keyboard back #149 - a line is typed out at about three and a half words a second, with a scan sweep running down the panel and faint rules across it while it decodes. The frame carries the charge while it works and settles when the line lands; the caret is a solid write-head during the decode and only starts blinking once it is waiting on the reader. Two implementation notes worth keeping. The full text is set and then REVEALED with visible_characters rather than the string being grown - a growing string re-wraps on nearly every frame, so words jump between rows as they are typed. And a press on a line still arriving FINISHES it instead of dismissing it: without that, a player clicking at their usual pace skips the second line having never seen a word of it, which is the exact thing #127 exists to prevent. #153 - "after a dialog popup the input system is lost on keypress". Nothing was lost; it was never delivered. A dialog stops the tree (#128), a paused node receives no input, so a key RELEASED while the line was up never reached the controller - keys_down kept it and the fleet flew on in that direction once the game restarted. NOTIFICATION_UNPAUSED arrives whatever a node's process mode is, which makes it the one moment the question can be asked, and the physical keyboard is the authority on what is actually held. That fixes anything that stops the tree, not only dialogs, and the test checks it that way. #154 - the banner was the ninth child of the UI layer and every panel came after it, so all twelve of them drew over the top. It is the last child now, in both scenes. Input order was never the problem and does not change: the UI layer already sees unhandled input before the controllers do.
2026-08-29 14:39:07 +02:00
print("TEST_DIALOG_TYPING: PASS")
quit(0)
return true
return false