Difference between revisions of "State"
m |
Mako Nozaki (talk | contribs) (merged translator's notes in Japanese page) |
||
| Line 77: | Line 77: | ||
**[[llSensorRepeat|Repeating sensors]] are released. | **[[llSensorRepeat|Repeating sensors]] are released. | ||
**The [[llSetTimerEvent|timer event clock]] is '''not''' cleared. | **The [[llSetTimerEvent|timer event clock]] is '''not''' cleared. | ||
**It means if next state has timer event, and previous state has set any timer, the timer event in the new state will be triggered when it comes to the event delay set in previous state. | |||
*The ''default'' state must be defined before all others. | *The ''default'' state must be defined before all others. | ||
*States cannot have user functions or variables inside their immediate scope, only event definitions may be inside a states scope. | *States cannot have user functions or variables inside their immediate scope, only event definitions may be inside a states scope. | ||
Revision as of 07:13, 28 April 2010
| LSL Portal | Functions | Events | Types | Operators | Constants | Flow Control | Script Library | Categorized Library | Tutorials |
In LSL, most scripts sit idle until they receive some input, or detect some change in their environment. At any moment, the script is in some state, and will react to events or inputs according to some scheme defined by the programmer. However, a script can also contain two or more different states, and react differently to events or inputs depending on what state it is in.
The main state is the default state. When a script is compiled, reset or loaded, this is the state it enters by default. After the default state definition can follow additional state definitions which the script may use to change how and which events are handled.
- The correct title of this article is state. The initial letter is shown capitalized due to technical restrictions.
default { events }
default { events }| • event | events | – | one or more events |
The default state definition.
state target { events }
| • label | target | – | state name | |
| • event | events | – | one or more events |
target state definition.
state target;
| • label | target | – | name of a state to run |
When a state target; is encountered at runtime, if the current state and the target state are different:
- Trigger state_exit in the current state if it exists and clear the event queue.
- Change state to target, any listens are unregistered.
- Trigger state_entry in the target state if it exists.
If target state is the same as the current state, no state change occurs nor do any of the side effects.
Caveats
- On state change:
- All listens are released.
- The event queue is cleared. (see Notes for a partial workaround)
- Repeating sensors are released.
- The timer event clock is not cleared.
- It means if next state has timer event, and previous state has set any timer, the timer event in the new state will be triggered when it comes to the event delay set in previous state.
- The default state must be defined before all others.
- States cannot have user functions or variables inside their immediate scope, only event definitions may be inside a states scope.
Important Issues
|
|
SVC-3017 | A | Server drops first touch event when a script returns to a state with a touch_start handler |
Examples
<lsl>default {
touch_end(integer a)
{
state hello;
}
}
state hello {
state_entry()
{
llOwnerSay("Hello");
state default;
}
state_exit()
{
llOwnerSay("Goodbye");
}
}</lsl>
Notes
- To avoid dumping previously queued events, consider moving the state target command to the timer event, and calling it with llSetTimerEvent( 0.01 ), then stopping the timer in state_entry of the new state. Do NOT use state_exit if this is a concern.
See Also
Deep Notes
Issues
|
|
|
SVC-3017 | A | Server drops first touch event when a script returns to a state with a touch_start handler |