nyuuzyou/wikis huggingface dataset:
LSL Protocol/Restrained Love Open Relay Group/autoforward

= autoforward =
STATUS: draft
version: 001
Implemented in Dahlia's multirelay 1.2.14 and anythingRLV3.6RC8
Two new commands !x-autoforward and !x-autoforward/clear explained below.
==Description of !x-autoforward and !x-autoforward/clear==
The relay must answer ok if and only if the source is a grabber. Otherwise the answer is always ko. The effect of this command is as follows: for any command @getsomething:xxx=channel, the relay must listen to the viewer's answer and resend it (by email, chat using llRegionSayTo(), http-in) together with the number of the channel.
Typical exchange (if C is already accepted by the relay) in chat session:
 C -chat on RLVRC-> R: enable_forward,!x-autoforward
 C <-chat on RLVRC- R: enable_forward,!x-autoforward,ok
 C -chat on RLVRC-> R: outfit_query,@getoutfit=1111
 C <-chat on RLVRC- R: outfit_query,@getoutfit=1111,ok
 R --llOwnerSay--> V: @getoutfit=1111
 R <-chat on 1111- V: 0010011111111110
 C <-chat on RLCRC- R: 1111,0010011111111110
To disable autoforwarding: 
 C -chat on RLVRC-> R: disable_forward,!x-autoforward/clear
 C <-chat on RLVRC- R: disable_forward,!x-autoforward/clear,ok
Typical exchange (if C is already accepted by the relay) in !x-email session:
 C -chat on RLVRC-> R: enable_forward,!x-autoforward
 C <-chat on RLVRC- R: enable_forward,!x-autoforward,ok
 C -chat on RLVRC-> R: outfit_query,@getoutfit=1111
 C <-chat on RLVRC- R: outfit_query,@getoutfit=1111,ok
 R --llOwnerSay--> V: @getoutfit=1111
 R <-chat on 1111- V: 0010011111111110
 C <------email---- R: 1111,0010011111111110
Other point: if autoforward is enabled, "@notify:channel;option" sets a permanent listener on that channel in the relay, and the relay will forward everything that comes from the viewer on this channel to the contoller.
 C -chat on RLVRC-> R: spy_outfit_changes,@notify:1111;worn=add
 C <-chat on RLVRC- R: spy_outfit_changes,@notify:1111;worn=add,ok
 R --llOwnerSay--> V: @notify:1111;worn=add
 ...
 R <-chat on 1111- V: /worn legally shirt
 C <-chat on RLVRC- R: 1111,/worn legally shirt
 ...
 R <-chat on 1111- V: /unworn legally pants
 C <-chat on RLVRC- R: 1111,/unworn legally pants
 ...
Remark
* After a !x-autoforward/clear, all listeners opened during the autoforwarding must be closed.
== Interaction with !x-channel ==
If the controller and the relay are in a private chat session using !x-channel,the forwarding must be done on the private channel (and the acknoledgments of receipt must be sent in the private channel too, as usual).
==Interaction with !x-handover==
After a !x-handover, the next grabber must send a new !x-autoforward if required. So all listeners opened by the relay for the preceding grabber must be closed.
LSL Protocol/Restrained Love Open Relay Group/cancel

= cancel =
STATUS: draft
version: 001
Implemented in Dahlia's multirelay 1.2.22 and anythingRLV3.7beta
* A unique command !x-cancel
==Description of !x-cancel==
===Syntax===
The relay must always answer !x-cancel,ok if it is supported. There are no exceptions !!
===Semantics===
 
