Difference between revisions of "User:Strife Onizuka/The State of State"

From Second Life Wiki
Jump to navigation Jump to search
m
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{RightToc}}
When it comes to [[LSL|scripting]] ''state'' can mean one of several things.
When it comes to [[LSL|scripting]] ''state'' can mean one of several things.
* It can be a '''group of events''' that as a group can be used to handle incoming events.
* It can be a '''named grouping of events''' that can be designated to handle incoming events.
** context: [[state]], [[default]]
* It can be the '''running status''' of the script.
* It can be the '''running status''' of the script.
* It can be the all of the '''script running information''' (memory, event queue, execution position, etc)
** context: [[llSetScriptState]], [[llGetScriptState]]
Unless otherwise stated, state will refer to the '''script running information'''.
* It can be all of the '''script running information''' (memory, event queue, execution position, etc)
** context:
Unless otherwise stated, 'state' will refer to the '''script running information'''.


===Background===
===Background===
Line 17: Line 21:
A script however is not a normal inventory item, besides the ordinary inventory aspect it also has an additional part. This extra part is the state which encompasses all execution information, pending events, etc.  
A script however is not a normal inventory item, besides the ordinary inventory aspect it also has an additional part. This extra part is the state which encompasses all execution information, pending events, etc.  


===Problems===
===Inventory Transfer===


The big issue with state, is when should it be maintained and when it should be discarded.
* When a script is copied, it's state is not copied.
* When a script is moved from one inventory to another, it's state is discarded.


*Optional
While it makes some sense to let a script keep the contents of it's memory when it is transfered from one inventory into another. It does not make sense for it to keep it's entire state. A script might be in the middle of parsing an event, where it is manipulating the rest of the object, or sending messages to others scripts within the object. Events do not interupt, the script would have no practicle way of knowing when it resumed execution that it was no longer in the same prim.
**pros
**cons
*Out of object
**pros
**cons
*Not Running
**pros
**cons


===Current Implementation===
===Bugs===


lorem ipsum yada yada
{{{!}} style="font-size:smaller;"
 
{{Issues/SVC-1853}}{{#var:issues}}
The state is not really a part the inventory item, it is better thought of as a part of the containing prim.
{{!}}}


=== FAQ ===
=== FAQ ===

Latest revision as of 20:44, 9 November 2011

When it comes to scripting state can mean one of several things.

  • It can be a named grouping of events that can be designated to handle incoming events.
  • It can be the running status of the script.
  • It can be all of the script running information (memory, event queue, execution position, etc)
    • context:

Unless otherwise stated, 'state' will refer to the script running information.

Background

Before we can talk about state, the structure of scripts needs to be expounded upon.

Inventory

A script (as the user sees it) is an inventory item that once put into a prim can interact with the world the prim exists in. The important part of this definition for now is that it is an inventory item. All inventory items are made up of two parts: the underlying asset and the wrapper. The wrapper holds the inventory aspects of the item, for example the name, permissions, etc. The asset is the actual data. Assets in SL are read-only.

State

A script however is not a normal inventory item, besides the ordinary inventory aspect it also has an additional part. This extra part is the state which encompasses all execution information, pending events, etc.

Inventory Transfer

  • When a script is copied, it's state is not copied.
  • When a script is moved from one inventory to another, it's state is discarded.

While it makes some sense to let a script keep the contents of it's memory when it is transfered from one inventory into another. It does not make sense for it to keep it's entire state. A script might be in the middle of parsing an event, where it is manipulating the rest of the object, or sending messages to others scripts within the object. Events do not interupt, the script would have no practicle way of knowing when it resumed execution that it was no longer in the same prim.

Bugs

   Scripts deactivated by llSetScriptState are reset when the region is reset, when they are taken into inventory and re-rezzed and when crossing sim boundaries.

FAQ