Second Life Wiki - User contributions [en]

Webmap API Advanced Examples

2012-07-29T09:13:52Z

Uzume Grigorovich: dbl redir

#REDIRECT [[Linden Lab Official:Map API Advanced Examples]]

Webmap API

2012-07-29T09:12:58Z

Uzume Grigorovich: dbl redir

#REDIRECT [[Linden Lab Official:Map API]]

MapAPI

2012-07-29T09:12:46Z

Uzume Grigorovich: dbl redir

#REDIRECT [[Linden Lab Official:Map API]]

LSL Protocol/Restrained Love Relay/Other Implementations/Felis Darwin's Amethyst Plugin

2012-07-29T08:26:41Z

Uzume Grigorovich: cat sort

This is an Amethyst Plugin implementation of the Restrained Life Relay, meant for use in Amethyst collars. '''At the moment this plugin may nullify commands issued by the standard Amethyst RLV Plugin.''' However, it will instruct the Amethyst RLV plugin to re-issue its restrictions once the relay is no longer active. (Collar v6.7 and above)

This version adds a few important things to the Reference Implementation, like periodically pinging the restraining object (optional) and fixing a loophole in the "ask" mode that could allow items to restrict you even if you hadn't approved them yet. It also adds some nice features for Owners set on the collar, such as automatic exceptions to certain restrictions (IM and TP) and the ability to "lock" the plugin's mode so that the wearer cannot turn it off. It currently complies with Marine's v1.100 spec.

Finally, this implementation does ''not'' include support for multiple control objects, due to the overhead necessary for the plugin to interact with the Amethyst collar system. If you absolutely need this functionality I recommend using one of the many free Relay HUDs.

== Current Changelog ==
Current version: v0.6

===v0.6===

:- Included support in the owner exceptions for the new "secure" IM and teleport restrictions. When the relay sees these commands it will add IM or teleport restrictions, allowing the owner to receive IMs from the wearer or teleport them to safety, respectively.

:- Cleaned up the Implementation Version text to be compatible with the new 1.100 spec.

:- Changed the release routine so it releases restrictions in reverse order, per the new spec.

:- If the user is seated when they receive an "@unsit" restriction it will assume the issuing object is the sit target, until told otherwise, per the new spec.

:- Relay will now silently reject malformed commands which lack a variable (e.g. "@version" instead of "!version")

:- Changed the "control attempt denied" dialog so it specifies what device the recipient was using.

:- Removed a few unused variables and irrelevant comments that were lying about.

:- A few other script cleanups that should add a little more working memory to the relay.

===v0.5===

:- Added an "Owner + Whitelist" mode, which automatically allows all commands issued from devices owned by the collar's Owner(s) or those on the Whitelist, while automatically denying all other commands.

===v0.4===

:- Implemented changes to bring the relay up to 1040 spec:

::+ Added a more complete fix to an exploit allowing devices to force the user to speak on the public channel
::+ Made sure the distance check fails when the controlling object has been de-rezzed/removed
::+ Stopped groupless objects from immediately passing the trustworthy check on groupless land
::+ Added support for the "!who" meta-command (tells you who is in control of the device), and updated the user dialog messages accordingly
::+ Added support fo the "!handover" meta-command (allows devices to "hand over" controlled residents)

:- Rewrote the rememberForceSit command to use less resources.

:- Removed the "!mode" meta-command I had proposed because 1) nobody used it, and 2) there were compilation errors (due to too many else/ifs) otherwise

:- Went through the script and combined a number of if statements so as to reduce memory usage and overhead

:- Removed a number of global variables and replaced them with the values they previously held. Examples are the command prefix variables (PREFIX_RL_COMMAND, etc.) and the mode variables (MODE_OFF, MODE_ASK, MODE_AUTO). This has reduced memory usage a bit, and has allowed me to cram in more features.

:- Objects owned by your owners (primary or secondary) are now automatically considered "trustworthy", thus bypassing the annoying "this object is not owned by the parcel owner blah blah" security message.

:- Added in a whitelist/blacklist feature. When you are presented with a prompt to approve a control request from an object you will notice two additional buttons, "Always" and "Never". This will add the CONTROLLER of the object (who is pushing the buttons, so to speak) to the white/blacklist if that information is known. (It will mention "so and so using X" if this is the case) If the controller ISN'T known then clicking either of these buttons will add the OWNER of the object to the white/blacklist.

:- Removed the as-yet unused "deny restrictions" list to make room for the above feature. If I figure out a way to fit it in while keeping the script compilable I'll do it.

===v0.3===

:- Upgraded implementation version to 1.021. (Was already compliant in v0.2, but the version reply is now updated)

:- Modified the "Send IM" exception so that it is now generalized and will work for any specified restriction. Currently it has been expanded to include the "Teleport Request"/tplure restriction.

:- Added in a means of disallowing certain restrictions, beyond just the "stripping" deny mode. The list (denyRestrictions) takes strings, and checks each restriction to see if it contains that string. If it does, the restriction is denied. (e.g. the entry "tp" would prohibit all tp-related restrictions like accepttp, tploc, tplure, sittp, etc.) Adding "=force" to the end of an entry will limit it to only work on "force" commands, e.g. "detach:skirt=force" or even "detach=force".

:- Removed the "stripping" deny mode, as the above method will handle the same thing.

:- Got rid of the separate list for restriction exceptions, originally added as a means of saving available memory. The code will now simply ignore exceptions if it runs to low on memory (and will notify the wearer of this).

:- Added a means to turn off the "ping" requirement

===v0.2 and v0.1===

No proper changelog exists. v0.2 was the first version to implement the now-optional "periodic ping" requirement, requiring furniture to respond to ping requests in order to keep the relay active.

== Current Source Code ==

<lsl>

//== RestrainedLife Viewer Relay Script
//== by Felis Darwin
//== Based on Reference Implementation by Marine Kelley

integer DEBUG = FALSE;

// ---------------------------------------------------
// Amethyst Plugin Variables
// ---------------------------------------------------

key nullkey = NULL_KEY;
string nullstr = "";

integer secaccess=0; //== Do secondary owners have access to the RL functions?

// Internal variables
key ownerkey = nullkey;
list secowners = [];

key setby = nullkey; //== Who set the RLV Relay status?

integer lockstatus; //== Has the collar been locked by the RLV plugin?

string ownerexcept = "@sendim @sendim_sec @tplure @tplure_sec"; //== List of restrictions owner (not wearer) will always be exempt from

// ---------------------------------------------------
// Constants
// ---------------------------------------------------

integer RLVRS_PROTOCOL_VERSION = 1100; // version of the protocol, stated on the specification page
string RLVRS_IMPL_VERSION = "Felis Darwin's implementation (Amethyst Plugin version)";

integer MAX_TIME_AUTOACCEPT_AFTER_FORCESIT = 60; // seconds

integer PERMISSION_DIALOG_TIMEOUT = 30;

integer LOGIN_DELAY_WAIT_FOR_PONG = 20;

integer PING_INTERVAL = 60; //== Time between pings, and time waiting for force-sit

// ---------------------------------------------------
// Variables
// ---------------------------------------------------

integer nMode;

list lRestrictions; // restrictions currently applied (without the "=n" part)
key kSource; // UUID of the object I'm commanded by, always equal to nullkey if lRestrictions is empty, always set if not
key kController; // UUID of the person controlling the object, if passed to us by the !who command

list WhiteBlack = []; //== A combined white/black list of residents. Whitelisting exempts them from ask mode. Blacklisting prevents their objects from even interacting with you.

string sPendingName; // name of initiator of pending request (first request of a session in mode 1)
key sPendingId; // UUID of initiator of pending request (first request of a session in mode 1)
string sPendingMessage; // message of pending request (first request of a session in mode 1)
integer sPendingTime;

// used on login
integer timerTickCounter; // count the number of time events on login (forceSit has to be delayed a bit)
integer loginWaitingForPong;
integer loginPendingForceSit;

integer noping = 0;

key lastForceSitDestination = nullkey;
integer lastForceSitTime;

integer stop = 0; //== Allows the relay to stop mid-command execution if directed to by another command

// ---------------------------------------------------
// Low Level Communication
// ---------------------------------------------------

debug(string x)
{
if (DEBUG)
{
llOwnerSay("DEBUG: " + x);
}
}

// acknowledge or reject
ack(string cmd_id, key id, string cmd, string ack)
{
if(id != nullkey)
llShout(-1812221819, cmd_id + "," + (string)id + "," + cmd + "," + ack);
}

// get current mode as string
string getModeDescription()
{
if (nMode == 0) return "RLV Relay is OFF";
if (nMode == 1) return "RLV Relay is ON (permission needed)";
if (nMode == 2) return "RLV Relay is ON (auto-accept)";
return "RLV Relay is ON (owners + whitelist only)";
}

// ---------------------------------------------------
// Permission Handling
// ---------------------------------------------------

// are we already under command by this object?
integer isObjectKnow(key id)
{
// are we not under command by any object but were we forced to sit on this object recently?
if (id != nullkey && (kSource == id || ((kSource == nullkey) && (id == lastForceSitDestination) && (lastForceSitTime + MAX_TIME_AUTOACCEPT_AFTER_FORCESIT > llGetUnixTime()))))
{
return TRUE;
}

return FALSE;
}

// check whether the object is in llSay distance.
// The specification requires llSay instead of llShout or llRegionSay
// to be used to limit the range. But this has to be checked here again
// because the objects are not trustworthy.
integer isObjectNear(key id)
{
vector myPosition = llGetRootPosition();
list temp = llGetObjectDetails(id, ([OBJECT_POS]));
vector objPosition = llList2Vector(temp,0);
if(temp == []) objPosition = <1000.0, 1000.0, -1000.0>;
float distance = llVecDist(objPosition, myPosition);
return distance <= 100;
}

// do a basic check on the identity of the object trying to issue a command
integer isObjectIdentityTrustworthy(key id)
{
key parcel_owner=llList2Key (llGetParcelDetails (llGetPos (), [PARCEL_DETAILS_OWNER]), 0);
key parcel_group=llList2Key (llGetParcelDetails (llGetPos (), [PARCEL_DETAILS_GROUP]), 0);
key object_owner=llGetOwnerKey(id);
key object_group=llList2Key (llGetObjectDetails (id, [OBJECT_GROUP]), 0);

debug("owner= " + (string) parcel_owner + " / " + (string) object_owner);
debug("group= " + (string) parcel_group + " / " + (string) object_group);

if (object_owner==llGetOwner () // IF I am the owner of the object
|| object_owner==parcel_owner // OR its owner is the same as the parcel I'm on
|| (object_owner==ownerkey && ownerkey != nullkey) //== Is this my owner's stuff?
|| ~llListFindList(secowners, [object_owner]) //== ...or my owners' stuff?
|| (object_group==parcel_group && object_group != nullkey) // OR its group is the same as the parcel I'm on
)
{
return TRUE;
}
return FALSE;
}

// Is this a simple request for information or a meta command like !release?
integer isSimpleRequest(list list_of_commands)
{
integer len = llGetListLength(list_of_commands);
integer i;

debug("Checking simplicity of commands...");

// now check every single atomic command
for (i=0; i < len; ++i)
{
string command = llList2String(list_of_commands, i);
if (!isSimpleAtomicCommand(command))
{
debug("Command "+ command +" fails simplicity check.");
return FALSE;
}
}

// all atomic commands passed the test
return TRUE;
}

// is this a simple atmar command
// (a command which only queries some information or releases restrictions)
// (e. g.: cmd ends with "=" and a number (@version, @getoutfit, @getattach) or is a !-meta-command)
integer isSimpleAtomicCommand(string cmd)
{
// check right hand side of the "=" - sign
integer index = llSubStringIndex (cmd, "=");
// check for a number after the "="
string param = llGetSubString (cmd, index + 1, -1);
if ((((((integer)param!=0 || param=="0") && llSubStringIndex(param, "n") <= -1 && llSubStringIndex(param, "add")<= -1) || param == "y" || param == "rem") || index == -1) || llSubStringIndex(cmd, "!") == 0 || cmd == "@clear") // is it an integer (channel number) or empty?
{
return TRUE;
}

// this one is not "simple".
return FALSE;
}

// If we already have commands from this object pending
// because of a permission request dialog, just add the
// new commands at the end.
// Note: We use a timeout here because the player may
// have "ignored" the dialog.
integer tryToGluePendingCommands(key id, string commands)
{
if (kSource == nullkey && (sPendingId == id) && (sPendingTime + PERMISSION_DIALOG_TIMEOUT > llGetUnixTime()) && llGetFreeMemory() > 500)
{
debug("Gluing " + sPendingMessage + " with " + commands);
sPendingMessage = (sPendingMessage=nullstr) + sPendingMessage + "|" + commands;
return TRUE;
}
return FALSE;
}

// verifies the permission. This includes mode
// (off, permission, auto) of the relay and the
// identity of the object (owned by parcel people).
integer verifyPermission(key id, string name, string message)
{
debug("Verifying permission for command "+ message);

// extract the commands-part
list tokens = llParseString2List (message, [","], []);
if (llGetListLength (tokens) < 3 || nMode == 0 || ~llListFindList(WhiteBlack, ["-"+(string)llGetOwnerKey(id)]) || ~llListFindList(WhiteBlack, ["-"+(string)kController]) || (nMode == 3 && llGetOwnerKey(id) != ownerkey && !~llListFindList(secowners, [llGetOwnerKey(id)]) && !~llListFindList(WhiteBlack,[llGetOwnerKey(id)])))
{
kController = nullkey;
return FALSE;
}
string commands = llList2String(tokens, 2);
list list_of_commands = llParseString2List(commands, ["|"], []);

// accept harmless commands silently
if (isSimpleRequest(list_of_commands) || ~llListFindList(WhiteBlack, [llGetOwnerKey(id)]))
{
debug("simple command or Owner in Whitelist, executing.");
return TRUE;
}

// if we are already having a pending permission-dialog request for THIS object,
// just add the new commands at the end of the pending command list.
if (tryToGluePendingCommands(id, commands))
{
debug("Appending to store of commands pending approval.");
return FALSE; //== Glue the commands and process them later
}

// check whether this object belongs here
integer trustworthy = isObjectIdentityTrustworthy(id);
string warning = nullstr;
if (!trustworthy)
{
warning = "\n\nWARNING: This object is not owned by the people owning this parcel. Unless you know the owner, you should deny this request.";
}

// ask in permission-request-mode and/OR in case the object identity is suspisous.
if ((nMode == 1 || !trustworthy))
{
sPendingId=id;
sPendingName=name;
sPendingMessage=message;
sPendingTime = llGetUnixTime();

list opts = ["Yes", "No"];

llSetTimerEvent(2.0);

if(llKey2Name(llGetOwnerKey(id)) != nullstr)
{
name += " (owned by "+llKey2Name(llGetOwnerKey(id))+")";
opts += ["Never", "Always"];
}

if(llKey2Name(kController) != nullstr)
{
name = llKey2Name(kController) +", using "+ name +",";
opts += ["Never"];
}

llDialog (llGetOwner(), name + " would like control your viewer." + warning + "\n\nDo you accept ?", llList2List(opts,0,3), -1812220409);
debug("Asking for permission");
return FALSE;
}
return TRUE;
}

// ---------------------------------------------------
// Executing of commands
// ---------------------------------------------------

// execute a non-parsed message
// this command could be denied here for policy reasons, (if it were implemenetd)
// but this time there will be an acknowledgement
execute(string name, key id, string message)
{
stop = 0;

list tokens=llParseString2List (message, [","], []);
if (llGetListLength (tokens)==3) // this is a normal command
{
string cmd_id=llList2String (tokens, 0); // CheckAttach
key target=llList2Key (tokens, 1); // UUID
if (target==llGetOwner ()) // talking to me ?
{
list list_of_commands=llParseString2List (llList2String (tokens, 2), ["|"], []);
integer len=llGetListLength (list_of_commands);
integer i;
string command;
string prefix;
for (i=0; i<len; ++i) // execute every command one by one
{
if(stop) return;

// a command is a RL command if it starts with '@' or a metacommand if it starts with '!'
command=llList2String (list_of_commands, i);
prefix=llGetSubString (command, 0, 0);

if(command == "@clear")
{
releaseRestrictions();
ack(cmd_id, id, command, "ok");
}
else if (prefix=="@") // this is a RL command
{
executeRLVCommand(cmd_id, id, command);
}
else if (prefix=="!") // this is a metacommand, aimed at the relay itself
{
executeMetaCommand(cmd_id, id, command);
}
}
}
}
}

// executes a command for the restrained life viewer
// with some additinal magic like book keeping
executeRLVCommand(string cmd_id, string id, string command)
{
// we need to know whether whether is a rule or a simple command
list tokens_command=llParseString2List (command, ["="], []);
string behav=llList2String (tokens_command, 0); // @getattach:skull
string param=llList2String (tokens_command, 1); // 2222
integer ind=llListFindList (lRestrictions, [behav]);

debug("behav = "+ behav +"; param=" + param);

//== Stop the public chat exploits, and disregard commands issued with no variable (clear is handled elsewhere)
if(param == nullstr || (~llSubStringIndex(behav, "@get") || ~llSubStringIndex(behav, "@findfolder") || ~llSubStringIndex(behav, "@version")) && ((integer)param <= 0))
{
ack(cmd_id, id, command, "ko");
return;
}
if (param=="n" || param=="add") // add to lRestrictions
{
if (ind<0)
{
if(~llSubStringIndex(behav, ":") && llGetFreeMemory() <= 1024)
{
llOwnerSay("Relay is running dangerously low on memory; some restrictions will not be processed.");
}
else
lRestrictions = (lRestrictions=[]) + lRestrictions + [behav];

if(~llSubStringIndex(ownerexcept,behav)) //== Handle owner exceptions
{
//== Trim off the _sec part so exceptions can be passed
if(~llSubStringIndex(behav, "_sec"))
behav = llGetSubString(behav, 0, -5);

if(ownerkey != nullkey)
llOwnerSay("@"+behav+":"+(string)ownerkey+"=add");
if(secaccess || ownerkey == nullkey)
{
integer i;
for(i = 0; i < llGetListLength(secowners); i++)
llOwnerSay("@"+behav+":"+llList2String(secowners,i)+"=add");
}
}
}

if(kSource == nullkey)
{
llSetTimerEvent(2.0);
if(!lockstatus)
llOwnerSay("@detach=n");
}

kSource=id; // we know that kSource is either nullkey or id already
}
else if (param=="y" || param=="rem") // remove from lRestrictions
{
if (ind>-1)
lRestrictions=llDeleteSubList ((lRestrictions=[]) + lRestrictions, ind, ind);

//== Unlisted Owner Exceptions are NEVER removed, for safety
//== Nor is the public chat exploit fixer

//== NOTE TO SELF: Find a memory-efficient way to add this protection for secowners
else if(~llSubStringIndex(behav, ownerkey) || behav == "@a-relay")
{
ack(cmd_id, id, command, "ko");
return;
}

if (llGetListLength (lRestrictions) == 0 && !lockstatus)
llOwnerSay("@detach=y");

}

rememberForceSit(command);
if(llGetListLength(lRestrictions) == 1)
llOwnerSay("@a-relay=n");
llOwnerSay(command); // execute command
ack(cmd_id, id, command, "ok"); // acknowledge
}

// remembers the time and object if this command is a force sit
//== Changed to work a little differently
rememberForceSit(string command)
{
command = llStringTrim(command, STRING_TRIM);
string param = llGetSubString(command, -6, -1);

if (param != "=force")
{
//== If we're seated on the kSource and it's restricting us, it's probably the sit target
if(lastForceSitDestination == nullkey && (command == "@unsit=n" || command == "@unsit=add") && llGetAgentInfo(llGetOwner()) & AGENT_SITTING)
lastForceSitDestination = kSource;

return;
}

string behav = llGetSubString(command, 0, 4);
param = llGetSubString(command, 5, 40);

debug("'force'-command:" + behav + "/" + param);

//== If this somehow isn't a sit command (or there's no valid target) then return
if(behav != "@sit:" || llStringLength(param) != 36)
return;

lastForceSitDestination = (key) param;
lastForceSitTime = llGetUnixTime();
debug("remembered force sit");
}

// executes a meta command which is handled by the relay itself
executeMetaCommand(string cmd_id, string id, string command)
{
if (command=="!version") // checking relay version
{
ack(cmd_id, id, command, (string)RLVRS_PROTOCOL_VERSION);
}
else if (command == "!implversion") // checking relay version
{
ack(cmd_id, id, command, RLVRS_IMPL_VERSION);
}
else if (command=="!release") // release all the restrictions (end session)
{
ack(cmd_id, id, command, "ok");
kSource = nullkey; //== So only one release message is sent
releaseRestrictions();
}

//== Depreciated but still supported here because it's easy
if (llGetSubString(command,0,4) == "!who/")
{
kController = (key)llGetSubString(command, 5, -1);
}
if (llGetSubString(command,0,9) == "!handover/")
{
list tokens = llParseString2List(command, ["/"], []);
if(!llList2Integer(tokens, 2))
releaseRestrictions();
kSource = llList2Key(tokens,1);
pingWorldObjectIfUnderRestrictions();
}
}

