MiceOnABeam Product Documentation

Modified: 4/21/2013 4:21 PM
Recently changed articles You can subscribe to this wiki article using an RSS feed reader.

Transition

Summary

A Transition is used to specify a handler for a particular LSL Event that may occur while in a particular State.

Graphic

A Transition with an un-defined event is represented by a directed dotted-line.

A Transition with a defined event is represented by a directed solid-line.

A Transition's Guard Condition and Transition Action can also optionally be shown (Options) as follows, where x==1 is the Guard Condition, x=2; is the Transition Action.

►Note that the length of the Guard Condition or Transition Action shown is capped to minimize the clutter of model diagrams.

A Transition's name is automatically set to the name of the event assigned to it. This setting can be changed within the Options menu. However the user can also manually assign the name of a Transition. Note that a Transition's name must be unique among the outgoing Transitions from it's source state.

Description

If a script wishes to respond to the occurrence of a particular event, then it must define a Transition in the MiceOnABeam model. Each Transition specifies:

  • Transition Source: The State the script must be in to receive the event: This is indicated by the state the Transition is drawn from.
  • Transition Event: This is the LSL Event which the Transition will respond to and is also referred to as the Transition's Trigger.
  • Guard Condition: This represents an additional constraint and is the condition under which the occurring event should be responded to. An LSL boolean expression is used for this which defaults to TRUE.
  • Transition Action: An action to take when the Transition is fired (i.e., taken), consisting of a set of LSL statements.
  • Transition Destination: The next state to proceed to after processing the event, which is indicated by the state the Transition is drawn to (i.e., the state the arrow is pointing to).
Transition Firing

A Transition is said to be fired when it is successfully triggered. For the latter to occur, the following must all be true:

  • The Transition Source must be a currently active state;
  • The Transition Event must have occurred and been dispatched to the running script by your virtual world's run-time system.
  • The Guard Condition is dynamically evaluated, and the result is TRUE.

When the Transition is fired, the Transition Action is executed and the script is moved to the state indicated by the Transition Destination.

Transition Types

The above discussion describes a standard transition. However we can refer to several different types of transitions which are described below.

  • Outgoing Transition: Used to describe a Transition in reference to the Transition Source it is originating from.
     
  • Incoming Transition: Used to describe a Transition in reference to the Transition Destination it is pointing to.
     
  • Originating Transition: An Originating Transition is a Transition which has an Event assigned to it and an optional Guard Condition which can be modifed and defaults to TRUE. A Transition outgoing from a Simple State is always an Originating Transition.

    With respect to a Composite State's inside and outside border, an Originating Transition starts from one side of the border with no corresponding connected transition
    (via an Entry/Exit Point) to any other component on the other side of the border.
     
  • Continuing Transition: A Continuing Transition is a Transition which cannot have an Event assigned to it. It's Guard Condition is fixed and set to TRUE With respect to a Composite State's inside and outside border, a Continuing Transition starts from one side of the border with a corresponding connected transition (via an Entry/Exit Point) on the other side of the border connecting to some component.
     
  • Initial Transition: An Initial Transition is the single outgoing transition from the Initial Point. It's name ("init") and event (%%init) are fixed, and it's Guard Condition is fixed to TRUE.
     
  • Default History Transition: Both Shallow History and Deep History Points may have a single outgoing transition called the Default History Transition. It's name ("defaultHistory") and event (%%defaulthistory_event) are fixed, but it does have a Guard Condition which can be modified and defaults to TRUE.
     
  • Choice Transition: A transition outgoing from a Choice Point. It cannot have an Event assigned to it but does have a Guard Condition which can be modifed and defaults to TRUE.
     
  • ELSE Transition: A Choice Transition whose Guard Condition has been set to ELSE. It is taken when no other Choice Transition's Guard Condition evaluates to TRUE.
     
  • Group Transition: Originating from the border of a Composite State, the Group Transition acts as if it had originated from every substate contained within the state's decomposition, and recursively so inside every substate that is also a Composite State.
     
  • Completion Transition: A Completion Transition is a Transition which has been assigned the internal event %%completion_event. The event is automatically generated for a Composite State whenever a transition is made to a Final State contained within it's decomposition.
     
  • Self Transition: When the Transition Source is the same as the Transition Destination then the transition is a Self Transition. A Self Transition which is on the outside border of a state will execute the state's Exit Action, followed by the Transition Action, and finally the state's Entry Action. A Self Transition which is on the inside border of a state will not execute the state's Entry or Exit Action when fired as it exists entirely within the context of the Composite State

►Note that a Self Transition on the inside border of a state will have no effect unless there is at least one substate defined within the state.

Transition Merging and Splitting

A merge of Transitions occurs when two or more incoming Transitions converge on the following component types: Choice Point, Entry Point, Exit Point, Junction Point, Shallow History Point, Deep History Point, Final State, and Terminate Point.

To split a Transition, a Choice Point must be used.

Transition Conflicts & Priority

Transition conflicts occur when two or more Transitions can successfully fire in response to the receipt of a particular event as described in Transition Firing above. There are two main cases in which this can occur.

First, if there are multiple Transitions with the same assigned event all originating from the same state whose Guard Conditions all evaluate TRUE, then the transitions are said to be in conflict.  In this case, each Transition's Guard Condition is evaluated in turn and the first one which evaluates TRUE is selected for firing.

►Note that ordering in which a state's Transitions are tested is unspecified and should not be relied upon, but will be consistent during execution of the script.

In the second case, transition conflicts may occur when Group Transitions are used. Here an originating Transition placed on a higher-level active state within the state hierarchy may potentially fire on receipt of a particular event. As well an originating transition placed on a lower-level active state within the state hierarchy may also potentially fire on receipt of the same event. In this case the relative placement of the transitions within the state hierarchy determines the implicit priority of the transition and hence which transition will be selected for firing.

The simple rule is that a transition defined at a lower level within the hierarchy has a higher priority than one placed at a higher level. So a Transition with a particular event on a substate whose Guard Condition evaluates TRUE will be selected before a Transition with the same event on the enclosing Composite State whose Guard Condition also evaluates TRUE.

 

Usage

The following example shows three states S, S1 and S2 cycling between themselves upon receiving touch_start events, each with unique Guard Conditions. S1 is a Composite State with incoming continuing transition inc_cont_TS, substate S1Substate, originating transition touch_start, with the latter leading to outgoing continuing transition out_cont_TS leaving S1.

Note the existence of the touch_start Group Transition on the TopState's border. It is also triggered by the touch_start event (Guard Condition is TRUE) but as per the transition priority rule, will fire only if the touch_start transition on the currently active substate does not fire.

TopState

State S1

 

As a transition is a basic concept, please see the Usage sections within the documentation of other MiceOnABeam modeling concepts such as Composite State, for further examples of the different types of transitions.

Notes

  • A transition whose Guard Condition is set to ELSE has the "else" meaning only when outgoing from a Choice Point. The error Undeclared Identifier: ELSE will be flagged during editing of the Guard Condition if used elsewhere. However, during code generation, if ELSE is used as the Guard Condition for a transition outgoing from any other modeling component, it is handled as if the Guard Condition was set to TRUE.

 

Tags:
Home: MiceOnABeam Product Documentation Copyright © 2010-2018 MiceOnABeam Software