Difference between revisions of "Talk:LSL Protocol/Restrained Love Relay/Specification"

From Second Life Wiki
Jump to navigation Jump to search
Line 33: Line 33:


--[[User:Unya Tigerfish|Unya Tigerfish]] 03:11, 7 July 2011 (PDT)
--[[User:Unya Tigerfish|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.
--[[User:Satomi Ahn|Satomi Ahn]] 06:51, 11 July 2011 (PDT)

Revision as of 05:51, 11 July 2011

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)