Ein paar Fragen zu behavior als node in einem graph:
wenn es keinen Start oder End node gibt, kann man trotztdem das behaviour in einem graph hinzufügen, aber wie läuft dann der flow? (vorallem wenn es keinen start node gibt)
ohne end node: woher weiß der parent graph (behavior) dass das child (sub behavior) "fertig" ist?
drag and drop vom asset inspector wäre auch gut als spwan im graph, ist das möglich?
doppelklick auf node (type behavior) um von dem asset behavior den graph zu öffnen wäre noch gut
Beantwortet und umgesetzt
Deine ersten zwei Punkte waren Fragen, die letzten zwei Wuensche. Die Antworten standen schon
im Code — der Mangel war, dass du sie nicht sehen konntest. Genau das ist jetzt behoben.
1. Ohne Start-Node: wie laeuft der Flow?
Gar nicht — der Aufruf wird uebersprungen, und der Fluss laeuft am exec-Ausgang weiter.
Ohne Start-Node gibt es keinen Eingang in den Sub-Graphen; der Interpreter bricht den Aufruf ab
(if (!start) return {}) und macht beim Aufrufer weiter. Dasselbe gilt, wenn gar kein Behavior
gewaehlt ist oder das gewaehlte geloescht wurde. Das ist Absicht: ein toter Verweis soll kein
Spiel abbrechen.
Das war aber still, und still ist hier falsch. Es ist derselbe Fehlgriff wie damals beim Run in editor-Schalter: der Node sah gesund aus und tat nichts. Ein Aufruf, der nichts tun kann, sagt es jetzt selbst — rote Zeile auf dem Node, roter Rand, dieselbe Zeile im Inspector:
Lage
was der Node sagt
kein Behavior gewaehlt
No behavior picked
Behavior geloescht
That behavior is gone
Behavior ohne Start-Node
No start node – does nothing
Behavior zeigt auf sich selbst
A behavior cannot run itself
Einfuegen kann man ein Behavior ohne Start-Node weiterhin — das ist der normale Weg beim Bauen
(erst den Aufruf setzen, dann den Sub-Graphen fuellen). Es sieht nur nicht mehr fertig aus.
2. Ohne End-Node: woher weiss der Parent, dass das Child fertig ist?
Die Frage stellt sich nicht: ein Aufruf ist immer synchron. Der aufrufende Node kehrt erst
zurueck, wenn der Fluss im Sub-Graphen ausgelaufen ist — "fertig" ist kein Signal, sondern das
Ende der Ausfuehrung. Der End-Node hat damit nichts zu tun; er entscheidet nur, welche Werte
zurueckkommen. Ohne ihn kommt schlicht nichts zurueck, alles andere ist unveraendert.
Deshalb wird ein fehlender End-Node auch nicht als Mangel angezeigt — das waere eine
Warnung vor etwas Erlaubtem. Ein eigener Test haelt das fest: der Sub-Graph loggt sub, der
Aufrufer danach after, und das Ergebnis ist ['sub', 'after'] — nicht umgekehrt und nicht
verschraenkt.
3. Drag & Drop aus dem Asset-Panel in den Graphen
Gebaut. Ein Behavior aus der Asset-Liste in den Graphen gezogen wird zu einem Aufruf-Node,
und zwar dort, wo du losgelassen hast (unter dem Zeiger zentriert, nicht rechts-unter ihm).
Waehrend des Ziehens zeigt ein Umriss die Landestelle. Ins eigene Behavior gezogen wird
abgelehnt — mit Meldung, statt einen Node zu erzeugen, der beim Laufen einen Fehler wirft.
Das war billig, weil der Mechanismus schon existierte: startDrag feuert im Asset-Panel
laengst fuer jedes platzierbare Asset, und die Szenen-Ansicht ist bereits ein Drop-Ziel. Neu
ist nur, dass der Graph-Canvas jetzt auch eines ist.
4. Doppelklick auf einen Behavior-Node oeffnet dessen Graph
Gebaut. Doppelklick auf einen Aufruf-Node zeigt den Graphen des Behaviors, das er ausfuehrt.
Auch das nutzt vorhandene Mechanik (pressCount, dieselbe Erkennung wie in den Listen); der
Node waehlt einfach das Asset aus, und der Graph-Tab folgt der Selektion.
Zusammen mit Punkt 1 schliesst sich damit ein Kreis: der Node sagt "No start node", ein
Doppelklick bringt dich in den Graphen, und dort legst du den Start-Node an.
Belegt
PASS a behavior dragged from the asset panel becomes a call node
PASS and it lands under the pointer, not at some default spot
PASS a behavior without a start node can be added just the same
PASS and the node says why it does nothing, instead of failing silently – "No start node – does nothing"
PASS a healthy call carries no such warning
PASS dropping a behavior into its own graph is refused, out loud
PASS double-clicking a call node opens the behavior it runs
Gegenprobe gefahren: ohne die Diagnose fallen beide neuen Unit-Tests. Der zweite war beim
ersten Versuch wertlos — er wollte zeigen, dass der Node neu gezeichnet wird, wenn der
Mangel entsteht, prueft das aber an einem Behavior mit Ports, wo sich die Signatur ohnehin
aendert. Jetzt haengt er an einem Behavior ganz ohne Ports, wo sich wirklich nur der Mangel
aendert.
volle Suite, remote
ALL PASSED – 387 Checks (379 + 8 neue), 0 FAIL
npm run check lokal
gruen, 527 Tests (+3)
Ein Fehlschlag, der zweimal dasselbe war
Der erste Drag klappte, die beiden folgenden nicht — und zwar nur im vollen Lauf, allein
war das Modul gruen. Ich habe zuerst die Drop-Punkte verdaechtigt (falsch: sie lagen in der
Flaeche) und dann die Reihenfolge der Module (falsch: die letzten drei reichten nicht zum
Reproduzieren). Erst eine Messung in der Check-Nachricht hat es gezeigt: die Asset-Zeile lag
bei y = 449 statt 293 — nach 18 Modulen ist die Liste so lang, dass die zuletzt
angehaengten Behaviors aus dem sichtbaren Bereich gescrollt waren. Der Druck landete auf
dem Panel dahinter, es startete gar kein Drag, und das sah exakt aus wie eine Ablehnung.
Die Testdaten liegen jetzt am Anfang der Liste. __gm.dragPayload() als neuer Hook
unterscheidet die beiden Faelle kuenftig direkt: abgelehnt hat einen Drag, nie angekommen
keinen.
Ein Reparaturversuch am Test-Hook selbst (rowGlobal sollte null liefern, wenn der
Scroll-Container die Zeile abschneidet) habe ich wieder zurueckgenommen — meine Pruefung
ueber die Masken-Bounds lieferte null auch fuer klar sichtbare Zeilen und hat den Lauf
sofort im ersten Modul zerlegt. Lieber ein Hook, der schweigt, als einer, der falsch redet.
Übernommen aus todo-notes/done/nexted-behavior-ergaenzung.md beim Umzug auf das Issue-System (2026-09-12).
Angelegt: 2026-09-09 · 1d8e6eb — Note down two follow-up wishes
Abgeschlossen: 2026-09-09 · c6f907b — Make a call node say why it does nothing, and easier to place
Gemeldet von: admin
Ein paar Fragen zu behavior als node in einem graph:
- wenn es keinen Start oder End node gibt, kann man trotztdem das behaviour in einem graph hinzufügen, aber wie läuft dann der flow? (vorallem wenn es keinen start node gibt)
- ohne end node: woher weiß der parent graph (behavior) dass das child (sub behavior) "fertig" ist?
- drag and drop vom asset inspector wäre auch gut als spwan im graph, ist das möglich?
- doppelklick auf node (type behavior) um von dem asset behavior den graph zu öffnen wäre noch gut
---
## Beantwortet und umgesetzt
Deine ersten zwei Punkte waren Fragen, die letzten zwei Wuensche. Die Antworten standen schon
im Code — der Mangel war, dass **du sie nicht sehen konntest**. Genau das ist jetzt behoben.
### 1. Ohne Start-Node: wie laeuft der Flow?
**Gar nicht — der Aufruf wird uebersprungen, und der Fluss laeuft am `exec`-Ausgang weiter.**
Ohne Start-Node gibt es keinen Eingang in den Sub-Graphen; der Interpreter bricht den Aufruf ab
(`if (!start) return {}`) und macht beim Aufrufer weiter. Dasselbe gilt, wenn gar kein Behavior
gewaehlt ist oder das gewaehlte geloescht wurde. Das ist Absicht: ein toter Verweis soll kein
Spiel abbrechen.
**Das war aber still, und still ist hier falsch.** Es ist derselbe Fehlgriff wie damals beim
`Run in editor`-Schalter: der Node sah gesund aus und tat nichts. Ein Aufruf, der nichts tun
*kann*, sagt es jetzt selbst — rote Zeile auf dem Node, roter Rand, dieselbe Zeile im Inspector:
| Lage | was der Node sagt |
|---|---|
| kein Behavior gewaehlt | `No behavior picked` |
| Behavior geloescht | `That behavior is gone` |
| Behavior ohne Start-Node | `No start node – does nothing` |
| Behavior zeigt auf sich selbst | `A behavior cannot run itself` |
Einfuegen kann man ein Behavior ohne Start-Node weiterhin — das ist der normale Weg beim Bauen
(erst den Aufruf setzen, dann den Sub-Graphen fuellen). Es sieht nur nicht mehr fertig aus.
### 2. Ohne End-Node: woher weiss der Parent, dass das Child fertig ist?
**Die Frage stellt sich nicht: ein Aufruf ist immer synchron.** Der aufrufende Node kehrt erst
zurueck, wenn der Fluss im Sub-Graphen ausgelaufen ist — "fertig" ist kein Signal, sondern das
Ende der Ausfuehrung. Der End-Node hat damit nichts zu tun; er entscheidet nur, **welche Werte**
zurueckkommen. Ohne ihn kommt schlicht nichts zurueck, alles andere ist unveraendert.
Deshalb wird ein fehlender End-Node auch **nicht** als Mangel angezeigt — das waere eine
Warnung vor etwas Erlaubtem. Ein eigener Test haelt das fest: der Sub-Graph loggt `sub`, der
Aufrufer danach `after`, und das Ergebnis ist `['sub', 'after']` — nicht umgekehrt und nicht
verschraenkt.
### 3. Drag & Drop aus dem Asset-Panel in den Graphen
**Gebaut.** Ein Behavior aus der Asset-Liste in den Graphen gezogen wird zu einem Aufruf-Node,
und zwar **dort, wo du losgelassen hast** (unter dem Zeiger zentriert, nicht rechts-unter ihm).
Waehrend des Ziehens zeigt ein Umriss die Landestelle. Ins **eigene** Behavior gezogen wird
abgelehnt — mit Meldung, statt einen Node zu erzeugen, der beim Laufen einen Fehler wirft.
Das war billig, weil der Mechanismus schon existierte: `startDrag` feuert im Asset-Panel
laengst fuer jedes platzierbare Asset, und die Szenen-Ansicht ist bereits ein Drop-Ziel. Neu
ist nur, dass der Graph-Canvas jetzt auch eines ist.
### 4. Doppelklick auf einen Behavior-Node oeffnet dessen Graph
**Gebaut.** Doppelklick auf einen Aufruf-Node zeigt den Graphen des Behaviors, das er ausfuehrt.
Auch das nutzt vorhandene Mechanik (`pressCount`, dieselbe Erkennung wie in den Listen); der
Node waehlt einfach das Asset aus, und der Graph-Tab folgt der Selektion.
Zusammen mit Punkt 1 schliesst sich damit ein Kreis: der Node sagt *"No start node"*, ein
Doppelklick bringt dich in den Graphen, und dort legst du den Start-Node an.
## Belegt
```
PASS a behavior dragged from the asset panel becomes a call node
PASS and it lands under the pointer, not at some default spot
PASS a behavior without a start node can be added just the same
PASS and the node says why it does nothing, instead of failing silently – "No start node – does nothing"
PASS a healthy call carries no such warning
PASS dropping a behavior into its own graph is refused, out loud
PASS double-clicking a call node opens the behavior it runs
```
Gegenprobe gefahren: ohne die Diagnose fallen beide neuen Unit-Tests. Der zweite war beim
ersten Versuch wertlos — er wollte zeigen, dass der Node **neu gezeichnet** wird, wenn der
Mangel entsteht, prueft das aber an einem Behavior mit Ports, wo sich die Signatur ohnehin
aendert. Jetzt haengt er an einem Behavior ganz ohne Ports, wo sich wirklich nur der Mangel
aendert.
| | |
|---|---|
| volle Suite, remote | **ALL PASSED – 387 Checks** (379 + 8 neue), 0 FAIL |
| `npm run check` lokal | gruen, **527 Tests** (+3) |
## Ein Fehlschlag, der zweimal dasselbe war
Der erste Drag klappte, die beiden folgenden nicht — und zwar **nur im vollen Lauf**, allein
war das Modul gruen. Ich habe zuerst die Drop-Punkte verdaechtigt (falsch: sie lagen in der
Flaeche) und dann die Reihenfolge der Module (falsch: die letzten drei reichten nicht zum
Reproduzieren). Erst eine Messung in der Check-Nachricht hat es gezeigt: die Asset-Zeile lag
bei **y = 449** statt 293 — nach 18 Modulen ist die Liste so lang, dass die zuletzt
angehaengten Behaviors **aus dem sichtbaren Bereich gescrollt** waren. Der Druck landete auf
dem Panel dahinter, es startete gar kein Drag, und das sah exakt aus wie eine Ablehnung.
Die Testdaten liegen jetzt am **Anfang** der Liste. `__gm.dragPayload()` als neuer Hook
unterscheidet die beiden Faelle kuenftig direkt: *abgelehnt* hat einen Drag, *nie angekommen*
keinen.
Ein Reparaturversuch am Test-Hook selbst (`rowGlobal` sollte `null` liefern, wenn der
Scroll-Container die Zeile abschneidet) habe ich **wieder zurueckgenommen** — meine Pruefung
ueber die Masken-Bounds lieferte `null` auch fuer klar sichtbare Zeilen und hat den Lauf
sofort im ersten Modul zerlegt. Lieber ein Hook, der schweigt, als einer, der falsch redet.
---
*Übernommen aus `todo-notes/done/nexted-behavior-ergaenzung.md` beim Umzug auf das Issue-System (2026-09-12).*
- **Angelegt:** 2026-09-09 · `1d8e6eb` — Note down two follow-up wishes
- **Abgeschlossen:** 2026-09-09 · `c6f907b` — Make a call node say why it does nothing, and easier to place
- **Gemeldet von:** admin
admin
added the todo-note label 2026-09-12 15:03:53 +02:00
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 paar Fragen zu behavior als node in einem graph:
Beantwortet und umgesetzt
Deine ersten zwei Punkte waren Fragen, die letzten zwei Wuensche. Die Antworten standen schon
im Code — der Mangel war, dass du sie nicht sehen konntest. Genau das ist jetzt behoben.
1. Ohne Start-Node: wie laeuft der Flow?
Gar nicht — der Aufruf wird uebersprungen, und der Fluss laeuft am
exec-Ausgang weiter.Ohne Start-Node gibt es keinen Eingang in den Sub-Graphen; der Interpreter bricht den Aufruf ab
(
if (!start) return {}) und macht beim Aufrufer weiter. Dasselbe gilt, wenn gar kein Behaviorgewaehlt ist oder das gewaehlte geloescht wurde. Das ist Absicht: ein toter Verweis soll kein
Spiel abbrechen.
Das war aber still, und still ist hier falsch. Es ist derselbe Fehlgriff wie damals beim
Run in editor-Schalter: der Node sah gesund aus und tat nichts. Ein Aufruf, der nichts tunkann, sagt es jetzt selbst — rote Zeile auf dem Node, roter Rand, dieselbe Zeile im Inspector:
No behavior pickedThat behavior is goneNo start node – does nothingA behavior cannot run itselfEinfuegen kann man ein Behavior ohne Start-Node weiterhin — das ist der normale Weg beim Bauen
(erst den Aufruf setzen, dann den Sub-Graphen fuellen). Es sieht nur nicht mehr fertig aus.
2. Ohne End-Node: woher weiss der Parent, dass das Child fertig ist?
Die Frage stellt sich nicht: ein Aufruf ist immer synchron. Der aufrufende Node kehrt erst
zurueck, wenn der Fluss im Sub-Graphen ausgelaufen ist — "fertig" ist kein Signal, sondern das
Ende der Ausfuehrung. Der End-Node hat damit nichts zu tun; er entscheidet nur, welche Werte
zurueckkommen. Ohne ihn kommt schlicht nichts zurueck, alles andere ist unveraendert.
Deshalb wird ein fehlender End-Node auch nicht als Mangel angezeigt — das waere eine
Warnung vor etwas Erlaubtem. Ein eigener Test haelt das fest: der Sub-Graph loggt
sub, derAufrufer danach
after, und das Ergebnis ist['sub', 'after']— nicht umgekehrt und nichtverschraenkt.
3. Drag & Drop aus dem Asset-Panel in den Graphen
Gebaut. Ein Behavior aus der Asset-Liste in den Graphen gezogen wird zu einem Aufruf-Node,
und zwar dort, wo du losgelassen hast (unter dem Zeiger zentriert, nicht rechts-unter ihm).
Waehrend des Ziehens zeigt ein Umriss die Landestelle. Ins eigene Behavior gezogen wird
abgelehnt — mit Meldung, statt einen Node zu erzeugen, der beim Laufen einen Fehler wirft.
Das war billig, weil der Mechanismus schon existierte:
startDragfeuert im Asset-Panellaengst fuer jedes platzierbare Asset, und die Szenen-Ansicht ist bereits ein Drop-Ziel. Neu
ist nur, dass der Graph-Canvas jetzt auch eines ist.
4. Doppelklick auf einen Behavior-Node oeffnet dessen Graph
Gebaut. Doppelklick auf einen Aufruf-Node zeigt den Graphen des Behaviors, das er ausfuehrt.
Auch das nutzt vorhandene Mechanik (
pressCount, dieselbe Erkennung wie in den Listen); derNode waehlt einfach das Asset aus, und der Graph-Tab folgt der Selektion.
Zusammen mit Punkt 1 schliesst sich damit ein Kreis: der Node sagt "No start node", ein
Doppelklick bringt dich in den Graphen, und dort legst du den Start-Node an.
Belegt
Gegenprobe gefahren: ohne die Diagnose fallen beide neuen Unit-Tests. Der zweite war beim
ersten Versuch wertlos — er wollte zeigen, dass der Node neu gezeichnet wird, wenn der
Mangel entsteht, prueft das aber an einem Behavior mit Ports, wo sich die Signatur ohnehin
aendert. Jetzt haengt er an einem Behavior ganz ohne Ports, wo sich wirklich nur der Mangel
aendert.
npm run checklokalEin Fehlschlag, der zweimal dasselbe war
Der erste Drag klappte, die beiden folgenden nicht — und zwar nur im vollen Lauf, allein
war das Modul gruen. Ich habe zuerst die Drop-Punkte verdaechtigt (falsch: sie lagen in der
Flaeche) und dann die Reihenfolge der Module (falsch: die letzten drei reichten nicht zum
Reproduzieren). Erst eine Messung in der Check-Nachricht hat es gezeigt: die Asset-Zeile lag
bei y = 449 statt 293 — nach 18 Modulen ist die Liste so lang, dass die zuletzt
angehaengten Behaviors aus dem sichtbaren Bereich gescrollt waren. Der Druck landete auf
dem Panel dahinter, es startete gar kein Drag, und das sah exakt aus wie eine Ablehnung.
Die Testdaten liegen jetzt am Anfang der Liste.
__gm.dragPayload()als neuer Hookunterscheidet die beiden Faelle kuenftig direkt: abgelehnt hat einen Drag, nie angekommen
keinen.
Ein Reparaturversuch am Test-Hook selbst (
rowGlobalsolltenullliefern, wenn derScroll-Container die Zeile abschneidet) habe ich wieder zurueckgenommen — meine Pruefung
ueber die Masken-Bounds lieferte
nullauch fuer klar sichtbare Zeilen und hat den Laufsofort im ersten Modul zerlegt. Lieber ein Hook, der schweigt, als einer, der falsch redet.
Übernommen aus
todo-notes/done/nexted-behavior-ergaenzung.mdbeim Umzug auf das Issue-System (2026-09-12).1d8e6eb— Note down two follow-up wishesc6f907b— Make a call node say why it does nothing, and easier to place