The effect of this command is to release the relay from all sessions controlled by objects owned by the same owner as the owner of the script which sends the !x-cancel. There are no exceptions to this behaviour !!
==A script for releasing an avatar==
<lsl>
// Author Dahlia Orfan (June 2011)
// Put this script in a prim (rezzed or worn); touch this prim 
// and type in the box the username of the avatar to release.
// If the avatar's relay supports !x-cancel, all sessions controlled
// by one of your devices will be cancelled. 
string avatar;
integer listener;
 default
 {
 touch_end(integer num)
 {
 if (llDetectedKey(0) != llGetOwner())
 return;
 integer channel = -1000000 - (integer)llFrand(1000000);
 llListenRemove(listener);
 listener = llListen(channel,"",llGetOwner(),"");
 llTextBox(llGetOwner(),
 "\n\nEnter the username of the avatar to release from your own devices (case sensitive)"
 ,channel);
 llSetTimerEvent(60.0);
 }
 listen(integer channel,string name,key id,string message)
 {
 llListenRemove(listener);
 llSetTimerEvent(0.0);
 integer n = llGetListLength(llParseString2List(message,[" "],[]));
 if (n == 1)
 message += " Resident";
 avatar = message;
 llSensor(avatar,NULL_KEY,AGENT,95.0,PI);
 }
 sensor(integer num)
 {
 integer RELAY_CHANNEL = -1812221819;
 llRegionSayTo(llDetectedKey(0),RELAY_CHANNEL,"cancel," 
 + (string)llDetectedKey(0) + ",!x-cancel");
 llDialog(llGetOwner(),"\n\n" 
 + llDetectedName(0) 
 + " is released if the relay supports !x-cancel.",[],-100);
 llResetScript();
 }
 no_sensor()
 {
 llDialog(llGetOwner(),
 "\n\n" 
 + avatar 
 + " not found. You must enter the exact username.",[],-100);
 llResetScript();
 }
 timer()
 {
 llResetScript();
 }
 }
</lsl>
==Caveat and remarks==
*!x-cancel and !x-delay
The implementation of !x-cancel requires to know the owner of a controller, so the use of llGetOwnerKey(). The latter instruction is sim-local. So it is important to store this information with all pending timers, if the session should start when the avatar is not anymore in the sim in which the !x-delay was received. 
*!x-cancel and !x-takeover by email
With a !x-takeover by email, it is impossible to get the UUID key of the owner of the new controller taking over the session. So the owner will be always the owner of the first controller.
LSL Protocol/Restrained Love Open Relay Group/channel

== !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.
--Satomi Ahn 06:18, 7 May 2011 (PDT)
LSL Protocol/Restrained Love Open Relay Group/custom

= !x-custom =
STATUS: proposal
VERSION: 001
!x-custom: Asks the relay for a list of custom commands
!x-custom/command: Triggers the command or menu "command"
!x-custom/command/parameter: Triggers the command or menu "command" with parameter string "parameter"
General syntax: !x-custom[/STRING]*, to which the relay acknowledges either "ok" if it is recognized, accepted and no answer is expected, "ko" if it is refused, and "<prompt>[/<choice>['+']]*" if the controller is supposed to be presented a new list of choices. The "+" after an item name means that the item expects a string parameter.
Example:
 C -> R: !x-custom
 C <- R: !x-custom,Relay main menu. Make a choice./CollarMenu/InfoMenu/Titler+
(the controlling device shows a dialog to its user with prompt "Relay main menu. Make a choice.", and buttons "CollarMenu", "InfoMenu", "Titler")
 C -> R: !x-custom/InfoMenu
 C <- R: !x-custom/InfoMenu,About the wearer:/Gender/Species/Owner
(the controlling device shows a dialog to its user with prompt "About the wearer", and buttons "Gender", "Species", "Owner")
 C -> R: !x-custom/InfoMenu/Species
 C <- R: !x-custom/InfoMenu/Species,Elf
(the controlling device pops up either a dialog with the answer "Elf"... or informs the wearer by any other suitable mean)
 C -> R: !x-custom/Titler
 R <- R: !x-custom/Titler,ko
(the command "Titler" expects one argument, because in the "+" in the first announce, so "ko". Alternately it could return an error dialog using the previous mechanism and explaining the syntax of the parameter of the "Titler" command.)
 C -> R: !x-custom/Titler/Cage me!
 R <- R: !x-custom/Titler/Cage me!,ok
