Difference between revisions of "LSL Protocol/RestrainedLifeAPI"

From Second Life Wiki
Jump to navigation Jump to search
(New page: =Restrained Life viewer 1.10 Specification= ==Audience== This document is aimed at people who wish to modify or create their own LSL scripts to use the functionalities of the RestrainedL...)
 
(Making this a redirect)
 
(143 intermediate revisions by 15 users not shown)
Line 1: Line 1:
=Restrained Life viewer 1.10 Specification=
#redirect [[LSL_Protocol/RestrainedLoveAPI]]
 
==Audience==
 
This document is aimed at people who wish to modify or create their own LSL scripts to use the functionalities of the RestrainedLife viewer. It does not, however, explains LSL concepts such as messages and events, nor universal concepts such as UUIDs.
 
 
==Introduction==
 
The RestrainedLife viewer is meant to execute certain behaviours when receiving special messages from scripts in-world. These messages are mostly calls to the llOwnerSay() LSL function.
 
 
==Architecture==
 
The RestrainedLife viewer parses every llOwnerSay call and executes every command beginning with '@'. For instance, a call to llOwnerSay ("@detach=n") will tell the viewer that the object sending the message cannot be detached until further notice.
 
Version 1.10 and above are able to parse multiple commands in one message, in order to avoid spamming the user who is not using this viewer. The format of a message is therefore :
 
@behaviour1:option1=param1,behaviour2:option2=param2,...,behaviourN:optionN=paramN
Note that there is only one '@' sign, placed at the beginning of the message. The viewer understands this as "this whole llOwnerSay() is actually a command to execute", so no need to put a '@' before every command, it wouldn't even work. If at least one command fails (typo), the viewer says "... fails command : ... " and mentions it all. However correct commands are parsed and executed, only incorrect ones are discarded.
 
WARNING : These behaviours are NOT persistent between sessions, and an object changes UUID everytime it rezzes. This means the object must resend its "status" (undetachable, preventing IMs...) in the on_rez () event as well as when it changes.

Latest revision as of 12:14, 5 April 2010