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

Revision as of 00:06, 15 February 2009

Functions in development

!vision

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

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.

Syntax

!vision/(transparency)/(color)/(texture)

(transparancy) = % transparent to make the HUD prim cover

(color) = color for the HUD covering prim in 'normal' RGB format <r,g,b> 0-255

(texture) = UUID for a texture to apply to the prim

Examples: Total blackout "!vision/0/<0,0,0>/TEXTURE_BLANK"; Light fog "!vision/50/<128,128,128>/TEXTURE_BLANK"; In a plywood box no matter where they look "!vision/0/<255,255,255>/TEXTURE_PLYWOOD"
Compatibility: since this is a metacommand, relays that don't support this should ignore it

--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. --Maike Short 07:54, 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. --Maike Short 07:50, 15 February 2009 (UTC)

There are both relays and world objects out there that implement an inofficial @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 --Maike Short 07:50, 15 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 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)
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.

Alpha Code

TODO: Think about (type)=2 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. --Maike Short 10:01, 14 February 2009 (UTC)

1.030

None known

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)

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 lwoer. Add this at the end of the huge if / else if / else if block in executeRLVCommand

<lsl>

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

</lsl>

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

<lsl> --- 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");