// lift all the restrictions (called by !release and by turning the relay off)
releaseRestrictions ()
{
ack("Relay Release Notification", kSource, "!release", "ok");

kSource=nullkey;
if(!lockstatus)
llOwnerSay("@detach=y");

//== Do this in reverse order because 1) it saves memory, and 2) the spec says so
integer len;
for (len = (llGetListLength(lRestrictions) - 1); len >= 0; len--)
{
llOwnerSay(llList2String (lRestrictions, len)+"=y");

if(~llSubStringIndex(ownerexcept,llList2String(lRestrictions,len)))
llOwnerSay("@clear="+llGetSubString(llList2String(lRestrictions, len),1,-1));
}
lRestrictions = [];

loginPendingForceSit = FALSE;
lastForceSitDestination = nullkey;
loginWaitingForPong = FALSE;
llSetTimerEvent(0.0);
ack("Relay Release Notification", sPendingId, "!release", "ok");

llMessageLinked(LINK_SET, 356, nullstr, nullkey);

if(kController != nullkey && sPendingId != nullkey)
llDialog(kController, llKey2Name(llGetOwner()) +" has not accepted your attempt to control their viewer via " + sPendingName +".", [], 99);

sPendingId = nullkey;
sPendingName = nullstr;
sPendingMessage = nullstr;
kController = nullkey;
}

// ---------------------------------------------------
// initialisation and login handling
// ---------------------------------------------------

init() {
debug("RLV Plugin Free Memory at "+ (string)llGetFreeMemory());
nMode=1;
kSource=nullkey;
lRestrictions=[];
sPendingId=nullkey;
sPendingName=nullstr;
sPendingMessage=nullstr;
llListen (-1812221819, nullstr, nullstr, nullstr);
llListen (-1812220409, nullstr, llGetOwner(), nullstr);
llOwnerSay (getModeDescription());
}

// sends the known restrictions (again) to the RL-viewer
// (call this functions on login)
reinforceKnownRestrictions()
{
integer i;
integer len=llGetListLength(lRestrictions);
string restr;

if(len > 0)
{
llOwnerSay("@a-relay=n");
llOwnerSay("@detach=n");
}

debug("kSource=" + (string) kSource);
for (i=0; i<len; ++i)
{
restr=llList2String(lRestrictions, i);
debug("restr=" + restr);
llOwnerSay(restr+"=n");
if (restr=="@unsit" && lastForceSitDestination != nullkey)
{
loginPendingForceSit = TRUE;
}
}
}

// send a ping request and start a timer
pingWorldObjectIfUnderRestrictions()
{
loginWaitingForPong = FALSE;
if (kSource != nullkey)
{
ack("ping", kSource, "ping", "ping");
timerTickCounter = 0;
llSetTimerEvent(1.0);
loginWaitingForPong = TRUE;
}
}

// Handle commands
HandleCommand(string message, key id)
{
list templist = llParseString2List(llToLower(message), [" "], []);
string cmd = llList2String(templist, 0);

if(cmd == "relay" && (id == ownerkey || (llListFindList(secowners, [id]) > -1 && (ownerkey == nullkey || secaccess)) || (id == llGetOwner() && (setby == nullkey || setby == llGetOwner() || (setby != ownerkey && llListFindList(secowners, [setby]) <= -1)))))
{
integer change = 0;

string second = llList2String(templist, 1);
string third = llList2String(templist, 2);

if(kSource != nullkey && id == llGetOwner())
{
llOwnerSay("You cannot change relay modes while the relay is locked.");
return;
}

if(id == ownerkey && (second == "secondaries" || second == "sec"))
{
if(third == "on" || third == "auto" || (third == nullstr && !secaccess))
{
secaccess = 1;
llWhisper(0, "Secondary owners can now adjust Restrained Life Relay settings.");
}
else
{
secaccess = 0;
llWhisper(0, "Secondary owners cannot adjust Restrained Life Relay settings.");
}
}

else if((secaccess || id == ownerkey || (id == llGetOwner() && kSource == nullkey)) && second == "ping")
{
if(third == "off" || (third == nullstr && !noping))
{
noping = 1;
llWhisper(0,"Restrained Life Relay no longer requires regular object communication. CAUTION: Relay will NOT detect if the control object has crashed or been removed, and in that instance will continue to enforce the last known restrictions until the wearer logs off.");
}
else
{
noping = 0;
llWhisper(0,"Restrained Life Relay now requires regular object communication.");
}
}

if(second == "on" || second == "auto")
{
nMode = 2;
change = 1;
}
if(second == "off")
{
nMode = 0;
change = 1;
}
if(second == "ask")
{
nMode = 1;
change = 1;
}
if(second == "owner" || second == "wl")
{
nMode = 3;
change = 1;
}

if(second == nullstr || second == "mode")
{
nMode++;
if(nMode > 3) nMode = 0;
change = 1;
}

if(second == "wbclear")
{
WhiteBlack = [];
llWhisper(0,"Relay Whitelist and Blacklist cleared.");
}

if(change)
{
setby = nullkey;
if (nMode == 0)
{
llSetTimerEvent(0.0);
releaseRestrictions();
setby = nullkey;
}
else
{
llSetTimerEvent((float)PING_INTERVAL);
if(nMode >= 2) setby = id;
}
if(id == llGetOwner())
llOwnerSay(getModeDescription());
else
llSay(0, getModeDescription());

llMessageLinked(LINK_THIS, 63, nullstr, nullstr);
}
}
else if(cmd == "relay" && id == llGetOwner())
{
llOwnerSay("Sorry, only your owner can deactivate the relay once they enable it.");
}
}

default
{
state_entry()
{
// Request owner list from the collar
llMessageLinked(LINK_THIS, 47, nullstr, nullstr);
// Reset the plugin list
llMessageLinked(LINK_THIS, 62, nullstr, nullstr);
init();
}

// Handle messages from the collar script
link_message(integer sender, integer num, string str, key id)
{
if(num == 47)
{
list templist = llParseString2List(str, [","], []);
integer x;
integer count = llGetListLength(templist);

// Handle owner list reply
ownerkey = id;
secowners = [];
for(x=0;x<count;x++)
{
secowners = secowners + [ (key)llList2String(templist, x) ];
}
}
// Prefixless commands
else if(num == 48 || num == 828)
{
if(llSubStringIndex(id,"|") != -1) //== Strip out the combo info from the 828 reply
id = (key)(llGetSubString(id,0,35));
// Handle Commands on the public or alternate channel
HandleCommand(str, id);
}
else if(num == 33 && id != nullkey)
{
// Collar script is giving us an owner
ownerkey = id;
}
else if(num == 34 && id != nullkey)
{
// Collar script is giving us a secondary owner
secowners = secowners + [ id ];
}
else if(num == 35)
{
// Collar script is clearing owners
ownerkey = nullkey;
secowners = [];
}
else if(num == 36)
{
// Collar script is clearing secondary owners
secowners = [];
}
// Handle plugin update
else if(num == 62)
{
string buttons = "Relay Mode";

if(str == nullstr && (id == nullstr || id == nullkey))
{
// Add for owner and owners (key)
llMessageLinked(LINK_SET, 62, "Relay Sec", buttons);
// Add for sub and unowned sub (key)
llMessageLinked(LINK_SET, 63, buttons, nullstr);
}
}
else if(num == 65)
{
lockstatus = (integer)str;
}
else if(num == 66) //== Safeword, unlock
{
releaseRestrictions();
setby = nullkey;
nMode = 0;
llOwnerSay(getModeDescription());
}
else if(num == 355)
reinforceKnownRestrictions();
}

attach(key id)
{
if(id == nullkey)
llOwnerSay("@clear");
}

on_rez(integer start_param)
{
// relogging, we must refresh the viewer and ping the object if any
// if mode is not OFF, fire all the stored restrictions
if (nMode)
{
reinforceKnownRestrictions();
pingWorldObjectIfUnderRestrictions();
}
// remind the current mode to the user
llOwnerSay(getModeDescription());
}

timer()
{
timerTickCounter++;

debug("timer (" + (string) timerTickCounter + "): waiting for pong: " + (string) loginWaitingForPong + " pendingForceSit: " + (string) loginPendingForceSit);
if (loginWaitingForPong && (timerTickCounter >= LOGIN_DELAY_WAIT_FOR_PONG))
{
llWhisper(0, "Lucky Day: " + llKey2Name(llGetOwner()) + " is freed because the device is not available or is not responding to pings.");
loginWaitingForPong = FALSE;
loginPendingForceSit = FALSE;
releaseRestrictions();
}

if (loginPendingForceSit)
{
integer agentInfo = llGetAgentInfo(llGetOwner());
if (agentInfo & AGENT_SITTING)
{
loginPendingForceSit = FALSE;
debug("is sitting now");
}
else if (timerTickCounter >= PING_INTERVAL) //== Force Sit check
{
llWhisper(0, "Lucky Day: " + llKey2Name(llGetOwner()) + " is freed because sitting down again was not possible.");
loginPendingForceSit = FALSE;
releaseRestrictions();
}
else if(!loginWaitingForPong)
{
llOwnerSay ("@sittp=y,sit:"+(string)lastForceSitDestination+"=force");
}
}

if(sPendingId != nullkey && sPendingTime + PERMISSION_DIALOG_TIMEOUT <= llGetUnixTime())
{
llDialog(llGetOwner(),"Request to control your viewer by "+ sPendingName +" automatically denied due to timeout.", ["OK"], -1812220409);
sPendingId = nullkey;
sPendingName = nullstr;
sPendingMessage = nullstr;
}

if(timerTickCounter == 0 && !noping)
pingWorldObjectIfUnderRestrictions();

if (!loginPendingForceSit && !loginWaitingForPong && sPendingId == nullkey)
{
timerTickCounter = -1;
if(!noping)
{
llSetTimerEvent((float)PING_INTERVAL);
return;
}
llSetTimerEvent(0.0);
}
}

listen(integer channel, string name, key id, string message)
{
if (channel==-1812221819)
{
debug("LISTEN: " + message);

//=== ALWAYS accept a lone "!release" command, no matter the distance
list tokens = llCSV2List(message);
if (!(llGetListLength(tokens) == 3 && llList2String(tokens, 1) == llGetOwner()) || (!isObjectNear(id) && llGetSubString(message, -9, -1) != ",!release"))
{
return;
}
tokens = [];

if (nMode== 0)
{
debug("deactivated - ignoring commands");
return; // mode is 0 (off) => reject
}

debug("Got message (active world object " + (string) kSource + "): name=" + name+ "; id=" + (string) id + "; message=" + message);

if (kSource != nullkey && kSource != id)
{
debug("already used by another object => reject");
return;
}

if(!loginPendingForceSit && sPendingId == nullkey)
{
llSetTimerEvent(0.0);
llSetTimerEvent((float)PING_INTERVAL);
}

loginWaitingForPong = FALSE; // whatever the message, it is for me => it satisfies the ping request
// timerTickCounter = -1;

if (!isObjectKnow(id))
if(!verifyPermission(id, name, message))
return;

debug("Executing: " + (string) kSource);
execute(name, id, message);
}
else if (channel==-1812220409 && id == llGetOwner())
{
if (sPendingId!=nullkey)
{
if (message=="Yes" || message == "Always") // pending request authorized => process it
{
//== Process Whitelist entry
if(message == "Always") WhiteBlack += [llGetOwnerKey(sPendingId)];
debug("Got approval of restrictions from wearer");
execute(sPendingName, sPendingId, sPendingMessage);
}
else if(kSource == sPendingId)
releaseRestrictions();

//== Process Blacklist entry
if(kController == nullkey) kController = llGetOwnerKey(sPendingId);
if(message == "Never") WhiteBlack += ["-"+(string)llGetOwnerKey(kController)];

// clear pending request
sPendingName=nullstr;
sPendingId=nullkey;
sPendingMessage=nullstr;
}
}
}

changed(integer change)
{
if (change & CHANGED_OWNER)
{
llResetScript();
}
}
}

</lsl>

[[Category:RestrainedLove|{{SUBPAGENAME}}]]

LSL Protocol/Restrained Love Relay/Specification

2012-07-29T08:23:27Z

Uzume Grigorovich: cleanup

{{Restrained Love Relay Specs TOC}}

'''VERSION 1.100'''

Written and maintained by {{User|Marine Kelley}}.

==Audience==

