Difference between revisions of "LSL Protocol/Restrained Love Open Relay Group/x-tensions"

From Second Life Wiki
Jump to navigation Jump to search
(updating links)
Line 7: Line 7:
Proposed list of approval stages [[LSL Protocol/Restrained Life Open Relay Group/x-tensions Validation Process|here]].
Proposed list of approval stages [[LSL Protocol/Restrained Life Open Relay Group/x-tensions Validation Process|here]].


Feature table (including ORG x-tensions) of existing relays here [[LSL_Protocol/Restrained_Love_Relay/Comparison]].


'''x-tensions''' that have been implemented or proposed are:
'''x-tensions''' that have been implemented or proposed are:




::'''''[[LSL Protocol/Restrained Life Open Relay Group/x-who|!x-who]]''''' - 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.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/who|who]]''''' - 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.


::'''''[[LSL Protocol/Restrained Life Open Relay Group/x-handover|!x-handover]]''''' - hands over the control of the relay to another device, with no further auth required, and possiblity to keep all the previous restrictions.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/handover|handover]]''''' - hands over the control of the relay to another device, with no further auth required, and possiblity to keep all the previous restrictions.


::'''''[[LSL Protocol/Restrained Life Open Relay Group/x-vision|!x-vision]]''''' - provide a means of obscuring the subjects vision '''WITHOUT''' having to muck about with extra wearables.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/vision|vision]]''''' - 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).
::::Originally conceived as a '''MOUSELOOK ENFORCER/PUNISHER''' and '''REQUIRES''' a HUDstyle relay. (already implemented and available to use).


Line 26: Line 27:
::::Nice for ''area effects'' (prison lock-down perhaps), cages (hold them in place so you can open the cage and take out one specific captive.
::::Nice for ''area effects'' (prison lock-down perhaps), cages (hold them in place so you can open the cage and take out one specific captive.


::'''''[[LSL Protocol/Restrained Life Open Relay Group/x-follow|!x-follow]]'''''  - makes the victim follow a given object or avatar at the given distance.  
::'''''[[LSL Protocol/Restrained Love Open Relay Group/follow|follow]]'''''  - makes the victim follow a given object or avatar at the given distance.  
::::This is exactly what current leashes already do, but without the particles. Useful for bringing the victim  
::::This is exactly what current leashes already do, but without the particles. Useful for bringing the victim  
::::from one place to another without using magic tricks like teleportation.
::::from one place to another without using magic tricks like teleportation.
Line 32: Line 33:
::'''''!x-control'''''  - 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.
::'''''!x-control'''''  - 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.


::'''''[[LSL Protocol/Restrained Life Open Relay Group/x-listen|!x-listen]]''''' - opens up a listener on the specified channel. Useful for cutting down the load on a sim by only having multiple listeners as needed.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/listen|listen]]''''' - opens up a listener on the specified channel. Useful for cutting down the load on a sim by only having multiple listeners as needed.


::'''''[[LSL Protocol/Restrained Life Open Relay Group/x-channel|!x-channel]]''''' - switches the control channel for the RLV relay communications to the specified channel to cut down on spam.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/channel|channel]]''''' - switches the control channel for the RLV relay communications to the specified channel to cut down on spam.


::<s>'''''!x-tensions''''' - queries the relay for supported x-tensions.</s> Deprecated by !x-orgversions, which is part of [[LSL_Protocol/Restrained_Life_Open_Relay_Group/ORG_Requirements|ORG core requirements]].
::<s>'''''!x-tensions''''' - queries the relay for supported x-tensions.</s> Deprecated by !x-orgversions, which is part of [[LSL_Protocol/Restrained_Love_Open_Relay_Group/ORG_Requirements|ORG core requirements]].


::'''''!x-animate''''' - 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.
::'''''!x-animate''''' - 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.


::'''''[[LSL Protocol/Restrained Life Relay/ORG email|!x-email]]''''' - initiates a gridwide email encapsulated protocol session.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/email|email]]''''' - initiates a gridwide email encapsulated protocol session.
::::The protocol itself is a work in progress now. A proof of concept is on its way in my relay and RLV remote. --[[User:Satomi Ahn|Satomi Ahn]] 10:03, 19 May 2009 (UTC)
::::The protocol itself is a work in progress now. A proof of concept is on its way in my relay and RLV remote. --[[User:Satomi Ahn|Satomi Ahn]] 10:03, 19 May 2009 (UTC)


