Behavior On and Execute Behavior
-
I have no idea who came up with the way it works now, but it needs to change.
Here’s my suggestion.
Make behavior on enable the selected behavior, but not execute it.
Make Execute behavior execute a behavior if it is on, and add a skip events toggle which causes the executed behavior to not execute its children. Optionally, add a Boolean output where true is executed successfully, false is behavior disabled. -
Yes, there's some inconsistency, missed opportunities for logic coordination/creation/condensation and poorly communicated/expressed conventions/processes and other issues being ignored in the way "Behaviours" have their states changed and are utilised.
Listing things, for clarity:
Behaviour On should simply turn a Behaviour On, not execute it. This permits the subsequent executions of a branch of Behaviours to perform differently than in prior runs, and is an incredibly powerful feature. Oddly, this is the default way in which this works if there's Behaviours above the behaviour being turned on, but not if the Behaviour is parentless.
Parentless "on" state changes, without execution, require the use of Receive Message, which requires the use of a broadcast and further branching.
Behaviour On, ideally, should never execute a behaviour, simply change its state from off to on.
Execute Behaviour should only execute a behaviour, even if it's off, without otherwise changing its state to on. It's a function call, in this sense.
Ideally, then, both Execute Behaviour and "Behaviour State" are the two terms that should be used, and can be combined into a single block.
Behaviour Control
Within this, a behaviour can be chosen to be executed (activated or invoked) and/or have its state changed (from off to on and vice-versa).
Done with the ability to operate on more than one behaviour, and this becomes a gate and state tool of significance to the usage and capabilities of visual logic within hyperPad, and a meaningful gateway to understanding how to best structure visual code.
This opens the gate to considering the path to switches and a better branching system(s).