This document is meant for people who want to create or modify '''in-world objects''' to use the features of someone else's [http://realrestraint.blogspot.com RestrainedLove viewer], typically '''cages''' and '''pieces of furniture''', which per definition are usually not owned by that person.

==Introduction==

The [http://realrestraint.blogspot.com RestrainedLove viewer] only executes commands issued through [[llOwnerSay]] () messages. Therefore, in order to issue commands to someone using the viewer who does not own the object, that person must wear an attachment that '''relays''' commands after some '''security checks'''.

==Why this spec ?==

Many cages and furniture creators are interested in using its features such as sit, outfit, tp etc. These objects can be found in public places, or owned by friends... but as they are usually not owned by the user, the relay has to implement some basic security in order to avoid [[griefing]]. On top of it, the user does not want to be forced to switch to another relay when going to the next piece of furniture.

This is the purpose of this specification: To lay common rules so all the relays implementing it are compatible with all the furniture implementing it too. Without such a specification, one cage/furniture would talk to the relay specifically made to operate with it and that's all, eventually making the creator stay behind because people rather use standard objects than proprietary closed ones.

==Basic principle==

Here is a sample use case:

# User is wearing a Relay
# User enters a cage in a public area
# Cage sends a chat message on a known private channel (for instance "@tploc=n")
# Relay receives the message, decides to repeat the command to the user and blocks their ability to teleport from the map with an [[llOwnerSay]] ("@tploc=n");
# User is allowed to get out after some time, the cage issues a "!release" command

Without the relay, the cage could never prevent the user from teleporting since it doesn't belong to them.

==Requirements==

Here are the informal requirements for a relay (formal requirements below).

===Security===
Any object sending commands over the channel the relay listens to is likely to harm the user if there is no security implemented in the former. For instance, one could [[rez]] an object that sends a "@remoutfit=force" command over the chat channel to force an avatar to get naked in front of everyone without a warning. Of course nobody wants that, so basic security is needed.

===User-friendliness===
Security often implies control (access lists, switch, permissions...) so the user must be given some basic control over what kind of objects are allowed to issue commands.

===Versatility===
Some users will prefer wearing a dedicated attachment that they can unwear any time they want, others will be required to have the relay locked on them so they cannot detach them, others will want the script only... It is important to keep those differences in mind when deciding about the permissions of the relay. However, it is the user's responsibility to choose the relay that suits their needs best.

===Licensing===
According to the level of complexity and support of the relay, the creator is allowed to either provide it for free (open/close source) or to sell it, as long as it implements all the formal requirements.

==Common questions==

===How hard is it to implement such a specification?===
That depends on what you do. Furniture/cage makers will find it very easy for it only comes down to sending commands over a chat channel and getting feedback. Relay makers will find it harder but then again, that depends on the level of security and user-friendliness they wish to offer. But make no mistake, the relay is what does almost all the job (along with the viewer), because there will be many more kinds of furniture and cages than relays around.

===Why do other people need to write such a relay?===
Couldn't you write it yourself and publish it?

Of course I could, and there is even a working code for a basic relay at [[LSL Protocol/Restrained Love Relay/Reference Implementation|Reference Implementation]]. However:
* The protocol is likely to improve because nobody sees the future
* One object only would not suit everyone's needs
* It would have to implement perfect security and perfect user-friendliness, in all cases
* It would of course have to be perfectly scripted, without any bug whatsoever

The security and user-friendliness are the key parts here. Some users will prefer to be safe from [[griefing]], others will prefer a good user interface, others will like a lot of features, others will want to move the script elsewhere... Everyone has their own tastes so there can be no one-size-fits-all relay.

==Protocol==

In-world objects send chat message over a channel (common to every relay and furniture), that the relay(s) acknowledges or not. If the message is a correct command and passes whatever security checks the relay implements, the latter repeats it as an [[llOwnerSay]] ().

When the session ends, possibly after several relogs, the object clears all the restrictions it has put the user under.

===Example===

Here is a basic example of messages exchanged between an avatar (id "9213...") and a world object (id "7adf...") :

Object : CmdTest,9213f69a-ed7d-4a70-907a-7dba88c8831a,@tploc=n
Relay executes llOwnerSay ("@tploc=n");
Relay : CmdTest,7adf6218-ab26-8566-8387-660133840794,@tploc=n,ok

Object : BunchoCommands,9213f69a-ed7d-4a70-907a-7dba88c8831a,@tploc=n|@tplm=n|@tplure=n|@remoutfit:shoes=force
Relay executes llOwnerSay ("@tploc=n");
Relay executes llOwnerSay ("@tplm=n");
Relay executes llOwnerSay ("@tplure=n");
Relay : BunchoCommands,7adf6218-ab26-8566-8387-660133840794,@tploc=n,ok
Relay : BunchoCommands,7adf6218-ab26-8566-8387-660133840794,@tplm=n,ok
Relay : BunchoCommands,7adf6218-ab26-8566-8387-660133840794,@tplure=n,ok
Relay : BunchoCommands,7adf6218-ab26-8566-8387-660133840794,@remoutfit:shoes=force,ok

After a relog :
Relay : ping,7adf6218-ab26-8566-8387-660133840794,ping,ping
Object : ping,9213f69a-ed7d-4a70-907a-7dba88c8831a,!pong (UUID found with llGetOwnerKey(id), where id is the sender-parameter of the listen-event)

==Formal requirements==

===Common requirements to the Relay and the in-world object===

* The chat channel used by both the Relay and the in-world object is '''-1812221819'''. That's "RLVRS" ("RestrainedLove Viewer Relay Script") translated from alphabet to numbers.

* Messages on the channel are described here in a pseudo [http://en.wikipedia.org/wiki/Backus-Naur_form Backus-Naur Form] :

** '''''Messages from in-world object to Relay (3 tokens) :'''''
*** ''message'' ::= <cmd_name>''','''<user_uuid>''','''<list_of_commands>
*** ''list_of_commands'' ::= <command>['''|'''<list_of_commands>] (list_of_commands is *lowercase*)
*** ''command'' ::= <rl_command> or <meta-command>
*** ''rl_command'' ::= '''@'''behav[''':'''option]['''='''param]
*** ''meta-command'' ::= '''!version''' or '''!release''' or '''!pong''' or '''!implversion''' or '''!handover/'''<hand-over parameter> or '''!who/'''<who parameter>

** '''''Messages from Relay to in-world object (4 tokens) :'''''
*** ''message'' ::= <cmd_name>''','''<object_uuid>''','''<command>''','''<reply> (cmd_name is equal to the one in the incoming message)
*** ''reply'' ::= '''ok''' or '''ko''' or '''ping''' or <protocol_version> or <implementation_version>
*** ''protocol_version'' ::= integer (it is the version of the ''specification'', not of the script)

* The effect of the "!release" meta-command is to wipe out all the restrictions issued by the object which sends it.
* The effect of the "!version" meta-command is to send the version of the protocol the Relay implements. See below.
* The effect of the "ping" message from the Relay to the object is to check the latter is still available. If not, release the user to avoid having orphaned rules.
* Notice that acknowledgments do not apply to the list of commands but to one command only. Therefore a list of N commands gives N acknowledgment messages in return (at most).

'''In plain English :'''
* <cmd_name> is the name of the command, decided by the object. It will be used to find out which command has been acknowledged, therefore it must be repeated '''exactly''' by the Relay (without changing its case). An exception to the freedom of choice of the <cmd_name> token is the "ping" reserved name, see below.
* <user_uuid> is the [[UUID]] of the '''avatar''' owning the Relay.
* <object_uuid> is the [[UUID]] of the '''in-world object'''. Notice that we never need the [[UUID]] of the Relay as it's usually an attachment, prone to change its id after each relog.
* <list_of_commands> is a list of RL commands separated by pipes ('|'). It can be a single command (meaning no pipe present).
* <command> is either a regular RL command (@behav:option=param) or a meta-command, aimed at the Relay itself (!version, !release and !pong)
* Commands are separated by pipes ('|') here, but if they must be sent in the same [[llOwnerSay]] to the viewer they must be separated by commas (',') and with only one ''''@'''' sign at the beginning of the whole message. This is on purpose, to force the Relay to parse them and check them one by one, as well as facilitate the parsing of the whole message coming from the in-world object.
* Everyone listening on the relay channel must have enough script memory available to handle a complete chat message which is limited to 1,000 character (2,000 bytes + processing).

===="!release" meta-command====
* This meta-command is meant to make the Relay clear all the restrictions linked to the object issuing it. It is better to use it than to issue "counter-commands" to lift every restriction one by one without forgetting any.
* If the relay cancels an active session (for example because of a safe-word being called), it has to send a !release,ok message.

===="!version" meta-command====
* When receiving this meta-command, the Relay must send a special acknowledgment that contains the version of the ''protocol'' it implements, on '''4 digits'''. This number must be an integer, equal to the version of this specification, written just after the title on this very page, times 1000. For instance, "1.120" would translate to "1120". It makes it easier to compare versions without fear of losing information with a float cast to a string and back to a float.
* Do not mistake the version of the ''protocol'' with the version (@version) of the ''viewer'' or the version of the ''scripts'' (!implversion).

===="ping" relay message and "!pong" object meta-command====
* When logging on, the relay will reapply all the stored restrictions but it only makes sense if the in-world object is still around and available for use. It could have been reset, crashed, or used by someone else while the primary user was offline. To let the relay apply the restrictions would therefore make no sense. That's why the relay has to ask the object if it's still around and available, and if no appropriate answer is received in a timely fashion then it must lift all the restrictions issued by it before, in order to start fresh again. Notice that "ping" is a simple word (to stay consistent with "ok" and "ko") while "!pong" is a meta-command.

The relay message must be "ping,<object_uuid>,ping,ping" and the object message must be "ping,<user_uuid>,!pong". This allows the object to keep a listener open with a static filter, to reduce lag. <user_uuid> can be retrieved by a [[llGetOwnerKey]]() call.

===Other meta-commands===
The following meta-commands are deemed "optional" and relays do not have to implement them to be considered RLV compliant. They are mostly tied to the specific implementation of a particular relay that a particular furniture needs to interrogate. Furniture must not rely on the implementation of any of these commands to work.

====="!implversion" meta-command=====
* The relay ''implementation'' should identify itself with a string.
* The is just like !version with the exception that !implversion is not about the ''protocol'' but about the implementation of it and may contain a string
* This version string is not intended for automatic checks but to help debugging problems
* Think of this as the signature of that particular relay
* The string must not contain any "," or "!" characters

===Deprecated meta-commands===
The following meta-commands used to belong to the specification without much discussion and without permission. They are mentioned here for reference but never meant to be part of the specification. They might be reinstated one day if they prove themselves useful, but at the time of this writing it would make no sense to consider a relay to be out of spec if it didn't implement those meta-commands.

====="!who" meta-command=====
* Syntax: !who/<UUID>
* This is an information message from the world telling the relay which avatar is controlling it.
* Traps that are automatically triggered by the victim should use the UUID of the victim instead of the person who has setup the trap, perhaps hours ago
* 00000000-0000-0000-0000-000000000000 (NULL_KEY) is valid, meaning an unknown avatar
* Note: The content of this message is obviously only as trustworthy as the world object is
''Note from Marine : This meta-command may be designed to check the avatar operating the object to make griefing harder... but if this command is only as trustworthy as the object is, I don't see that as an improvement security-wise. Otherwise the idea has merit.''

====="!handover" meta-command=====
* Syntax: !handover/<key>/<type>
* Allows one world object to tell the relay it should accept commands from another world object instead without asking for permissions again. (For example a kidnapper object may do a force tpto to another sim where an other world object is waiting for the victim.
** (key) is the id of the target object
** (type) : 0 lift all restrictions of the source object, 1 keep them, it is the responsibility of the target object to keep them in mind
* The relay must ignore further "/"-parameters for future extension of the command.
* The relay must ignore any following commands on the same chat line
* The source object should send !handover/(key)/(type)|!release, so that relays that don't support !handover will release the restrictions and the next object can start normally.
* The relay must ensure with the !ping mechanism that the target object is available.
* The target object, however, might not be able to see the ping: For example because of a slow intersim teleport. In this case the target object must send a !pong on arrival of the victim anyway.
''Note from Marine : This meta-command is particularly interesting, and is likely to go to the Other Meta-commands section in the future, or even in the main spec. It needs to be designed thoroughly first, though. I don't think it needs to be so complex, but it sure needs some checking.''

===Relay requirements===
* Send the exact @behav:option=param part in an [[llOwnerSay]] ()
* Retain a list of restrictions and their sources for when the user relogs.
* Force sit if unsit is prevented when relogging.
* When relogging, send a "ping" message (see above) to check the in-world object is still available. If no message after a few seconds (not necessarily a "!pong", any message aimed at the relay can do), release the rules linked to this object.
* The user must have access to the version of the specification and the version of the implementation (dialog, message, object name...) to check everything works correctly.
* The relay must silently ignore commands to remove non-existing restrictions without spamming the user with pointless "ask for permission dialogs"
* Relays must accept !release even if the world object is out of range.
* Relays must send a !release,ok if they cancel an active session (for example because of an safe-word)
* Relays must ensure that it preserves the order of commands. For example: If a restriction is queued in the Ask-dialog, the lifting of the restriction must not be executed immediately unless the pending restriction in the ask-dialog-queue is removed, too.

===In-world object requirements===
* If a world object sent any restrictions, it must end the session with !release even if the relay did not respond with "ok" unless all commands have been "ko"-ed. The relay may have delayed the execution to ask permission from the user who may confirm them after the session has already ended
* When receiving a "ping" message from a relay, reply with a "!pong" message (as described above) aimed at the avatar owning it, provided they are still restricted by the object.
* Never rely on an answer from the Relay, requests can be denied silently, the Relay can be unworn, the avatar can TP out or crash... => use timeouts.
* Don't poll the [[dataserver]] for online status, the Relay takes care of the relog part.
* World objects should not spam the relay channel. For example: Querying every minute the relay version of every person near although nobody shows any signs to actually use the object.

== History ==

You can find the change history of this specification at [[LSL Protocol/Restrained Love Relay/Change History|Change History]],

Template:Restrained Love Open Relay Group TOC

2012-07-29T08:17:05Z

Uzume Grigorovich: cat sort

<div class="floatright"><div class="navbox" style="width:20em; font-weight:bold">
<div style="text-align:center">Restrained Love<br/>Open Relay Group<br/>x-tensions</div>
*[[LSL Protocol/Restrained Love Open Relay Group|ORG Home]]
*[[LSL Protocol/Restrained Love Open Relay Group/ORG Logo|Logo]]
*[[LSL Protocol/Restrained Love Open Relay Group/ORG Introduction|ORG Introduction]]
*[[LSL Protocol/Restrained Love Open Relay Group/ORG Requirements|ORG Requirements]]
*[[LSL Protocol/Restrained Love Open Relay Group/Prefix|ORG Prefix]]
*[[LSL Protocol/Restrained Love Open Relay Group/x-tensions|x-tensions, full list]]
*[[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|x-tensions, validation process]]
</div></div>
{{Restrained Love Relay Specs TOC<noinclude>|cat={{FULLPAGENAME}}</noinclude>}}

Template:Restrained Love Open Relay Group TOC

2012-07-29T08:14:29Z

Uzume Grigorovich: cat sort

Template:Restrained Love Relay Specs TOC

2012-07-29T08:13:08Z

Uzume Grigorovich: typo

<div class="floatright"><div class="navbox" style="width: 20em">
<center>'''Restrained Love Relay'''</center>
* '''[[LSL Protocol/Restrained Love Relay/Introduction|Introduction]]'''
* '''[[LSL Protocol/Restrained Love Relay/Specification|Specification]]'''
* '''[[LSL Protocol/Restrained Love Relay/Change History|Change History]]'''
* '''[[LSL Protocol/Restrained Love Relay/Reference Implementation|Reference Implementation]]'''
* '''[[LSL Protocol/Restrained Love Relay/Development & Contribution|Development & Contribution]]'''
** [[LSL Protocol/Restrained Love Relay/Bugs and Pending Features|Bugs and Pending Features]]
** [[LSL Protocol/Restrained Love Relay/How to Test|How to Test]]
** [[LSL Protocol/Restrained Love Relay/Other Implementations|Other Implementations]]
</div></div>
[[Category:RestrainedLove<includeonly>|{{{cat|{{SUBPAGENAME}}}}}</includeonly>]]

LSL Protocol/Restrained Love Relay/Bugs and Pendings Features

2012-07-29T08:12:20Z

Uzume Grigorovich: moved LSL Protocol/Restrained Love Relay/Bugs and Pendings Features to LSL Protocol/Restrained Love Relay/Bugs and Pending Features: typo

#REDIRECT [[LSL Protocol/Restrained Love Relay/Bugs and Pending Features]]

LSL Protocol/Restrained Love Relay/Bugs and Pending Features

2012-07-29T08:12:20Z

Uzume Grigorovich: moved LSL Protocol/Restrained Love Relay/Bugs and Pendings Features to LSL Protocol/Restrained Love Relay/Bugs and Pending Features: typo

{{Restrained Life Relay Specs TOC}}

== Functions in discussion/development ==
* [[LSL Protocol/Restrained Life Relay/resetting environment settings|resetting environment settings]]
* [[LSL Protocol/Restrained Life Relay/pong handling contradiction|pong handling contradiction]]
* [[LSL Protocol/Restrained Life Relay/delay|delay]]
* [[LSL Protocol/Restrained Life Relay/gender|gender]]

== Discussion about new features in 1.040 ==

* [[LSL Protocol/Restrained Life Relay/vision|vision restriction]]
* [[LSL Protocol/Restrained Life Relay/handover|handover]]
* [[LSL Protocol/Restrained Life Relay/who|who]]
* [[LSL Protocol/Restrained Life Relay/editorial changes|editorial changes]]

== 1.040 ==
Maike Short single script version
; Description : In listen event for the permission dialog, message is always freed before being send to the process function => message is never handled and permission never given.
; Discovered by : herina Bode
; Fix : Replace call to processDialogResponse(id, message) by processDialogResponse(id, currentMessage);

== 1.030 ==

=== isObjectNear and non existing objects ===

; Description : If an objects does not exist (anymore) in the current sim and its neighbors, llGetObjectDetails returns <0, 0, 0> which means it is wrongly detected as being close if you are within 100m to that locations
; Discovered by : Kitty Barnett
; Fix : [https://wiki.secondlife.com/w/index.php?title=LSL_Protocol%2FRestrained_Life_Relay%2FOther_Implementations%2FMaike_Short%27s_Relay&diff=262273&oldid=255372 Maike's fix]

=== groupless objects are trusted on parcels not set to a group ===

; Description : On a parcel which is not set to a group, the not-owner warning is not displayed for groupless objects
; Discovered by : Kitty Barnett
; Fix : [https://wiki.secondlife.com/w/index.php?title=LSL_Protocol%2FRestrained_Life_Relay%2FOther_Implementations%2FMaike_Short%27s_Relay&diff=262273&oldid=255372 Maike's fix]

=== Fake Avatar Chat ===

; Description : 1. An object can remove the guarding prefix for chatting on channel using =y. 2. An object can use @getstatus=n or @getstatus=-1 (and in some cased @getstatus=some random text) to cause the agent to should on public chat. This does work for the other query commands as well.
; Discovered by : Marissa Mistwallow and Maike Short
; Affected relays : I did some quick tests on a number of different relays and so far all have been vulnerable (including my own one) to one or both of theses attacks.
; Fix : [https://wiki.secondlife.com/w/index.php?title=LSL_Protocol%2FRestrained_Life_Relay%2FOther_Implementations%2FMaike_Short%27s_Relay&diff=255362&oldid=253182 Maike's fix]

== 1.020 ==

Version 1.020 reintroduces all the problems listed in 1.014.

=== Foreign Channel Chat ===

; Discovered by : Maike Short
; Description : An object can force the agent to say any lower case text on any channel using @getstatus
; Note : Relays which do not add any restriction on their own (like @detach=n) may be abused using @gestatus to trigger dialog responses, gag talk or other scripts like "to buy as gift, say the name of the receiver on channel /''x''". Any version of the reference implementation smaller than (not including) 1.015 (but including 1.020 which is based on 1.014) are affected by this.
; Workaround : none
; Fixed : in [[LSL Protocol/Restrained Life Relay/Other Implementations/Maike Short's Relay|Maike Short's Relay]]
; Proposed fixed : Add "this-is-a-script-generated-message-beyond-the-control-of-the-agent/" at the beginning of @getstatus-replies on all channel by issuing this as the very first restriction. This still allows to trigger gags but it will include a human readable warning (if you speak Gagish well enough). The usual "to buy as gift, say the name of the receiver on channel /''x''" scripts will try to resolve this text as part of the name and will fail because such long avatar names are not allowed. Other scripts waiting for commands are very likely not to accept this text either. A more secure solution would be to define one single channel which must be used for such queries but that would break a lot of content.

:: It would probably be sufficient to "ko" @getstatus=x requests where x < 1000. Most gags or other scripts that expect human-typed channel numbers stick to < 1000, whereas most furniture looking for status use much larger channel numbers (mine use random channels, but with a minimum of 1000000, for example). --Julia Banshee
::: I agree that disallowing low channel numbers for all query types may be a good idea and I am not objecting a change of the spec although it has a low change of breaking content. (Well, since Marine is back, i can easily say this without having to think about all the time it will cost me to talk to affected people). I strongly suggest, however, to put something at the beginning of @getstatus replies anyway. Fixed high level channels with a filter to the owner are sometimes used for debugging. (Yes, I am having a concrete object in my mind). --[[User:Maike Short|Maike Short]] 11:03, 18 September 2008 (PDT)

:: This problem appears related to the Fake Avatar Chat above. This issue could be fixed with the RLV Viewer itself, by simply discarding invalid restrictions, preventing this from ocurring in the first place and improving the performance of every relay out there by removing unnecessary checks. --[[User:Da Chrome|Da Chrome]] 7 December 2011

=== Foreign Public Chat ===

; Discovered by : Maike Short
; Description : An object can force the agent to say any text in public chat using @getstatus=0 and use similar functions (like @version) to spam other text there.
; Note : This allows the same abuse mentioned in the above entry, too. But being public chat makes even non abusable cases very annoying.
; Workaround : none
; Fixed : in the Restraint Life Viewer version 1.12.4. For older viewers the relay should prevent it: [[LSL Protocol/Restrained Life Relay/Other Implementations/Maike Short's Relay|Maike Short's Relay]]
; Proposed fixed : The relay should filter all queries directed to answer on channel 0 for Restraint Life Viewer version 1.12.3 and lower. Add this at the end of the huge if / else if / else if block in executeRLVCommand
<lsl>
else if ((integer) param == 0) {
// this is either an unknown param (not "n", "add", "y", "rem", "force")
// or a query which should be answered on the public chat channel 0.
ack(cmd_id, id, command, "ko");
return;
}
</lsl>

=== Relay Crash in Ask mode ===

; Discovered by : Maike Short
; Description : A malicious objects scans for all avatars within the sensor range. For each avatar a new object is rezes out of the content. This objects sends 10 messages to the relay each of about 1000 characters causing sPendingMessage to overflow. After the 10 messages are send these objects die making tracking very difficult.
; Note : Some relays accept commands from objects more than <del>20</del>100 meters away so the attacking objects can be hidden far away.
; Workaround : None
; Open : although fixed in version 1.15 it was reintroduced by the revert in version 1.02

== 1.015 ==

The below problems are fixed [[LSL_Protocol/Restrained_Life_Relay/Other_Implementations/Maike_Short's_Relay|here]], except for the forced sit issue below.

== 1.014 ==

The following problems occured in version 1.014 and have been fixed:

=== Stuck: Accepting Permission Dialog after !release ===
; Discovered by : Maike Short
; Workaround : Don't accept requests after you have been freed. In case it happend, reenter the cage / sit down again; relog.
; Fixed : in 1.015

=== Force Sit during Login on the control object instead of the forced-sit one ===

; Discovered by : Azoth Amat
; Workaround : Always send a "@sit:<id>=force" command if you want a forced sit on relog, even if the victim is already sitting.
; Fix : change in <code>timer()</code>: <code>sendRLCmd ("@sit:"+(string)kSource+"=force");</code> to <code>sendRLCmd ("@sit:"+(string)lastForceSitDestination+"=force");</code>
; Note : This prevents @unsit to work in case the person set down without being forced if the furniture in question hasn't sent a @sit:<id>=force command. (This should probably be considered a bug in the furniture, not the relay.)
; Fixed : in 1.015 (but that fix breaks other things, forcing sits when not appropriate), and 1.02 (that fix always works, assuming the furniture is properly setting the @sit destination)

:: Sending a bogus force sit on sit as you suggested may not work if force-sits are filtered. As far as I know there is no way for an attachment to detect the object the avatar is sitting on. So the relay will not be able to tell real force-sits (which should be subjected to the filter) and bogus force-sits for this problem apart.
:: It could accept a force-sit on the control-object but this would allow to kidnap an agent sitting on an other object. Well, the same can happen with my approach of using the sending object as fall back. Could you give an example for a forced sit when not appropriate with my approach? This may reveal other aspects of the problem.
:: The specification says "Force sit if unsit is prevented when relogging" in "Relay requirements" so I think objects that just send @unsit=n without force-sit should not be called buggy. If it turns out the current approach does cause more problems than it fixes it may be worth to adjust the spec. But this will cause existing world object to break so should not be taken lightly. --[[User:Maike Short|Maike Short]] 12:55, 17 September 2008 (PDT)

=== Stuck on crash/relog with objects asking for relay upon being sat on ===

; Discovered by : Gregor Mougin
; Problem : Many objects check for presence of a relay and the RR viewer by asking for the !version when sat on. If the user crashes, and the object was used by someone else in the meantime (or, for testing, reset), the relay enforces all previous restrictions whereas the object doesn't know of them.
; Workaround : none
; Suggested fix :
<lsl>
--- RLV_v1.014a 2008-07-06 23:17:14.000000000 +0200
+++ RLV_v1.014a-xxx 2008-07-06 23:18:32.000000000 +0200
@@ -545,10 +545,16 @@
loginPendingForceSit = FALSE;
releaseRestrictions();
}
- else
- {
- sendRLCmd ("@sit:"+(string)kSource+"=force");
- }
+ // XXX
+ // DON'T do it here
+ // Some (many?) objects ask the relay for the !version upon
+ // sitting on it. Since the !version is interpreted the same
+ // as !pong, the relay would think the object is still available
+ // and put all restrictions on the wearer unconditionally.
+ //else
+ //{
+ // sendRLCmd ("@sit:"+(string)kSource+"=force");
+ //}
}

if (!loginPendingForceSit && !loginWaitingForPong)
@@ -583,6 +589,18 @@

loginWaitingForPong = FALSE; // whatever the message, it is for me => it satisfies the ping request

+ // XXX
+ // force sit here instead of unconditionally in the timer event
+ if (loginPendingForceSit)
+ {
+ integer agentInfo = llGetAgentInfo(llGetOwner());
+
+ loginPendingForceSit = FALSE;
+ if (!(agentInfo & AGENT_SITTING))
+ sendRLCmd ("@sit:"+(string)kSource+"=force");
+ }
+ // end XXX
+
if (!isObjectKnow(id))
{
debug("asking for permission because kSource is NULL_KEY");
</lsl>
; Fixed : in 1.015 by specially looking for the !pong reply so that the fix works for cages as well (no "force sit" in this situation but a collision detection which is triggered on login, too).

Template:Restrained Love Relay Specs TOC

2012-07-29T08:11:43Z

Uzume Grigorovich: cat sort

<div class="floatright"><div class="navbox" style="width: 20em">
<center>'''Restrained Love Relay'''</center>
* '''[[LSL Protocol/Restrained Love Relay/Introduction|Introduction]]'''
* '''[[LSL Protocol/Restrained Love Relay/Specification|Specification]]'''
* '''[[LSL Protocol/Restrained Love Relay/Change History|Change History]]'''
* '''[[LSL Protocol/Restrained Love Relay/Reference Implementation|Reference Implementation]]'''
* '''[[LSL Protocol/Restrained Love Relay/Development & Contribution|Development & Contribution]]'''
** [[LSL Protocol/Restrained Love Relay/Bugs and Pendings Features|Bugs and Pending Features]]
** [[LSL Protocol/Restrained Love Relay/How to Test|How to Test]]
** [[LSL Protocol/Restrained Love Relay/Other Implementations|Other Implementations]]
</div></div>
[[Category:RestrainedLove<includeonly>|{{{cat|{{SUBPAGENAME}}}}}</includeonly>]]

LSL Protocol/Restrained Love Open Relay Group/who/002 draft

2012-07-29T08:07:28Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

STATUS: Silver

VERSION: 002

Relay implementations: TK, Dahlia's, Satomi's, OpenCollar, Cool HUD(?) ...

Controller implementations: TK/dd, Dahlia, Witchy, and so on...

'''Commands:'''
* !x-who: secondary behavior

''(was previously !who, which is now deprecated)

'''Synopsis:'''
This x-tension makes it possible for the controller to tell the relay who is currently operating the device.

This is motivated by a legitimate question relay wearers ask themselves when they get the authorization dialog "Should I? Should I not? I know this device. It could be fine... if only I knew the one pressing the buttons was not some -BEEP-!".

Using the information provided by !x-who, now the relay can inform the wearer and tell them the name of the avatar pressing the buttons.

==Usage==
===Syntax===
!x-who/<key>
:: (key) is the UUID of the AV that you wish to present to the relay.

It is assumed that all commands following !x-who in the message are sent on behalf of that AV.

Commands in next messages are not affected by !x-who.

===Usage scenarios===
'''Use of !x-who in front of a bunch of commands to inform the relay:'''
C -> R: @detach=n|!x-who/<user_key>|@remoutfit=force
<- : @detach=n,ok
-- auth dialog, the wearer says they don't like the avatar with key <user_key> --
<- : !x-who/<user_key>,ko
<- : @remoutfit=force,ko
-> : @remoutfit:shoes=force
<- : @remoutfit:shoes=force,ok

As a result, the wearer's relay is locked, and the wearer is stripped only of their shoes.

C -> R: !x-who/<user_key_1>|@remoutfit=force
-- auth dialog, the wearer says they like the avatar with key <user_key_1> --
<- : !x-who/<user_key_1>,ok
<- : @remoutfit=force,ok
-> : !x-who/<user_key_2>|@detach:skull=force
-- auth dialog, the wearer says they don't like the avatar with key <user_key_2> --
<- : !x-who/<user_key_2>,ko
<- : @detach:skull=force,ko

As a result, the wearer's relay is locked, and the wearer is stripped of their clothes, but keeping their prim hair.

'''Alternatively, use of !x-who alone for its acknowledgement value:'''
C -> R: !x-who/<user_key>
-- auth dialog, the wearer says they don't like the avatar with key <user_key> --
<- : !x-who/<user_key>,ko;
After this ko, the controller knows not to send further commands on behalf of that user.

C <- R: !x-who/<user_key>
-- auth dialog, the wearer says they like the avatar with key <user_key> --
-> : !x-who/<user_key>,ok
After this ok, the controller knows it is fine to send commands on behalf of that user.

===Requirements===
* !x-who is always the first command in a RLVR message from the controller.
* The relay must remember the last key positively authenticated that was given in a !x-who. This way, if several subsequent messages use the same user key in !x-who, the ask dialog will appear for the first message only. Therefore the controller can safely put !x-who in front of every batch of commands.
* For the sake of simplicity of implementation, it is not expected (but allowed) that the relay remembers all users in the session.
*!x-who/clear tells the relay that following commands are not sent by a menu user and that it is not required for the relay to remember the user key anymore.
*!x-who/00000000-0000-0000-0000-000000000000 (NULL_KEY) is valid, meaning "some user", with no more info given.

===Caveat===
The content of this message is obviously only as trustworthy as the controller is. Hence when you accept a bunch of commands prefixed by a "!x-who", you have to trust not only the avatar whose key is in after the "!x-who" '''''and''''', but also the owner of the device issuing the command.

Fortunately this requirement can be met easily (i.e.: if the owner is also the land owner, or if you personally know her), which makes this meta-command useful nonetheless.

==Implementation ideas==
* The acknowledgement to a !x-who can be used by the controller to display some message and warn the user attempting to use its menus.
* The ask dialog in relays would ideally show the device name, its owner's name and that of the avatar using the device at the moment. Several actions can be proposed for accepting/rejecting the control attempt, with or without adding owner and/or controller to a white or black list.

LSL Protocol/Restrained Love Open Relay Group/email/006 draft

2012-07-29T08:06:09Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

= !x-email =
STATUS: draft

VERSION: 006

MANDATORY DEPENDENCIES: '''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]'''''

RECOMMENDED: '''''[[LSL Protocol/Restrained Love Open Relay Group/autoforward|autoforward]]''''', '''''[[LSL Protocol/Restrained Love Open Relay Group/sensor|sensor]]'''''

''005 implemented in Satomi's Multi-Relay HUD 0.93, and Satomi's Witchy Remote 1.1beta2''

''005 Implemented in Dahlia's multirelay >=0.39 and anythingRLV >=2.97''

==Presentation of e-mails==
The topic: ORG encapsulated RLVR protocol,<protocol version>, <session_key>

ex: ORG encapsulated RLVR protocol,006,45afb982-d02c-35e1-d492-a948b92c92f3
The session key is a secret shared by both relay and controlling device, and will be created during the protocol initiation using !x-key as defined in '''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]'''''.

==Example of initialization between a controller C and the relay R==

In the following exchange, the controller C and the relay R negotiates a secret UUID key which will be the key of the session. The exchange is done using llRegionSayTo() to keep the key secret (k(R) is the UUID key of the wearer of the relay and k(C) the UUID key of the controller).

1 C--RLVR--> R secret_key,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C<-RLVR--- R secret_key,k(C),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok

Then C can start an email session using !x-email as follows:

1 C--RLVR--> R blah,k(R),!x-email
2 C<-RLVR--- R blah,k(C),!x-email,ok

Without secret key, the answer for !x-email must be a "ko". There are no exceptions. Then the session can continue by email using the subject "ORG encapsulated RLVR protocol,006,a586c562-bf27-b7db-e36e-822d0a9ba02a".

1 -e> bleh,<anything>
2 <e- bleh,<anything>,<ack>
...

'''Remark'''

* The autoforward and sensor x-tensions are not required: a controller does not necessarily need to send @getxxx or @notify commands, or to scan for objects or avatars. The autoforward and the sensor x-tensions may be used also for a simwide control (i.e. a chat session with the controller and the relay distant of more than 100m).

==Ending the email session between a controller C and the relay R==

To end up an email session, the command !x-takeover is used (in 005, the command !x-channel was used but this command will be less useful in the future and probably deprecated because of llRegionSayTo()).

1 C--RLVR--> R back_to_chat,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C<-RLVR--- R back_to_chat,k(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok

Note that in the above exchange, the controller C is not necessarily the first controller; the above commands can also be interpreted as a kind of handover.

'''Remarks'''

* The commands using the secret session key must use llRegionSayTo(): !x-key and !x-takeover
* This behaviour of !x-takeover is already in the version 002 of the x-tension key.

==Testing controller's presence==

For garbage collection purposes, be it on relog, or on regular basis, R might want to check if C is still active. The ping mechanism can be used here.
<e- ping,ping,ping
-e> ping,!pong

The important thing is that the relay remembers it was an email session after relog.

C can check R's presence by sending any valid message, as acknowledgement by R is required for every RLVR message from C. If the only purpose of the message is presence verification, the following scenario is recommended:
-e> blah,!x-email
<e- blah,!x-email,ok

==Handover==
!x-handover/K/n should work like in chat sessions (with the semantics that the session is transferred to the object of key K, chatting on standard RLVR channel).

Handing over to another object while remaining in e-mail mode, doesn't however require any special step. The following scenario can be used:
1 - assume C has a session with R, using key k(S)
2 - C gives k(S) to another object C' via any preferred medium
3 - now C' can continue e-mailing with S, using key k(S) (and can use the "C has a new key" scenario)

Handing over to oneself can also be used to switch back to chat mode.

LSL Protocol/Restrained Love Open Relay Group/key/003 draft

2012-07-29T08:04:38Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

STATUS: draft

VERSION: 003

RECOMMENDED WITH: '''''[[LSL Protocol/Restrained Love Open Relay Group/delay|delay]]''''','''''[[LSL Protocol/Restrained Love Open Relay Group/cancel|cancel]]'''''

COMMANDS:
* !x-key/<session_key>: associates key <session_key> to current session.
* !x-takeover/<session_key>: takes over control of the session with specified key.

IMPLEMENTATIONS:
* Version 002 in Dahlia's multirelay >= 0.48 and in anythingRLV >= 3.1
* Version 002 and 003 in Dahlia's multirelay >= 1.2.20 and in anythingRLV >= 3.7

=!x-key and !x-takeover=

!x-key/<session_key> associates the key <session_key> with the current session, where <session_key> is a [[UUID]] randomly generated by the controller of the current session. After a session key is set, any other controller can then take the control of this session by sending the command !x-takeover/<session_key>. By "other", it can also mean the same controller after a relog or region restart and thus a different key.

==Example==
Two controllers on the left:
* C1 is in control of the session before this exchange,
* and C2 will gain control at the end of the exchange (with all restrictions carried over under its own key).
On the right, R is the relay.

k(C1), k(C2), k(C) are the keys of the controllers and k(R) is the key of the avatar wearing the relay.

# C1 -> R: blah,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
# C1 <- R: blah,k(C1),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
# C2 -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
# C2 <- R: blah,k(C2),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok

* At 1, C1 generates a random UUID key which must be recorded by the relay.
* Between 2 and 3, C1 gives the key to C2. Often C2 will actually be C1 after a relog and thus with a new object key, but with LSL remembering everything from before the relog, in particular the session key.

==Requirements==
General requirements:
* By supporting this x-tension, a relay associates a new key/UUID field to each RLVR session: the session key.
* The relay must acknowledge !x-key and !x-takeover using private communications only (so that nobody can eavesdrop and read the session key). Use of [[llRegionSayTo]] is therefore mandatory in case you use chat on standard RLVR channel.

Requirements concerning !x-key:
* !x-key is to be considered as a secondary behavior (it can trigger an ask dialog and open a session but the session will eventually time out if there is no primary behavior)
* On !x-key/<UUID> acceptation, the relay sets the current session key to <UUID>.
* If a relay accepts a command !x-key/<uuid> within a session which already had a key, then the new one replaces the old one.

Requirements concerning !x-takeover:
* If <UUID> is an existing session key !x-takeover/<UUID> cannot be refused by the relay (acknowledgement by "ok").
* If <UUID> is NULL_KEY or is equal to no existing session key, !x-takeover/<UUID> must be refused by the relay (acknowledgement by "ko").
* In no case !x-takeover triggers an interactive dialog or opens a session.
* On accepting !x-takeover/<UUID>
:* the relay makes the device who issued the command the controller of the session having <uuid> as session key,
:* the relay considers that if that device already was controlling a session, then that session has no controller anymore.
* The communication method (chat, email, http, ...) of the session that was taken over becomes the same as the one by which !x-takeover was received, no matter the way that session was previously accessed. For instance, if a device sends !x-takeover by chat and takes over an existing email session, then the session continues by chat.

==Recommendations==
* The controller should preferably send !x-key and !x-takeover through private channels only too. But letting session keys be "leaked" or not is only the controller's responsibility. It could actually be done on purpose.
* The key should preferably be randomly generated, so there is little risk for a session to be stolen by another device by guessing the key.
* In relay implementations, take care that the following scenario cannot happen:
:# C1 has an open session with R and no key set
:# C2 sends hijack_session,!x-takeover/00000000-0000-0000-0000-000000000000
:# Now C2 controls the session that formerly was C1's.
:For this reason, it is required that the relay refuses !x-takeover/NULL_KEY, so that the relay implementation can initialize session keys to NULL_KEY by default (which we recommend).
* Consequently, if a controller sends !x-key/00000000-0000-0000-0000-00000000000, it is equivalent to !x-key/clear (which does not formally exist); this command is mostly useless: its effect is to make any !x-takeover impossible.
* A session currently having no controller will fail all pings and thus unless !x-delay is set, a controller sending !x-takeover within a session will lose its former session (all restrictions will be released). In this case, the relay can release the current session immediately after !x-takeover is accepted.
* As a RLVR controller scriptwriter, most likely you don't want !x-takeover to be sent within an existing session, as this would mean closing/releasing it. If you do that, ask yourself if you want the session to remain in the background for some more time. If the answer is yes, don't forget to make the session resistant to !ping's by sending !x-delay/<some_more_time_in_seconds> before you send !x-takeover/<uuid> of the other session>. Also preferably set a key in the first session so it can be recovered later on.

= (DEPRECATED) !x-noping / !x-nopingclear=

:These commands are '''deprecated''', use !x-delay and !x-delay/clear instead.
:New RLVR controllers should not use them at all. They can instead send a command like !x-delay/<some_reasonable_amount_of_seconds>/noping|!release if they need to keep the session open for <some_reasonable_amount_of_seconds>, and then !x-delay/clear/noping after !x-takeover.
:Relays can either interpret them as they used to mean, or preferably translate them to respectively to !x-delay/<some_long_enough_amount_of_time>/noping and !x-delay/clear/noping if the relay supports '''''[[LSL Protocol/Restrained Love Open Relay Group/delay|delay]]'''''.

We remind the reader that, like with !x-noping, pings are disabled for a session as long as a delay is running within that session. The obvious advantage over !x-noping is that it forces the controller scriptwriter to think of a reasonable delay after which to release the session is meant to expire if not taken over.

For information, we recall below what !x-noping / !x-nopingclear used to mean:

==Motivation==
There usually are three ways a relay can end a session:
* when a !release is sent by the controller,
* when the user safe-words from the relay,
* and when the relay finds the controller is not present (not answering !pong to a ping after a relog or on refresh).
The command !x-noping disables the latter possibility, so that the session can persist despite the controller disappearing. This would typically happen very often if the controller is a portable HUD.

Combined with !x-key and !x-takeover, !x-ping makes it possible for that portable HUD to recover a RLVR session after its wearer relogs, possibly after a long time offline.

* !x-noping cannot exist without !x-key. Without a session key negotiated with !x-key, the relay must answer !x-noping,ko to any !x-noping. The reason of this choice is that a session with !x-noping and without session key is not cancellable anymore by a controller if the controller disappears (e.g. unrezzed).

* The command !x-key/NULL_KEY or !x-key/clear must cancel any previous !x-noping for the same reason.

==Example==
After the following sequence of commands, the user of the controller C if it is a HUD can go offline. The session will persist until the relay safe-words.

1 C -> R: blah,k(R),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k(C),!x-key/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),!x-noping
4 C <- R: blah,k(C),!x-noping,ok

k'(C) is the new UUID key of C after the relog. To cancel this setting after a relog:

1 C -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),!x-noping/clear
4 C <- R: blah,k'(C),!x-noping/clear,ok

To release the victim after a relog:

1 C -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),!release
4 C <- R: blah,k'(C),!release,ok

To continue with the session after a relog:

1 C -> R: blah,k(R),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a
2 C <- R: blah,k'(C),!x-takeover/a586c562-bf27-b7db-e36e-822d0a9ba02a,ok
3 C -> R: blah,k(R),@xxx=add
4 C <- R: blah,k'(C),@xxx=add,ok

==Requirements==

* !x-noping is a secondary behavior. It can trigger an interactive ask dialog, depending on settings.
* On answering "!x-noping,ok" to !x-noping, the relay commits itself not to check for presence of the controller of this session anymore and thus not to close the session because the controller fails to answer a ping.

==Caveat==
On relog, the fact there is no ping/pong exchange for a session with !x-noping does not mean the relay should not sit the avatar back to where it was sat if this session had @unsit=n as active behavior. So the key <UUID> of the sit target should still be remembered, and @sit:<UUID>=force be sent a few seconds after relog.

LSL Protocol/Restrained Love Open Relay Group/x-xtensions

2012-07-29T07:58:30Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

Deprecated by !x-orgversions, which is part of [[LSL Protocol/Restrained Love Open Relay Group/ORG Requirements|ORG core requirements]].

LSL Protocol/Restrained Love Open Relay Group/Satomi's Damn Fast Relay

2012-07-29T07:56:12Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

= Satomi's Damn Fast Relay =

This is the shortest known implementation of an ORG compliant relay.

This relay only makes the minimal verifications (no ask mode, no distance checks, ping on relog only but safe-word on touch).

Code is under a BSD-style license, feel free to use in your own projects, provided you credit Satomi Ahn for the original script.

<lsl>
//Damn Fast Relay, by Satomi Ahn
//
//This is a minimalist RLV Relay intended for laggy playgrounds, with the aim of making the answer to scan requests as fast as possible and decreasing the global lag.
//It only features the auto-accept mode but tries to fully comply to ORG 003 specifications.
//Touching the relay will make it release restrictions and reset (in other words: safewording).
//
//This script is provided as-is with mo guarrantee whatsoever.
//Feel free to use the code in anyway you want, provided you credit the original author, ie: myself, Satomi Ahn.
//(can be seen as a BSD-style license)

integer rlvrc = -1812221819;
key source = NULL_KEY;
key wearer = NULL_KEY;
integer viewerlistener;
key sitid;
list restrictions = [];

release(key id) {
llOwnerSay("@clear");
llRegionSayTo(id, rlvrc, "release,"+(string)id+",!release,ok");
llResetScript();
}

default {
state_entry() {
wearer = llGetOwner();
llListen(rlvrc,"", NULL_KEY, "");
}

touch_start(integer total_number) {
llOwnerSay("Now safewording. Restrictions will be removed and the relay reset.");
release(source);
}

listen(integer c, string w, key id, string msg) {
if (c == 12345) {
if (msg) sitid = (key) msg;
llListenRemove(viewerlistener);
return;
}
if (source) { if (source != id) return; } // already grabbed by another device
list args = llParseStringKeepNulls(msg,[","],[]);
if (llGetListLength(args)!=3) return;
if (llList2Key(args,1)!=wearer && llList2Key(args, 1)!=(key)"ffffffff-ffff-ffff-ffff-ffffffffffff") return;
string ident = llList2String(args,0);
list commands = llParseString2List(llList2String(args,2),["|"],[]);
integer i;
string command;
integer nc = llGetListLength(commands);
for (i=0; i<nc; ++i) {
command = llList2String(commands,i);
if (llGetSubString(command,0,0)=="@") {
llOwnerSay(command);
llRegionSayTo(id, rlvrc, ident+","+(string)id+","+command+",ok");
list subargs = llParseString2List(command, ["="], []);
string behav = llGetSubString(llList2String(subargs, 0), 1, -1);
integer index = llListFindList(restrictions, [behav]);
string comtype = llList2String(subargs, 1);
if (comtype == "n" || comtype == "add") {
if (index == -1) restrictions += [behav];
if (behav == "unsit" && llGetAgentInfo(wearer) & AGENT_SITTING) {
viewerlistener = llListen(12345, "", wearer, "");
llOwnerSay("@getsitid=12345");
}
}
else if (comtype=="y" || comtype == "rem") {
if (index != -1) restrictions = llDeleteSubList(restrictions, index, index);
if (behav == "unsit") sitid = NULL_KEY;
}
}
else if (command=="!pong") {
llOwnerSay("@sit:"+(string)sitid+"=force,"+llDumpList2String(restrictions, "=n,")+"=n");
llSetTimerEvent(0);
}
else if (command=="!version") llRegionSayTo(id, rlvrc, ident+","+(string)id+",!version,1100");
else if (command=="!implversion") llRegionSayTo(id, rlvrc, ident+","+(string)id+",!implversion,ORG=0003/Satomi's Damn Fast Relay v2");
else if (command=="!x-orgversions") llRegionSayTo(id, rlvrc, ident+","+(string)id+",!x-orgversions,ORG=0003");
else if (command=="!release") release(id);
else llRegionSayTo(id, rlvrc, ident+","+(string)id+","+command+",ko");
}
if (restrictions) { source = id; llOwnerSay("@detach=n"); }
else { llOwnerSay("@clear"); llResetScript(); }
}

changed(integer c) {
if (c & CHANGED_OWNER) llResetScript();
}

on_rez(integer i) {
if (source) {
llSleep(30);
llRegionSayTo(source, rlvrc, "ping,"+(string)source+",ping,ping");
llSetTimerEvent(30);
}
}

timer() {
llResetScript();
}
}

</lsl>

LSL Protocol/Restrained Love Open Relay Group/ORG Requirements/0004 draft

2012-07-29T07:54:45Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}
STATUS: draft

VERSION: 0004

'''Summary'''

This page lists requirements that make a RLV relay or a RLVR controller "ORG compliant".
Main advantages of an ORG compliant device over a classic RLVR devices are the following:
* ORG devices follow a stricter specification (while keeping compatibility), thus making the experience more predictable for scriptwriters;
* ORG devices support wildcards for easy and low lag relay scanning and mass effects;
* ORG devices can support optional x-tensions for more fun. Supported x-tensions can easily be discovered thanks to [[#!x-orgversions|a new query meta-command]].

For a quick overview of the motivations and general working of the RLVR protocol and a few examples, we refer the reader to [[LSL Protocol/Restrained Love Relay/Specification|the original RLVR specification]].

If you are making furniture, traps, or other RLVR controllers and you are not interested in what [[LSL Protocol/Restrained Love Open Relay Group/x-tensions|optional ORG x-tensions]] can offer, then you can stick with the original RLVR specification and still be compatible with [[LSL Protocol/Restrained Love Relay/Comparison|ORG relays]]. However, to have the right to call your controller "ORG compatible", there are still a few light additional requirements such as:
* using only [[llRegionSayTo]] for communications (in both directions),
* not spamming the RLVR channel with messages that do not belong to the protocol,
* and remain responsive to ping messages at every time if you want the session to remain locked.

If you are interested in [[LSL Protocol/Restrained Love Open Relay Group/x-tensions|ORG x-tensions]], then you should also read the part about [[#!x-orgversions|!x-orgversions]].

If you are making a relay, sorry we are afraid you will have to read all this page.

==Definition of an ORG device==

A RLVR device is compliant with ORG specifications if it implements the consolidated RLVR protocol and meta-commands described in sections below, along with the [[LSL Protocol/Restrained Love Open Relay Group/x-tensions|optional ORG x-tensions]] it announces supporting.

Remarks:
* An x-tension can constrain the core specification (this document) even more, but cannot alter its requirements or make them less constraining by the mere fact of being there.
* However requirements may be altered as the result of executing a meta-command belonging to an x-tension.
* Thus, although the protocol is extensible, a controller can always rely on the fact an ORG relay abides by the core requirements until the controller knowingly asks the relay to do otherwise.

If a device is ORG compliant, it may be advertised by the use of the [[LSL Protocol/Restrained Love Open Relay Group/ORG Logo|ORG logo]]. ORG device makers are encouraged to do so.

==Consolidated RLVR protocol==
This consolidated RLVR protocol is roughly the same as [[LSL Protocol/Restrained Love Relay/Specification|Marine Kelley's RLVR protocol version 1.100]], minus a few embarrassing loose ends.

Main differences are highlighted at the beginning of each subsection.
=== Protocol Syntax ===
Summary of differences with original RLVR:
* we force use of llRegionSayTo,
* we explicitly forbid incorrect syntax on the relay channel
* the relay is supposed to ignore bad commands
* wildcards are supported

==== Definitions ====
* The '''Restrained Love Relay (RLVR) protocol''' implies two partners (SL objects): the '''relay''', attachment worn by the avatar commands are intended for, and a '''controller''', which sends commands to the relay.

* The goal of the protocol is to force the relay wearer to make perform actions and to toggle restrictions on their behavior. Both actions and restrictions can be enforced either through use of viewer hooks ([[LSL Protocol/RestrainedLoveAPI|Restrained Love API]], or RLV) or through LSL scripting.

* Hence we distinguish between "'''RLV commands'''", starting with "@", which are commands following the syntax of the RLV API and which will ultimately be forwarded to the viewer, and "'''meta-commands'''", starting with "!", which are meant to be interpreted by LSL functions.

====Requirements====
RLVR protocol consists of messages exchanged between relay and controller
* on channel -1812221819 (called '''RLVR channel'''),
* using the LSL function [[llRegionSayTo]] (except for <c_msg>'s using a wildcard)
* all sent from the same prim of the controller or relay (within a [[#Protocol session|session]])
* and having the following syntax (non-terminal <c_msg> for controller messages/'''command messages''' and <r_msg> for relay messages/'''acknowledgement messages'''):

<c_msg> ::= IDENT "," KEY "," <commands>
<r_msg> ::= IDENT "," KEY "," <command> "," ACK
<commands> ::= <command> | <command> "|" <commands>
<command> ::= <rlv-command> | <meta-command>
<rlv-command> ::= "@" RLV-COMMAND
<meta-command> ::= "!" META-COMMAND_NAME <meta-command arguments>
<meta-command arguments> ::= "" | "/" ARG <meta-command arguments>

where we explicit the different terminal tokens:
IDENT: any string without ","
KEY: any UUID
ACK: any string without ","
RLV-COMMAND: any string without ","
META-COMMAND_NAME: any string without "/" and ","
ARG: any string without "/" and ","

* Relays can only send <r_msg>'s, and controllers <c_msg>'s. Nothing else is allowed on RLVR channel.
* In <c_msg>, KEY is always either the UUID of the relay wearer or ffffffff-ffff-ffff-ffff-ffffffffffff ('''wildcard''') if it is a message intended for all relays who can hear it. If llRegionSayTo is used, then the first parameter will also be the UUID of the relay wearer.
* In <r_msg>, KEY is always the UUID of the controller (more accurately: the uuid of the primitive sending the <c_msg>'s), this will also be used as the first parameter of llRegionSayTo.

'''Remark'''

IDENT and ARG can be empty, relay makers must take care of properly handling messages with empty IDENT or ARG (use [[llParseStringKeepNulls]] instead of [[llParseString2List]]). However, due to the fact many existing relays do not properly handle them, controllers should avoid using empty IDENTS.

====On the relay side only====
'''Further requirements:'''
*A relay MUST ignore any message on RLVR channel which is not a <c_msg> with KEY being either the key of the avatar wearing the relay or ffffffff-ffff-ffff-ffff-ffffffffffff.
Then, for every <command>:
* if <command> is neither a valid <rlv-command> or <meta-command>, the relay must ignore it and process the next <command>'s;
* if <command> is a <rlv-command> or a <meta-command>, the relay MUST send back to the controller a <r_msg> (see above) such that:
:*IDENT is the same as IDENT in the <c_msg> being processed,
:*<command> is the subcommand being processed
:*and ACK is a string called ''acknowledgement value''. By default the acknowledgement value is "ok" if the relay will execute the <command >, "ko" otherwise.

'''Remarks:'''
* Many meta-commands may have other acknowledgements than "ok" or "ko" (or none, for !pong). Their definitions supersede this specification.
* Note that unknown meta-commands cannot be executed and thus wil be acknowledged by "ko".
* Known meta-commands which are sent with not enough parameters or parameters with types incompatible with those in the definition known by the relay also cannot be executed and will also be acknowledged by "ko". (ex: the relay knows !x-who/key, but receives !x-who/integer/string).

===On executing commands===
Summary of differences with original RLVR:
* explanation on how to handle meta-commands with variable number of parameters,
* the relay knows commands in both core specification and x-tensions,
* clarification on multi-controller relays.

====Relay side====
'''Requirements:'''
* If a <rlv-command> is acknowledged with value "ok", the relay ensures the viewer is affected the same way as if the LSL instruction llOwnerSay(<rlv-command>) was executed by a script in a primitive that handles only one controller.
* When processing a <meta-command>, if the relay knows at least one definition of '!'+META-COMMAND_NAME for which the received <meta-command arguments> provide enough parameters, then it will be handled according to the definition handling the most parameters among the latter. Extra parameters are ignored.
* A relays knows the following meta-command definitions:
:*[[#Core meta-commands and associated mechanisms|definitions listed in the core requirements]]
:*all definitions included in [[LSL Protocol/Restrained Love Relay/Comparison|x-tensions]] announced by the relay.
* When acknowledging a <meta-command> by anything else than "ko", the relay commits itself to execute it.

'''Remarks:'''
* For first requirement, it must be understood that the reference behavior is that the relay would have if it had one controller per prim. However handling several controllers from one unique prim is possible but requires taking care that different controllers do not interfere with each other, releasing each others restrictions, for instance.
* For the second requirement, the word "handled" means that if the meta-command with these parameters is known, then requirements in known definition cannot be ignored. Sometimes, this can imply that the meta-command cannot be refused, for instance.

====Controller side====
* The controller can send any command within allowed syntax.
* Only commands described in this specification and commands belonging to x-tensions announced by the relay are guaranteed to be understood by the relay. If not understood, the relay will just answer "ko", do nothing and skip to the next command.

===Protocol session===
Summary of differences with original RLVR:
* it is now clear when a session starts and stops (and what a session is!)
* it is clear when to expect interactive dialogs (and how to avoid spamming relay wearers with blue dialogs)
* no session for unreachable controllers (answer to ping is mandatory to ensure session persistence)

====Definitions====
* During an execution of the RLVR protocol, a relay and a controller establish a '''session''' together. A relay may manage several sessions with several controllers. Likewise, a controller could establish sessions with several relays.
* Restrictions on a relay wearer are relative to a session. So are most other variables (authorization state, key of the controller, ... ).
* A session is '''Opened''' whenever the relay accepts a RLVR command from a controller.
* A session is '''Closed''' (or '''released''') as soon as the relay forgets every variables and releases all restrictions pertaining to that session.
* A session is '''Locked''' whenever it holds active restrictions.
* A session is '''Authenticated''' if the controller has been allowed to control the relay (not only store some variables with no consequence). Once authenticated, no interactive "ask" dialog should pop up anymore concerning this session. Most commands should now normally be accepted (and maybe a few automatically rejected).
* A controller is called '''reachable''' if it can receive messages from the relay and can prove it by answering [[#ping/!pong|ping]] requests from the relay. By "can", it is meant by the method of communication agreed upon by the relay and controller (by default: chat messages sent on RLVR channel by llRegionSayTo). X-tensions such as email and delay can modify what is meant by reachable.

====Relay side requirements====
On closing sessions:
*Closing a session clears all RLV restrictions that belong only to that session, clears all session variables and disables all restrictions relative to that session. This MUST happen on the following events and no other:
:*on executing !release (received from the controller, or relay-triggered as in a safe-word, see [[#!release]])
:*on noticing the controller is not reachable
:*on timeout, if the session is not Locked
*Sessions that are not locked MUST be closed after a reasonable timeout.

On interactive Authentication:
*Unless specified otherwise (see !x-who), no command can trigger an interactive dialog unless the command requires an Authenticated session and the session is not already Authenticated.
*Relay implementations MAY require an authenticated session for all <rlv-command>'s of the form @xxx=force, @xxx=add and @xxx=n, and for meta-commands whose specifications say it is allowed.
*Other RLV commands MUST automatically accepted or rejected by any relay.

On removing and adding restrictions:
* Commands that remove restrictions are always accepted (RLV @...=<channel_number>, @clear[=...] and @...=y/rem commands, !release, and !x-.../clear[/...] meta-commands).
* No restriction can be released unless as the result of one of the above commands, or of closing a session.
*@xxx=n/add <rlv-command>'s, after being accepted, add a restriction and therefore Lock the session.
*Some meta-commands described in x-tensions can also add restrictions and therefore Lock the session.

Reachability:
*A relay MUST provide a mechanism for checking that every controlling device is reachable. It is not specified whether this checking process should be automatic or manually triggered.

====Controller side requirements====
* A controller MUST eventually close any Locked session using the meta-command !release.

In particular, non-portable controllers should not let a Locked relay wearer run free out of reach. Moreover, any controller should either react to some kind of event that is bound to happen (timer expiration being the most common) or provide a user interface for closing the session. It should be clear at least to the person who set the trap how the victim will be released.

==Core meta-commands and associated mechanisms==

An ORG device MUST at least support the meta-commands !release, !pong, !version, !implversion and !x-orgversions described below and implement their associated mechanisms.

Particular meta-commands definitions and mechanisms may override general requirements above.

New in ORG compared to RLVR: !x-orgversions

===!release===
Sent by a controller, this command closes the session.

* !release obviously opens no session, requires no Authrnyication and is not Locking.
* If there is an actual session to close, !release MUST be accepted by the relay and acknowledged by "ok".
* On accepting !release, the relay erases all data pertaining to the session and disables all restrictions of the session.
* When a relay decides to close a session on its own (user safe-word, for instance) and it is not due to the controller being unreachable, the relay must send the following acknowledgement message:
release,<controller_key>,!release,ok

When receiving the latter message, the controller should act accordingly, for instance by resetting itself and making itself ready for the next session.

Note that !release is not the same as @clear. @clear is interpreted by the relay as a RLV command and, as such, can only clear RLV restrictions. If RLV restrictions were the only restrictions of the session, then the session will be closed, but some x-tensions also define pure LSL based restrictions.

===ping/!pong===

The ping/!pong mechanism exists so that relays can check presence and responsiveness of a controller. This was primarily meant to be used on relay wearer relog, in order to reactivate all restrictions so that sessions persist on relog if the controller still exists and is ready to continue the session.

''!pong'' cannot require authentication and does not lock a session

We call ''ping message'' a message from the relay, having the following syntax:
ping,<controller_key>,ping,ping
We call ''!pong message'' a message from the controller, having the following syntax:
ping,<relay_key>,!pong

====Relay side====
*A relay SHOULD NOT send an acknowledgement in response to ''!pong''.
*A ping message can be sent any time by the relay to a known controller.
*On wearer relog, for each existing Locked session, the relay must send a ping message to the session controller.
*When a !pong message is received from a controller, if it was a reply to a previous ping message:
:#if the session RLV restrictions contain unsit and the avatar was sitting on some object when the restriction was applied, then the relay MUST force the avatar to sit back on the same object (if still existing);
:#the relay MUST make sure all restrictions belonging to the session are made active again.
*If a ping message is sent and is not answered by the controller, then the relay closes the session.

Note that the relay is responsible for storing restrictions and the key of the sit target across sessions, not the controller.

====Controller side====
*Unless it does not matter that the relay could close the session (or for another reason, the controller knows the relay will not close it), a controller SHOULD listen to ping messages and answer any ping message with a !pong message.
*A controller should ignore ping requests from relays it is not ready to handle.

Note controller don't have to poll for relay presence to resume a session but should just listen for ping messages instead. The relay should have stored all restrictions and handle sitting back to whatever furniture the relay wearer was tied up to.

Concerning the second bullet: for instance, if the controller is a furniture which is already in use by another relay wearer, it would be cause dysfunctions to let the pinging relay restore the restrictions without letting its wearer sit on the furniture. Or if the controller is not stateless and the state for the pinging relay has not been saved before, resuming the session from the initial state might be inconsistent.

===!version===
The purpose of this meta-command is to query the version of the RLVR protocol supported by a relay.

* !version opens no session (and requires no authentication, neither can lock a session)
* A relay MUST always acknowledge !version with the version number of the RLVR protocol it supports ("1100" here, since ORG 0004 includes RLVR 1.100).

Note this is the most common command for a controller to scan for nearby relays, as non-ORG relays also accept this command and answer it the way described above.

===!implversion===
The purpose of this meta-command is to query the name and version of the relay implementation.

* !implversion opens no session (and requires no authentication, neither can lock a session)
* A relay MUST always acknowledge !implversion with its implementation version string... which can be any string.

It is recommended this string includes the following elements:
* the relay name/brand/identifier,
* the version number of that relay name/brand/identifier,
* at the beginning, the string prefix "ORG=0004/"
The latter is convenient for checking for ORG compatibility using a command even non-ORG relay should understand.

===!x-orgversions===

This meta-command's purpose is to make it possible for the controller to have detailed information on the protocol the relay supports. First the version of the ORG consolidated protocol, second the list of supported optional x-tensions, also with their version numbers.

'''Example:'''
C<->R
-> query,rUUID,!x-orgversions
<- query,cUUID,!x-orgversions,ORG=0004/who=002/email=006

'''Requirements:'''
* !x-orgversions should always be accepted with no Auth required, it does not open a session or Lock one.
* The acknowledgement value in a reply to !x-orgversions is a "/"-list of items of the form <package>=<version>. The first <package> is always "ORG" (representing the core specification package of ORG relays), its version string is the version of the specification (4 digits). The other packages are x-tension names, whose version string is 3 digits.
* If several incompatible versions of a same x-tension are supported, they must be listed ordered by version number. Ex: ORG=0004/who=002/email=005/email=006. If versions are backward compatible, only the last version should be reported.
* By announcing an x-tension, the relay commits itself to comply to all requirements of its specification.

'''Remarks:'''
* In a controller, it is however recommended to use !x-orgversions as soon as possible in order to avoid sending unsupported and useless meta-commands later on.
* In the acknowledgement message, x-tension names are listed, not meta-command names (as one x-tension can have several meta-commands). Thus listed names do not include the prefix "!x-".
* x-tensions do not have to be standards defined by ORG but can also be proprietary. We recommend that the x-tension name then contains the name of the brand who proposes it.

===Other meta-commands===

Commands not listed here can belong to one of the following categories:
# (unlikely) commands from a future revision of Marine Kelley's original RLVR protocol.
# (more likely but not that much!) core commands from a future revision of ORG
# (very likely) commands from optional [[LSL Protocol/Restrained Love Open Relay Group/x-tensions|x-tensions]]
# proprietary commands

ORG intends for its successive versions to be backward compatible. Therefore ORG relays handle all unknown meta-commands.

We also intend for future versions of ORG consolidated protocol to include last version of original RLVR protocol, hence the prefix "!x-" for all meta-commands coming from ORG, which ensures there will be reasonably no collision.

For the same reason, we require that proprietary commands use an obvious prefix such as "!a-" or "!b-", and so on. Not doing so would prevent ensuring backward compatibility, hence a relay or controller who would use proprietary commands with wrong prefixes are not ORG compliant.

LSL Protocol/Restrained Life Open Relay Group/x-xtensions

2012-07-28T16:24:34Z

Uzume Grigorovich: moved LSL Protocol/Restrained Life Open Relay Group/x-xtensions to LSL Protocol/Restrained Love Open Relay Group/x-xtensions: RestrainedLove

#REDIRECT [[LSL Protocol/Restrained Love Open Relay Group/x-xtensions]]

LSL Protocol/Restrained Love Open Relay Group/x-xtensions

2012-07-28T16:24:34Z

Uzume Grigorovich: moved LSL Protocol/Restrained Life Open Relay Group/x-xtensions to LSL Protocol/Restrained Love Open Relay Group/x-xtensions: RestrainedLove

{{ ORG Restrained Life Relay Specs TOC }}

Deprecated by !x-orgversions, which is part of [[LSL_Protocol/Restrained_Life_Open_Relay_Group/ORG_Requirements|ORG core requirements]].

LSL Protocol/Restrained Love Open Relay Group/Prefix

2012-07-28T16:23:26Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

== '''Prefix Discussion''' ==

The current relay specification calls for two prefixes ! for meta-commands and @ for commands to be passed through to and executed by the viewer. For the most part, meta-commands are informational only (!release being an obvious exception). [[LSL Protocol/Restrained Love Open Relay Group/x-tensions|x-tensions]] fall into two significant categories: those that are largely informational and those that could be (but are not) implemented in the viewer. There is no hard and fast line between these two, for example, the currently proposed !gender add-on to the existing relay spec implies functionality that could, potentially, be implemented in the viewer or could be implemented by a script in the relay.

Clearly, though, there is need of some form of prefix for x-tensions, if only to separate them from the functionality required by all relays. There are a number of obvious alternatives: use the existing prefixes and simply document the x-tensions; create a single, new prefix for all x-tensions; and use multiple, new prefixes for the x-tensions. The first choice seems inappropriate, and choices for the second and third are to either use '''!x-''' alone or '''!x-''' for informational and '''#''' for viewer commands.