(... and the relay changes the floating text above the wearer to "Cage me!")
Note that the parameters of those message could potentially include various characters. Maybe this calls to some higer level standardization, stating that any string of the relay protocol can include escaped characters (for instance "\," should be interpreted as a comma, and not as a high level separator of relay protocol message). Unfortunately it is a pain to manage in LSL, as llParseString2List won't abstract escaped characters.
Other important thing: this mechanism allows the relay not to send directly a llDialog to the device user. It could be quite useful in cases the relay protocol is going over e-mail or http and the device user is not in the same region as the relay wearer. Moreover, those command lists could be dispayed by a different mean than a llDialog.
LSL Protocol/Restrained Love Open Relay Group/follow

==!x-follow==
STATUS: draft
VERSION: 002
001 Implemented in Satomi's Multi-Relay HUD 1.03b2 (thanks Winter!)
001 Implemented in Dahlia's multirelay >= 0.44b2
== Possible uses ==
!x-follow: Make the victim stay next to the issuer
!x-follow/2c0df8cb-148b-4907-beb6-c01832321f3f/3: Make the victim follow Winter Seale at 3m
!x-follow/clear: Allow the victim to move freely again
!x-followclear: (DEPRECATED) Synonym of !x-follow/clear. Will be removed in next version.
== Syntax and semantics ==
!x-follow[/target_key[/distance[/tau]]]
:: target_key = defaults to the key of the object issuing the command
:: distance = how close you should stay to the target_key, defaults to 2 meters
:: tau = the tau that llMoveToTarget should be given, lower means you move faster. defaults to 1.5
!x-follow/clear
This is essentially a leash with no particles, just the movement part. Only one object may have an active follow at a time. If multirelay receives a second x-follow while another one's still active, it should deny it. If the key is not currently present, the relay should scan for it regularly (example: every 5 seconds) and continue moving toward it when it's found.
LSL Protocol/Restrained Love Open Relay Group/freeze

== !x-freeze ==
STATUS: draft
version: 002
001 Implemented in Dahlia's multirelay >= 0.48 and in anythingRLV >= 3.1
Description of commands
!x-freeze: freezes the avatar wearing the relay: all arrow keys are disabled. This command must be processed as any locking command.
!x-freeze/clear: cancels !x-freeze.
!x-freezeclear: (DEPRECATED) Synonym of !x-freeze/clear. Will be removed in next version.
The interest of this command is twofold: 
# the controller need not be in the same sim (this command is compatible with any gridwide mode);
# the permission to take control is automatically granted.
Comments: 
*If several concurrent controllers send an !x-freeze command, the avatar must be freezed until the last one unfreezes it.
*An !x-freeze/clear command must be performed by a llReleaseControls().
*This feature is really easy to implement for any kind of relay (1-prim or multi-prim relays).
LSL Protocol/Restrained Love Open Relay Group/gridurl

== gridurl ==
STATUS: proposal
version: 000
The idea of this ORG x-tension comes from the site http://gridurl.appspot.com/about built by Latif Khalifa.
RECOMMENDED WITH: key,email
== Description of !x-gridurl ==
The controller tells the relay to open a Web site and to send its URL in a server outside SecondLife. The syntax is 
 !x-gridurl/STRING/STRING/STRING/STRING
For example: 
 !x-gridurl/server.subdomain.domain/reg/relayurl/gorelay
where http://server.subdomain.domain is the URL where to send the URL of the server with a GET on the address
 http://server.subdomain.domain/reg?relayurl=<current_url>
The acknowledgment of receipt of the relay is 
 !x-gridurl/server.subdomain.domain/reg/relayurl/gorelay,ok
if the command is accepted (URL created and registred in the site server.subdomain.domain); otherwise the acknowledgment is 
 !x-gridurl/server.subdomain.domain/reg/relayurl/gorelay,ko
The relay will take care of resending the URL after a new rezzing, or if the wearer changes of region.
The controller will be able to get back the uuid key of the relay by the command 
<lsl>
 llHTTPRequest("http://server.subdomain.domain/gorelay/<uuid_of_the wearer_of_the_relay>",["POST"],"ping")
</lsl>
The UUID key will be received in an event http_response().
== Interest of this command ==
This command is intended to be used with key. Its interest is that the controller can take over a session even if the relay is not in the same region. The session must be an email session using the x-tension email. As soon as the UUID key of the relay is received by the controller, a !x-takeover sends by email to the relay restores the session.
LSL Protocol/Restrained Love Open Relay Group/listen

