Behaviour Models
In depth learning on Behaviour Models can be found in this course in Motive Academy.
Sometimes you want to control or monitor an object in a scene in a way that doesn’t map to an existing Motive Resource or Condition. For example:
Is a door opened or closed
Is a plug plugged in or unplugged
Is a screw fastened or unfastened
What is the current setting of a dial or other controller
Etc.
Behaviour Models allow you to manage these sorts of objects without having to create new Resources or Conditions. Creating a Behaviour Model allows you to map named object states into elements that can be managed in a Motive Script.
Create the Model in the Editor
On the Script side, Behaviour Models are created in the editor in a Behaviour Model catalog. A Behaviour Model allows you to establish named states that will map to the states of objects in a scene. Behaviour States are currently limited to Enums and primitive types. In the example below, you can see the various states of a meat slicer have been connected to a Behaviour Model:
Wire Up the Object in the Scene
There are a number of components in the SDK that can be used to translate object states to a Behaviour Model. This list will continue to grow. These components are broken into:
StateListeners: monitor a Behaviour State and update an object based on that state.
StateSetters: monitor an object and set a Behaviour State based on the object’s state.
StateHandlers: combine a listener and a setter [deprecated - use Two-Way links instead]
Note that either a Listener or Setter alone will not offer the other functionality: e.g., if an object has only a StateSetter, users will be able to monitor a state using a variable or an object interaction, but updating that variable in a Script will have no impact on the scene.