Difference between revisions of "LSL States"
Tapple Gao (talk | contribs) (mentioned timer is persisted across state changes) |
|||
(10 intermediate revisions by 6 users not shown) | |||
Line 1: | Line 1: | ||
{{LSL Header}} | {{LSL Header|ml=*}} | ||
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 '''state'''s, and react differently to events or inputs depending on what state it is in. | 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 '''state'''s, and react differently to events or inputs depending on what state it is in. | ||
One common abstract model that is used in such cases is called a ''Finite State Machine'' (see Wikipedia[http://en.wikipedia.org/wiki/Finite_state_machine])]. | One common abstract model that is used in such cases is called a ''Finite State Machine'' (see Wikipedia[http://en.wikipedia.org/wiki/Finite_state_machine])]. | ||
For example, a door might be in a ''waiting'' state, and ignore all inputs except being touched. Once touched, it goes to the ''open'' state, in which it | For example, a door might be in a ''waiting'' state, and ignore all inputs except being touched. Once touched, it goes to the ''open'' state, in which it ignores being touched, but monitors which avatars pass through it. After a while, it changes to the ''closing'' state during which it closes, and then it returns to the ''waiting'' state. | ||
States are not the only way to represent this kind of behavior, but in some cases they are a very good way. | States are not the only way to represent this kind of behavior, but in some cases they are a very good way. | ||
In LSL, | In LSL, a '''state''' is a specified section of code within which all {{LSLGC|Events}} are specified. The main state that is required by all LSL scripts is called ''default''; all scripts must have a default state, and every state must have at least one event. | ||
a '''state''' is a specified section of code within which all {{LSLGC|Events}} are specified. The main state that is required by all LSL scripts is called ''default'' | |||
To add another state add an entry like this: | To add another state add an entry like this: | ||
state my_state | |||
{ | |||
state_entry() | |||
{ | |||
// What should happen when we enter this state | |||
} | |||
// other events and code | |||
} | |||
To switch from one state to another add a line like this: | |||
state my_state; | |||
When this line of code is executed, it will run anything in the [[state_exit]] event, and then switch to the new state. | |||
When switching states, all event queues are cleared, and events requiring setup are disabled such as [[sensor]] and [[listen]]. Surprisingly, [[timer]] is persisted across state changes | |||
state | |||
The state_entry event is run when the code enters that state. There is sometimes confusion in thinking that the state_entry event will run when a scripted object is rezzed from inventory. This is not the case as scripts are frozen when taken into inventory in the state they are in, and resume operation in that state when rezzed. The event first called when an object is rezzed out of inventory is [[on_rez]]. | |||
== See also == | |||
For more information, see [[State]]. |
Latest revision as of 09:05, 21 September 2023
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.
One common abstract model that is used in such cases is called a Finite State Machine (see Wikipedia[1])].
For example, a door might be in a waiting state, and ignore all inputs except being touched. Once touched, it goes to the open state, in which it ignores being touched, but monitors which avatars pass through it. After a while, it changes to the closing state during which it closes, and then it returns to the waiting state.
States are not the only way to represent this kind of behavior, but in some cases they are a very good way.
In LSL, a state is a specified section of code within which all Events are specified. The main state that is required by all LSL scripts is called default; all scripts must have a default state, and every state must have at least one event.
To add another state add an entry like this:
state my_state { state_entry() { // What should happen when we enter this state } // other events and code }
To switch from one state to another add a line like this:
state my_state;
When this line of code is executed, it will run anything in the state_exit event, and then switch to the new state.
When switching states, all event queues are cleared, and events requiring setup are disabled such as sensor and listen. Surprisingly, timer is persisted across state changes
The state_entry event is run when the code enters that state. There is sometimes confusion in thinking that the state_entry event will run when a scripted object is rezzed from inventory. This is not the case as scripts are frozen when taken into inventory in the state they are in, and resume operation in that state when rezzed. The event first called when an object is rezzed out of inventory is on_rez.
See also
For more information, see State.