Ein im Play neu angelegter On start-Node feuert nicht für Behaviors, die schon laufen.
Stand: seit der Graph im Play bearbeitbar ist, wirken Änderungen ab dem nächsten Frame — nur On start nicht, weil der Start schon vorbei ist.
Abzuklären: nachträglich feuern (einmal pro laufender Instanz) oder bewusst so lassen und im Editor darauf hinweisen.
EDIT auch noch abzuklären: Wann feuert On start:
nur beim ersten Frame?
muss das behavior enabled sein?
wenn ein behavior später enabled wird, feuert On start dann noch einmalig?
Übernommen aus todo-notes/on-start-during-play.md beim Umzug auf das Issue-System (2026-09-12).
Angelegt: 2026-09-11 · bf41919 — Add todo notes for the next round of features, gaps and upkeep
Zuletzt geändert: 2026-09-12 · 11c900c — Drop the per-list item declaration; every item carries its own kind
Gemeldet von: Claude (Assistent)
Ein im Play neu angelegter `On start`-Node feuert nicht für Behaviors, die schon laufen.
Stand: seit der Graph im Play bearbeitbar ist, wirken Änderungen ab dem nächsten Frame — nur `On start` nicht, weil der Start schon vorbei ist.
Abzuklären: nachträglich feuern (einmal pro laufender Instanz) oder bewusst so lassen und im Editor darauf hinweisen.
EDIT auch noch abzuklären: Wann feuert `On start`:
- nur beim ersten Frame?
- muss das behavior enabled sein?
- wenn ein behavior später enabled wird, feuert `On start` dann noch einmalig?
---
*Übernommen aus `todo-notes/on-start-during-play.md` beim Umzug auf das Issue-System (2026-09-12).*
- **Angelegt:** 2026-09-11 · `bf41919` — Add todo notes for the next round of features, gaps and upkeep
- **Zuletzt geändert:** 2026-09-12 · `11c900c` — Drop the per-list item declaration; every item carries its own kind
- **Gemeldet von:** Claude (Assistent)
Nein, beim Entstehen der Instanz (syncInstances), noch vor dem ersten On update derselben Instanz. Das passiert beim Weltstart, beim Spawn und beim ersten Einschalten eines versteckten Screens.
Muss das Behavior enabled sein?
Ja, es selbst und alle Eltern (isHandleEnabled), im Editor-Lauf zusätzlich "run in editor".
Später enabled, feuert es einmalig?
Beim ersten Einschalten ja, danach nie wieder: Aus/Ein friert die Instanz nur ein (enabled.test.ts "frozen again, state kept").
Der eigentliche Fehler: ein im Play neu eingefügter On start feuert an einer laufenden Instanz nie, weil OnStart nach dem Instanz-Start nicht wieder abgefragt wird (der Interpreter sieht den Node zwar sofort). Entscheidung: so lassen, im Wiki (Behaviors, Absatz Lifecycle) als Grenze festgehalten.
Gebaut: On enable, On disable, On destroy
Reihenfolge pro Instanz: On start -> On enable -> On update ... -> On disable -> On destroy.
On enable: direkt nach On start im selben Pulse, und jedes Mal, wenn das Behavior wieder wirksam an ist.
On disable: in dem Frame, in dem es wirksam aus geht, auch wenn nur ein Elternteil schaltet. Die Instanz bleibt eingefroren (Variablen, Timer, States).
On destroy: wenn das Entity die Welt verlässt (Destroy-Node, Kind eines zerstörten Objekts) und beim Stop/Restart (Entscheidung: Stop zählt als Destroy). War es noch an, geht On disable voraus. Ein Restart ist damit On disable -> On destroy -> (neue Welt) On start -> On enable.
Mechanik (BehaviorSystem.ts): jede Instanz merkt sich active; switched() vergleicht pro Frame und feuert die Flanke. reap() am Frame-Ende und am Sync-Anfang gibt zerstörten Entities die Abschiedsereignisse, stop() allen Instanzen vor dem Abbau.
Benannte Grenzen
Der Frame, der zerstört, läuft für die Instanz zu Ende: On key down -> Destroy(Owner) liefert update, update, disable, destroy (im Test festgenagelt, war schon so).
Aus und wieder an innerhalb eines Frames per Graph-Code ist keine Flanke: keines der beiden Events.
Beweis
./check.sh: === CHECK EXIT 0 ===, 837 Tests (vorher 831; sechs neue in behavior-events.test.ts).
e2e Module 17 + 18 (Editor-Run, Play/Pause): ALL PASSED - 37 checks, Bundle nach der letzten src/-Änderung gebaut.
Fünf Gegenproben, jede beißt an ihrer Stelle: Flanke abgeklemmt, On disable auch bei schon-aus, kein Abschied beim Stop, kein On enable nach On start, kein Reap am Frame-Ende.
Voller Lauf und die drei Spiele: CI nach dem Push.
Doku: Wiki Behaviors (Node-Liste, Lifecycle), Containers (Screens), Concepts (Enabled).
## Abgeschlossen mit `6141d07` (Wiki `e3e65b9`)
### Befund zu den drei Fragen aus der Notiz
| Frage | Gemessen |
|---|---|
| Feuert `On start` nur beim ersten Frame? | Nein, **beim Entstehen der Instanz** (`syncInstances`), noch vor dem ersten `On update` derselben Instanz. Das passiert beim Weltstart, beim Spawn und beim ersten Einschalten eines versteckten Screens. |
| Muss das Behavior enabled sein? | Ja, es selbst *und* alle Eltern (`isHandleEnabled`), im Editor-Lauf zusätzlich "run in editor". |
| Später enabled, feuert es einmalig? | Beim ersten Einschalten ja, danach nie wieder: Aus/Ein friert die Instanz nur ein (`enabled.test.ts` "frozen again, state kept"). |
**Der eigentliche Fehler:** ein im Play neu eingefügter `On start` feuert an einer laufenden Instanz nie, weil `OnStart` nach dem Instanz-Start nicht wieder abgefragt wird (der Interpreter sieht den Node zwar sofort). **Entscheidung: so lassen**, im Wiki (*Behaviors*, Absatz *Lifecycle*) als Grenze festgehalten.
### Gebaut: `On enable`, `On disable`, `On destroy`
Reihenfolge pro Instanz: **`On start` -> `On enable` -> `On update` ... -> `On disable` -> `On destroy`.**
- `On enable`: direkt nach `On start` im selben Pulse, und jedes Mal, wenn das Behavior wieder wirksam an ist.
- `On disable`: in dem Frame, in dem es wirksam aus geht, auch wenn nur ein Elternteil schaltet. Die Instanz bleibt eingefroren (Variablen, Timer, States).
- `On destroy`: wenn das Entity die Welt verlässt (`Destroy`-Node, Kind eines zerstörten Objekts) **und beim Stop/Restart** (Entscheidung: Stop zählt als Destroy). War es noch an, geht `On disable` voraus. Ein Restart ist damit `On disable -> On destroy -> (neue Welt) On start -> On enable`.
Mechanik (`BehaviorSystem.ts`): jede Instanz merkt sich `active`; `switched()` vergleicht pro Frame und feuert die Flanke. `reap()` am Frame-Ende und am Sync-Anfang gibt zerstörten Entities die Abschiedsereignisse, `stop()` allen Instanzen vor dem Abbau.
### Benannte Grenzen
- Der Frame, der zerstört, läuft für die Instanz zu Ende: `On key down -> Destroy(Owner)` liefert `update, update, disable, destroy` (im Test festgenagelt, war schon so).
- Aus und wieder an innerhalb eines Frames per Graph-Code ist keine Flanke: keines der beiden Events.
### Beweis
- `./check.sh`: `=== CHECK EXIT 0 ===`, **837 Tests** (vorher 831; sechs neue in `behavior-events.test.ts`).
- e2e Module 17 + 18 (Editor-Run, Play/Pause): `ALL PASSED - 37 checks`, Bundle nach der letzten `src/`-Änderung gebaut.
- Fünf Gegenproben, jede beißt an ihrer Stelle: Flanke abgeklemmt, `On disable` auch bei schon-aus, kein Abschied beim Stop, kein `On enable` nach `On start`, kein Reap am Frame-Ende.
- Voller Lauf und die drei Spiele: CI nach dem Push.
Doku: Wiki *Behaviors* (Node-Liste, *Lifecycle*), *Containers* (Screens), *Concepts* (Enabled).
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.
Ein im Play neu angelegter
On start-Node feuert nicht für Behaviors, die schon laufen.Stand: seit der Graph im Play bearbeitbar ist, wirken Änderungen ab dem nächsten Frame — nur
On startnicht, weil der Start schon vorbei ist.Abzuklären: nachträglich feuern (einmal pro laufender Instanz) oder bewusst so lassen und im Editor darauf hinweisen.
EDIT auch noch abzuklären: Wann feuert
On start:On startdann noch einmalig?Übernommen aus
todo-notes/on-start-during-play.mdbeim Umzug auf das Issue-System (2026-09-12).bf41919— Add todo notes for the next round of features, gaps and upkeep11c900c— Drop the per-list item declaration; every item carries its own kindAbgeschlossen mit
6141d07(Wikie3e65b9)Befund zu den drei Fragen aus der Notiz
On startnur beim ersten Frame?syncInstances), noch vor dem erstenOn updatederselben Instanz. Das passiert beim Weltstart, beim Spawn und beim ersten Einschalten eines versteckten Screens.isHandleEnabled), im Editor-Lauf zusätzlich "run in editor".enabled.test.ts"frozen again, state kept").Der eigentliche Fehler: ein im Play neu eingefügter
On startfeuert an einer laufenden Instanz nie, weilOnStartnach dem Instanz-Start nicht wieder abgefragt wird (der Interpreter sieht den Node zwar sofort). Entscheidung: so lassen, im Wiki (Behaviors, Absatz Lifecycle) als Grenze festgehalten.Gebaut:
On enable,On disable,On destroyReihenfolge pro Instanz:
On start->On enable->On update... ->On disable->On destroy.On enable: direkt nachOn startim selben Pulse, und jedes Mal, wenn das Behavior wieder wirksam an ist.On disable: in dem Frame, in dem es wirksam aus geht, auch wenn nur ein Elternteil schaltet. Die Instanz bleibt eingefroren (Variablen, Timer, States).On destroy: wenn das Entity die Welt verlässt (Destroy-Node, Kind eines zerstörten Objekts) und beim Stop/Restart (Entscheidung: Stop zählt als Destroy). War es noch an, gehtOn disablevoraus. Ein Restart ist damitOn disable -> On destroy -> (neue Welt) On start -> On enable.Mechanik (
BehaviorSystem.ts): jede Instanz merkt sichactive;switched()vergleicht pro Frame und feuert die Flanke.reap()am Frame-Ende und am Sync-Anfang gibt zerstörten Entities die Abschiedsereignisse,stop()allen Instanzen vor dem Abbau.Benannte Grenzen
On key down -> Destroy(Owner)liefertupdate, update, disable, destroy(im Test festgenagelt, war schon so).Beweis
./check.sh:=== CHECK EXIT 0 ===, 837 Tests (vorher 831; sechs neue inbehavior-events.test.ts).ALL PASSED - 37 checks, Bundle nach der letztensrc/-Änderung gebaut.On disableauch bei schon-aus, kein Abschied beim Stop, keinOn enablenachOn start, kein Reap am Frame-Ende.Doku: Wiki Behaviors (Node-Liste, Lifecycle), Containers (Screens), Concepts (Enabled).