From e77acc5a07841ad31cf8555733e10274ba04e92e Mon Sep 17 00:00:00 2001 From: meleki Date: Fri, 25 Sep 2026 17:27:56 +0200 Subject: [PATCH] Describe the On start fallback of Run behavior (#230) A nested behavior without a Behavior start node used to do nothing when called. It now runs from its On start nodes. - Behaviors: Run behavior starts at the On start nodes when the called behavior has no Behavior start, all of them in graph order. - The Behavior end still returns its values. Such a call has no inputs, because only the start node declares them. - The note on the node now reads "No start or On start node - does nothing" and only shows when neither exists. --- Behaviors.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Behaviors.md b/Behaviors.md index 1028f88..fef1623 100644 --- a/Behaviors.md +++ b/Behaviors.md @@ -203,8 +203,8 @@ shown on the node and editable in the inspector. `Object by name` taking the name the round put together (`"c" + index`). Two guards, not one: a pulse may take 100 000 steps (a loop legitimately runs long), but exec edges may only nest 1000 deep — that is what catches a flow feeding back into itself before the call stack does. -- **A behavior as a node** (nesting): a behavior that has a **Start** and an **End** node can be - run as a step of another behavior's graph. Every input declared on the start node becomes an +- **A behavior as a node** (nesting): a behavior, usually one with a **Start** and an **End** + node, can be run as a step of another behavior's graph. Every input declared on the start node becomes an input port of the calling node, every output declared on the end node one of its outputs; the node is drawn under the behavior's own name, and the palette lists it there too, so a call is one pick. Declaring a port keeps both sides in step — renaming carries the typed-in value along, @@ -213,6 +213,9 @@ shown on the node and editable in the inspector. variable defaults, so values travel in and out through the ports and nothing else. That makes a call repeatable and keeps a nested behavior free of hidden state. A behavior that would run itself raises an error instead of looping; there is one start and one end node per behavior. + A behavior **without a start node** is called from its **On start** nodes instead, all of them in + graph order, as when it starts on its own. It takes no inputs then, but its end node still hands + back what it is given. With a start node in the graph, its On start nodes stay out of the call. - **Keep** (a switch on each variable of the called behavior, in its inspector): a kept variable picks up where the last call **from this node, on this object** left it; the others start at their default every call. A variable added to a behavior starts out kept, and one from a project @@ -231,8 +234,8 @@ shown on the node and editable in the inspector. stays in the same tab, and the trail belongs to that tab: a behavior opened any other way comes up in a tab of its own, without a trail, and switching back brings the trail back with it. And a call that cannot do anything **says so on the node** — no behavior picked, the behavior deleted, - or no start node in it. The last one is the one worth naming: without a start node there is no - way in, so the call is skipped and the flow simply carries on at its `exec` output. A missing + or neither a start node nor an On start in it. The last one is the one worth naming: without + either there is no way in, so the call is skipped and the flow simply carries on at its `exec` output. A missing *end* node is not a defect — a call is always synchronous, "done" is the nested flow running out, and the end node only decides what comes back. - **Shared state**: a **Variables asset** is a list of declarations and nothing else — no graph, no