LSL Protocol/RestrainedLifeAPI

From Second Life Wiki
< LSL Protocol
Revision as of 13:58, 28 January 2008 by Marine Kelley (talk | contribs) (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...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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 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.