==!x-listen==
STATUS: ???
VERSION: 001
Implemented?
; Description : Command to open up a second communication channel to undocumented features of the object containing the relay.
; Implementation : Simply opens up a new listener on the given channel for the specified period of time (indefinitely if no time is specified)
; Syntax : !x-listen/(channel)/(time)
::(channel) = the channel to be opened up by the relay
:: (time) = the length of time to keep the channel open
; Examples
: Opens up a listener on channel 1234 for one minute '!x-listen/1234/60'
: opens up a listener on channel -56789 indefinitely '!x-listen/-56789'
; Discussion
There are many instances where a relay is embedded in a bigger device (e.g., the Think Kink PBA, collars, and the Cool HUD). These devices often need additional listeners, and might even need listeners for short periods of time to listen to some external object. Of course, it would be simple for the devices to always listen on the specified channel, but that would add to lag which is a big enough problem as it is. The goal here is to allow the device to use the relay channel (to which the person should always be listening) to open up the additional listener as needed, cutting down on overall lag as the second listener is only open as needed.
It should be the responsibility of the bigger device and not the relay to shut the channel down.
LSL Protocol/Restrained Love Open Relay Group/mode

== mode ==
STATUS: proposal
version: 000
This extension is purely informational, allowing a controller to query the relay to obtain its operational mode.
; Description: The controller sends the command !x-mode to the relay, which responds with its current operating mode.
; Syntax:
:: Controller: !x-mode
:: Relay: !x-mode,(ask,auto)/(none,black,white,blackwhite)
; Usage:
:: A device needs precise timing or multiple controllers in series to work, and requires different methods for Ask mode or Auto mode relays, for compatibility.
; Notes:
:: Some Relays have a "semi auto" or "playful" mode, which allows "=force" commands, but not restrictions. This should be considered "ask" unless there is significant reason to have a third identifier.
:: Relays that have "Landowner Trusted" as an option should also be considered "ask" mode if they ask permissions for non-trusted objects, since not all RLV devices may be Landowner's.
LSL Protocol/Restrained Love Open Relay Group/safe

= safe =
VERSION: 000 (not implementable yet)
STATUS: proposal
Enables safewording in the relay for the current source (if safewording was disabled).
===Syntax===
 !x-setsafe/safe_mode
 !x-getsafe
!x-setsafe possible answers: ok or ko
!x-getsafe possible answers: a safe_mode
safe_mode's can be either "none", "cond" or "uncond"... (maybe more to be added... and maybe names should be changed)
===Key points===
* for a source: never rely on safewords if we are not sure the targeted relay accepted and understood the command, i.e: "safe" must be in !x-orgversions reply AND, !x-setsafe must have been "ok"'d to be considered valid
* for a relay: !x-setsafe will always either
** change safewording mode to a mode that is easier or as easy to safeword as both the relay general safewording setting and the requested one, and then answer "ok"
** or answer "ko".
* safewording modes are:
** "none": there is no way to safeword
** "cond": the wearer can safeword under some conditions that are possible to meet (ex: the infamous "evil safeword" makes it possible to safeword only if nobody is around or it will ask one person around for authorization)
** "uncond": the wearer can always safeword
===Examples===
 delayed_invisible_release,<avtar_id>,@remoutfit=force|@addoutfit=n|!x-noping|!x-delay/1800|!x-setsafe/cond
Will force the avatar naked for at least half an hour of SL time, then make it possible to ask permissions to put clothes on after that delay. Note that the victim does not necessarily know the delay duration... and is not necessarily notified when it expires!
If the relay only implements a simple unconditional safeword, then the unconditional safeword should be enabled instead.
LSL Protocol/Restrained Love Open Relay Group/simwide

