Crate arora_behavior 

Behavior interpreters: the executors the Arora runtime ticks each step.

Two things share the word “behavior”, and this crate is about only one of them:

• A behavior (the noun) is an authored, editable representation of what a device should do — a behavior tree, a node graph — produced in a visual editor (Studio, the Vizij Workspace) and shipped as data.
• A BehaviorInterpreter is the runtime-level executor that runs one of those: a behavior-tree interpreter, a node-graph interpreter. It is the thing the runtime actually ticks.

The runtime holds a queue of Box<dyn BehaviorInterpreter> and ticks them interchangeably — it just swaps the interpreter. The behavior tree is one interpreter (arora-behavior-tree’s [BehaviorTreeInterpreter]); a Vizij node graph is another. Adding a new kind of authored behavior means adding a new interpreter here. Hand-implementing the trait to hard-code a single behavior in Rust is possible, but it is a corner case — the promoted path is to author a behavior in an editor and let an interpreter run it.

Each tick an interpreter gets a BehaviorContext: the shared DataStore (read inputs, write intent / outputs) and a CallBridge (so a module-calling interpreter like the behavior tree can reach the engine). An interpreter uses whichever it needs — a graph reads/writes the store; the tree drives the caller.

Timing is not a tick argument. The runtime publishes the frame’s clock into the store under the golden keys before it ticks, so an interpreter that needs dt or elapsed time reads it from the store like any other slot.

Modules

golden

Golden keys: well-known store slots the runtime maintains for every behavior.

Structs

BehaviorContext

What a BehaviorInterpreter receives each tick.

BehaviorError

An interpreter failed to tick.

Enums

BehaviorStatus

Whether an interpreter wants to be ticked again.

Traits

BehaviorInterpreter

A behavior executor: something the Arora runtime ticks once per step to run an authored behavior.