Clearly, making this choice needs to be done very early in the life of ORG.

:Well, I wouldn't draw the line between informational or not, but between RLVR protocol load (commands proper) and RLVR protocol control (meta-commands).
:*For me a meta-command is something which is only there for making the protocol work. Information about protocol and relay version (!version and !implversion), are of course meta-commands. But !ping/!pong isn't really informational, neither it is a command that will have a direct observable effect, but it is needed for the protocol to work when you log on. !who gives information, but not about the relay or its wearer, but about the furniture user. !handover makes the protocol able to transfer a session from one furniture to another. !release ends a protocol session.
:*Commands proper have no effect on how the protocol behaves but instead have extra-protocol effects (up to now, the only type of effect was issuing RLV commands to the viewer). !vision (or now !x-vision) is also such a command, as it doesn't change anything to the RLVR session, but produces a HUD behavior.
:NB: this distinction only makes sense with respect to one precise protocol. Indeed the load of the RLVR protocol contains RLV commands which in turn can have different roles with respect to RLV API (a different "protocol" it encapsulates). For instance @version is load with respect to RLVR protocol, but is clearly a "meta-command" w.r.t. RLV API.
:Drawing the line between load and control isn't always easier than between mostly "informational" or not, but I find this distinction more useful. --[[User:Satomi Ahn|Satomi Ahn]] 20:35, 25 April 2009 (UTC)
:: Hmmmm... you're almost certainly right... !x-vision could be implemented in the viewer, indeed, I wish it was because then I could do without every device trying to put a prim on my screen so it can block this, or that! I think that !handover is in a gray area.. and could be in either camp. It affects the protocol (which device the relay should respond to) but also the RLV API (which restrictions the person is under).
:: My bottom line is that I would like to get something simple, I really like the !x- convention, but am willing to go with another choice if that makes sense. --[[User:Chloe1982 Constantine|Chloe1982 Constantine]] 13:39, 11 June 2009 (UTC)
::: Let us wait for having more people on this discussion rather than take a hasty decision ;-). Btw, I have some other ideas like suggesting y-, z- prefixes for proprietary and draft extensions (so that device makers can play around without messing with the x- namespace).--[[User:Satomi Ahn|Satomi Ahn]] 16:21, 11 June 2009 (UTC)

