Fix the web build: a wasm trap on integer % 0, and buttons that never fired
The web export reached the main menu and went no further. Two separate bugs,
one hiding the other.
BUTTONS NEVER FIRED. A browser on a phone delivers the touch DOWN and never
the release. IconButton emits `pressed` only on release, deliberately, so
that dragging off cancels - so on the web it never emitted at all, on every
button in the game. fire_on_press (default OS.has_feature("web")) completes
the press there instead, and does not latch, since nothing is coming to
unlatch it. The cost is drag-off-to-cancel, which every other platform keeps.
Measured on the device rather than guessed: an on-screen probe reported
`touch=1 mouse=1 held=y` after one tap - one down, one emulated mouse down,
the button latched through ordinary GUI routing, then nothing.
THE ENGINE THEN TRAPPED. With the button working, pressing Play loaded and
built Main.tscn and the whole engine stopped mid-frame, page still alive.
An error overlay in a custom HTML shell finally showed why:
Uncaught RuntimeError: remainder by zero
An integer % 0. Wasm TRAPS on that; native builds silently tolerate it. So
the bug was equally present on Android and in all 100 tests, doing nothing
in both - which is why nothing runnable here could ever have caught it, and
why reasoning from frozen screenshots got nowhere for several rounds. Every
variable modulo is now guarded: the hangar grid's `i % columns`, planet
naming's `% names.size()`, and two in the map editor.
WHAT IS KEPT, AND WHY
- web_shell.html mirrors console errors onto the page, hidden until one
occurs. Godot's errors go to the browser console, which is unreachable on
a phone; this found in one shot what inference had failed to find all
evening. It costs nothing when there is nothing to report.
- MainMenu._start does load -> instantiate -> add_child by hand instead of
change_scene_to_file. That call does all three opaquely, so a failure is
indistinguishable from an unpressed button; split, each step reports.
- PlanetAtmosphereController defers the forced world populate out of the
frame that builds Main.tscn. It did not fix the hang - the trap did - but
25 chunks of asteroids and 49 of planets do not belong in the one frame
that already constructs 197 nodes, and nothing can paint until it ends.
Removed the direct-input-routing experiment and its test: it was written on
the theory that touches were not reaching Controls, which `held=y` later
disproved, and its set_input_as_handled() swallowed the very events the
probe was reading.
Full suite green at 100/100.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
00455dc6ba
commit
137e4e528d
13 changed files with 319 additions and 89 deletions
|
|
@ -110,24 +110,6 @@ func _blocked_by_modal() -> bool:
|
|||
return false
|
||||
|
||||
|
||||
# Fire on the PRESS instead of the release.
|
||||
#
|
||||
# A browser on a phone delivers the touch down and then never delivers the
|
||||
# release. Measured directly on the deployed build: presses arrive with
|
||||
# correct coordinates, land inside the button, and the button visibly latches
|
||||
# into its held state - and no release ever follows, in _gui_input or in raw
|
||||
# _input. A button that only emits on release therefore never emits at all,
|
||||
# which is exactly the "Play does nothing" report.
|
||||
#
|
||||
# The cost is the drag-off-to-cancel affordance below, which is worth much
|
||||
# less than the button working. Everywhere else keeps it, because everywhere
|
||||
# else delivers releases.
|
||||
#
|
||||
# Settable rather than a constant so a test can exercise both paths without
|
||||
# needing to be a web build.
|
||||
@export var fire_on_press: bool = OS.has_feature("web")
|
||||
|
||||
|
||||
func _gui_input(event: InputEvent) -> void:
|
||||
if _blocked_by_modal():
|
||||
return
|
||||
|
|
@ -139,14 +121,28 @@ func _gui_input(event: InputEvent) -> void:
|
|||
accept_event()
|
||||
|
||||
|
||||
# Complete the press immediately instead of waiting for a release.
|
||||
#
|
||||
# Measured on the device, in the web build: an on-screen probe reported
|
||||
# `touch=1 mouse=1 held=y` after one tap - one touch down, one emulated mouse
|
||||
# down, the button latched into its held state through ordinary GUI routing,
|
||||
# and then nothing. The release is never delivered. A button that only emits
|
||||
# on release therefore never emits at all.
|
||||
#
|
||||
# GUI routing itself works fine; `held=y` is the proof. An earlier attempt to
|
||||
# bypass it made things worse and hid the evidence.
|
||||
#
|
||||
# The cost is the drag-off-to-cancel affordance below. Everywhere that
|
||||
# delivers releases keeps it.
|
||||
@export var fire_on_press: bool = OS.has_feature("web")
|
||||
|
||||
|
||||
func _handle_press(is_pressed: bool, at_position: Vector2) -> void:
|
||||
if is_pressed:
|
||||
pressed_down = true
|
||||
queue_redraw()
|
||||
if fire_on_press:
|
||||
# Nothing is coming to complete this press, so complete it here.
|
||||
# Not latched: with no release to clear it, the button would
|
||||
# otherwise stay drawn in its held state forever.
|
||||
# Not latched: nothing is coming to clear it.
|
||||
pressed_down = false
|
||||
pressed.emit()
|
||||
elif pressed_down:
|
||||
|
|
|
|||
Loading…
Reference in a new issue