feuerwerk/todo-notes/done/nodes-mit-dynamischer-port-zahl.md

Dynamische Portzahl bei Nodes ermöglichen

Wenn das möglich ist, umsetzen. Folgende Dinge wären dafür praktisch:

1. sequence node

diese hat momentan fixe 3 outputs, diese könnten somit ebenfalls dynamisch sein

2. eine variable vom typ struct

sprich eine variable die mehreren properties (key mit allen bisher möglichen variablen typen + value). dazu passende nodes um von einer variable alle properties zu expanden und umgekehrt (alle werte eines structs setzen)

variablen vom typ struct und list im inspector

bei typ list: momentan steht es einfach nur als string geparsed in einem textfeld. für die liste bräuchten wir eine view, sprich liste mit variablen.

für typ struct: hier wäre natürlich auch eine passende view gut, wo man bei der variable type + key + default value angeben kann.

---

lass uns das mal ausarbeiten. wie weit das sinnvoll bzw. möglich ist.

---

Umgesetzt (2026-09-10), Teil 1 und der Werttyp. Was offen bleibt, steht unten.

Dynamische Ports gab es schon — nur nicht aus Node-Einstellungen. Verschachtelte Behaviors leben seit jeher davon: GraphNode.ports speichert eine Deklaration pro Node, resolveDef loest den Def pro Node auf, portSignature ist der Ausloeser, an dem View und Inspector merken, dass sich eine abgeleitete Portliste geaendert hat. Die Regel dafuer stand als Dreier-Switch auf Node-Typen in nested.ts — die einzige Stelle im Projekt, die Node-Typen namentlich kannte.

Der Switch ist jetzt aufgeloest in zwei Vertraege am NodeDef:

• declaresPorts: 'inputs' | 'outputs' — der Node traegt seine eigene Portliste, editierbar im Inspector. Das haben Start, End und neu Pack/Expand.
• derivePorts(source) — der Node rechnet seine Ports aus sich und dem Graphen aus, in dem er sitzt. Das haben Sequence (aus den eigenen Kanten) und Run behavior (Ports des benannten Behaviors).

Sequence hatte zuerst eine Einstellung Outputs (2…26). Die ist wieder weg — siehe den Nachtrag unten: die Ports wachsen jetzt mit den Kanten. Die Keys bleiben a, b, c, … statt out1..N, weil im Jump-and-Run zwei Nodes an einer Sequence haengen und deren Kanten heil bleiben sollen.

Die einzige echte Falle war das Schrumpfen. SetNodeParamCommand war ein reiner Bag-Schreiber: verschwand ein Port, blieb seine Kante liegen — unsichtbar (drawEdge steigt bei unbekanntem Port still aus), aber sie ueberlebte jedes Speichern und waere beim Hochzaehlen wieder angesprungen. Der Befehl ist jetzt port-bewusst und nimmt solche Kanten mit, Undo gibt sie zurueck. Das schliesst einen bestehenden Fehler mit: derselbe Verwaisungs-Effekt trat schon immer auf, wenn man an einem Run behavior-Node das Behavior wechselte.

Struct als echter Werttyp (Weg C). PropertyValue ist jetzt number | string | boolean | ListValue | StructValue. Felder sind Primitive oder Listen, nie wieder ein Struct — aus demselben Grund, aus dem eine Liste flach ist.

Zwei Dinge waren dafuer noetig, und beide sind der eigentliche Preis von C:

1. Ein Objekt auf einer Datenkante hiess bisher zwangslaeufig Entity. An drei Stellen in values.ts bedeutete „Objekt, kein Array" ein Entity-Handle. EntityHandle traegt jetzt eine Symbol-Marke (ENTITY_HANDLE) — ein Symbol, damit kein Struct-Feldname sie imitieren kann, und es serialisiert nie, was fuer etwas richtig ist, das nur waehrend des Spiels existiert. Der Typechecker hat jede betroffene Stelle selbst benannt.
2. String(value) haette einen Struct als [object Object] geschrieben — an 39 Stellen. Die gehen jetzt alle ueber textOf(). Das war kein Stilfehler, sondern eine echte Luecke, die erst der neue Typ sichtbar gemacht hat.

