meleki/feuerwerk
1
0 Fork 0
Code Issues 38 Actions Projects 1 Wiki Activity

e2e 41: Zieh-Check während Play wackelt bei trägem Browser #282

New Issue
Closed
opened 2026-09-29 18:26:31 +02:00 by meleki · 1 comment
meleki commented 2026-09-29 18:26:31 +02:00
Owner
Copy link
Copy source

Aus der CI-Durchsicht in #156 (Durchgang 3). Regel aus #152: Ein Wackler, der wiederkommt, bekommt ein eigenes Issue.

Befund

  • Der Check „a body dragged while playing hangs where the pointer holds it and is let go at rest“ (tools/e2e/41-physics.mjs:311) war zweimal rot: Task 347 (2eeabf7, Hierarchie-Gruppen aus #241) und Task 357 (320d3e2, Lerp-Node aus #246), beide am 2026-09-27. Keiner der beiden Commits fasst das Ziehen in der Scene View an. Der jeweils nächste Lauf war grün.
  • Von 74 fertigen suite-Läufen seit dem 23.09. war er nur in diesen zwei rot. Seit Task 357 lief er in 21 Läufen durch.
  • Beide Male stand im Log "held":[-3475,-3490]. In der Haltesekunde kamen also nur 2 Messpunkte zurück, der Check verlangt mehr als 10 (Zeile 313). Gemessen wird per CDP-evaluate im 50-ms-Takt (sampleCrate, Zeile 294), und jede Abfrage wartet auf den Browser. War der Browser in dem Moment träge, kommen zu wenige Punkte, und der erste liegt noch 15 Einheiten vor dem Ziel.

Zu bauen (Vorschlag)

  • Die Positionen im Browser selbst aufzeichnen (pro Frame, über einen Test-Hook) und am Ende einmal abholen, statt jede einzeln per CDP zu fragen. Dann hängt die Zahl der Punkte an den Frames und nicht an der Latenz.
  • Die Bedingung auf Frames stellen: mindestens 30 gehaltene Frames, alle am Ziel.
  • Gegenprobe: Mit dem alten Verhalten (der Körper fällt beim Halten weiter) muss der Check fallen.

Offen

Keine Rückfrage.

Aus der CI-Durchsicht in #156 (Durchgang 3). Regel aus #152: Ein Wackler, der wiederkommt, bekommt ein eigenes Issue. ## Befund - Der Check „a body dragged while playing hangs where the pointer holds it and is let go at rest“ (`tools/e2e/41-physics.mjs:311`) war zweimal rot: Task 347 (`2eeabf7`, Hierarchie-Gruppen aus #241) und Task 357 (`320d3e2`, `Lerp`-Node aus #246), beide am 2026-09-27. Keiner der beiden Commits fasst das Ziehen in der Scene View an. Der jeweils nächste Lauf war grün. - Von 74 fertigen `suite`-Läufen seit dem 23.09. war er nur in diesen zwei rot. Seit Task 357 lief er in 21 Läufen durch. - Beide Male stand im Log `"held":[-3475,-3490]`. In der Haltesekunde kamen also nur **2** Messpunkte zurück, der Check verlangt mehr als 10 (Zeile 313). Gemessen wird per CDP-`evaluate` im 50-ms-Takt (`sampleCrate`, Zeile 294), und jede Abfrage wartet auf den Browser. War der Browser in dem Moment träge, kommen zu wenige Punkte, und der erste liegt noch 15 Einheiten vor dem Ziel. ## Zu bauen (Vorschlag) - Die Positionen im Browser selbst aufzeichnen (pro Frame, über einen Test-Hook) und am Ende einmal abholen, statt jede einzeln per CDP zu fragen. Dann hängt die Zahl der Punkte an den Frames und nicht an der Latenz. - Die Bedingung auf Frames stellen: mindestens 30 gehaltene Frames, alle am Ziel. - Gegenprobe: Mit dem alten Verhalten (der Körper fällt beim Halten weiter) muss der Check fallen. ## Offen Keine Rückfrage.
meleki added the new label 2026-09-29 18:26:31 +02:00
admin added high-priority and removed new labels 2026-09-29 18:27:40 +02:00
admin added this to the Development project 2026-09-29 18:27:43 +02:00
admin moved this to Next in Development on 2026-09-29 18:27:45 +02:00
meleki commented 2026-09-29 22:20:31 +02:00
Author
Owner
Copy link
Copy source

Done in 9cff528. No wiki change.

What you get

  • The drag check in e2e 41 ("a body dragged while playing hangs where the pointer holds it and is let go at rest") no longer races the last mouse move. It passed 6 of 6 runs under WSL, where it had failed in 2 of 3 before.

The diagnosis above was wrong

  • "held":[-3475,-3490] were not two samples. The log printed only the first and the last sample of the held second. -3475 is the height of the ninth of ten mouse moves.
  • The real cause: the last move reaches the body a few frames later (preview, physics step, drawn one step behind). The first sample came right after the move and sometimes beat it. Frames under WSL are longer, which made it likely there.

Under the hood (tools/e2e/41-physics.mjs)

  • The check first waits until the crate is at the pointer, for at most 2 s. If it never arrives, the check fails with arrived: false instead of stopping the run.
  • The page then records the crate's height in every frame, and the check fetches the samples once. The count follows the frames, not the CDP round trips. The check asks for at least 30 held frames, all at the target.
  • Held and released samples are split by page timestamps taken right before and after the release. "Fell" is the last sample within 200 ms of letting go, as before it must be 1 to 40 below the hold.

Tests

e2e 41 (WSL, melektaus-atx)   6 of 6 runs ALL PASSED - 21 checks, 59-64 held frames
gate (melektaus-atx)          195 files, 2827 tests, CHECK EXIT 0
  • Counter-check 1 works: when the hold is not passed to the world, the crate stays on the ground and the check fails.
  • Counter-check 2 does not: a body let go without zeroing its speed keeps the check green, because after a second of holding the speed is 0 anyway. The unit test "grab too short for a physics step" covers that case, as it did before.
  • No full run yet. The CI run for 9cff528 is the first full run with this fix.
Done in `9cff528`. No wiki change. **What you get** - The drag check in e2e 41 ("a body dragged while playing hangs where the pointer holds it and is let go at rest") no longer races the last mouse move. It passed 6 of 6 runs under WSL, where it had failed in 2 of 3 before. **The diagnosis above was wrong** - `"held":[-3475,-3490]` were not two samples. The log printed only the first and the last sample of the held second. -3475 is the height of the ninth of ten mouse moves. - The real cause: the last move reaches the body a few frames later (preview, physics step, drawn one step behind). The first sample came right after the move and sometimes beat it. Frames under WSL are longer, which made it likely there. **Under the hood** (`tools/e2e/41-physics.mjs`) - The check first waits until the crate is at the pointer, for at most 2 s. If it never arrives, the check fails with `arrived: false` instead of stopping the run. - The page then records the crate's height in every frame, and the check fetches the samples once. The count follows the frames, not the CDP round trips. The check asks for at least 30 held frames, all at the target. - Held and released samples are split by page timestamps taken right before and after the release. "Fell" is the last sample within 200 ms of letting go, as before it must be 1 to 40 below the hold. **Tests** ``` e2e 41 (WSL, melektaus-atx) 6 of 6 runs ALL PASSED - 21 checks, 59-64 held frames gate (melektaus-atx) 195 files, 2827 tests, CHECK EXIT 0 ``` - Counter-check 1 works: when the hold is not passed to the world, the crate stays on the ground and the check fails. - Counter-check 2 does not: a body let go without zeroing its speed keeps the check green, because after a second of holding the speed is 0 anyway. The unit test "grab too short for a physics step" covers that case, as it did before. - No full run yet. The CI run for `9cff528` is the first full run with this fix.
admin moved this to Done in Development on 2026-09-29 22:22:09 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
held-back
high-priority
low-priority
new
particles
question
shader
Shader-Assets, Shader-Graph, Filter
 state-machine
State machine follow-ups (from #51)
 todo-note
Aus dem alten todo-notes/-Ordner übernommen
No labels high-priority
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Development
Done
Assignees
Clear assignees
meleki
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: meleki/feuerwerk#282