This discussion is dying... and I believe this would be a big mistake not pursue it to its goal. Independently from what we decide in the end, I can easily already sort the different x-tensions of the current list into 2 categories without any ambiguity:

True meta-commands:
* who
* handover
* e-mail
* http
* channel

LSL effect commands:
* vision
* gender
* species
* freeze
* follow
* control
* listen
* message
* animate

The second category contains both commands that will enable/disable a behavior (like !x-vision/!x-vision-clear), and commands that will ask for some data (!x-get-gender). Maybe the second subcategory can be handled in a generic way by requiring that the asked data is actually the acknowledgement string (in this respect very similar to !version, !implversion and !x-orgversions).

My current view is that the LSL effect commands can be implemented by relay plugins whereas meta-commands are too much imbricated within the inner working of a relay to become a separate plugin. I believe this criterion alone could be enough to distinguish what is a meta-command and what is a LSL effect command.

Now that the distinction is clear enough (for me at least!), my argument for having a different prefix would be to make easy for a relay to distinguish between the two at a early stage for handling them differently (for LSL effects, that would mean transmitting the command to the plugin in a link message).

Moreover, LSL effects could possibly become viewer effects in the future, either without modification, or with a trivial conversion. The plugin architecture will make it easy to replace the handling of a given effect in a plugin by a LSL mechanism with a viewer mechanism when it becomes available, only replacing the plugin.

