Difference between revisions of "LSL Protocol/Restrained Love Relay/Bugs and Pending Features"

From Second Life Wiki
Jump to navigation Jump to search
m (<lsl> tag to <source>)
 
(21 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Restrained Life Relay Specs TOC}}
{{Restrained Life Relay Specs TOC}}


== Functions in development ==
== Functions in discussion/development ==
* [[LSL Protocol/Restrained Life Relay/resetting environment settings|resetting environment settings]]
* [[LSL Protocol/Restrained Life Relay/pong handling contradiction|pong handling contradiction]]
* [[LSL Protocol/Restrained Life Relay/delay|delay]]
* [[LSL Protocol/Restrained Life Relay/gender|gender]]


=== !vision ===
== Discussion about new features in 1.040 ==


; Description : meta command to control what the victim can see while under restraint. This will allow a full range of vision control of the victim. Full blindness, partial, color, textures, etc..
* [[LSL Protocol/Restrained Life Relay/vision|vision restriction]]
; Implementation : using a small microprim that hides on the back of our RelayHUD, we can expand and texture this to control the sight of the victim. Put them in a dark cell, they go blind. Or in a forcefield change the color, make it partially transparant, put up a texture, etc. We are/will also be using this as a "MouseLook" enforcer to punish a victim when they won't stay in mouselook (get out of mouselook, go totally blind). Currently being implemented in devices from THINK KINK.
* [[LSL Protocol/Restrained Life Relay/handover|handover]]
; Syntax : !vision/(color)/(alpha)/(texture)/(repeats)/(offsets)/(rotation)
* [[LSL Protocol/Restrained Life Relay/who|who]]
::(color) = color for the HUD covering prim in RGB format <r'g'b> 0-255 (NOTE: the ' is the seperator instead of , to avoid parsing issues with the rest of the RLV command string)
* [[LSL Protocol/Restrained Life Relay/editorial changes|editorial changes]]
::(alpha) = % transparent to make the HUD prim cover (in alpha format 0.0-1.0)
::(texture) = UUID for a texture to apply to the prim
::(repeats) = x/y repeats for the texture, same format as the texture tab on an prim 1.0'1.0
::(offsets) = x/y offsets for the texture, same format as the texture tab on an prim 0.0'0.0
::(rotation) = rotation of the texture


:: SPECIAL ENTRY, any of the parameters can be replaced with "*" for 'do not change existing value'
== 1.040 ==
Maike Short single script version
; Description : In listen event for the permission dialog, message is always freed before being send to the process function => message is never handled and permission never given.
; Discovered by : herina Bode
; Fix : Replace call to processDialogResponse(id, message) by processDialogResponse(id, currentMessage);


:: NOTE: the 'default' value of the HUD prim is 100% transparent, white, TEXTURE_BLANK. ie. !vision/0.0/<255'255'255>/TEXTURE_BLANK/1.0'1.0/0.0'0.0
== 1.030 ==
:: if all you want to do is 'blind' someone, then !vision/<0'0'0>/1.0/*/*/*/*
 
 
; Examples
: Total blackout "!vision/<0'0'0>/1.0/TEXTURE_BLANK/1.0'1.0/0.0'0.0/0.0
: Light fog "!vision/<128'128'128>/0.5/TEXTURE_BLANK/1.0'1.0/0.0'0.0/0.0"
: In a plywood box no matter where they look "!vision/<255'255'255>/1.0/TEXTURE_PLYWOOD/1.0'1.0/0.0'0.0"
; Compatibility : since this is a metacommand, relays that don't support this should ignore it
--[[User:Ilana Debevec|Ilana Debevec]] 06:57, 15 February 2009 (UTC)
 
; Discussion and Suggestions :
:: Relays that implement !vision and/or mouselook enforcement ''must'' check that they are attached to an HUD attachment point (llGetAttached()). They must ignore further parameters silently. A HUD-less relay may simulate the effects using the @setenv_xxx windlight controls. --[[User:Maike Short|Maike Short]] 07:54, 15 February 2009 (UTC)
 
::: yes --[[User:Ilana Debevec|Ilana Debevec]] 08:06, 15 February 2009 (UTC)
 
 
:: I'd suggest to use the same scale LSL uses: For color <0, 0, 0> to <1, 1, 1>. For transparency 0.0 to 1.0. Scripters are used to that. --[[User:Maike Short|Maike Short]] 07:50, 15 February 2009 (UTC)
 
::: only reason we doing that is it's the same format as the viewer color picker. agree on the transparency, soon as we recode it we will make that correction. --[[User:Ilana Debevec|Ilana Debevec]] 08:06, 15 February 2009 (UTC)
 
 
:: There are both relays and world objects out there that implement an inofficial [[LSL Protocol/Restrained Life Relay/Mouselook|@thirdview=n]] command to enforce mouselook (for example MJ, MSM). It may be a good idea to get mouselook enforcement into the protocol specification, too. Either this way or as a similar meta command. Mouselook enforcement is something that can be very stressful for the sim and therefor I would prefer to have it in the relay instead of world objects. The are a lot of world objects out there that are written by people with very little experience. I am scared of objects that will keep the high frequency time active all time, even if they are not used. This might not be a problem on the sim of the scripter but it is a problem on sims like Stonehaven --[[User:Maike Short|Maike Short]] 07:50, 15 February 2009 (UTC)


::: that's why I'm posting this, perhaps it can be worked into the protocol, but that's also why we're doing this as a meta, don't want to step on the @'s in the protocol. --[[User:Ilana Debevec|Ilana Debevec]] 08:06, 15 February 2009 (UTC)
=== isObjectNear and non existing objects ===


:::: I take Marine has been asked countlessly for a command such @thirdview=n... thus there must be a reason for not having it... is there one? --[[User:Satomi Ahn|Satomi Ahn]] 16:46, 19 February 2009 (UTC)
; Description : If an objects does not exist (anymore) in the current sim and its neighbors, llGetObjectDetails returns <0, 0, 0> which means it is wrongly detected as being close if you are within 100m to that locations
::::: Are you talking about the viewer or the relay here? I did not include it into the spec because I was afraid that Marine might add it to the viewer at a later time causing the relays to get incompatible. And nobody was pushing me to put it in. --[[User:Maike Short|Maike Short]] 18:23, 19 February 2009 (UTC)
; Discovered by : Kitty Barnett
:::::: I am speaking of the viewer. As forced ML is quite popular, I am just surprised it is still unimplemented in RLV... and I thought there must be a good reason for that. --[[User:Satomi Ahn|Satomi Ahn]] 22:00, 19 February 2009 (UTC)
; Fix : [https://wiki.secondlife.com/w/index.php?title=LSL_Protocol%2FRestrained_Life_Relay%2FOther_Implementations%2FMaike_Short%27s_Relay&diff=262273&oldid=255372 Maike's fix]


:: EDIT : changing the transparency to 0.0 - 1.0 per Maike's suggestion
:::changed the separator for the color vector to ' to avoid issues parsing the string. This must be converted by the relay GPU to 'normal' color vectors. --[[User:Ilana Debevec|Ilana Debevec]] 20:14, 15 February 2009 (UTC)
:: EDIT : added the repeats and offset parameters and the "*" value.. I thought I did those already, must have forgotten to save --[[User:Ilana Debevec|Ilana Debevec]] 18:41, 16 February 2009 (UTC)


=== groupless objects are trusted on parcels not set to a group  ===


:: Just an idea: The order and range of the parameter could be similar to [[llSetPrimitiveParams]]: vector color, float alpha, integer face, string texture, vector repeats, vector offsets, float rotation_in_radians --[[User:Maike Short|Maike Short]] 19:45, 16 February 2009 (UTC)
; Description : On a parcel which is not set to a group, the not-owner warning is not displayed for groupless objects
::: Agreed and done --[[User:Ilana Debevec|Ilana Debevec]] 22:59, 16 February 2009 (UTC)
; Discovered by : Kitty Barnett
; Fix : [https://wiki.secondlife.com/w/index.php?title=LSL_Protocol%2FRestrained_Life_Relay%2FOther_Implementations%2FMaike_Short%27s_Relay&diff=262273&oldid=255372 Maike's fix]


:: There is something I don't like with the fact it is a "!" metacommand. It is true that !vision is not a RLV command (though it has several RLV realisations: env settings and resolution divisor), so it should not start with a "@" unless it could be directly transmitted to viewer. However, up to now, metacommands were used for commands controlling the protocol, not for producing border effects. If more of that type of commands were to be proposed, maybe having a third different prefix would be an idea. But would there be compatibility issues? --[[User:Satomi Ahn|Satomi Ahn]] 16:39, 19 February 2009 (UTC)


::: I like the idea of having another prefix for restrictive command. As far as I know there would be no compatibility issue if we pay attention to which character we pick. Bad Characters are: @!,|'/=. Suggestion: ''%'' ? --[[User:Maike Short|Maike Short]] 18:23, 19 February 2009 (UTC)
=== Fake Avatar Chat ===


::: Well, the ! was the best idea I had, and was guaranteed to be ignored by non supporting relays, but if we could reach consensus on something other than !, sounds reasonable to me --[[User:Ilana Debevec|Ilana Debevec]] 23:39, 19 February 2009 (UTC)
; Description : 1. An object can remove the guarding prefix for chatting on channel using =y. 2. An object can use @getstatus=n or @getstatus=-1 (and in some cased @getstatus=some random text) to cause the agent to should on public chat. This does work for the other query commands as well.
 
; Discovered by : Marissa Mistwallow and Maike Short
=== !visionclear ===
; Affected relays : I did some quick tests on a number of different relays and so far all have been vulnerable (including my own one) to one or both of theses attacks.
 
; Fix : [https://wiki.secondlife.com/w/index.php?title=LSL_Protocol%2FRestrained_Life_Relay%2FOther_Implementations%2FMaike_Short%27s_Relay&diff=255362&oldid=253182 Maike's fix]
; Description : complimentary command to !vision. Reset and remove all !vision restrictions.
; Syntax : !visionclear
; Compatibility : same as !vision, if the relay can't, then don't
 
--[[User:Ilana Debevec|Ilana Debevec]] 10:44, 15 February 2009 (UTC)
 
=== !who ===
 
; Description : meta command to pass the UUID of WHO is trying to operate your relay, not just WHAT device and the OWNER of the device (more often than not, WHO's the operator and WHO's the owner are NOT the same avatar).  
; Background : we constantly have people coming to our store wanting a way to know WHO is trying to control their relay, it's almost become a mantra "I don't care WHAT it is, I want to know WHO it is!". This is a simple way to pass that information from a device to the relay when the device attempts use the relay.
; Syntax: !who/(key)
:: (key) is the UUID of the AV that you wish to present to the relay.
; Implementation :
:: as THINK KINK is implementing this, we are making a few caveats -
::: We are making the !who as the FIRST entry in a command string, so it can be picked up immediately and used in an ASK dialog (if necessary)
::: IF the !who on a new command from an object is the same as the last !who from the same object, no ASK necessary
::: IF the !who on a new command from an object is DIFFERENT from the last !who from the same object, ASK again
::: IF no !who on a command string, normal object verification rules apply
 
; Further Points of Implementation :
:: The ASK message will change if a !who command comes in, instead of "Dastardly Device owned by Random Avatar wants to control your relay, ALLOW/DENY?"
:: the message becomes "Crafty Avatar wants to control your relay using Random Avatar's Dastardly Device, ALLOW/DENY?"
 
:: if the owner and the operator are the same, then a more succinct message could be "Crafty Avatar wants to control your relay using their Dasterdly Device, ALLOW/DENY?"
 
:: further if YOU (the victim) are the 'operator' (ie. by walking into an area effect device) you could say "You have activated Crafty Avatar's Area of Doom and it is attempting to control your relay, ALLOW/DENY?"
 
:: addition of a this will make for clearer messages and communication with the victim.
 
:: if a !who is present, then should the victim DENY the request, an IM can go back to the 'clicker' "Sitting Duck has denied your attempt to control their relay".
 
:: Extension of the ALLOW/DENY dialog to include ALLOW/DENY/ALWAYS ALLOW (effectively give this AV 'Auto' Permission, no matter the relay setting)/ALWAYS ASK (give this AV the 'Ask' requirement no matter the relay setting)/ALWAYS DENY (effectively 'blacklist' this AV from any attempts to control your AV)
 
:: Means of saving/restoring these AV lists (allow/ask/ban) to/from the relay as backup/restore of data
 
:: This function is currently being implemented in the THINK KINK tkRLV 5IVE relay and THINK KINK devices.
; Compatibility : since this is a metacommand, relays that don't support this should ignore it
--[[User:Ilana Debevec|Ilana Debevec]] 10:44, 15 February 2009 (UTC)
 
EDIT: added some usability message examples --[[User:Ilana Debevec|Ilana Debevec]] 20:22, 15 February 2009 (UTC)
 
; Discussion : I came to this page to add something similar to this !who meta-command. But I am not opposed to the proposed mechanism, provided it ensures that there is never an ambiguity on who is the current user (but as you present it, it looks ok).
: Now imagine you are using a multi-device relay and you are under restrictions from several users through the same device. How should the relay interpret a !release? Should it clear every restriction from the device? Or only those that where issued by the user in the latest !who? I believe both should be made possible (but in a way that won't make the older relays go wrong... Should, in this case, a pratial release be ignored or be interpreted as a full release?).
:If we can agree on a good spec, I'll try to help you pushing it into the official protocol ^^. Anyway I put this in the TODO list of my multi-relay. :--[[User:Satomi Ahn|Satomi Ahn]] 16:30, 19 February 2009 (UTC)
 
:: I am sorry I am not sure whether I understand you correctly: On the one hand you are talking about a multi-device relay and on the other hand you are talking about multiple doms controlling the same device. !release must be implemented on a per device basis. Imagine you are locked up in a cell. Someone griever could simply free you with an attachment that sends !release otherwise, so spoiling all the fun.
:: For multiple persons controlling the same device, I think the last one should override older settings. It gets way to complicated to understand my non-coders otherwise. The world object should check whether it allows access by another person or not. And the relay can ask the user if she trust the new dom or not.
:: We have to keep in mind that !who can be easily faked by untrusted world objects. --[[User:Maike Short|Maike Short]] 18:36, 19 February 2009 (UTC)
:::Ok, I admit what I have in mind is quite complicated. I was thinking of considering a single device as several virtual devices when controlled by several doms (no risk of faking: if the command comes from another real device, of course I don't want it to allow releasing the commands from another one!). But even without going that far, it would make sense, if restrictions come from several doms on a single device, that in certain cases (to be determined by the device maker), only the restrictions coming from one dom would be cleared. --[[User:Satomi Ahn|Satomi Ahn]] 22:05, 19 February 2009 (UTC)
:: We are only !release'ing by object, not by person. We COULD say "release everything this person has" when they !release one... but that's not very .. er.. realistic... if they have you locked in multiple restrictions (a device in a cage for instance), they can only undo you one-at-a-time... and for the !who being faked.. yes it could be, but a) you have to have an object with the !who command (by default) so you would have to be able to fake the UUID of an object that has you actively controlled and the UUID of a person... --[[User:Ilana Debevec|Ilana Debevec]] 23:51, 19 February 2009 (UTC)
 
Other point of discussion: when a bunch of commands prefixed by a !who have been ok'ed, should the device assume that every following bunch of commands from the same user will also be accepted?
 
If no, the device should take care of eventually releasing every restriction in a non-prefixed command (which should work, provided the relay keeps the order of execution for commands issued by a same device).
 
If yes, this makes the relay more complicated, as you have to keep in memory the fact that a user still has restrictions on the wearer. Then either you allow only one user per device to lock the relay (as older relays did for devices: only one device using a relay at a time), or you have to do some very complicated bookkeeping for users, similar as what you do for devices in multidevices-relay (which would give an over-kill, over-bloated, multi-device and multi-user relay!).
 
Well, what is your opinion on this?
 
PS: in the relay requirements, shouldn't we add that the commands must be executed in the same order as they are received? Without this assumption, a furniture maker can never be sure that the victim will be released in the end.
 
--[[User:Satomi Ahn|Satomi Ahn]] 14:35, 23 February 2009 (UTC)
 
=== !handover proposal ===
 
; Proposed Change : Add meta command !handover/key/type
; Justification : There should be a way to handover the victim from one world object to another without the having to ask for permission again
; Requirements : The change must enable world objects to be easily compatible with both old and new relays. The relay must ensure that the target object is ready.
; Syntax : !handover/(key)/(type)|!release
:: (key) is the id of the target object
:: (type) : 0 lift all restrictions of the source object, 1 keep them, it is the responsibility of the target object to keep them in mind
; Compatibility : Immediately after the "!handover" a "!release" command must be sent by the world objects. Relays which support !handover must ignore the rest of the chat line, including that !release command.
: Old Relays which do not support "!handover" will ignore it and execute the "!release" command instead. So they are available for the target object in the old way (e. g. may ask for permission again).
: The relay must ignore further "/"-parameters for future extension of the command.
; Note on ping/pong : The relay must ensure with the !ping meachnism that the target object is available. The target object, however, might not see the ping, for example because of a slow intersim teleport. The target object must respond to !pong on arrival anyway.
 
'''[[LSL_Protocol/Restrained_Life_Relay/Alpha_Version|Alpha Code]]'''
 
; TODO : Think about an additional "/"-paramter meaning "let that target object control the relay but keep me on the list, too" for relays that support multiple world objects. This needs a bit more of thinking because the policy of ignoring !release does not work this simple anymore. Since Dominatech's sample code is under a very restrictive license, i am unable to look at it, to see who much work this would be. --[[User:Maike Short|Maike Short]] 08:54, 15 February 2009 (UTC)
 
; 3 way handshake
 
:: This is a GREAT idea that perhaps should be expanded a little.. "Handover" (to me) implies "here, take this", "ok I got it, thanks". So perhaps this should be three commands? A !handover-r (request), !handover-s (send) and !handover-a (ack) something like -
 
:: sent to source object that has to do the handover - !handover-r/target-key/(type)              (request you hand restrictions you have to target-key)
:: sent from source object to the target object - !handover-s/target-key/(type)/(list of restrictions in effect)
:: sent from the target object back to the source object !handover-a/target-key/(type)/0          (0 = handover accepted)  -OR-
:: sent from the target object back to the source object !handover-a/target-key/(type)/-1          (-1 = handover failed)
 
:: the source takes whatever actions necessary depending on the success or failure of the handover. Just thinking out loud. --[[User:Ilana Debevec|Ilana Debevec]] 02:22, 17 February 2009 (UTC)
 
::: Unfortunatally, there is a situation in which this won't work using normal chat: The first objects sends @tpto:././.=force|!handover/./.|!release. The tpto destination can be in another sim anywhere on the grid. There is such an object called "Kidnapper" in Stonehaven at &lt;76, 202, 11&gt;. --[[User:Maike Short|Maike Short]] 19:38, 17 February 2009 (UTC)
 
== 1.030 ==
 
None known


== 1.020 ==
== 1.020 ==
Line 176: Line 58:
:: It would probably be sufficient to "ko" @getstatus=x requests where x < 1000.  Most gags or other scripts that expect human-typed channel numbers stick to < 1000, whereas most furniture looking for status use much larger channel numbers (mine use random channels, but with a minimum of 1000000, for example). --Julia Banshee
:: It would probably be sufficient to "ko" @getstatus=x requests where x < 1000.  Most gags or other scripts that expect human-typed channel numbers stick to < 1000, whereas most furniture looking for status use much larger channel numbers (mine use random channels, but with a minimum of 1000000, for example). --Julia Banshee
::: I agree that disallowing low channel numbers for all query types may be a good idea and I am not objecting a change of the spec although it has a low change of breaking content. (Well, since Marine is back, i can easily say this without having to think about all the time it will cost me to talk to affected people).  I strongly suggest, however, to put something at the beginning of @getstatus replies anyway. Fixed high level channels with a filter to the owner are sometimes used for debugging. (Yes, I am having a concrete object in my mind).  --[[User:Maike Short|Maike Short]] 11:03, 18 September 2008 (PDT)
::: I agree that disallowing low channel numbers for all query types may be a good idea and I am not objecting a change of the spec although it has a low change of breaking content. (Well, since Marine is back, i can easily say this without having to think about all the time it will cost me to talk to affected people).  I strongly suggest, however, to put something at the beginning of @getstatus replies anyway. Fixed high level channels with a filter to the owner are sometimes used for debugging. (Yes, I am having a concrete object in my mind).  --[[User:Maike Short|Maike Short]] 11:03, 18 September 2008 (PDT)
:: This problem appears related to the Fake Avatar Chat above. This issue could be fixed with the RLV Viewer itself, by simply discarding invalid restrictions, preventing this from ocurring in the first place and improving the performance of every relay out there by removing unnecessary checks. --[[User:Da Chrome|Da Chrome]] 7 December 2011


=== Foreign Public Chat ===
=== Foreign Public Chat ===
Line 185: Line 69:
; Fixed : in the Restraint Life Viewer version 1.12.4. For older viewers the relay should prevent it: [[LSL Protocol/Restrained Life Relay/Other Implementations/Maike Short's Relay|Maike Short's Relay]]
; Fixed : in the Restraint Life Viewer version 1.12.4. For older viewers the relay should prevent it: [[LSL Protocol/Restrained Life Relay/Other Implementations/Maike Short's Relay|Maike Short's Relay]]
; Proposed fixed : The relay should filter all queries directed to answer on channel 0 for Restraint Life Viewer version 1.12.3 and lower. Add this at the end of the huge if / else if / else if block in executeRLVCommand
; Proposed fixed : The relay should filter all queries directed to answer on channel 0 for Restraint Life Viewer version 1.12.3 and lower. Add this at the end of the huge if / else if / else if block in executeRLVCommand
<lsl>
<source lang="lsl2">
     else if ((integer) param == 0) {
     else if ((integer) param == 0) {
         // this is either an unknown param (not "n", "add", "y", "rem", "force")
         // this is either an unknown param (not "n", "add", "y", "rem", "force")
Line 192: Line 76:
         return;
         return;
     }     
     }     
</lsl>
</source>


=== Relay Crash in Ask mode ===
=== Relay Crash in Ask mode ===
Line 234: Line 118:
; Workaround : none
; Workaround : none
; Suggested fix :  
; Suggested fix :  
<lsl>
<source lang="diff">
--- RLV_v1.014a 2008-07-06 23:17:14.000000000 +0200
--- RLV_v1.014a 2008-07-06 23:17:14.000000000 +0200
+++ RLV_v1.014a-xxx    2008-07-06 23:18:32.000000000 +0200
+++ RLV_v1.014a-xxx    2008-07-06 23:18:32.000000000 +0200
Line 277: Line 161:
             {
             {
                 debug("asking for permission because kSource is NULL_KEY");
                 debug("asking for permission because kSource is NULL_KEY");
</lsl>
</source>
; Fixed : in 1.015 by specially looking for the !pong reply so that the fix works for cages  as well (no "force sit" in this situation but a collision detection which is triggered on login, too).
; Fixed : in 1.015 by specially looking for the !pong reply so that the fix works for cages  as well (no "force sit" in this situation but a collision detection which is triggered on login, too).

Latest revision as of 12:22, 25 January 2015

Restrained Love Relay

Functions in discussion/development

Discussion about new features in 1.040

1.040

Maike Short single script version

Description
In listen event for the permission dialog, message is always freed before being send to the process function => message is never handled and permission never given.
Discovered by
herina Bode
Fix
Replace call to processDialogResponse(id, message) by processDialogResponse(id, currentMessage);

1.030

isObjectNear and non existing objects

Description
If an objects does not exist (anymore) in the current sim and its neighbors, llGetObjectDetails returns <0, 0, 0> which means it is wrongly detected as being close if you are within 100m to that locations
Discovered by
Kitty Barnett
Fix
Maike's fix


groupless objects are trusted on parcels not set to a group

Description
On a parcel which is not set to a group, the not-owner warning is not displayed for groupless objects
Discovered by
Kitty Barnett
Fix
Maike's fix


Fake Avatar Chat

Description
1. An object can remove the guarding prefix for chatting on channel using =y. 2. An object can use @getstatus=n or @getstatus=-1 (and in some cased @getstatus=some random text) to cause the agent to should on public chat. This does work for the other query commands as well.
Discovered by
Marissa Mistwallow and Maike Short
Affected relays
I did some quick tests on a number of different relays and so far all have been vulnerable (including my own one) to one or both of theses attacks.
Fix
Maike's fix

1.020

Version 1.020 reintroduces all the problems listed in 1.014.

Foreign Channel Chat

Discovered by
Maike Short
Description
An object can force the agent to say any lower case text on any channel using @getstatus
Note
Relays which do not add any restriction on their own (like @detach=n) may be abused using @gestatus to trigger dialog responses, gag talk or other scripts like "to buy as gift, say the name of the receiver on channel /x". Any version of the reference implementation smaller than (not including) 1.015 (but including 1.020 which is based on 1.014) are affected by this.
Workaround
none
Fixed
in Maike Short's Relay
Proposed fixed
Add "this-is-a-script-generated-message-beyond-the-control-of-the-agent/" at the beginning of @getstatus-replies on all channel by issuing this as the very first restriction. This still allows to trigger gags but it will include a human readable warning (if you speak Gagish well enough). The usual "to buy as gift, say the name of the receiver on channel /x" scripts will try to resolve this text as part of the name and will fail because such long avatar names are not allowed. Other scripts waiting for commands are very likely not to accept this text either. A more secure solution would be to define one single channel which must be used for such queries but that would break a lot of content.
It would probably be sufficient to "ko" @getstatus=x requests where x < 1000. Most gags or other scripts that expect human-typed channel numbers stick to < 1000, whereas most furniture looking for status use much larger channel numbers (mine use random channels, but with a minimum of 1000000, for example). --Julia Banshee
I agree that disallowing low channel numbers for all query types may be a good idea and I am not objecting a change of the spec although it has a low change of breaking content. (Well, since Marine is back, i can easily say this without having to think about all the time it will cost me to talk to affected people). I strongly suggest, however, to put something at the beginning of @getstatus replies anyway. Fixed high level channels with a filter to the owner are sometimes used for debugging. (Yes, I am having a concrete object in my mind). --Maike Short 11:03, 18 September 2008 (PDT)
This problem appears related to the Fake Avatar Chat above. This issue could be fixed with the RLV Viewer itself, by simply discarding invalid restrictions, preventing this from ocurring in the first place and improving the performance of every relay out there by removing unnecessary checks. --Da Chrome 7 December 2011

Foreign Public Chat

Discovered by
Maike Short
Description
An object can force the agent to say any text in public chat using @getstatus=0 and use similar functions (like @version) to spam other text there.
Note
This allows the same abuse mentioned in the above entry, too. But being public chat makes even non abusable cases very annoying.
Workaround
none
Fixed
in the Restraint Life Viewer version 1.12.4. For older viewers the relay should prevent it: Maike Short's Relay
Proposed fixed
The relay should filter all queries directed to answer on channel 0 for Restraint Life Viewer version 1.12.3 and lower. Add this at the end of the huge if / else if / else if block in executeRLVCommand
    else if ((integer) param == 0) {
        // this is either an unknown param (not "n", "add", "y", "rem", "force")
        // or a query which should be answered on the public chat channel 0.
        ack(cmd_id, id, command, "ko");
        return;
    }

Relay Crash in Ask mode

Discovered by
Maike Short
Description
A malicious objects scans for all avatars within the sensor range. For each avatar a new object is rezes out of the content. This objects sends 10 messages to the relay each of about 1000 characters causing sPendingMessage to overflow. After the 10 messages are send these objects die making tracking very difficult.
Note
Some relays accept commands from objects more than 20100 meters away so the attacking objects can be hidden far away.
Workaround
None
Open
although fixed in version 1.15 it was reintroduced by the revert in version 1.02


1.015

The below problems are fixed here, except for the forced sit issue below.

1.014

The following problems occured in version 1.014 and have been fixed:

Stuck: Accepting Permission Dialog after !release

Discovered by
Maike Short
Workaround
Don't accept requests after you have been freed. In case it happend, reenter the cage / sit down again; relog.
Fixed
in 1.015

Force Sit during Login on the control object instead of the forced-sit one

Discovered by
Azoth Amat
Workaround
Always send a "@sit:<id>=force" command if you want a forced sit on relog, even if the victim is already sitting.
Fix
change in timer(): sendRLCmd ("@sit:"+(string)kSource+"=force"); to sendRLCmd ("@sit:"+(string)lastForceSitDestination+"=force");
Note
This prevents @unsit to work in case the person set down without being forced if the furniture in question hasn't sent a @sit:<id>=force command. (This should probably be considered a bug in the furniture, not the relay.)
Fixed
in 1.015 (but that fix breaks other things, forcing sits when not appropriate), and 1.02 (that fix always works, assuming the furniture is properly setting the @sit destination)
Sending a bogus force sit on sit as you suggested may not work if force-sits are filtered. As far as I know there is no way for an attachment to detect the object the avatar is sitting on. So the relay will not be able to tell real force-sits (which should be subjected to the filter) and bogus force-sits for this problem apart.
It could accept a force-sit on the control-object but this would allow to kidnap an agent sitting on an other object. Well, the same can happen with my approach of using the sending object as fall back. Could you give an example for a forced sit when not appropriate with my approach? This may reveal other aspects of the problem.
The specification says "Force sit if unsit is prevented when relogging" in "Relay requirements" so I think objects that just send @unsit=n without force-sit should not be called buggy. If it turns out the current approach does cause more problems than it fixes it may be worth to adjust the spec. But this will cause existing world object to break so should not be taken lightly. --Maike Short 12:55, 17 September 2008 (PDT)

Stuck on crash/relog with objects asking for relay upon being sat on

Discovered by
Gregor Mougin
Problem
Many objects check for presence of a relay and the RR viewer by asking for the !version when sat on. If the user crashes, and the object was used by someone else in the meantime (or, for testing, reset), the relay enforces all previous restrictions whereas the object doesn't know of them.
Workaround
none
Suggested fix
--- RLV_v1.014a 2008-07-06 23:17:14.000000000 +0200
+++ RLV_v1.014a-xxx     2008-07-06 23:18:32.000000000 +0200
@@ -545,10 +545,16 @@
                 loginPendingForceSit = FALSE;
                 releaseRestrictions();
             }
-            else
-            {
-                 sendRLCmd ("@sit:"+(string)kSource+"=force");
-            }
+            // XXX
+            // DON'T do it here
+            // Some (many?) objects ask the relay for the !version upon
+            // sitting on it. Since the !version is interpreted the same
+            // as !pong, the relay would think the object is still available
+            // and put all restrictions on the wearer unconditionally.
+            //else
+            //{
+            //    sendRLCmd ("@sit:"+(string)kSource+"=force");
+            //}
         }
  
         if (!loginPendingForceSit && !loginWaitingForPong)
@@ -583,6 +589,18 @@
  
             loginWaitingForPong = FALSE; // whatever the message, it is for me => it satisfies the ping request
  
+            // XXX
+            // force sit here instead of unconditionally in the timer event
+            if (loginPendingForceSit)
+            {
+                integer agentInfo = llGetAgentInfo(llGetOwner());
+                
+                loginPendingForceSit = FALSE;
+                if (!(agentInfo & AGENT_SITTING))
+                    sendRLCmd ("@sit:"+(string)kSource+"=force");
+            }
+            // end XXX
+            
             if (!isObjectKnow(id))
             {
                 debug("asking for permission because kSource is NULL_KEY");
Fixed
in 1.015 by specially looking for the !pong reply so that the fix works for cages as well (no "force sit" in this situation but a collision detection which is triggered on login, too).
Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_Protocol/Restrained_Love_Relay/Bugs_and_Pending_Features&oldid=1195251"