= simwide =
STATUS: deprecated
version: 000
Two new commands !x-simwide and !x-simwide/clear explained below.
==Description of !x-simwide==
The relay must answer ok if and only if the source is a grabber. Otherwise the answer is always ko. The effect of this command is as follows: for any command @getsomething:xxx=channel, the relay must listen to the viewer's answer and resend it using llRegionSayTo() using the same channel and to the source. So !x-simwide enables to use such command with a hud which is more than 100m away (simwide mode).
Typical exchange (if C is already accepted by the relay) in chat session:
 C -chat on RLVRC-> R: enable_forward,!x-simwide
 C <-chat on RLVRC- R: enable_forward,!x-simwide,ok
 C -chat on RLVRC-> R: outfit_query,@getoutfit=1111
 C <-chat on RLVRC- R: outfit_query,@getoutfit=1111,ok
 R --llOwnerSay--> V: @getoutfit=1111
 R <-chat on 1111- V: 0010011111111110
 C <-chat on 1111- R: 0010011111111110
 C -chat on RLVRC-> R: disable_forward,!x-simwide/clear
 C <-chat on RLVRC- R: disable_forward,!x-simwide/clear,ok
==Interaction with !x-takeover==
These instructions must be used only with llRegionSayTo(). So the relay will have to save the uuid key of the grabber and also will have to update it after a !x-takeover.
==Interaction with !x-handover==
After a !x-handover, the next grabber must send a new !x-simwide to enable the simwide mode again.
LSL Protocol/Restrained Love Open Relay Group/speech

= speech =
STATUS: draft
version: 002
version 001 implemented in Dahlia's multirelay 1.3.7 and in AnythingRLV 3.9.30
Two new commands !x-speech and !x-rename
==Description of !x-rename==
*The syntax is !x-rename[/STRING[/FLOAT]]
The effect of !x-rename is to clear any previous setting (it is equivalent to !x-rename/clear which does not exist for obvious reasons). The effect of the command !x-rename/string is to rename the wearer of the relay for all messages and emotes sent to the local chat. The second optional parameter is the range (default: 20.0m). In a relay simulating several controllers, only one controller at a given time can rename the wearer.
The relay must answer "ok" and accepts this command only if the controller sending it is already accepted and if there is no other controller already renaming the wearer of the relay. Otherwise this command has no effect and the relay must answer "ko".
The string must be escaped using llEscapeURL() in the version 002 of the protocol.
==Description of !x-speech==
*The syntax is !x-speech/INTEGER/STRING[/FLOAT[/STRING]]. 
The effect of !x-speech/0/string is to force the avatar wearing the relay to say the string. The effect of !x-speech/1/string is to force the avatar wearing the relay to emote the string. The default range is the say range (default: 20.0m). The third optional parameter is the range. The fourth optional parameter is the name given to the wearer of this avatar for whispering/saying/shouting the string. If no fourth argument is given, the argument given in a previous accepted !x-rename will be taken, or the username of the wearer. Note that it is written username, not displayname. The controller can always force the displayname if necessary by adding it as fourth argument.
The relay must answer "ok" and accepts this command only if the controller sending it is already accepted. Otherwise this command has no effect and the relay must answer "ko". This setting is to avoid grieffers sending forced speech commands using a wildcard.
The strings must be escaped using llEscapeURL() in the version 002 of the protocol.
= Caveat =
No caveat anymore since the strings are escaped in the version 002 of the protocol. So the separators / (slash) and , (comma) are not anymore a problem.
LSL Protocol/Restrained Love Open Relay Group/thirdview

= thirdview =
STATUS: draft
version: 001
Implemented in Dahlia's multirelay and Satomi's multirelay with Susan's syntax
Implemented in Dahlia's multirelay 1.3.7 with ORG syntax
RECOMMENDED WITH: vision
Two new commands !x-thirdview and !x-thirdview/clear which are synonyms of Susan's relays commands @thirdview=add and @thirdview=rem
==Description of !x-thirdview==
!x-thirdview forces the wearer of the relay to use mouselook mode. The interest of this command is to be able to force the wearer to use mouselook mode even in grid-wide mode. 
*The acknowledgment for !x-thirdview is either !x-thirdview,ok or !x-thirdview,ko, not @thirdview=add,ok or @thirdview=add,ko. Idem for !x-thirdview/clear.
==Interaction with !x-vision==
When the wearer does not want to switch for mouselook mode, a blind command like !x-vision/<0'0'0>/1.0/TEXTURE_BLANK/1.0'1.0/0.0'0.0/0.0 will be executed by the relay itself until the wearer changes the mode.