--[[User:Satomi Ahn|Satomi Ahn]] 12:25, 24 July 2009 (UTC)

LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process

2012-07-28T16:19:36Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

Proposed x-tensions should go through the following successive stages:

* '''Proposal''': someone proposes a new feature
* '''Draft''': there is a proof of concept implementation and specification
* '''Accepted''': a vote of board members decided the extension is accepted as an ORG x-tension.
* '''Ready''': a complete test set has been written and approved by 3 board members.
* '''Bronze''': there exists one implementation of the feature in one relay and one compatible controlling device, which both pass the test set.
* '''Silver''': there exists 2 interoperable implementations on each side passing the tests. One implementation either relay side or controller side has to be open source.
* '''Gold''': there exists 3 tested interoperable implementations both sides. There must exist at least one open source relay side implementation and one open source controller side implementation.
* '''Platinum''': 4 tested interoperable implementations both sides. One open source each side. Further more we require that a fully automated test suite (implemented by open source scripts) exists.

The '''Ready''' stage should be interpreted as a green light for device makers: "this x-tension is almost ready for prime time, you should really consider implementing it now".

The subsequent stages are more indicators of the level of confidence the buyer should have in the stuff (and confidence for the maker that enough compatible devices already exist).

However, those levels of confidence (from '''Ready''' to '''Platinum''') only apply to one given version of the specification. If it is updated, new tests might have to be written, and anyway all the tests tests have to be started over. This means that any new version starts at '''Accepted''' stage.

LSL Protocol/Restrained Love Open Relay Group/ORG Requirements

2012-07-28T16:17:35Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}
STATUS: ready

VERSION: 0003

(In writing: [[LSL Protocol/Restrained Love Open Relay Group/ORG Requirements/0004 draft|Version 0004 draft]])
==Summary==

This page is a list of requirements for a relay or an in-world device to have the right to be called "ORG compliant". It is mostly about adding support for an ORG-centered informational meta-command and specifying Marine Kelley's RLVR protocol a bit more that it is now, while of course preserving full compatibility.

If you are making in-world devices and are not interested in optional ORG x-tensions, you can skip most of this page, as your requirements amount to the following:
#Do not let your device spam the RLVR channel with commands that are not syntactically correct with respect to RLVR protocol.
#Never let your device be stuck in a state where no future event can unlock a currently locked relay.

If you are interested in ORG x-tensions, then you should also read the part about !x-orgversions.

If you are a relay maker, sorry we are afraid you will have to read all the page!

==Definition of an ORG device==

A RLVR device is compliant with ORG specifications if
* it implements Marine Kelley's RLVR protocol version 1.100
* it handles rely commands whose second field is ffffffff-ffff-ffff-ffff-ffffffffffff exactly the same as if it was the key of the wearer (NULL_KEY is a wildcard)
* it implements the !x-orgversions meta-command as defined below
* it implements the protocol fixes below
* all meta-commands it supports are of the following types:
:*meta-commands in RLVR protocol, behaving as described in RLVR specifications
:*meta-commands, whose names start with "!x-", behaving as described in ORG specifications
:*proprietary or experimental meta-commands, whose names start with "!_-" (replace "_" by any letter that is not "x")

'''Note that as soon as a RLVR controlling device makes use of a command defined in an ORG x-tension, then the specification of this x-tension MAY override one or several requirements of the core specification (this document).''' An x-tension that is not triggered by a specific command that it defines can only add more constraints, never override existing requirements. Indeed a controlling device has no way to know what requirements an unknown x-tension could override.

ORG devices may be advertised by the use of the [[LSL Protocol/Restrained Love Open Relay Group/ORG Logo|ORG logo]] for advertising compliance with ORG requirements. ORG devices makers are encouraged to do so.

==!x-orgversions==

This meta-command purpose it two-fold. First it allows a controlling device to ask a relay for the list of ORG x-tensions it supports, second it is similar to !version in RLVR protocol, as its reply gives the versions of the ORG core specification and ORG x-tensions that are implemented in the relay.

C<->R
-> query,rUUID,!x-orgversions
<- query,cUUID,!x-orgversions,ORG=0001/who=001/email=005

The acknowledgement string of the relay is a list separated by "/" whose items are of the form <package>=<version>. The first package is "ORG", the core specification of ORG relays, its version string is the version of the specification (4 digits). The other packages are ORG x-tension names (not meta-command names, as one x-tension can require several meta-commands, thus the name does not include the prefix "!x-"), whose version string is 3 digits.

''Requirements for a relay:''
* The support of this meta-command is mandatory for an ORG relay.
* It is also required that the list of packages in the !x-orgversions reply includes the package "ORG" and the exact list of supported optional x-tensions.

''Requirements for a controlling device:'' None. It is however recommended to use !x-orgversions when it makes sense for avoiding sending unsupported and useless meta-commands later.

==ORG RLVR fixes==
Marine Kelley's specification for RLVR protocol gives too much room for interpretation and incompatibilities between supposedly compliant devices. This is why in this section we add further requirements for RLVR+ORG devices.

===Preliminaries/Reminders===

Here we establish some notations related to RLVR protocol.

Here is the RLVR device message grammar (as it already is, nothing new):
<r_msg> ::= IDENT','KEY','<command>','ACK;
<d_msg> ::= IDENT','KEY','<commands>;
<commands> ::= <command> | <command>'|'<commands>;
<command> ::= <rlv-command> | <meta-command>;
<rlv-command> ::= '@'RLV-COMMAND;
<meta-command> ::= '!'META-COMMAND_NAME<meta-command arguments>;
<meta-command arguments> ::= '' | '/'ARG<meta-command arguments>;

where the following tokens were used:
IDENT: any string without ","
KEY: any UUID
ACK: any string without ","
RLV-COMMAND: any string without ","
META-COMMAND_NAME: any string without "/" and ","
ARG: any string without "/" and ","

Furthermore we give the following definitions:
* A controlling device is always considered to be "reachable" if it is within shout range of the relay, as long it does not fail to answer a ping request from the relay. A controlling device is usually considered to be "unreachable" if it is out of shout range of the relay, but x-tensions such as !x-email or proprietary enhancements may modify the notion of "unreachability".

* The following actions are considered ''locking'' a relay:
:* a restricting command followed by a "ok" acknowledgement
:* a ping/pong exchange with this relay

* The following actions are considered ''unlocking'' a relay:
:* the controlling device becoming unreachable.
:* the relay sends "release,KEY,!release,ok"
:* the controlling device sends a !release
* A relay is ''locked'' by a controller if their last interaction of the above types was locking.

===General Relay requirements===
The relay must behave the following way by default (unless at some point a meta-command explicitly requires another behavior):
*A relay MUST provide a mechanism for checking that every controlling device is reachable, and releasing it if it is not. It is not specified whether this checking process should be automatic or manually triggered.
*A relay MUST NOT send anything on RLVR channel that is not a valid <r_msg>.
*A relay MUST ignore any message on RLVR channel that is not a ","-list of 3 items and whose second item is not the key of the avatar wearing the relay or ffffffff-ffff-ffff-ffff-ffffffffffff.
*When the relay receives a message meeting the above conditions, considering the 3rd item as a "|"-list of <command>s, then for every <command>:
:* if the <command> is a <rlv-command>, the relay MUST acknowledge it, either by "ok", and transmit the command as such to the viewer with llOwnerSay("@"+RLV-COMMAND), or by "ko" and not transmit it.
:* if the <command> is a <meta-command>
::* if the META-COMMAND_NAME is !pong, no acknowledgement is expected. The relay MUST reinstate all stored restrictions belonging to the controlling device if they weren't already active.
::* if the META-COMMAND_NAME is unknown or is not provided with enough arguments for at least one definition of the meta-command, the relay MUST acknowledge by "ko"
::* else if the relay knows the META-COMMAND_NAME with at least one definition having less or as many arguments as received in <meta-command arguments>, it MUST acknowledge it by "ok" and choose among possible definitions the one that uses the most arguments. Then if the number of arguments of this definition is ''n'', it MUST execute it using only the ''n'' first arguments of <meta-command arguments>, ignoring the trailing arguments if any.
:* if the <command> is neither, then the relay MUST ignore it (no acknowledgement whatsoever)
:* every acknowledgement or message sent by the relay to one given controlling device must be issued by the same prim (so that the controlling device can restrict its listener to one source key)
*A relay MUST release all restrictions belonging to a controlling device when an unlocking action relative to this device happens (whether if it is just before or just after is irrelevant, as long as the relay does not wait for any further event).
*A relay MUST never release a restriction outside one of those 2 cases:
:* the controlling device the restriction comes from specifically asks for the restriction to be released ("@restriction=y", "@clear=restriction")
:* the relay is being unlocked with respect to the device the restriction belongs to (for instance !release coming from the device, or safe-word)

===General controlling device requirements===
* A controlling device MUST not send anything on RLVR channel that is not a valid <d_msg>.
* A controlling device MUST, at any time when a relay is locked, provide a mechanism that will unlock it in bounded time. (i.e.: either there is a menu that will release the victim, or there is a timer, or a menu should be able to start such a timer). At least one person MUST know what this mechanism is, and if it requires an action from someone else, be able to tell that other person what s/he has to do.

LSL Protocol/Restrained Love Open Relay Group

2012-07-28T16:10:45Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

The purpose of this and other related pages is to create an environment for the development of extensions to the existing Restrained Love Relay specification. The goal is to create an environment where ideas for extending the existing specification can be discussed openly and in the spirit of cooperation and not competition.

A stated aim of the existing relay is that the specification should not include anything that can be done in a script. The goal of this specification is to get as many of those ''script'' ideas made as open as possible so that toy builders do not have to invent new and incompatible ways of doing the same thing.

Finally, and perhaps the most important, our thanks go out to Maike Short. Her work on the existing relay specification was tireless and, appears to have been under-appreciated. Her generosity in making her relay code public enabled many others to develop their relays, using her script as a basis.

; '''Founding Members'''
* Chloe1982 Constantine
* Ilana Debevec
* Kira Welty
* Kitty Barnett
* Lyssa Daehlie
* Maike Short
* Monica Jewell
* Nano Siemens
* samatha Congrejo
* Satomi Ahn
* Toy Wylie

LSL Protocol/Restrained Love Open Relay Group/ORG Introduction

2012-07-28T16:09:30Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

==ORG - The OpenRelay Group==

'''ORG''', ''the OpenRelay Group'', are scriptwriters and builders of Restrained Love Enabled furniture and
devices. '''ORG''' wants to see the RLV Relay Spec grow and evolve to meet the needs of all
users, even to meet needs outside the capabilities of the RL Viewer.

The purpose of an ORG Enhanced Relay is two-fold: First, to capture and validate the necessary commands to
pass to the RL Viewer to enable its functionality for whatever purpose. Second, to do the things
that the Viewer does not (or will not) do that may have use in the '''RLV''' environment, but to do it in an
open, documented form to avoid a confusing flood of "secret", or "special purpose" relays. Any
extension documented here are, by definition explicitly non-proprietary and open for anyone
to use in any their products. We specifically reject the "not invented here", closed minded
position. There are already several builders using the RLV for non-BDSM solutions to problems,
the RLV is slowly becoming mainstream and we can help that process along.

The only required job of a relay is to deliver a properly formed ''"llOwnerSay"'' command to the RLViewer,
with properly formed RLV commands.. whatever else done in the relay proper is to enable features the viewer
can't. The viewer's work starts at ''"llOwnerSay"''.. the viewer's tasks start at ''"llOwnerSay"'' anything
else is up to us, and it is our responsibility to make sure that everyone knows what and how we do it and
make it easier for them to do it. From a furniture builder's perspective, the more standard the set of features,
the easier it is to design furniture and other devices to enhance the RLV-user's experience, no matter if it's
BDSM or any other use. Imagination is a good thing that should be encouraged.

This is not to say that every extension may be accepted by '''ORG'''. If it's dangerous, uses undocumented hacks
to the viewer and is not user friendly, then this is not the place. But we will discuss every suggested
extension and consider how to make them more useful to the user and the viewer.

One caveat for our discussions. Personal, ''ad-hominem'' attacks are not welcome and not permitted. We're here
to help builders, not to build empires. No one is required to use any of these extensions,
but everyone is welcome to do so. We want to help people avoid 're-inventing the wheel' and we want to
do so in the spirit of cooperation, not control.

We are making '''x-tensions''' to the existing relay spec as meta-commands, adopting the '''!x-''' prefix convention. Other
'''x-tensions''' that might be implemented in a viewer could use the '''!x-''' convention or adopt some other prefix
such as '''#'''. Given the importance of a decision, [[LSL Protocol/Restrained Love Open Relay Group/Prefix|discussion]] has been initiated.

The relay spec is silent with respect to unknown commands and the behavior has been dependent on each relay
maker's whim's, ''e.g.'', they may not even be '''ko'ed'''. So you can never assume the extensions will always be
recognized or even acknowledged.
We require that every ''ORG Enabled'' relay respond to the meta-command '''!x-orgversions''', comparable to the current meta-command '''!version''', with a string such as

'''ORG=0001/who=001/email=005/vision=002'''

so the device talking to the relay can know which extensions the relay you are talking to are supported and what specification version is used for each, and which version of the core [[LSL Protocol/Restrained Love Open Relay Group/ORG Requirements|ORG requirements]] is implemented.

Some example [[LSL Protocol/Restrained Love Open Relay Group/x-tensions|x-tensions]] that have been implemented or proposed are:

::'''''!x-vision''''' - provide a means of obscuring the subjects vision without having to muck about with extra attachments. Originally conceived as a mouselook enforcer/punisher and requires a HUD-style relay. (already implemented and available to use).

::'''''!x-listen''''' - to open up a second channel for any commands the device needs. This allows scriptwriters to open a channel for short term use; the intent is to cut down on lag by not requiring listeners that are always on.

::'''''!x-gender''''' - allow the users to set their defined sex, and be queried by a device and set by the device!

::'''''!x-species''''' - ditto for species.

::'''''!x-freeze''''' - stop the victim dead in their tracks. Effectively disables the arrow movement keys, jump and crouch. Sure you can do it other ways, but this keeps down extra script/attachment counts and gives a 'standard interface'. Nice for ''area effects'' (prison lock-down perhaps), cages (hold them in place so you can open the cage and take out one specific captive.

Come join us and help us make our Restrained Love life, the best life.

LSL Protocol/Restrained Love Open Relay Group/ack

2012-07-28T16:00:57Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

= !x-ack =
STATUS: draft

VERSION: 002

''002 Implemented in Dahlia's multirelay (<-- this command is not supported anymore due to llRegionSayTo())''

''001 Implemented in Satomi's multirelay''

!x-ack/quiet: tells the relay to stop sending "ok" and "ko" acknowledgements

!x-ack/verbose: tells the relay to resume sending them

Rationale: reduce relay channel spam, and thus lag, by disabling acknowledgements that the controlling device does not care about.

General syntax: !x-ack[/STRING]*, where STRING is the desired acknowledgement policy.

Behavior requirements:
* This will change the way the relay acknowledge commands, applying the policy given in the argument of the command, thus overriding the [[LSL Protocol/Restrained Love Open Relay Group/ORG Requirements|core requirement]] that every command should be acknowledged. There are now, in 002, two policies:
:* verbose: it is the default usual policy for RLV relays
:* quiet: "ok" and "ko" acknowledgements are not sent (other useful replies '''should''' still be sent!).
* This behavior change only concerns the acknowledgements to commands from the device issuing !x-ack.
* The possible acknowledgements to "!x-ack" are "ok" to say it was accepted, and "ko" otherwise. The acknowledgement may or may not be sent, depending on the current acknowledgement policy but, in every case, if there is a policy change, its effects start immediately, that is ''before'' the relay (does not) acknowledges "!x-ack".
* No matter the active acknowledgement policy, "!release,ok" should be always sent in case of safe-wording (which is not really an acknowledgement because it is not a reply to a command from the controlling device). Same goes for any other message sent at the initiative of the relay.
* The acknowledgement policy is restored on relog.

Example 1:
C -> R: !x-ack/quiet
(nothing)
C -> R: @remoutfit=force
(nothing)
C -> R: !x-orgversions
C <- R: 0002/ack=001
C -> R: !x-ack/verbose
C <- R: !x-ack/verbose,ok
C -> R: @detach:pelvis=force
R <- C: @detach:pelvis=force,ok

Example 2, a low-lag RLV zone controller:
C −> *: !x-ack/quiet|@sittp=n|@tplure=n|@tploc=n|@tplm=n|@showworldmap=n|@showminimap=n|@showloc=n
(Then no relay should answer, but everybody should be restricted. "*" instead of "R" means
a wildcard was used, as introduced in ORG-0002. Without the wildcard and !x-ack, a lot of
spam would have been sent to the RLV channel.)

Template:Restrained Love Relay Specs TOC

2012-07-28T15:56:41Z

Uzume Grigorovich: cat

<div class="floatright"><div class="navbox" style="width: 20em">
<center>'''Restrained Love Relay'''</center>
* '''[[LSL Protocol/Restrained Love Relay/Introduction|Introduction]]'''
* '''[[LSL Protocol/Restrained Love Relay/Specification|Specification]]'''
* '''[[LSL Protocol/Restrained Love Relay/Change History|Change History]]'''
* '''[[LSL Protocol/Restrained Love Relay/Reference Implementation|Reference Implementation]]'''
* '''[[LSL Protocol/Restrained Love Relay/Development & Contribution|Development & Contribution]]'''
** [[LSL Protocol/Restrained Love Relay/Bugs and Pendings Features|Bugs and Pending Features]]
** [[LSL Protocol/Restrained Love Relay/How to Test|How to Test]]
** [[LSL Protocol/Restrained Love Relay/Other Implementations|Other Implementations]]
</div></div>
[[Category:RestrainedLove]]

LSL Protocol/Restrained Love Open Relay Group/ORG Logo

2012-07-28T15:55:22Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

== Logo ==

A graphical image can make it easier to recognize devices and relays that support ORG extensions to the standard relay. As such, the following image

[[File:org button.png]]

can be added to an existing store or device logo to indicate use of or support for ORG.

Here's a great place to post suggestions for an overall ORG logo.

LSL Protocol/Restrained Love Open Relay Group/x-tensions

2012-07-28T15:53:55Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

== Full list of x-tensions ==

At present, the list of x-tensions is short and it makes sense to list them all on a single page, In the future, it may make sense to separate the list into those that have group approval and those that do not, either because they are still under discussion or because they have been rejected by majority opinion.

Proposed list of approval stages [[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|here]].

Feature table (including ORG x-tensions) of existing relays [[LSL Protocol/Restrained Love Relay/Comparison|here]].

'''x-tensions''' that have been implemented or proposed are:

These x-tensions are live, up and well running with several independant implementations:
{| style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000" border="1"

|-
! x-tension
! [[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|status]]
! version
! description

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/who|who]]'''''
| silver (?)
| 001
| tells the relay the identity of the avatar operating the controlling device. Can be useful in playgrounds with bondage furnitures whose grabbing function is open to everybody.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/handover|handover]]'''''
| bronze (?)
| 001
| hands over the control of the relay to another device, with no further auth required, and possiblity to keep all the previous restrictions.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/vision|vision]]'''''
| bronze (?)
| 001
| provide a means of obscuring the subjects vision '''WITHOUT''' having to muck about with extra wearables. Originally conceived as a '''MOUSELOOK ENFORCER/PUNISHER''' and '''REQUIRES''' a HUDstyle relay. (already implemented and available to use).

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/follow|follow]]'''''
| draft
| 002
| makes the victim follow a given object or avatar at the given distance.
::::This is exactly what current leashes already do, but without the particles. Useful for bringing the victim
::::from one place to another without using magic tricks like teleportation.

|-
! '''''[[LSL Protocol/Restrained Love Open Relay Group/email|email]]'''''
| draft
| 006
| initiates a gridwide email encapsulated protocol session.
::::The protocol itself is a work in progress now. A proof of concept is on its way in my relay and RLV remote. --[[User:Satomi Ahn|Satomi Ahn]] 10:03, 19 May 2009 (UTC)

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/delay|delay]]'''''
| draft
| 004
| !x-delay/10 will delay the execution of the remaining subcommands by 10 seconds. This can be useful either for setting release timers or... making delayed surprises.

|}

These x-tensions have some working implementations are not considered useful anymore due to llRegionSayTo:

{| style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000" border="1"

|-
! x-tension
! [[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|status]]
! version
! description

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/channel|channel]]'''''
| draft
| 001
| switches the control channel for the RLV relay communications to the specified channel to cut down on spam.

|-
! '''''[[LSL Protocol/Restrained Love Open Relay Group/ack|ack]]'''''
| draft
| 002
| !x-ack/quiet tells the relay to stop sending "ok" and "ko" acknowledgements... until it receives !x-ack/verbose. This should help reduce spam on the relay channel.

