Difference between revisions of "LSL Protocol/Restrained Love Open Relay Group/channel"

From Second Life Wiki
Jump to navigation Jump to search
(RestrainedLove)
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{ ORG Restrained Life Relay Specs TOC }}
{{Restrained Love Open Relay Group TOC}}


== !x-channel ==
== !x-channel ==


STATUS: preliminary
STATUS: draft


VERSION: 001


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


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


VERSION: 001


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


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

Latest revision as of 08:48, 28 July 2012

!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)