Difference between revisions of "LSL States"

From Second Life Wiki
Jump to navigation Jump to search
(added link to wikipedia)
(mentioned timer is persisted across state changes)
 
(11 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 [http://en.wikipedia.org/wiki/Finite_state_machine|link Finite State Machine (see Wikipedia)].
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 ignoers being touched, but monitors what 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.
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'' and is automatically created when a new script is created in Second Life.
All scripts must have a default state, and each states must have a {{LSLG|state_entry}} event.


To add another state add an entry like this:
To add another state add an entry like this:
<pre>
<lsl>
state my_state
{
    state_entry()
    {
          // What should happen when we enter this state
    }


    // other events and code
    state my_state
}
    {
        state_entry()
        {
            // What should happen when we enter this state
        }
       
        // other events and code
    }


</lsl>
To switch from one state to another add a line like this:
</pre>


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.


<pre><lsl>
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 my_state;
</lsl></pre>


When this line of code is executed, it will run anything in the {{LSLG|state_exit}} event, and then switch to the new 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]].


When switching states, all event queues are cleared, and events requiring setup are disabled such as {{LSLG|timer}}, {{LSLG|sensor}}, and {{LSLG|listen}}.
== See also ==


The state_entry event is run when the code enters that state. There is sometimes confusion in thinking that the stat_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 {{LSLG|on_rez}}.
For more information, see [[State]].

Latest revision as of 09:05, 21 September 2023

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.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_States&oldid=1214612"