|}

These x-tensions have only one implementation but their specifications look final enough:
{| style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000" border="1"

|-
! x-tension
! [[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|status]]
! version
! description

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/freeze|freeze]]'''''
| draft
| 002
| stop the victim dead in their tracks. Effectively disables the arrow movement keys, jump and crouch.
::::Sure you can do it other ways, but this keeps down extra script/attachment counts and gives a 'standard interface'.
::::Nice for ''area effects'' (prison lock-down perhaps), cages (hold them in place so you can open the cage and take out one specific captive.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/key|key]]'''''
| draft
| 002
| creates an abstract key for the current session which enables another controller (or the same one after a relog) to take over the session; with !ping activated or not if the controller is not present

|}

These x-tensions are under debate:
{| style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000" border="1"

|-
! x-tension
! [[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|status]]
! version
! description
|-

|-
!<s>'''''[[LSL Protocol/Restrained Love Open Relay Group/simwide|simwide]]''''' </s>
| deprecated
| 000
| Enables simwide control without requiring a gridwide control: the viewer's answer is resent in a special channel and the relay performs the llSensor; interest of this simwide mode even if the capture avatar is close to the grabber: a scan is done around the avatar, not around the grabber.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/speech|speech]]'''''
| draft
| 002
| Forced speech

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/gridurl|gridurl]]'''''
| proposal
| 000
| Persistent URL to get the UUID key of the relay

|-
!<s>'''''[[LSL Protocol/Restrained Love Open Relay Group/thirdview|thirdview]]'''''</s>
| deprecated
| 001
| Forced mouselook mode

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/camera|camera]]'''''
| draft
| 001
| Controlling/tracking the camera of the wearer of the relay (this x-tension contains thirdview)

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/autoforward|autoforward]]'''''
| draft
| 001
| Simpler alternative to simwide: no new listener is opened, fully compatible with a !x-email session

|-
!<s>'''''[[LSL Protocol/Restrained Love Open Relay Group/forward|forward]]'''''</s>
| deprecated
| 001
| Deprecated but the first idea could be taken in a future version of autoforward, depending how these things will evolve

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/sensor|sensor]]'''''
| draft
| 002
| remote llSensor

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/cancel|cancel]]'''''
| draft
| 001
| release any avatars from any session controlled by an object owned by the owner of the object sending this command

|}

These x-tensions have different stages of maturity but are not currently implemented and neither being worked on at the moment:
{| style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000" border="1"

|-
! x-tension
! [[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|status]]
! version
! description

|-
!'''''gender'''''
| proposal
| 000
| allow the users to set their defined sex, and be queried by a device '''AND SET BY THE DEVICE'''.

|-
!'''''species'''''
| proposal
| 000
| ditto for species.

|-
!'''''control'''''
| proposal
| 000
| makes the victim move as if the control given in argument had been pressed. In conjunction with !x-freeze, this allows the device user to control the victim as if they controlled their own avatar.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/listen|listen]]'''''
| ?
| 001
| opens up a listener on the specified channel. Useful for cutting down the load on a sim by only having multiple listeners as needed.

|-
!'''''animate'''''
| proposal
| 000
| animates the victim with the given animation. The animation has to be a standard one, or an animation from a freebie set we would have to standardize and include in every relay that supports x-animate.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/http-in|http-in]]'''''
| draft
| 002
| initiates a gridwide http encapsulated protocol session, using the new SL server http-in feature.
::::I see it as using exactly the same mechanisms as the email extension. It is likely that one of the two methods should eventually be deprecated as they would have the same use and one of the two has to be more efficient than the other! --[[User:Satomi Ahn|Satomi Ahn]] 10:03, 19 May 2009 (UTC)

|-
!'''''message'''''
| proposal
| 000
| Use the relay to send messages from the restraining device to the victim.
::::Mainly to negate the inconvenients of llInstantMessage as the only means for a restraining device to send a message only to the victim (Especially useful with multi line messages where the inherent script delay for llInstantMessage is more apparent). --[Regan Flasheart] 13:59, 26 June 2009 (UTC)

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/custom|custom]]'''''
| proposal
| 001
| Asks the relay for a list of custom commands or sublists of such. The controlling device issuing this would display the list in a dialog to the device user. Items of the list could include simple actions like triggering animations, or blinding the relay wearer, or even display the menus of various compatible restraints worn by the relay wearer. The idea is to give the possibility for any relay maker to implement various custom extensions without having to wait for every furniture or remote maker to implement them in their menus.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/mode|mode]]'''''
| proposal
| 000
| Queries for relay current auth mode. Answers (in ack) should tell the source useful information such as if the relay is in interactive mode (ask) or not (auto) and the presence of black and white lists.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/safe|safe]]'''''
| proposal
| 000
| Enables safewording in the relay for the current source (if safewording was disabled). Options could specify that only conditional safewording ("evil safeword") should be allowed, thus allowing another way to close a session if the source is not available to send !release. This x-tension should have a command to query the current safewording mode.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/multi|multi]]'''''
| proposal
| 000
| By announcing this x-tension, a relay announces it can support several simultaneous controllers. This x-tension should also contain a command to ask for (an estimation of) a number of available controllers, and a command to close the relay to new controllers.

|-
!'''''[[LSL Protocol/Restrained Love Open Relay Group/status|status]]'''''
| proposal
| 000
| an alternative for @getstatus

|}

These commands are forever deprecated:
{| style="border-collapse: collapse; border-width: 1px; border-style: solid; border-color: #000" border="1"

|-
! x-tension
! [[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|status]]
! version
! description

|-
!<s>'''''(!x-)tensions'''''
| deprecated
| 000
| queries the relay for supported x-tensions.</s> Deprecated by !x-orgversions, which is part of [[LSL_Protocol/Restrained_Love_Open_Relay_Group/ORG_Requirements|ORG core requirements]].

|}

Note: x-tension names do not contain "!x-" or even "x-". Only the meta-commands they define are prefixed that way. One x-tension can define several meta-commands, which must all be implemented if the x-tension is supported.

LSL Protocol/Restrained Love Open Relay Group/channel

2012-07-28T15:48:22Z

Uzume Grigorovich: RestrainedLove

{{Restrained Love Open Relay Group TOC}}

== !x-channel ==

STATUS: draft

VERSION: 001

''001 Implemented in Dahlia's multirelay and the RLV remote control anythingRLV''

''001 Implemented in Satomi's multirelay and Witchy Remote''

!x-channel/xxxx: changes the communication beween relay and controlling device to channel xxxx instead of RLVR, assuming xxxx is a high negative integer.

Motivation: the relay and the device thus stop spamming the RLVR channel with messages that only concerns those two objects.

Scenario:
(session on channel RLVR between R and C)
-RLVR> blah,k(R),!x-channel/-12345
<RLVR- blah,k(C),!x-channel/-12345,ok
(session continues on channel -12345)

Neither R and C are required to listen on channel RLVR after this. It is even recommended that R and C close every useless listener.

Both R and C are required to listen to each other on channel -12345 after this dialog.

C should only propose high negative channels (<1000). The relay is not required to accept any other channel than high negative ones. If the proposed channel is wrong, the relay can "ko" the message.

Recommendation: this command should preferably be used after the session is locked, as the relay is not required to retain any data concerning a non-locking device.

Good practice scenario:
(session on channel RLVR between R and C)
-RLVR> blah,k(R),@randomlockingcommand=n|!x-channel/-12345
<RLVR- blah,k(C),@randomlockingcommand=n,ok
<RLVR- blah,k(C),!x-channel/-12345,ok
(session continues on channel -12345)

It is not recommended to place other commands after the !x-listen, as it is not clear on which channel they should be acknowledged (depending on whether or not the relay ok's the !x-listen, and even when ok'd it is might make relay implementation harder in some cases if the acknowledgement channel changes within a batch of commands).

== Probably to be deprecated ==

See [[llRegionSayTo]].

--[[User:Satomi Ahn|Satomi Ahn]] 06:18, 7 May 2011 (PDT)

Template:Restrained Love Open Relay Group TOC

2012-07-28T15:47:54Z

Uzume Grigorovich: Restrained Love Relay Specs TOC

Template:Restrained Love Open Relay Group TOC

2012-07-28T15:44:58Z

Uzume Grigorovich: cleanup

<div class="floatright">
<div class="navbox" style="width:20em; font-weight:bold">
<div style="text-align:center">Restrained Love<br/>Open Relay Group<br/>x-tensions</div>
*[[LSL Protocol/Restrained Love Open Relay Group|ORG Home]]
*[[LSL Protocol/Restrained Love Open Relay Group/ORG Logo|Logo]]
*[[LSL Protocol/Restrained Love Open Relay Group/ORG Introduction|ORG Introduction]]
*[[LSL Protocol/Restrained Love Open Relay Group/ORG Requirements|ORG Requirements]]
*[[LSL Protocol/Restrained Love Open Relay Group/Prefix|ORG Prefix]]
*[[LSL Protocol/Restrained Love Open Relay Group/x-tensions|x-tensions, full list]]
*[[LSL Protocol/Restrained Love Open Relay Group/x-tensions Validation Process|x-tensions, validation process]]
</div>
<div class="navbox" style="width:20em; font-weight:bold">
*[[LSL Protocol/Restrained Love Relay|Basic Relay Pages]]
</div>
</div>
<includeonly>[[Category:RestrainedLove]]</includeonly>

Category:RestrainedLove/Documentation/Command

2012-07-28T15:33:23Z

Uzume Grigorovich: cat sort

This category collects all Restrained Love API commands.

