LSL Protocol/Restrained Love Open Relay Group/x-tensions
Full list of x-tensions
At present, the list of x-tensions is short and it makes sense to list them all on a single page, In the future, it may make sense to separate the list into those that have group approval and those that do not, either because they are still under discussion or because they have been rejected by majority opinion.
Proposed list of approval stages here.
Feature table (including ORG x-tensions) of existing relays here.
x-tensions that have been implemented or proposed are:
These x-tensions are live, up and well running with several independant implementations:
|who||silver (?)||001||tells the relay the identity of the avatar operating the controlling device. Can be useful in playgrounds with bondage furnitures whose grabbing function is open to everybody.|
|handover||bronze (?)||001||hands over the control of the relay to another device, with no further auth required, and possiblity to keep all the previous restrictions.|
|vision||bronze (?)||001||provide a means of obscuring the subjects vision WITHOUT having to muck about with extra wearables. Originally conceived as a MOUSELOOK ENFORCER/PUNISHER and REQUIRES a HUDstyle relay. (already implemented and available to use).|
|follow||draft||002|| makes the victim follow a given object or avatar at the given distance.
|draft||006|| initiates a gridwide email encapsulated protocol session.
|delay||draft||004||!x-delay/10 will delay the execution of the remaining subcommands by 10 seconds. This can be useful either for setting release timers or... making delayed surprises.|
These x-tensions have some working implementations are not considered useful anymore due to llRegionSayTo:
|channel||draft||001||switches the control channel for the RLV relay communications to the specified channel to cut down on spam.|
|ack||draft||002||!x-ack/quiet tells the relay to stop sending "ok" and "ko" acknowledgements... until it receives !x-ack/verbose. This should help reduce spam on the relay channel.|
These x-tensions have only one implementation but their specifications look final enough:
|freeze||draft||002|| stop the victim dead in their tracks. Effectively disables the arrow movement keys, jump and crouch.
|key||draft||002||creates an abstract key for the current session which enables another controller (or the same one after a relog) to take over the session; with !ping activated or not if the controller is not present|
These x-tensions are under debate:
|deprecated||000||Enables simwide control without requiring a gridwide control: the viewer's answer is resent in a special channel and the relay performs the llSensor; interest of this simwide mode even if the capture avatar is close to the grabber: a scan is done around the avatar, not around the grabber.|
|deprecated||001||Forced mouselook mode|
|camera||draft||001||Controlling/tracking the camera of the wearer of the relay (this x-tension contains thirdview)|
|autoforward||draft||001||Simpler alternative to simwide: no new listener is opened, fully compatible with a !x-email session|
|deprecated||001||Deprecated but the first idea could be taken in a future version of autoforward, depending how these things will evolve|
|cancel||draft||001||release any avatars from any session controlled by an object owned by the owner of the object sending this command|
These x-tensions have different stages of maturity but are not currently implemented and neither being worked on at the moment:
|gender||proposal||000||allow the users to set their defined sex, and be queried by a device AND SET BY THE DEVICE.|
|species||proposal||000||ditto for species.|
|control||proposal||000||makes the victim move as if the control given in argument had been pressed. In conjunction with !x-freeze, this allows the device user to control the victim as if they controlled their own avatar.|
|listen||?||001||opens up a listener on the specified channel. Useful for cutting down the load on a sim by only having multiple listeners as needed.|
|animate||proposal||000||animates the victim with the given animation. The animation has to be a standard one, or an animation from a freebie set we would have to standardize and include in every relay that supports x-animate.|
|http-in||draft||002|| initiates a gridwide http encapsulated protocol session, using the new SL server http-in feature.
|message||proposal||000|| Use the relay to send messages from the restraining device to the victim.
|custom||proposal||001||Asks the relay for a list of custom commands or sublists of such. The controlling device issuing this would display the list in a dialog to the device user. Items of the list could include simple actions like triggering animations, or blinding the relay wearer, or even display the menus of various compatible restraints worn by the relay wearer. The idea is to give the possibility for any relay maker to implement various custom extensions without having to wait for every furniture or remote maker to implement them in their menus.|
|mode||proposal||000||Queries for relay current auth mode. Answers (in ack) should tell the source useful information such as if the relay is in interactive mode (ask) or not (auto) and the presence of black and white lists.|
|safe||proposal||000||Enables safewording in the relay for the current source (if safewording was disabled). Options could specify that only conditional safewording ("evil safeword") should be allowed, thus allowing another way to close a session if the source is not available to send !release. This x-tension should have a command to query the current safewording mode.|
|multi||proposal||000||By announcing this x-tension, a relay announces it can support several simultaneous controllers. This x-tension should also contain a command to ask for (an estimation of) a number of available controllers, and a command to close the relay to new controllers.|
|status||proposal||001||an alternative for @getstatus|
These commands are forever deprecated:
|deprecated||000|| queries the relay for supported x-tensions. Deprecated by !x-orgversions, which is part of ORG core requirements.
Note: x-tension names do not contain "!x-" or even "x-". Only the meta-commands they define are prefixed that way. One x-tension can define several meta-commands, which must all be implemented if the x-tension is supported.