Dazu ein gemessener, lebender Fehler, der dabei aufflog und mitrepariert ist: der List-Node verlor seinen Wert beim Speichern. normalizeGraph liess bei Node-Params nur Primitive durch, Arrays fielen weg ([3,1,4] → undefined nach Round-Trip). Listen-Variablen waren nicht betroffen — die haben ein Schema. Params haben keins, weil sie Einstellungen und Inline-Werte mischen.

Belegt (tests/core/dynamic-ports.test.ts): ein Bündel faehrt ueber eine Kante durch ein verschachteltes Behavior — Pack{x:30,y:12} → Run behavior-Port vom Typ struct → Expand → Add → 42. Genau die Form, die Tetris heute von Hand parallel fuehrt (Next move: 8 rein, 7 raus; 49 deklarierte Ports ueber 9 Behaviors).

Offen, bewusst nicht gebaut:

• Variablen vom Typ struct (Teil 2 der Notiz). Dafuer braucht eine Variable eine editierbare Feldliste im Inspector — die Deklaration liegt bisher nur am Node (Pack/Expand) und am Behavior-Port. writeTyped/mergeStruct sind schon darauf vorbereitet: ein Struct-Slot behaelt seine Felder, was ankommt fuellt die benannten, der Rest bleibt stehen.
• Die Views im Inspector (Teil 3). [Die Listen-Haelfte ist inzwischen gebaut — siehe den Nachtrag „der List-Tab steht". Der Struct-Teil ist weiter offen.] Das Textfeld war nicht nur Kosmetik: ['red, green', 'blue'] wurde als "red, green, blue" geschrieben und las sich als drei Items zurueck — ein Komma in einem Text-Item war nicht darstellbar. Fuer den Struct ist Zeile-pro-Feld richtig, das sind wenige.
• Ein unverbundener list-Eingang zeigt weiterhin ein Zahlenfeld (inlineInputDef hat keinen list-Zweig), und eine Listen-Variable kann nur Zahlen-Items: AddVariableCommand nimmt items gar nicht entgegen.

---

EDIT:

Eine Liste braucht eher einen eigenen Editor als Overlay

ok, eigener tab "List"

dann machen wir es so: es gibt dann einfach statt dem textfeld ein button wo drinnen steht "42 items". klickt man darauf switch zu Tab "List" und dort wird die liste aller items dargestellt die man bearbeiten kann.

dort soll auch der selbe "renderer" verwendet werden wie beim inspector.

wenn wir dann struct (teil 3) umsetzen, kann es auch eine liste aus struct variablen geben (bitte das bedenken) und im tab "List" sollen variablen (egal welcher type) im prinzip genauso dargestellt werden wie im inspector

---

Antwort auf den Edit (2026-09-10): geht, mit drei Auflagen

Der Tab ist hier besser als das Overlay, aus einem Grund, der erst beim Nachsehen auffiel: der Inspector haengt nicht im Tab-Bereich, sondern als eigene Spalte daneben (Editor.ts:156). Er bleibt in jedem Tab sichtbar, der Sprung verliert also keinen Kontext.

„Derselbe Renderer" ist fast geschenkt. createField (fieldFactory.ts:171) braucht als Kontext nur { project(): Project } — keine Inspector-Instanz, keinen Command-Stack. Die Zeile baut selbst kein Kommando, sie ruft onInput/onChange. previewingHandlers benutzt vom InspectorHost ausschliesslich host.state; den Parametertyp zu verengen macht auch die Undo-Mechanik wiederverwendbar. Ein Struct kommt spaeter an einer Stelle dazu: dem switch (def.kind) in fieldFactory.ts:177.

Der Weg in den Tab muss ueber den Zustand laufen, nicht ueber showTab. Kein Tab kennt den Editor; Tab-Wechsel von innen gibt es nur selektionsgetrieben, gebuendelt in Editor.ts:169-179.

Woran der Tab haengt

Die anderen Tabs haengen an einer Asset-Id. Eine Liste ist kein Asset, sondern ein Slot: Asset-Property (assetId+key), Objekt-Override (holderId+objectId+key) oder Node-Param (assetId+nodeId+key). Also eine explizite Adresse mit Pfad, die der Tab behaelt wie die anderen ihre Asset-Id und die auf „nichts" zurueckfaellt, wenn das Ziel verschwindet (AssetTabEditor.refresh() macht genau das). Der Drill-down spaeter ist derselbe Mechanismus eine Ebene tiefer.

Zeile-pro-Item traegt — gemessen

Zeilen echt ueber createFieldRow gebaut, mit GPU im Browser, dabei jeden Frame gescrollt:

Zeilen	Aufbau	Display-Objekte	fps
0 (Grundlinie)	–	11	58
200	15 ms	2 011	51
300	17 ms	3 011	46
3 000	122 ms	30 011	18

Dagegen die laengsten Listen im echten Bestand: tetris 224 (shapes), 224 (eine Variablen-Vorgabe), 200 (grid); jumpRun und fixture haben keine. Der reale Hoechstfall liegt also bei 224 — kein Windowing noetig. Bei 3 000 Eintraegen faellt es auseinander, aber nichts kommt dem nahe.

Der eigentliche Fund steckt in der Aufbau-Spalte: 15 ms pro Rebuild bei 200 Zeilen. Deshalb kam der Fokus-Schutz zuerst (siehe Nachtrag oben) — ein Rebuild pro Tastendruck waere dort die Regel.

Was „Liste aus Structs" kostet

Gibt es heute nicht: ListValue = readonly (number | string | boolean)[] (Properties.ts:5), FieldValue schliesst Struct aus (:8), sameValue verlaesst sich auf „recurses exactly one level deep" (:50), LIST_ITEM_KINDS kennt kein struct, coerceListItem gibt ein Primitiv zurueck. Das macht ListValue und StructValue gegenseitig rekursiv (beliebige Tiefe, echter Deep-Compare) und die Items brauchen eine deklarierte Feldform — wieder „eine geteilte Struct-Form hat keine Heimat" (~29 Dateien fuer einen neuen Asset-Typ). Deshalb: Tab jetzt fuer flache Listen, aber um einen Pfad herum; die Typerweiterung kommt mit den Struct-Variablen.

Beibehalten: eine Liste ist homogen (ein ListItemKind), der Struct ist das heterogene Ding. Das Textfeld sollte als Massenbearbeitung im Tab bleiben, sonst geht das Einfuegen einer Komma-Liste verloren. Der unverbundene list-Eingang (heute faelschlich ein Zahlenfeld) loest sich mit dem Knopf mit.

---

Nachtrag (2026-09-10): Sequence waechst mit den Kanten, statt gezaehlt zu werden

Das Zahlenfeld Outputs war unbedienbar: tippen ging nicht, Pfeil rauf/runter ging nicht, nur das Ziehen mit der Maus. Die Ursache ist allgemein und nicht NumberField zuzuschreiben:

onInput (jeder Tastendruck, auch jede Pfeiltaste) → previewingHandlers schreibt in node.params → state.preview() → Event project → Inspector.refreshValues() → die nodeSignature enthaelt die Portliste, hat sich also geaendert → rebuild() wirft die Zeile weg, in der gerade getippt wird. Ziehen ueberlebt das, weil ein laufender Drag seine globalpointermove-Events weiter am alten (zerstoerten) Widget bekommt; Tippen braucht den Fokus, und den gibt es nach dem Rebuild nicht mehr.

Diese Falle ist inzwischen zu (siehe „List-Tab" unten): refreshValues() verschiebt einen faelligen Rebuild, solange der Fokus im Inspector sitzt, und holt ihn nach, sobald das Feld verlassen wird (FocusManager.changeHandlers + isWithin). Werte sind waehrenddessen ohnehin sicher — TextField.setValue ignoriert eine laufende Eingabe (TextField.ts:92). Damit war der Fehler auch nie NumberField zuzuschreiben.

Statt das Feld zu reparieren, ist es nach Wunsch des Users ersetzt: die Sequence haelt immer einen freien Ausgang unter dem letzten verbundenen. Nichts verbunden = 1 Ausgang; den Ersatz-Ausgang verbinden = ein neuer erscheint; die unterste Kante loesen = schrumpft wieder. Gezaehlt wird der letzte verbundene Port, nicht die Anzahl der Kanten — so kann keine Kante verschwinden, wenn in der Mitte eine geloest wird (dann bleibt eine Luecke stehen).

Preis dafuer: derivePorts bekommt jetzt den Graphen statt nur der Params (resolveDef(node, graph, lookup), ~15 Aufrufstellen, alle hatten den Graphen schon zur Hand), und run bekommt als viertes Argument den aufgeloesten Def — anders kann ein Node mit abgeleiteten Ports nicht wissen, wie viele er hat. SetNodeParamCommand bleibt port-bewusst, das braucht Run behavior weiterhin.

Nebeneffekt: die Sequence braucht keinen Param mehr, also auch kein Aufraeumen von Kanten beim Verkleinern — eine Kante zu loesen ist das Verkleinern.

---

Nachtrag (2026-09-10): der List-Tab steht

Gebaut wie im Edit gewuenscht: eine Listen-Property ist im Inspector ein Knopf N items; er schaltet auf den neuen sechsten Tab List, wo jedes Item eine Zeile mit demselben Widget bekommt, das der Inspector fuer diese Item-Art baut (createField — Zahl, Text, Ja/Nein oder Farbe). Der Inspector bleibt daneben stehen, der Kontext geht also nicht verloren.

Der Weg dorthin laeuft ueber den Zustand, nicht ueber showTab: EditorState.listSlot + openList(slot) + Event list; der Editor hoert darauf und schaltet um. Ein Slot ist eine Asset-Property, ein Objekt-Override oder eine Node-Einstellung — ListSlot steht in state.ts neben Selection, weil state.ts sonst in einen UI-Ordner importieren muesste. resolveList(state, slot) in src/editor/list/slot.ts liefert Wert, Item-Art, Titel und die zwei Schreibwege; die drei Faelle benutzen exakt die Spec der passenden Inspector-Sektion, also dasselbe Kommando, dieselbe Beschichtung, denselben Undo-Schritt.

Abweichung vom eigenen Vorschlag: kein path in der Adresse. Ein immer leeres Feld, das niemand liest, ist Spekulation; die Naht, an der ein Pfad spaeter ansetzt, ist die eine Funktion resolveList — das ist dann eine Signaturaenderung, kein Umbau. Ehrlicher so.

Zwei Dinge, die erst die Gegenprobe gezeigt hat:

• Die Zeilen-Handler duerfen nicht auf einer Momentaufnahme der Liste sitzen. Sie ueberleben einen Commit (der Tab baut nur bei geaenderter Laenge neu), also wuerde die zweite bearbeitete Zeile die erste zuruecksetzen. Gemessen: mit Momentaufnahme faellt genau dieser Test.
• Die Beschichtung in replace war redundant — alle drei Kommandos laufen selbst durch coerceValue. Raus. In toModel ist sie noetig: dort entsteht der Wert, der als Vorschau am Kommando vorbei direkt ins Modell geschrieben wird. Auch das ist jetzt bewacht.

Nebenbei mitgenommen: showTab schaltete fuenf visible-Zeilen von Hand — nicht typgeschuetzt, ein sechster Tab waere dort still vergessen worden. Jetzt ein Record<CentreTab, Widget>, das jede Auslassung zum Typfehler macht.

Der unverbundene list-Eingang zeigt weiterhin ein Zahlenfeld: inlineInputDef hat keinen list-Zweig, und der Inline-Pfad kann gar keine Liste erzeugen. Der Knopf loest das nicht mit.

Zahlen stehen mit drei Nachkommastellen (30.000). Das ist Hausentscheidung, kein Versehen: formatNumber zeigt immer alle Stellen, „so a value can never look whole when it is not".

Weiterhin offen: Variablen vom Typ struct, die Struct-View im Inspector, und „Liste aus Structs" (macht ListValue/StructValue gegenseitig rekursiv — siehe oben).

---

Nachtrag (2026-09-10): drei Korrekturen am List-Tab

Kurze Liste baute sich nicht auf (User: „muss die Fenstergroesse kurz aendern"). Die Ursache lag nicht im Tab, sondern im ScrollContainer — und traf jeden seiner Benutzer, auch Menu:

rebuild() uebergibt die Zeilen-VStack an setContent(), solange sie noch leer ist. Der leere Inhalt wird ueber Math.max(size.h, this.h) auf die Viewporthoehe gesetzt. Danach kommen die Zeilen hinein, und relayoutContent() rechnet fuer eine kurze Liste wieder dieselbe Hoehe aus — Widget.resize() sieht keine Aenderung und ueberspringt layout() (Widget.ts:41). Alle Zeilen bleiben auf dem Ursprung gestapelt. Eine lange Liste aendert die Hoehe und faellt deshalb nie auf; die erste Oeffnung ueberhaupt auch nicht, weil der Tab dann noch w=h=0 hat.

Gemessen an Tetris, bevor etwas geaendert wurde: colors (7) nach shapes (224) → alle vier Zeilen auf {245,116}; grid (200) → sauber gestapelt; test (16) → wieder kaputt.

Fix in ScrollContainer.relayoutContent(): wenn die Groesse gleich bleibt, layout() selbst rufen. Die Methode wird genau dann gerufen, wenn der Inhalt sich geaendert hat — sich auf die Aenderungserkennung von resize zu verlassen ist dort grundsaetzlich falsch.

Die Kommazeile im Fuss ist raus (User-Wunsch). Damit ist auch der Komma-Fallback in fieldFactory unerreichbar geworden — jede Sektion, die eine Liste tragen kann, liefert openList (assetSection:135, nodeSection:134, objectSection:325). Fallback, listToText und listFromText sind geloescht; der Test dafuer ist auf coerceValue umgeschrieben statt gestrichen, sonst haette coerceListItem seine Abdeckung verloren (Boolean-Schreibweise, Farbe).

JSON-Speicherung war bereits da. Gemessen an der Projektdatei: props.shapes ist ein JSON-Array mit 224 Zahlen, kein Komma-String; die PHP-API ist reines JSON. Das Komma war nur die Anzeige im geloeschten Textfeld. Es bleibt genau eine Stelle, an der ein Komma-Format wirklich persistiert wird: eine Liste, die in ein Text-Property rutscht, wird ueber textOf() zu "1, 2, 3" (Properties.ts:33, via coerceValue kind text) — betrifft auch die Ausgabe des Log-Nodes. Der User hat entschieden, das so zu lassen; falls eine Liste je verlustfrei durch ein Text-Feld muss, ist das die Stelle.

---

Nachtrag (2026-09-10): Variablen vom Typ struct — Teil 2 und 3 sind zu

Der Werttyp war fertig, die Deklaration fehlte. StructValue, textOf, sameValue, writeTyped/mergeStruct und der Port-Typ struct gab es seit dem ersten Teil; Get/Set variable haben any-Ports, ein Bündel fliesst also ohne Änderung durch den Graphen. Neu ist allein, dass eine Variable eine Feldliste deklarieren kann: PropertyDef bekommt kind: 'struct' mit fields: StructFieldDef[], VARIABLE_KINDS das fünfte Kind, variableDef einen fünften Parameter.

Ein deklariertes Feld ist ein Primitiv (ListItemKind — Zahl, Text, Ja/Nein, Farbe), obwohl FieldValue auch eine Liste zulässt. Grund: ein Listen-Feld bräuchte einen verschachtelten Editor und damit den Pfad in der Slot-Adresse — genau der Schritt, auf den auch „Liste aus Structs" wartet. Der Werttyp bleibt unverändert, die Erweiterung ist additiv.

coerceValue gibt jetzt PropertyValue statt FieldValue zurück — der erste Werttyp, der kein Feld ist. Gemessen: das bricht keine der fünf Aufrufstellen.

Die UI: Block statt Zeile — und nicht der Tab

Der List-Tab entstand, weil hunderte Zeilen in keine Inspector-Zeile passen. Ein Struct ist der Gegenfall: wenige Felder, die untereinander passen. Also kein siebter Tab, keine zweite Navigation. Eine Struct-Variable ist ein Block:

⊞ [piece   ]        [+ Field ▾] [×]
    # [x    ] [ 30.000 ] [×]
   Aa [tag  ] [ tee    ] [×]

Das ist der Port-Editor, den Pack schon hat (portSection.ts), eine Ebene tiefer und mit Wertspalte: Typ, Key und Default-Wert an einer Stelle — genau der Wortlaut aus Teil 3 der Notiz. Ein platziertes Objekt sieht dieselben Felder als reine Wertzeilen (createField liefert für struct einen Stapel beschrifteter Zeilen): überschreiben ja, deklarieren nein.

Drei Dinge, die den Ausschlag gaben

Eine Feldänderung muss jeden Wert erreichen. AddStructFieldCommand &co. fassen die Deklaration, den Default, den Wert des Behaviors und jeden Instanz-Override in einem Kommando an (structSites); sonst behält ein gespeicherter Wert eine Form, die seine Deklaration nicht mehr verspricht. Gegenprobe: ohne die Override-Sites fallen 3 Unit-Tests.

Kein Retype-Knopf — der Port-Editor hat auch keinen. Feld löschen und neu anlegen.

Die Handler dürfen nicht auf einer Momentaufnahme sitzen, dieselbe Falle wie beim List-Tab: ein Feld schreibt das ganze Bündel, muss es also im Moment der Änderung lesen. Gegenprobe im Browser: mit Momentaufnahme wird {"x":42,"tag":"ell"} zu {"x":30,"tag":"ell"} — die zweite bearbeitete Zeile belebt den alten Wert der ersten wieder.

Die Signatur trägt jetzt die Felder (defSignature): Felder sind eigene Zeilen, ein neues Feld muss die Sektion also neu bauen. Ohne das erscheint die Zeile erst beim nächsten Rebuild — gemessen, genau ein Browser-Check fällt.

Bewusst nicht gebaut: „Liste aus Structs", ein Struct-Feld vom Typ Liste und der unverbundene list-Eingang. Die drei stehen als eigene Notiz in todo-notes/struct-und-listen-restposten.md.

Der teuerste Fund lag nicht im Struct

Der Schritt lief solo grün und in der vollen Suite mit drei Fehlschlägen — identische Klick- koordinaten, das Menü ging auf, Boolean lag genau unter dem Zeiger, und trotzdem passierte nichts. Kein Notice, also war es kein CommandError, sondern eine echte Ausnahme, die das Menü (closeThen: erst schliessen, dann ausfuehren) als „Klick auf den Hintergrund" aussehen liess.

Halbiert (GM_STEPS=1-9,22 gruen, 1-10,22 rot) und dann im Fenster abgefangen: Cannot convert undefined or null to object. Die Ursache ist ein Fixture-Fehler: Schritt 10 schiebt sein Text-Objekt per mutate von Hand in die Szene — ohne instanceEdits, obwohl SceneObject das Feld verlangt. overrideSites laeuft mit Object.entries darueber. Mein AddStructFieldCommand ist die erste Stelle, die overrideSites aus diesem Zustand heraus ruft.

Das Produkt bleibt unangetastet: geladen wird das Feld von normalizeObjects gefuellt, angelegt von den Kommandos — ein Objekt ohne instanceEdits kann echt nicht entstehen. Repariert ist das Objektliteral im Schritt.

Lehre fuer den naechsten Schritt: ein Schritt, der solo gruen ist, ist nicht belegt. Nur der volle Lauf sieht, was die Vorgaenger hinterlassen.