metaheavens/spaceship - Forgejo

metaheavens/spaceship

Watch

1 line

20 B

Text

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

uid://ce1elyyw2ds53