::'''''[[LSL Protocol/Restrained Life Relay/ORG http-in|!x-http-in]]''''' - initiates a gridwide http encapsulated protocol session, using the new SL server http-in feature.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/http-in|http-in]]''''' - initiates a gridwide http encapsulated protocol session, using the new SL server http-in feature.
::::I see it as using exactly the same mechanisms as the email extension. It is likely that one of the two methods should eventually be deprecated as they would have the same use and one of the two has to be more efficient than the other! --[[User:Satomi Ahn|Satomi Ahn]] 10:03, 19 May 2009 (UTC)
::::I see it as using exactly the same mechanisms as the email extension. It is likely that one of the two methods should eventually be deprecated as they would have the same use and one of the two has to be more efficient than the other! --[[User:Satomi Ahn|Satomi Ahn]] 10:03, 19 May 2009 (UTC)


Line 49: Line 50:
::::Mainly to negate the inconvenients of llInstantMessage as the only means for a restraining device to send a message only to the victim (Especially useful with multi line messages where the inherent script delay for llInstantMessage is more apparent). --[Regan Flasheart] 13:59, 26 June 2009 (UTC)
::::Mainly to negate the inconvenients of llInstantMessage as the only means for a restraining device to send a message only to the victim (Especially useful with multi line messages where the inherent script delay for llInstantMessage is more apparent). --[Regan Flasheart] 13:59, 26 June 2009 (UTC)


::'''''[[LSL Protocol/Restrained Life Relay/ORG custom|!x-custom]]''''' - 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.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/custom|custom]]''''' - 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.


::'''''[[LSL Protocol/Restrained Life Relay/ORG ack|!x-ack]]''''' - !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.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/ack|ack]]''''' - !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.


::'''''[[LSL Protocol/Restrained Life Relay/ORG delay|!x-delay]]''''' - !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.
::'''''[[LSL Protocol/Restrained Love Open Relay Group/delay|delay]]''''' - !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.
 
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.

Revision as of 06:12, 21 October 2010

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 LSL_Protocol/Restrained_Love_Relay/Comparison.

x-tensions that have been implemented or proposed are:


who - 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 - hands over the control of the relay to another device, with no further auth required, and possiblity to keep all the previous restrictions.
vision - 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).
!x-gender - allow the users to set their defined sex, and be queried by a device AND SET BY THE DEVICE.
!x-species - ditto for species.
!x-freeze - stop the victim dead in their tracks. Effectively disables the arrow movement keys, jump and crouch.
Sure you can do it other ways, but this keeps down extra script/attachment counts and gives a 'standard interface'.
Nice for area effects (prison lock-down perhaps), cages (hold them in place so you can open the cage and take out one specific captive.
follow - makes the victim follow a given object or avatar at the given distance.
This is exactly what current leashes already do, but without the particles. Useful for bringing the victim
from one place to another without using magic tricks like teleportation.
!x-control - 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 - opens up a listener on the specified channel. Useful for cutting down the load on a sim by only having multiple listeners as needed.
channel - switches the control channel for the RLV relay communications to the specified channel to cut down on spam.
!x-tensions - queries the relay for supported x-tensions. Deprecated by !x-orgversions, which is part of ORG core requirements.
!x-animate - 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.
email - initiates a gridwide email encapsulated protocol session.
The protocol itself is a work in progress now. A proof of concept is on its way in my relay and RLV remote. --Satomi Ahn 10:03, 19 May 2009 (UTC)
http-in - initiates a gridwide http encapsulated protocol session, using the new SL server http-in feature.
I see it as using exactly the same mechanisms as the email extension. It is likely that one of the two methods should eventually be deprecated as they would have the same use and one of the two has to be more efficient than the other! --Satomi Ahn 10:03, 19 May 2009 (UTC)
!x-message - Use the relay to send messages from the restraining device to the victim.
Mainly to negate the inconvenients of llInstantMessage as the only means for a restraining device to send a message only to the victim (Especially useful with multi line messages where the inherent script delay for llInstantMessage is more apparent). --[Regan Flasheart] 13:59, 26 June 2009 (UTC)
custom - 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.
ack - !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.
delay - !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.

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.