== Function Index ==
{{#vardefine:path|User:Toy_Wylie/RLV_Documentation}}

*[[{{#var:path}}/acceptpermission|@acceptpermission]]
*[[{{#var:path}}/accepttp|@accepttp]]
*[[{{#var:path}}/addattach|@addattach]]
*[[{{#var:path}}/addoutfit|@addoutfit]]
*[[{{#var:path}}/attach|@attach]]
*[[{{#var:path}}/attachall|@attachall]]
*[[{{#var:path}}/attachallthis|@attachallthis]]
*[[{{#var:path}}/attachthis|@attachthis]]
*[[{{#var:path}}/chatnormal|@chatnormal]]
*[[{{#var:path}}/chatshout|@chatshout]]
*[[{{#var:path}}/chatwhisper|@chatwhisper]]
*[[{{#var:path}}/clear|@clear]]
*[[{{#var:path}}/defaultwear|@defaultwear]]
*[[{{#var:path}}/denypermission|@denypermission]]
*[[{{#var:path}}/detach|@detach]]
*[[{{#var:path}}/detachall|@detachall]]
*[[{{#var:path}}/detachallthis|@detachallthis]]
*[[{{#var:path}}/detachme|@detachme]]
*[[{{#var:path}}/detachthis|@detachthis]]
*[[{{#var:path}}/edit|@edit]]
*[[{{#var:path}}/emote|@emote]]
*[[{{#var:path}}/fartouch|@fartouch]]
*[[{{#var:path}}/findfolder|@findfolder]]
*[[{{#var:path}}/fly|@fly]]
*[[{{#var:path}}/getattach|@getattach]]
*[[{{#var:path}}/getdebug_|@getdebug_]]
*[[{{#var:path}}/getenv|@getenv]]
*[[{{#var:path}}/getinv|@getinv]]
*[[{{#var:path}}/getinvworn|@getinvworn]]
*[[{{#var:path}}/getoutfit|@getoutfit]]
*[[{{#var:path}}/getpath|@getpath]]
*[[{{#var:path}}/getsitid|@getsitid]]
*[[{{#var:path}}/getstatus|@getstatus]]
*[[{{#var:path}}/getstatusall|@getstatusall]]
*[[{{#var:path}}/notify|@notify]]
*[[{{#var:path}}/permissive|@permissive]]
*[[{{#var:path}}/recvchat|@recvchat]]
*[[{{#var:path}}/recvchat_sec|@recvchat_sec]]
*[[{{#var:path}}/recvemote|@recvemote]]
*[[{{#var:path}}/recvemote_sec|@recvemote_sec]]
*[[{{#var:path}}/recvim|@recvim]]
*[[{{#var:path}}/recvim_sec|@recvim_sec]]
*[[{{#var:path}}/redirchat|@redirchat]]
*[[{{#var:path}}/rediremote|@rediremote]]
*[[{{#var:path}}/remattach|@remattach]]
*[[{{#var:path}}/remoutfit|@remoutfit]]
*[[{{#var:path}}/rez|@rez]]
*[[{{#var:path}}/sendchannel|@sendchannel]]
*[[{{#var:path}}/sendchannel_sec|@sendchannel_sec]]
*[[{{#var:path}}/sendchat|@sendchat]]
*[[{{#var:path}}/sendim|@sendim]]
*[[{{#var:path}}/sendim_sec|@sendim_sec]]
*[[{{#var:path}}/setdebug|@setdebug]]
*[[{{#var:path}}/setdebug_|@setdebug_]]
*[[{{#var:path}}/setdebug_avatarsex|@setdebug_avatarsex]]
*[[{{#var:path}}/setdebug_renderresolutiondivisor|@setdebug_renderresolutiondivisor]]
*[[{{#var:path}}/setenv|@setenv]]
*[[{{#var:path}}/setrot|@setrot]]
*[[{{#var:path}}/showhovertext|@showhovertext]]
*[[{{#var:path}}/showhovertextall|@showhovertextall]]
*[[{{#var:path}}/showhovertexthud|@showhovertexthud]]
*[[{{#var:path}}/showhovertextworld|@showhovertextworld]]
*[[{{#var:path}}/showinv|@showinv]]
*[[{{#var:path}}/showloc|@showloc]]
*[[{{#var:path}}/showminimap|@showminimap]]
*[[{{#var:path}}/shownames|@shownames]]
*[[{{#var:path}}/showworldmap|@showworldmap]]
*[[{{#var:path}}/sit|@sit]]
*[[{{#var:path}}/sittp|@sittp]]
*[[{{#var:path}}/tplm|@tplm]]
*[[{{#var:path}}/tploc|@tploc]]
*[[{{#var:path}}/tplure|@tplure]]
*[[{{#var:path}}/tplure_sec|@tplure_sec]]
*[[{{#var:path}}/tpto|@tpto]]
*[[{{#var:path}}/unsit|@unsit]]
*[[{{#var:path}}/version|@version]]
*[[{{#var:path}}/versionnew|@versionnew]]
*[[{{#var:path}}/versionnum|@versionnum]]
*[[{{#var:path}}/viewnote|@viewnote]]
*[[{{#var:path}}/viewscript|@viewscript]]
*[[{{#var:path}}/viewtexture|@viewtexture]]

[[Category:RestrainedLove/Documentation|{{SUBPAGENAME}}]]

Category:RestrainedLove/Documentation

2012-07-28T15:32:46Z

Uzume Grigorovich: cat sort

This category is for documentation around the Restrained Love Viewer API: [[User:Toy Wylie/RLV Documentation|RLV Documentation]]

[[Category:RestrainedLove|{{SUBPAGENAME}}]]

User:Toy Wylie/RLV Documentation/Function Index

2012-07-28T15:24:04Z

Uzume Grigorovich: typo

#REDIRECT [[:Category:RestrainedLove/Documentation/Command]]

Template:RLV Documentation/Command

2012-07-28T15:22:42Z

Uzume Grigorovich: cat sort

__NOTOC__{{#if:{{{lock|}}}|
<div style="background:#ff9999; padding:1em; font-size:12px; text-align:center">'''LOCKED - Locked by {{{lock}}} - Please do not modify! - LOCKED'''</div>}}

== @{{SUBPAGENAME}} ==

{{#if:{{{deprecated|}}}|<div id="box" style="margin-top:2em; clear:both; color:red">
<h2>DEPRECATED</h2>
<div style="padding: 0.5em">'''This function is DEPRECATED - Do not use it!'''</div>
</div>}}

<div id="box" style="margin-top:2em; float:right">
<h2>Type</h2>
<div style="padding: 0.5em">{{{type|<noinclude>"Restriction", "Force", "Exception" or "General"</noinclude>}}}</div>
</div>

<div id="box" style="margin-top:2em; margin-right:2em; float:right">
<h2>Implemented</h2>
<div style="padding:0.5em">Implemented since RLV version {{{version|<noinclude>NUMBER</noinclude>}}}</div>
</div>

<div id="box" style="margin-top:2em; float:left">
<h2>Usage</h2>
<div style="padding: 0.5em">{{{usage|<noinclude>Usage here</noinclude>}}}</div>
</div>

<div id="box" style="margin-top:2em; clear:both">
<h2>Purpose</h2>
<div style="padding: 0.5em">{{{purpose|<noinclude>Purpose of this command here</noinclude>}}}</div>
</div>

{{#if:{{{notes|}}}|<div id="box" style="margin-top:2em; clear:both">
<h2>Notes</h2>
<div style="padding:0.5em">{{{notes|<noinclude>Additional notes go here</noinclude>}}}</div>
</div>}}

<div id="box" style="margin-top:2em">
<h2>See Also</h2>
<div style="padding: 0.5em">{{#if:{{{seealso|}}}|
{{#vardefine:path|User:Toy Wylie/RLV Documentation/}}
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |0}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |1}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |2}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |3}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |4}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |5}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |6}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |7}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |8}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{{seealso}}}| |9}}}}{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
}} }} }} }} }} }} }} }} }} }}<noinclude>|
*List of related commands here</noinclude>}}
{{#if:{{{seealsoalso|}}}|{{{seealsoalso}}}<noinclude>|Further notes here<noinclude>}}
</div>
</div>

<div id="box" style="margin-top:2em">
<h2>{{#if:{{{example_2|}}}|Example 1|Example}}</h2>
<div style="padding:0.5em">{{{example<noinclude>|Example LSL code here</noinclude>}}}</div>
</div>

{{#if:{{{example_2|}}}|<div id="box" style="margin-top:2em">
<h2>Example 2</h2>
<div style="padding:0.5em">{{{example_2<noinclude>|Second Example LSL code here</noinclude>}}}</div>
</div>}}

[[Category:RestrainedLove/Documentation/Command<includeonly>|{{SUBPAGENAME}}</includeonly>]]

Template:RLV Documentation/Command

2012-07-28T15:21:46Z

Uzume Grigorovich: cleanup

Template:RLV Documentation/Command

2012-07-28T14:34:47Z

Uzume Grigorovich: list

__NOTOC__{{#if:{{{lock|}}}|
<div style="background: #ff9999; padding: 1em; font-size: 12px; text-align: center;">'''LOCKED - Locked by {{{lock}}} - Please do not modify! - LOCKED'''</div>
}}
== @{{SUBPAGENAME}} ==

{{#if:{{{deprecated|}}}|
<div id="box" style="margin-top: 2em; clear: both; color: red;"><h2>DEPRECATED</h2>
<div style="padding: 0.5em;">
'''This function is DEPRECATED - Do not use it!'''
</div></div>
|}}

<div id="box" style="margin-top: 2em; float: right;"><h2>Type</h2>
<div style="padding: 0.5em;">
{{{type|<noinclude>"Restriction", "Force", "Exception" or "General"</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; margin-right: 2em; float: right;"><h2>Implemented</h2>
<div style="padding: 0.5em;">
Implemented since RLV version {{{version|<noinclude>NUMBER</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; float: left;"><h2>Usage</h2>
<div style="padding: 0.5em;">
{{{usage|<noinclude>Usage here</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; clear: both;"><h2>Purpose</h2>
<div style="padding: 0.5em;">
{{{purpose|<noinclude>Purpose of this command here</noinclude>}}}
</div></div>
{{#if:{{{notes|}}}|
<div id="box" style="margin-top: 2em; clear: both;"><h2>Notes</h2>
<div style="padding: 0.5em;">
{{{notes|<noinclude>Additional notes go here</noinclude>}}}
</div></div>
}}
<div id="box" style="margin-top: 2em;"><h2>See Also</h2>
<div style="padding: 0.5em;">
{{#if:{{{seealso|}}}|

{{#vardefine:path|User:Toy_Wylie/RLV_Documentation/}}
{{#vardefine:commands|{{{seealso}}}}}

{{#vardefine:cmd|{{#explode:{{#var:commands}}| |0}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |1}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |2}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |3}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |4}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |5}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |6}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |7}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |8}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |9}}}}
{{#if:{{#var:cmd|}}|*[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
}} }} }} }} }} }} }} }} }} }}

|<noinclude>List of related commands here</noinclude>}}
{{#if:{{{seealsoalso|}}}|{{#if:{{{seealso|}}}|<br />}}
{{{seealsoalso}}}|<noinclude>Further notes here</noinclude>}}
</div></div>

<div id="box" style="margin-top: 2em;"><h2>Example {{#if:{{{example_2|}}}|1}}</h2>
<div style="padding: 0.5em;">
{{{example|<noinclude>Example LSL code here</noinclude>}}}
</div></div>

{{#if:{{{example_2|}}}|
<div id="box" style="margin-top: 2em;"><h2>Example 2</h2>
<div style="padding: 0.5em;">
{{{example_2|<noinclude>Second Example LSL code here</noinclude>}}}
</div></div>
}}<includeonly>
[[Category:RestrainedLove/Documentation/Command|{{SUBPAGENAME}}]]
</includeonly><noinclude>
[[Category:RestrainedLove/Documentation]]
</noinclude>

User:Toy Wylie/RLV Documentation

2012-07-28T14:30:52Z

Uzume Grigorovich: typo

== Restrained Love Documentation ==

I want to start a proper documentation of the available Restrained Love (RLV) functions, their usage and caveats. Since I don't know yet how to structure this properly, I don't want to pollute the LSL_Protocol namespace yet. So the document will be found here for the time being.

Be aware that this is a documentation on how to use the commands only, not how to use them together with a relay. This will be part of another project. RLV only works with objects you own yourself - for example, in attachments - so all of the example scripts use the [[llOwnerSay]] command.

[[:Category:RestrainedLove/Documentation/Command|Alphabetical Function Index]]

= Function Groups =

*[[/General|General]]
*[[/Chat|Chat]]
*[[/Movement|Movement]]
*[[/Outfit|Outfit]]
*[[/Interaction|Interaction]]
*[[/Informational|Informational]]
*[[/Environment|Environment]]
**@setdebug_renderresolutiondivisor
**@setenv_
**@showhovertext
**@showhovertextall
**@showhovertexthud
**@showhovertextworld
**@shownames
*[[/User Interface|User Interface]]
**@setenv
**@setdebug
**@showinv
**@showloc
**@showminimap
**@showworldmap
**@viewnote
**@viewscript
**@viewtexture
*[[/Shared Items|Shared Items]]
**@attach
**@attachall
**@attachallover
**@attachallthis
**@attachallthisover
**@attachover
**@attachthis
**@attachthisover
**@detach
**@detachall
**@detachallthis
**@detachthis
**@findfolder
**@getinv
**@getinvworn
**@getpath
**@getpathnew

[[Category:RestrainedLove/Documentation|*]]
[[Category:RestrainedLove|{{SUBPAGENAME}}]]

User:Toy Wylie/RLV Documentation

2012-07-28T14:28:07Z

Uzume Grigorovich: cat sort

== Restrained Love Documentation ==

I want to start a proper documentation of the available Restrained Love (RLV) functions, their usage and caveats. Since I don't know yet how to structure this properly, I don't want to pollute the LSL_Protocol namespace yet. So the document will be found here for the time being.

Be aware that this is a documentation on how to use the commands only, not how to use them together with a relay. This will be part of another project. RLV only works with objects you own yourself - for example, in attachments - so all of the example scripts use the [[llOwnerSay]] command.

[[Category:RestrainedLove/Documentation/Command|Alphabetical Function Index]]

= Function Groups =

*[[/General|General]]
*[[/Chat|Chat]]
*[[/Movement|Movement]]
*[[/Outfit|Outfit]]
*[[/Interaction|Interaction]]
*[[/Informational|Informational]]
*[[/Environment|Environment]]
**@setdebug_renderresolutiondivisor
**@setenv_
**@showhovertext
**@showhovertextall
**@showhovertexthud
**@showhovertextworld
**@shownames
*[[/User Interface|User Interface]]
**@setenv
**@setdebug
**@showinv
**@showloc
**@showminimap
**@showworldmap
**@viewnote
**@viewscript
**@viewtexture
*[[/Shared Items|Shared Items]]
**@attach
**@attachall
**@attachallover
**@attachallthis
**@attachallthisover
**@attachover
**@attachthis
**@attachthisover
**@detach
**@detachall
**@detachallthis
**@detachthis
**@findfolder
**@getinv
**@getinvworn
**@getpath
**@getpathnew

[[Category:RestrainedLove/Documentation|*]]
[[Category:RestrainedLove|{{SUBPAGENAME}}]]

Category:RestrainedLove/Documentation

2012-07-28T14:20:36Z

Uzume Grigorovich: link

This category is for documentation around the Restrained Love Viewer API: [[User:Toy Wylie/RLV Documentation|RLV Documentation]]

[[Category:RestrainedLove]]

User:Toy Wylie/RLV Documentation/Function Index

2012-07-28T14:18:49Z

Uzume Grigorovich: redir to cat

#REDIRECT [[Category:RestrainedLove/Documentation/Command]]

Category:RestrainedLove/Documentation/Command

2012-07-28T14:15:03Z

Uzume Grigorovich: function index

Template:RLV Documentation/Command

2012-07-28T14:11:59Z

Uzume Grigorovich: SUBPAGENAME better than passing in command name

__NOTOC__{{#if:{{{lock|}}}|
<div style="background: #ff9999; padding: 1em; font-size: 12px; text-align: center;">'''LOCKED - Locked by {{{lock}}} - Please do not modify! - LOCKED'''</div>
}}
== @{{SUBPAGENAME}} ==

{{#if:{{{deprecated|}}}|
<div id="box" style="margin-top: 2em; clear: both; color: red;"><h2>DEPRECATED</h2>
<div style="padding: 0.5em;">
'''This function is DEPRECATED - Do not use it!'''
</div></div>
|}}

<div id="box" style="margin-top: 2em; float: right;"><h2>Type</h2>
<div style="padding: 0.5em;">
{{{type|<noinclude>"Restriction", "Force", "Exception" or "General"</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; margin-right: 2em; float: right;"><h2>Implemented</h2>
<div style="padding: 0.5em;">
Implemented since RLV version {{{version|<noinclude>NUMBER</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; float: left;"><h2>Usage</h2>
<div style="padding: 0.5em;">
{{{usage|<noinclude>Usage here</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; clear: both;"><h2>Purpose</h2>
<div style="padding: 0.5em;">
{{{purpose|<noinclude>Purpose of this command here</noinclude>}}}
</div></div>
{{#if:{{{notes|}}}|
<div id="box" style="margin-top: 2em; clear: both;"><h2>Notes</h2>
<div style="padding: 0.5em;">
{{{notes|<noinclude>Additional notes go here</noinclude>}}}
</div></div>
}}
<div id="box" style="margin-top: 2em;"><h2>See Also</h2>
<div style="padding: 0.5em;">
{{#if:{{{seealso|}}}|

{{#vardefine:path|User:Toy_Wylie/RLV_Documentation/}}
{{#vardefine:commands|{{{seealso}}}}}

{{#vardefine:cmd|{{#explode:{{#var:commands}}| |0}}}}
{{#if:{{#var:cmd|}}|[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |1}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |2}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |3}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |4}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |5}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |6}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |7}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |8}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |9}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
}} }} }} }} }} }} }} }} }} }}

|<noinclude>List of related commands here</noinclude>}}
{{#if:{{{seealsoalso|}}}|{{#if:{{{seealso|}}}|<br />}}
{{{seealsoalso}}}|<noinclude>Further notes here</noinclude>}}
</div></div>

<div id="box" style="margin-top: 2em;"><h2>Example {{#if:{{{example_2|}}}|1}}</h2>
<div style="padding: 0.5em;">
{{{example|<noinclude>Example LSL code here</noinclude>}}}
</div></div>

{{#if:{{{example_2|}}}|
<div id="box" style="margin-top: 2em;"><h2>Example 2</h2>
<div style="padding: 0.5em;">
{{{example_2|<noinclude>Second Example LSL code here</noinclude>}}}
</div></div>
}}<includeonly>
[[Category:RestrainedLove/Documentation/Command|{{SUBPAGENAME}}]]
</includeonly><noinclude>
[[Category:RestrainedLove/Documentation]]
</noinclude>

Template:RLV Documentation/Command

2012-07-28T14:10:20Z

Uzume Grigorovich: cat sort

__NOTOC__{{#if:{{{lock|}}}|
<div style="background: #ff9999; padding: 1em; font-size: 12px; text-align: center;">'''LOCKED - Locked by {{{lock}}} - Please do not modify! - LOCKED'''</div>
}}
== {{{command}}} ==

{{#if:{{{deprecated|}}}|
<div id="box" style="margin-top: 2em; clear: both; color: red;"><h2>DEPRECATED</h2>
<div style="padding: 0.5em;">
'''This function is DEPRECATED - Do not use it!'''
</div></div>
|}}

<div id="box" style="margin-top: 2em; float: right;"><h2>Type</h2>
<div style="padding: 0.5em;">
{{{type|<noinclude>"Restriction", "Force", "Exception" or "General"</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; margin-right: 2em; float: right;"><h2>Implemented</h2>
<div style="padding: 0.5em;">
Implemented since RLV version {{{version|<noinclude>NUMBER</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; float: left;"><h2>Usage</h2>
<div style="padding: 0.5em;">
{{{usage|<noinclude>Usage here</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; clear: both;"><h2>Purpose</h2>
<div style="padding: 0.5em;">
{{{purpose|<noinclude>Purpose of this command here</noinclude>}}}
</div></div>
{{#if:{{{notes|}}}|
<div id="box" style="margin-top: 2em; clear: both;"><h2>Notes</h2>
<div style="padding: 0.5em;">
{{{notes|<noinclude>Additional notes go here</noinclude>}}}
</div></div>
}}
<div id="box" style="margin-top: 2em;"><h2>See Also</h2>
<div style="padding: 0.5em;">
{{#if:{{{seealso|}}}|

{{#vardefine:path|User:Toy_Wylie/RLV_Documentation/}}
{{#vardefine:commands|{{{seealso}}}}}

{{#vardefine:cmd|{{#explode:{{#var:commands}}| |0}}}}
{{#if:{{#var:cmd|}}|[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |1}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |2}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |3}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |4}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |5}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |6}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |7}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |8}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |9}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
}} }} }} }} }} }} }} }} }} }}

|<noinclude>List of related commands here</noinclude>}}
{{#if:{{{seealsoalso|}}}|{{#if:{{{seealso|}}}|<br />}}
{{{seealsoalso}}}|<noinclude>Further notes here</noinclude>}}
</div></div>

<div id="box" style="margin-top: 2em;"><h2>Example {{#if:{{{example_2|}}}|1}}</h2>
<div style="padding: 0.5em;">
{{{example|<noinclude>Example LSL code here</noinclude>}}}
</div></div>

{{#if:{{{example_2|}}}|
<div id="box" style="margin-top: 2em;"><h2>Example 2</h2>
<div style="padding: 0.5em;">
{{{example_2|<noinclude>Second Example LSL code here</noinclude>}}}
</div></div>
}}<includeonly>
[[Category:RestrainedLove/Documentation/Command|{{SUBPAGENAME}}]]
</includeonly><noinclude>
[[Category:RestrainedLove/Documentation]]
</noinclude>

Template:RLV Documentation/Command

2012-07-28T14:04:02Z

Uzume Grigorovich: cat sort

__NOTOC__{{#if:{{{lock|}}}|
<div style="background: #ff9999; padding: 1em; font-size: 12px; text-align: center;">'''LOCKED - Locked by {{{lock}}} - Please do not modify! - LOCKED'''</div>
}}
== {{{command}}} ==

{{#if:{{{deprecated|}}}|
<div id="box" style="margin-top: 2em; clear: both; color: red;"><h2>DEPRECATED</h2>
<div style="padding: 0.5em;">
'''This function is DEPRECATED - Do not use it!'''
</div></div>
|}}

<div id="box" style="margin-top: 2em; float: right;"><h2>Type</h2>
<div style="padding: 0.5em;">
{{{type|<noinclude>"Restriction", "Force", "Exception" or "General"</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; margin-right: 2em; float: right;"><h2>Implemented</h2>
<div style="padding: 0.5em;">
Implemented since RLV version {{{version|<noinclude>NUMBER</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; float: left;"><h2>Usage</h2>
<div style="padding: 0.5em;">
{{{usage|<noinclude>Usage here</noinclude>}}}
</div></div>

<div id="box" style="margin-top: 2em; clear: both;"><h2>Purpose</h2>
<div style="padding: 0.5em;">
{{{purpose|<noinclude>Purpose of this command here</noinclude>}}}
</div></div>
{{#if:{{{notes|}}}|
<div id="box" style="margin-top: 2em; clear: both;"><h2>Notes</h2>
<div style="padding: 0.5em;">
{{{notes|<noinclude>Additional notes go here</noinclude>}}}
</div></div>
}}
<div id="box" style="margin-top: 2em;"><h2>See Also</h2>
<div style="padding: 0.5em;">
{{#if:{{{seealso|}}}|

{{#vardefine:path|User:Toy_Wylie/RLV_Documentation/}}
{{#vardefine:commands|{{{seealso}}}}}

{{#vardefine:cmd|{{#explode:{{#var:commands}}| |0}}}}
{{#if:{{#var:cmd|}}|[[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |1}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |2}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |3}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |4}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |5}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |6}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |7}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |8}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
{{#vardefine:cmd|{{#explode:{{#var:commands}}| |9}}}}
{{#if:{{#var:cmd|}}| [[{{#var:path}}{{#var:cmd|}}|@{{#var:cmd|}}]]
}} }} }} }} }} }} }} }} }} }}

|<noinclude>List of related commands here</noinclude>}}
{{#if:{{{seealsoalso|}}}|{{#if:{{{seealso|}}}|<br />}}
{{{seealsoalso}}}|<noinclude>Further notes here</noinclude>}}
</div></div>

<div id="box" style="margin-top: 2em;"><h2>Example {{#if:{{{example_2|}}}|1}}</h2>
<div style="padding: 0.5em;">
{{{example|<noinclude>Example LSL code here</noinclude>}}}
</div></div>

{{#if:{{{example_2|}}}|
<div id="box" style="margin-top: 2em;"><h2>Example 2</h2>
<div style="padding: 0.5em;">
{{{example_2|<noinclude>Second Example LSL code here</noinclude>}}}
</div></div>
}}<includeonly>
[[Category:RestrainedLove/Documentation/Command|{{#explode:{{{command}}}|@|1}}]]
</includeonly><noinclude>
[[Category:RestrainedLove/Documentation]]
</noinclude>

User:Toy Wylie/RLV Documentation/Outfit

2012-07-28T13:57:48Z

Uzume Grigorovich: cat sort

== Outfit Functions ==

{| border=1 cellspacing="0" cellpadding="2"
|-
| [[User:Toy_Wylie/RLV_Documentation/attach|@attach]]
| Forces the user to attach all items inside a shared folder
|-
| [[User:Toy_Wylie/RLV_Documentation/addattach|@addattach]]
| Blocks the user from attaching something to a certain attachment spot
|-
| [[User:Toy_Wylie/RLV_Documentation/addoutfit|@addoutfit]]
| Blocks the user from wearing a certain type of clothing
|-
| [[User:Toy_Wylie/RLV_Documentation/defaultwear|@defaultwear]]
| Disables the "Wear" contect menu item to prevent kicking off of attachments
|-
| [[User:Toy_Wylie/RLV_Documentation/detach|@detach]]
| Prevent the user from detaching an object, or forcing them to detach an object or a folder
|-
| [[User:Toy_Wylie/RLV_Documentation/detachme|@detachme]]
| Detaches the object issuing this command
|-
| [[User:Toy_Wylie/RLV_Documentation/getattach|@getattach]]
| Retrieve a list of all attachments currently worn
|-
| [[User:Toy_Wylie/RLV_Documentation/getoutfit|@getoutfit]]
| Retrieve a list of all clothes currently worn
|-
| [[User:Toy_Wylie/RLV_Documentation/remattach|@remattach]]
| Blocks the user from detaching an object or forcing them to detach it
|-
| [[User:Toy_Wylie/RLV_Documentation/remoutfit|@remoutfit]]
| Blocks the user from removing a certain type of clothing or forcing them to remove it
|}

[[Category:RestrainedLove/Documentation|{{SUBPAGENAME}}]]

User:Toy Wylie/RLV Documentation/Movement

2012-07-28T13:57:36Z

Uzume Grigorovich: cat sort

== Movement Functions ==

{| border=1 cellspacing="0" cellpadding="2"
|-
| [[User:Toy_Wylie/RLV_Documentation/accepttp|@accepttp]]
| Automatically accepts teleport requests from certain people or from everyone
|-
| [[User:Toy_Wylie/RLV_Documentation/fly|@fly]]
| Forbids the user to fly
|-
| [[User:Toy_Wylie/RLV_Documentation/setrot|@setrot]]
| Rotates the user's avatar to a given orientation
|-
| [[User:Toy_Wylie/RLV_Documentation/sittp|@sittp]]
| Forbids the user from sitting on objects that are far away
|-
| [[User:Toy_Wylie/RLV_Documentation/standtp|@standtp]]
| Makes sure to move the avatar back to the position they were before sitting down
|-
| [[User:Toy_Wylie/RLV_Documentation/tplm|@tplm]]
| Blocks the user from teleporting using landmarks
|-
| [[User:Toy_Wylie/RLV_Documentation/tploc|@tploc]]
| Blocks the user from teleporting using the map or other means
|-
| [[User:Toy_Wylie/RLV_Documentation/tplure|@tplure]]<br />[[User:Toy_Wylie/RLV_Documentation/tplure_sec|@tplure_sec]]
| Blocks the user from accepting teleports from others or adds an exception to the block
|-
| [[User:Toy_Wylie/RLV_Documentation/tpto|@tpto]]
| Teleports the user to a given location without confirmation
|}

[[Category:RestrainedLove/Documentation|{{SUBPAGENAME}}]]

User:Toy Wylie/RLV Documentation/Interaction

2012-07-28T13:57:22Z

Uzume Grigorovich: cat sort

== Interaction Functions ==

{| border=1 cellspacing="0" cellpadding="2"
|-
| [[User:Toy_Wylie/RLV_Documentation/edit|@edit]]
| Prevents the user from editing objects
|-
| [[User:Toy_Wylie/RLV_Documentation/fartouch|@fartouch]]
| Prevents the user from clicking on (touching) objects that are far away
|-
| [[User:Toy_Wylie/RLV_Documentation/rez|@rez]]
| Blocks the user from rezzing or creating objects
|-
| [[User:Toy_Wylie/RLV_Documentation/sit|@sit]]
| Blocks the user from sitting down or forces the user to sit on a specific object
|-
| [[User:Toy_Wylie/RLV_Documentation/unsit |@unsit ]]
| Forbids the user to stand up or forces them to stand up immediately
|}

[[Category:RestrainedLove/Documentation|{{SUBPAGENAME}}]]

User:Toy Wylie/RLV Documentation/Informational

2012-07-28T13:57:06Z

Uzume Grigorovich: cat sort

== Informational Functions ==

{| border=1 cellspacing="0" cellpadding="2"
|-
| [[User:Toy_Wylie/RLV_Documentation/getdebug_avatarsex|@getdebug_avatarsex]]
| Get the avatar's gender
|-
| [[User:Toy_Wylie/RLV_Documentation/getdebug_renderresolutiondivisor|@getdebug_renderresolutiondivisor]]
| Get the current screen blurriness
|-
| [[User:Toy_Wylie/RLV_Documentation/getenv|@getenv]]
| A set of functions to get the environmental values of the user
|-
| [[User:Toy_Wylie/RLV_Documentation/getsitid|@getsitid]]
| Get the key of the object the user is sitting on
|-
| [[User:Toy_Wylie/RLV_Documentation/getstatus|@getstatus]]
| Get a list of restrictions placed on the user by this object
|-
| [[User:Toy_Wylie/RLV_Documentation/getstatusall|@getstatusall]]
| Get a list of all restrictions the user is currently subject to
|-
| [[User:Toy_Wylie/RLV_Documentation/notify|@notify]]
| Get notified if certain restrictions are applied or removed
|-
| [[User:Toy_Wylie/RLV_Documentation/version|@version]]
| Gets a version string from the user's RLV compliant viewer (deprecated)
|-
| [[User:Toy_Wylie/RLV_Documentation/versionnew|@versionnew]]
| Gets a version string from the user's RLV compliant viewer
|-
| [[User:Toy_Wylie/RLV_Documentation/versionnum|@versionnum]]
| Gets the RLV version the user's client implements
|}

[[Category:RestrainedLove/Documentation|{{SUBPAGENAME}}]]

User:Toy Wylie/RLV Documentation/General

2012-07-28T13:56:50Z

Uzume Grigorovich: cat sort

== General Functions ==

{| border=1 cellspacing="0" cellpadding="2"
|-
| [[User:Toy_Wylie/RLV_Documentation/acceptpermission|@acceptpermission]]
| Removes the permission dialog for control and attach requests
|-
| [[User:Toy_Wylie/RLV_Documentation/clear|@clear]]
| Releases all restrictions placed on the avatar by this object
|-
| [[User:Toy_Wylie/RLV_Documentation/denypermission|@denypermission]]
| Denies all permission requests for control and attach automatically
|-
| [[User:Toy_Wylie/RLV_Documentation/permissive|@permissive]]
| Turns all commands that have a _sec counterpart into their secure variations
|-
| [[User:Toy_Wylie/RLV_Documentation/setdebug_avatarsex|@setdebug_avatarsex]]
| Set the avatar's gender
|}

[[Category:RestrainedLove/Documentation|{{SUBPAGENAME}}]]