Aus #410, gefunden beim ersten Lauf von e2e 66s. In #410 nicht behoben, weil es ein bestehendes Verhalten aus #404/#420 ändert.
Befund
Steht ein Driven-Sprite (#404) in der Szene, wartet der Run beim Start bis zu VIDEO_WAIT_MS (3 s) auf dessen erstes Bild (src/editor/PlaySession.ts:318, waitForVideos; im exportierten Spiel src/player/Player.ts:145). Die Welt tickt in dieser Zeit nicht.
Die freien Videos (Video clock: Free) laufen in dieser Zeit aber schon, ihr geteilter Player im Viewport hält nicht an.
Seit #410 führt das VideoSystem für freie Sprites eine eigene Uhr ab ihrem Erscheinen. Diese Uhr steht während des Wartens. Sie hinkt dem Bild also um die Wartezeit hinterher.
Folgen
On video finished kommt bei einem freien Video um die Wartezeit zu spät.
Video time (Daten-Node) liefert für ein freies Video um die Wartezeit zu wenig.
Ein Pause video auf ein freies Sprite übernimmt die verspätete Uhr: Der eigene Player hält an einer Stelle, die das Bild schon hinter sich hat, das Bild springt also zurück. Seek video ist nicht betroffen, es setzt eine feste Zeit.
Tastendrücke in der Wartephase gehen verloren. Das war schon vor #410 so.
Vorschlag
Während des Wartens auch die freien Player anhalten und erst mit dem ersten Tick der Welt weiterlaufen lassen. Dann stimmen Bild und Uhr überein.
Zu klären: Ob das auch für die Aufnahme (#405, #423) gilt, die schon eigene Halteregeln hat (RecordingTake.ts:324).
Prüfen
Unit: Uhr eines freien Sprites gegen die Zeit des Players nach einer Wartephase.
e2e 66: Szene mit einem Driven-Sprite, das langsam lädt, und einem freien Video daneben. On video finished des freien Videos muss mit seinem letzten Bild kommen, nicht um die Wartezeit später.
Aus #410, gefunden beim ersten Lauf von e2e 66s. In #410 nicht behoben, weil es ein bestehendes Verhalten aus #404/#420 ändert.
## Befund
- Steht ein *Driven*-Sprite (#404) in der Szene, wartet der Run beim Start bis zu `VIDEO_WAIT_MS` (3 s) auf dessen erstes Bild (`src/editor/PlaySession.ts:318`, `waitForVideos`; im exportierten Spiel `src/player/Player.ts:145`). Die Welt tickt in dieser Zeit nicht.
- Die **freien** Videos (`Video clock: Free`) laufen in dieser Zeit aber schon, ihr geteilter Player im Viewport hält nicht an.
- Seit #410 führt das `VideoSystem` für freie Sprites eine eigene Uhr ab ihrem Erscheinen. Diese Uhr steht während des Wartens. Sie hinkt dem Bild also um die Wartezeit hinterher.
## Folgen
- *On video finished* kommt bei einem freien Video um die Wartezeit zu spät.
- *Video time* (Daten-Node) liefert für ein freies Video um die Wartezeit zu wenig.
- Ein *Pause video* auf ein freies Sprite übernimmt die verspätete Uhr: Der eigene Player hält an einer Stelle, die das Bild schon hinter sich hat, das Bild springt also zurück. *Seek video* ist nicht betroffen, es setzt eine feste Zeit.
- Tastendrücke in der Wartephase gehen verloren. Das war schon vor #410 so.
## Vorschlag
- Während des Wartens auch die freien Player anhalten und erst mit dem ersten Tick der Welt weiterlaufen lassen. Dann stimmen Bild und Uhr überein.
- Zu klären: Ob das auch für die Aufnahme (#405, #423) gilt, die schon eigene Halteregeln hat (`RecordingTake.ts:324`).
## Prüfen
- Unit: Uhr eines freien Sprites gegen die Zeit des Players nach einer Wartephase.
- e2e 66: Szene mit einem *Driven*-Sprite, das langsam lädt, und einem freien Video daneben. *On video finished* des freien Videos muss mit seinem letzten Bild kommen, nicht um die Wartezeit später.
Erledigt mit beb95c17, Wiki 31deb31 (Videos, Punkt „Free videos wait with it“).
Was gebaut ist
Wartet ein Run auf seine Driven-Videos, halten auch die freien Videos an: beim Start, nach einem Load scene und während eine Aufnahme ihre Encoder einrichtet. Mit dem ersten Frame der Welt spielen sie weiter. Bild und Uhr des Sprites passen damit zusammen, also auch On video finished, Video time und Pause video.
Die Aufnahme braucht keine eigene Regel: Sie nimmt während der Wartephase nichts auf und beginnt mit dem gehaltenen Bild.
Umsetzung: VideoLibrary.setHeld hält zusätzlich zur Toolbar-Pause an, PlaySession und Player schalten es mit dem Warten.
Ausnahme: Ein freies Video ohne erstes Bild läuft weiter, bis es eines hat.
Mitbehoben
Beim Weiterspielen wurde ein Clip ohne Loop, der schon am Ende stand, wieder von vorn gestartet. Das kam schon bei der Toolbar-Pause vor. Jetzt bleibt so ein Clip am Ende stehen.
Tests
Prüfung
Ergebnis
Unit video-library
14/14, davon 2 neu; 7 Gegenproben, alle rot
e2e 66 (atx)
ALL PASSED, 40 Checks. Neu 66t: Driven-Video 1,5 s verzögert, Wartephase 1686 ms. Das freie Video blieb die ganze Zeit rot, Blau bei 0,983 s, Weiß bei 1,483 s, On video finished bei 2,017 s. Ohne den Halt war es schon im ersten Frame weiß.
Gate (atx)
CHECK EXIT 0, 339 Dateien, 5253 Tests
Der Schutz für das Clip-Ende kam erst während des Gates dazu. Geprüft ist er mit tsc, Lint und der Testdatei samt 3 Gegenproben; den vollen Lauf macht CI.
Erledigt mit `beb95c17`, Wiki `31deb31` (*Videos*, Punkt „Free videos wait with it“).
**Was gebaut ist**
- Wartet ein Run auf seine Driven-Videos, halten auch die freien Videos an: beim Start, nach einem *Load scene* und während eine Aufnahme ihre Encoder einrichtet. Mit dem ersten Frame der Welt spielen sie weiter. Bild und Uhr des Sprites passen damit zusammen, also auch *On video finished*, *Video time* und *Pause video*.
- Die Aufnahme braucht keine eigene Regel: Sie nimmt während der Wartephase nichts auf und beginnt mit dem gehaltenen Bild.
- Umsetzung: `VideoLibrary.setHeld` hält zusätzlich zur Toolbar-Pause an, `PlaySession` und `Player` schalten es mit dem Warten.
- Ausnahme: Ein freies Video ohne erstes Bild läuft weiter, bis es eines hat.
**Mitbehoben**
- Beim Weiterspielen wurde ein Clip ohne Loop, der schon am Ende stand, wieder von vorn gestartet. Das kam schon bei der Toolbar-Pause vor. Jetzt bleibt so ein Clip am Ende stehen.
**Tests**
| Prüfung | Ergebnis |
|---|---|
| Unit `video-library` | 14/14, davon 2 neu; 7 Gegenproben, alle rot |
| e2e 66 (atx) | ALL PASSED, 40 Checks. Neu 66t: Driven-Video 1,5 s verzögert, Wartephase 1686 ms. Das freie Video blieb die ganze Zeit rot, Blau bei 0,983 s, Weiß bei 1,483 s, *On video finished* bei 2,017 s. Ohne den Halt war es schon im ersten Frame weiß. |
| Gate (atx) | `CHECK EXIT 0`, 339 Dateien, 5253 Tests |
Der Schutz für das Clip-Ende kam erst während des Gates dazu. Geprüft ist er mit `tsc`, Lint und der Testdatei samt 3 Gegenproben; den vollen Lauf macht CI.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Aus #410, gefunden beim ersten Lauf von e2e 66s. In #410 nicht behoben, weil es ein bestehendes Verhalten aus #404/#420 ändert.
Befund
VIDEO_WAIT_MS(3 s) auf dessen erstes Bild (src/editor/PlaySession.ts:318,waitForVideos; im exportierten Spielsrc/player/Player.ts:145). Die Welt tickt in dieser Zeit nicht.Video clock: Free) laufen in dieser Zeit aber schon, ihr geteilter Player im Viewport hält nicht an.VideoSystemfür freie Sprites eine eigene Uhr ab ihrem Erscheinen. Diese Uhr steht während des Wartens. Sie hinkt dem Bild also um die Wartezeit hinterher.Folgen
Vorschlag
RecordingTake.ts:324).Prüfen
vorschläge passen
Erledigt mit
beb95c17, Wiki31deb31(Videos, Punkt „Free videos wait with it“).Was gebaut ist
VideoLibrary.setHeldhält zusätzlich zur Toolbar-Pause an,PlaySessionundPlayerschalten es mit dem Warten.Mitbehoben
Tests
video-libraryCHECK EXIT 0, 339 Dateien, 5253 TestsDer Schutz für das Clip-Ende kam erst während des Gates dazu. Geprüft ist er mit
tsc, Lint und der Testdatei samt 3 Gegenproben; den vollen Lauf macht CI.