Talk:LSL Protocol/Restrained Love Relay/Specification

Script name requirement

The current version of the spec contains rules for the name of the relay script. The problem is, the rules seem to preclude the possibility of updating using llRemoteLoadScriptPin, which requires a stable name for the target script in order to properly replace it. If the script is changed to support a new version, the spec requires the script be renamed, but that's impractical for a script subject to automatic updating. I'm also unsure if there's any point to this rule. In the case of the product I'm currently working on, the relay script is buried in a child prim (to prevent relayed rules interfering with its own rules), which makes attempting to check its name a pretty unfriendly way for the end user to determine version information. Having version information easily available to the end user is a good idea, but requiring the script be named a particular way doesn't provide that, it just interferes with auto-update functionality without apparent benefit. Is there some other reason for saying a script must be named a particular way (e.g. the viewer checks the script name for this info), or can that rule be safely ignored (despite the "must" in the spec)? If there's a technical reason for the naming requirement, can it be changed so that the prim containing the script is required to be named a particular way, rather than the script itself? --Galatea Gynoid 17:48, 19 August 2008 (PDT)

I think there is no technical reason. --Maike Short 12:26, 22 August 2008 (PDT)

There is no technical reason indeed, and I think that naming rule may be lifted in the near future, especially if it is a problem for people to update their stuff... however the user 'must' be able to check the version one way or another. --Marine Kelley 11:44, 1 September 2008 (PDT)

Fair enough -- I'm using a "Version..." command in my menus that prints:

• Implant Version 0.7
• Compatibility:
• Restrained Life Viewer: 1.12.2 +
• Relay Specification: 1.014

iz gud? --Galatea Gynoid 23:44, 1 September 2008 (PDT)

!release command from relay

Really just for clarification. But it's mentioned several times that a relay should issue a !release metacommand to force a session to end, however this isn't very clear. I'm assuming that the relay, for whatever reason, chooses to clear an object's commands, and sends a !release command to the object such as CmdName,<object uuid>,!release,ok. Should CmdName be something specific in this case? If not does that require in-world objects to recognise arbitrary command names other than those that it produced itself? This could do with some clarification and/or examples under the !release heading to avoid confusion, as I'm assuming objects should be aware of !release so that they know they no longer have control over an avatar.
-- Haravikk ^{(talk|contribs)} 20:11, 24 October 2010 (UTC)

I saw a few devices who send a !pong answer with another CmdName than ping, although the specification says it has to be ping. So... even if the specification was clear for !release, I would not be surprised if some relays still sent another CmdName string. So careful anyway ;-). --Satomi Ahn 14:56, 27 October 2010 (UTC)

llRegionSayTo

This new LSL command is a godsend for RLV relays and furniture. Its purpose is to send channel chat to one target key in the region only. If the key is that of an avatar, then all their attachments (including their RLV relay) will receive the message and no other object. Conversely, the relay can send acknowledgements back to the trap/furniture key, and no other object will hear them and even less process them with LSL.

In short, this new command helps easing on sim lag, and does not create backward compatibility issues for RLV devices who start using it.

Maybe this should be stated as an explicit recommendation in the RLV Relay protocol main page?

--Satomi Ahn 09:21, 1 June 2011 (PDT)

I strongly support this! I am currently doing an application where I am getting crazy by some relays answering on llSay, some on llShout, some on llWhisper... and I need the responses!

--Unya Tigerfish 03:11, 7 July 2011 (PDT)

Just a few caveats for llRegionSayTo:

• I haven't met any furniture that would not work with a relay using llRegionSayTo, but I can see a possible scenario where it would fail. Imagine the furniture listens and speaks from two different prims. Then if the relay uses llRegionSayTo to speak to the primitive who spoke to it, then the furniture won't be able to hear the message. If this becomes an official recommendation, then it should also be recommended that the same prim is used for communication both ways.
• On the furniture side, the relay should obviously send the llRegionSayTo message to the avatar UUID, since the relay UUID is not known first. llRegionSayTo works in such a way that if an avatar UUID is given (and channel is not 0), then the message will be heard by all their attachments.

--Satomi Ahn 06:51, 11 July 2011 (PDT)

I'm not sure when this was added, but if call this function on an Avatar's key using a non-zero channel, every attachment worn by that avatar will hear what is sent. That effectively solves the issues with using this function for issuing relay commands. The relay itself using it is almost as reliable, though I'd still recommend using both transmission methods, since one can extend past sim boundaries and one can't. -- Felis Darwin 19:38, 14 October 2011 (PDT)

Bug in example?

A part of the example says:

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

Shouldn't the following line be there too, or am I missing something?

Relay executes llOwnerSay ("@remoutfit:shoes=force");

--Sei Lisa 16:34, 8 December 2013 (PST)

I've found out what's wrong. It was broken by this edit: [1] by Khisme Nitely. The shoe removal is supposed to be ko'd (rejected) by the relay, not ok'd (accepted). I'm reverting that change. --Sei Lisa 04:59, 9 December 2013 (PST)