Heute startet ein Behavior, das per Run behavior aufgerufen wird, bei jedem Aufruf mit den Standardwerten seiner Variablen. Was es während des Aufrufs hineinschreibt, ist nach dem Rücksprung weg. Dasselbe gilt für lokale State Machines im aufgerufenen Behavior. Ein Zähler oder ein Merker im verschachtelten Behavior ist damit nicht möglich.
Gewünscht
Ein verschachteltes Behavior soll sich seine Variablen über mehrere Aufrufe merken können, mit einem eigenen Zustand für jedes aufrufende Objekt.
Entscheidungen (mit dem User abgestimmt)
Schalter „Keep state“ am Run behavior-Node, Standard aus. Bestehende Projekte laufen unverändert weiter.
Jeder Node hat seinen eigenen Zustand, pro Objekt. Zwei Run behavior-Nodes, die dasselbe Behavior aufrufen, teilen sich nichts. So wie jeder Timer-Node seinen eigenen Takt hat.
Lokale State Machines im aufgerufenen Behavior werden genauso behandelt wie seine Variablen.
Ruft ein behaltenes Behavior selbst wieder ein Behavior mit „Keep state“ auf, hat auch dieser innere Aufruf einen eigenen Zustand je äußerem Aufrufer.
Wird im aufgerufenen Behavior eine Variable dazu deklariert oder gelöscht, gilt die heutige Deklaration: neue Variablen starten mit ihrem Standardwert, gelöschte fallen weg.
Der Zustand lebt so lange wie das Objekt im Lauf. Er wird nicht gespeichert.
Heute startet ein Behavior, das per `Run behavior` aufgerufen wird, bei jedem Aufruf mit den Standardwerten seiner Variablen. Was es während des Aufrufs hineinschreibt, ist nach dem Rücksprung weg. Dasselbe gilt für lokale State Machines im aufgerufenen Behavior. Ein Zähler oder ein Merker im verschachtelten Behavior ist damit nicht möglich.
## Gewünscht
Ein verschachteltes Behavior soll sich seine Variablen über mehrere Aufrufe merken können, mit einem eigenen Zustand für jedes aufrufende Objekt.
## Entscheidungen (mit dem User abgestimmt)
- **Schalter „Keep state“ am `Run behavior`-Node, Standard aus.** Bestehende Projekte laufen unverändert weiter.
- **Jeder Node hat seinen eigenen Zustand, pro Objekt.** Zwei `Run behavior`-Nodes, die dasselbe Behavior aufrufen, teilen sich nichts. So wie jeder Timer-Node seinen eigenen Takt hat.
- **Lokale State Machines** im aufgerufenen Behavior werden genauso behandelt wie seine Variablen.
- Ruft ein behaltenes Behavior selbst wieder ein Behavior mit „Keep state“ auf, hat auch dieser innere Aufruf einen eigenen Zustand je äußerem Aufrufer.
- Wird im aufgerufenen Behavior eine Variable dazu deklariert oder gelöscht, gilt die heutige Deklaration: neue Variablen starten mit ihrem Standardwert, gelöschte fallen weg.
- Der Zustand lebt so lange wie das Objekt im Lauf. Er wird nicht gespeichert.
Neue Checkbox Keep state am Run behavior-Node, standardmäßig aus. Bestehende Projekte laufen unverändert.
Ist sie an, macht das aufgerufene Behavior beim nächsten Aufruf dort weiter, wo der letzte Aufruf von diesem Node auf diesem Objekt aufgehört hat. Das gilt für Variablen und lokale State Machines.
Zwei Nodes mit demselben Behavior haben je einen eigenen Zustand, zwei Objekte ebenso. Verschachtelte Aufrufe mit Keep state bekommen je äußerem Node einen eigenen Zustand.
Ändert sich das aufgerufene Behavior: Eine neue Variable startet mit ihrem Standardwert, eine gelöschte fällt weg, eine Variable mit geänderter Art startet von vorn.
Der Zustand lebt, solange das Objekt im Lauf existiert. Ins Savegame wird er nicht geschrieben.
Umsetzung
RunBehavior.ts: Parameter keepState.
GraphInterpreter.ts: keptCalls merkt sich den Zustand pro Aufrufpfad, resumedVariables() gleicht mit den aktuellen Deklarationen ab.
Grenze: Ein Eingang namens keepState im aufgerufenen Behavior kommt dem Schalter in die Quere (wie heute schon behavior).
10 neue Unit-Tests in tests/core/keep-state.test.ts, 1 neuer Fall im Node-Katalog.
e2e 19: 35 Checks grün, darunter der neue Check 19c-ii (Checkbox, Klick, Undo).
5 Gegenproben, jede fällt an ihrer Stelle.
Doku: Wiki Behaviors (Keep state) und State machines.
Umgesetzt in 7c70245.
**Verhalten**
- Neue Checkbox **Keep state** am `Run behavior`-Node, standardmäßig aus. Bestehende Projekte laufen unverändert.
- Ist sie an, macht das aufgerufene Behavior beim nächsten Aufruf dort weiter, wo der letzte Aufruf **von diesem Node auf diesem Objekt** aufgehört hat. Das gilt für Variablen und lokale State Machines.
- Zwei Nodes mit demselben Behavior haben je einen eigenen Zustand, zwei Objekte ebenso. Verschachtelte Aufrufe mit Keep state bekommen je äußerem Node einen eigenen Zustand.
- Ändert sich das aufgerufene Behavior: Eine neue Variable startet mit ihrem Standardwert, eine gelöschte fällt weg, eine Variable mit geänderter Art startet von vorn.
- Der Zustand lebt, solange das Objekt im Lauf existiert. Ins Savegame wird er nicht geschrieben.
**Umsetzung**
- `RunBehavior.ts`: Parameter `keepState`.
- `GraphInterpreter.ts`: `keptCalls` merkt sich den Zustand pro Aufrufpfad, `resumedVariables()` gleicht mit den aktuellen Deklarationen ab.
**Grenze:** Ein Eingang namens `keepState` im aufgerufenen Behavior kommt dem Schalter in die Quere (wie heute schon `behavior`).
**Tests**
- `./check.sh`: 163 Dateien, 2388 Tests, grün (vorher 2377).
- 10 neue Unit-Tests in `tests/core/keep-state.test.ts`, 1 neuer Fall im Node-Katalog.
- e2e 19: 35 Checks grün, darunter der neue Check 19c-ii (Checkbox, Klick, Undo).
- 5 Gegenproben, jede fällt an ihrer Stelle.
Doku: Wiki *Behaviors* (Keep state) und *State machines*.
Umgestellt in 454d202 (Wiki f436f6d): Keep sitzt jetzt an der Variable, nicht mehr am Run behavior-Node.
Verhalten
Jede Variable eines Behaviors hat im Inspector einen Knopf Keep. Ein Klick schaltet um, jede Änderung ist ein eigener Undo-Schritt. Variables-Assets haben den Knopf nicht.
Neu angelegte Variablen starten mit Keep an. Variablen aus bestehenden Projekten starten mit Keep aus, alte Projekte laufen also unverändert.
Behalten wird wie bisher pro Run behavior-Node und pro Objekt. Variablen ohne Keep starten bei jedem Aufruf mit ihrem Startwert.
Lokale State Machines in einem aufgerufenen Behavior starten wieder bei jedem Aufruf ohne Zustand, wie vor #229. global und scene sind unverändert.
Der Schalter keepState am Node ist entfernt. Steht er in einem gespeicherten Projekt noch drin, wird er ignoriert.
Der Knopf zeigt seinen Zustand sofort nach dem Klick an. Die Keep-Liste gehört dafür zur Signatur des Inspectors.
Umsetzung
BehaviorAsset.keptVariables in src/core/model/Asset.ts, geladen und gespeichert in serialize.ts. Beim Laden fallen nicht deklarierte Namen weg.
SetVariableKeptCommand in variableCommands.ts. Anlegen, Löschen und Umbenennen ziehen die Liste mit.
GraphInterpreter.resumedVariables() behält nur die Variablen aus der Liste.
Tests
./check.sh: 163 Dateien, 2392 Tests, CHECK EXIT 0
tests/core/keep-state.test.ts neu geschrieben, 15 Tests
e2e 19: ALL PASSED, 35 Checks. 19c-ii klickt den Keep-Knopf einer neuen Variable (an beim Anlegen, aus nach Klick, wieder an, aus nach Undo).
Gegenproben: Keep-Liste ignoriert, States behalten, neue Variable nicht an, Umbenennen ohne Liste, kein Knopf. Jede fällt an ihrem Test.
Umgestellt in `454d202` (Wiki `f436f6d`): **Keep sitzt jetzt an der Variable, nicht mehr am `Run behavior`-Node.**
**Verhalten**
- Jede Variable eines Behaviors hat im Inspector einen Knopf **Keep**. Ein Klick schaltet um, jede Änderung ist ein eigener Undo-Schritt. Variables-Assets haben den Knopf nicht.
- Neu angelegte Variablen starten mit Keep **an**. Variablen aus bestehenden Projekten starten mit Keep **aus**, alte Projekte laufen also unverändert.
- Behalten wird wie bisher pro `Run behavior`-Node und pro Objekt. Variablen ohne Keep starten bei jedem Aufruf mit ihrem Startwert.
- Lokale State Machines in einem aufgerufenen Behavior starten wieder bei jedem Aufruf ohne Zustand, wie vor #229. `global` und `scene` sind unverändert.
- Der Schalter `keepState` am Node ist entfernt. Steht er in einem gespeicherten Projekt noch drin, wird er ignoriert.
- Der Knopf zeigt seinen Zustand sofort nach dem Klick an. Die Keep-Liste gehört dafür zur Signatur des Inspectors.
**Umsetzung**
- `BehaviorAsset.keptVariables` in `src/core/model/Asset.ts`, geladen und gespeichert in `serialize.ts`. Beim Laden fallen nicht deklarierte Namen weg.
- `SetVariableKeptCommand` in `variableCommands.ts`. Anlegen, Löschen und Umbenennen ziehen die Liste mit.
- `GraphInterpreter.resumedVariables()` behält nur die Variablen aus der Liste.
**Tests**
- `./check.sh`: 163 Dateien, 2392 Tests, `CHECK EXIT 0`
- `tests/core/keep-state.test.ts` neu geschrieben, 15 Tests
- e2e 19: ALL PASSED, 35 Checks. 19c-ii klickt den Keep-Knopf einer neuen Variable (an beim Anlegen, aus nach Klick, wieder an, aus nach Undo).
- Gegenproben: Keep-Liste ignoriert, States behalten, neue Variable nicht an, Umbenennen ohne Liste, kein Knopf. Jede fällt an ihrem Test.
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.
Heute startet ein Behavior, das per
Run behavioraufgerufen wird, bei jedem Aufruf mit den Standardwerten seiner Variablen. Was es während des Aufrufs hineinschreibt, ist nach dem Rücksprung weg. Dasselbe gilt für lokale State Machines im aufgerufenen Behavior. Ein Zähler oder ein Merker im verschachtelten Behavior ist damit nicht möglich.Gewünscht
Ein verschachteltes Behavior soll sich seine Variablen über mehrere Aufrufe merken können, mit einem eigenen Zustand für jedes aufrufende Objekt.
Entscheidungen (mit dem User abgestimmt)
Run behavior-Node, Standard aus. Bestehende Projekte laufen unverändert weiter.Run behavior-Nodes, die dasselbe Behavior aufrufen, teilen sich nichts. So wie jeder Timer-Node seinen eigenen Takt hat.Umgesetzt in
7c70245.Verhalten
Run behavior-Node, standardmäßig aus. Bestehende Projekte laufen unverändert.Umsetzung
RunBehavior.ts: ParameterkeepState.GraphInterpreter.ts:keptCallsmerkt sich den Zustand pro Aufrufpfad,resumedVariables()gleicht mit den aktuellen Deklarationen ab.Grenze: Ein Eingang namens
keepStateim aufgerufenen Behavior kommt dem Schalter in die Quere (wie heute schonbehavior).Tests
./check.sh: 163 Dateien, 2388 Tests, grün (vorher 2377).tests/core/keep-state.test.ts, 1 neuer Fall im Node-Katalog.Doku: Wiki Behaviors (Keep state) und State machines.
Umgestellt in
454d202(Wikif436f6d): Keep sitzt jetzt an der Variable, nicht mehr amRun behavior-Node.Verhalten
Run behavior-Node und pro Objekt. Variablen ohne Keep starten bei jedem Aufruf mit ihrem Startwert.globalundscenesind unverändert.keepStateam Node ist entfernt. Steht er in einem gespeicherten Projekt noch drin, wird er ignoriert.Umsetzung
BehaviorAsset.keptVariablesinsrc/core/model/Asset.ts, geladen und gespeichert inserialize.ts. Beim Laden fallen nicht deklarierte Namen weg.SetVariableKeptCommandinvariableCommands.ts. Anlegen, Löschen und Umbenennen ziehen die Liste mit.GraphInterpreter.resumedVariables()behält nur die Variablen aus der Liste.Tests
./check.sh: 163 Dateien, 2392 Tests,CHECK EXIT 0tests/core/keep-state.test.tsneu geschrieben, 15 Tests