Let a node work out its own ports
Ports that vary per node already existed, but only for the three nested-behavior
types, and the rule for them sat as a switch on type names in nested.ts – the
one place in the project that knew node types by name. It dissolves into two
optional contracts on NodeDef, so a type carries its own rule:
declaresPorts the node holds an editable list, shown as a section in the
inspector – behavior start/end, and now Pack/Expand
derivePorts the node computes them from its settings – Sequence from a
count, Run behavior from the behavior it names
Sequence gains an Outputs setting (2 to 26). Its keys stay a, b, c and count on
with d, e, so the edges of the sequences already out there survive.
A param can now take a port away, and the edge on it would stay: it draws as
nothing yet survives every save, and comes back to life if the port returns.
SetNodeParamCommand takes those edges with it, which also closes the same leak
that switching a Run behavior node's target has always had.
The port editor addresses its node by id rather than by type, so two Pack nodes
can live in one graph, and it calls the rows Fields when they are not a
behavior's signature.
This commit is contained in:
1 parent
2cf788eedd
commit
b6a609ae24
23 files changed
+438
-98
No files matched your search
@@ -116,7 +116,7 @@ shown on the node and editable in the inspector.
|
||||
`Substring`, `Find text`, `Equals`,
|
||||
lists `List` (a constant), `Fill` (one value repeated – how an empty board is made), `Count`,
|
||||
`Item at`, `Set item` (a *new* list, the one that came in is left alone), `Sub list`,
|
||||
`Join lists`, `Index of`,
|
||||
`Join lists`, `Index of`, structs `Pack`/`Expand`,
|
||||
`Length`, `Distance`, `Normalize`, `Axis input` (four keys → a
|
||||
normalized direction, so diagonals are not faster), `Compare`, `And/Or/Not`, `Key is down`,
|
||||
`Mouse position`, `Mouse button`, `Is hovered`, `Is touching` ·
|
||||
@@ -125,6 +125,23 @@ shown on the node and editable in the inspector.
|
||||
(ports, settings, `run`), listed in `nodes/index.ts`; palette, ports, validation and
|
||||
inspector fields are generated from it. A port may declare a `default` for its inline value
|
||||
(e.g. `Move.scale = 1`), shown on the node and in the inspector.
|
||||
- **Ports that are not fixed by the type**: a `NodeDef` may say `declaresPorts` (the node carries
|
||||
its own list, edited in the inspector) or `derivePorts` (the node computes them from its
|
||||
settings). `resolveDef(node, lookup)` is what applies both, so the canvas and the inspector see
|
||||
a definition that fits *this* node. `Sequence` counts its outputs from an **Outputs** setting
|
||||
(2…26, keys `a`, `b`, `c`, … – the old three keep their edges), `Run behavior` takes its ports
|
||||
from the behavior it names, and a behavior's `Start`/`End` node declares them. Turning a number
|
||||
down, or pointing a call at a different behavior, **takes the edges of the ports that go away**
|
||||
and gives them back on undo: an edge on a port that no longer exists draws as nothing but
|
||||
survives every save, and would come back to life once the port returns.
|
||||
- **Structs**: several named values travelling as one, so a bundle needs one edge instead of one
|
||||
per part. `Pack` declares its fields as inputs, `Expand` reads them back out as outputs, and a
|
||||
behavior port may be declared `struct` – which is how a bundle crosses a call. Fields are
|
||||
primitives or lists, never another struct, for the same reason a list is flat. A live entity is
|
||||
an object on a data edge too, so it carries a `Symbol` brand (`ENTITY_HANDLE`) that no struct
|
||||
field name can impersonate; nothing may hand a property value to `String()` (`textOf` instead),
|
||||
or a struct would read as `[object Object]`. A struct port has no inline value (its parts come
|
||||
from a `Pack`), and compatibility is per *kind*, not per shape – any struct fits any struct port.
|
||||
- **Loops**: `Repeat` runs its `body` output a number of times, counting `index` up from 0, and
|
||||
continues at `done`. Data nodes are cached for the length of one event pulse, but a loop round
|
||||
drops that cache, so an expression built on `index` really changes with it. That is what makes
|
||||
|
||||
Reference in new issue
Block a user