Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

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.

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.

Components

  • No labels