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

From Second Life Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=!x-listen=
{{ ORG Restrained Life Relay Specs TOC }}
!x-listen/xxxx: changes the communication beween relay and controlling device to channel xxxx instead of RLVR, assuming xxxx is a high negative integer.
==!x-listen==


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


Scenario:
VERSION: 001
(session on channel RLVR between R and C)
-RLVR> blah,k(R),!x-listen/-12345
<RLVR- blah,k(C),!x-listen/-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.
Implemented?


Both R and C are required to listen to each other on channel -12345 after this dialog.
; Description : Command to open up a second communication channel to undocumented features of the object containing the relay.


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.
; Implementation : Simply opens up a new listener on the given channel for the specified period of time (indefinitely if no time is specified)


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


Good practice scenario:
; Examples
(session on channel RLVR between R and C)
: Opens up a listener on channel 1234 for one minute '!x-listen/1234/60'
-RLVR> blah,k(R),@randomlockingcommand=n|!x-listen/-12345
: opens up a listener on channel -56789 indefinitely '!x-listen/-56789'
<RLVR- blah,k(C),@randomlockingcommand=n,ok
<RLVR- blah,k(C),!x-listen/-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).
; 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.

Latest revision as of 07:43, 21 October 2010

Restrained Love
Open Relay Group
x-tensions
Restrained Love Relay

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

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_Protocol/Restrained_Love_Open_Relay_Group/listen&oldid=1069733"