LSL Protocol/Restrained Life Relay/vision

This is a discussion page for adding vision restriction.

!vision

Implemented in THINK KINK's tkPBA v30i

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/(color)/(alpha)/(texture)/(repeats)/(offsets)/(rotation)

(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)

(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'

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

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

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

yes --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. --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. --Ilana Debevec 08:06, 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)

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. --Ilana Debevec 08:06, 15 February 2009 (UTC)

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? --Satomi Ahn 16:46, 19 February 2009 (UTC)

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. --Maike Short 18:23, 19 February 2009 (UTC)

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. --Satomi Ahn 22:00, 19 February 2009 (UTC)

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. --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 --Ilana Debevec 18:41, 16 February 2009 (UTC)

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 --Maike Short 19:45, 16 February 2009 (UTC)

Agreed and done --Ilana Debevec 22:59, 16 February 2009 (UTC)

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? --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: % ? --Maike Short 18:23, 19 February 2009 (UTC)

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 --Ilana Debevec 23:39, 19 February 2009 (UTC)

And why not animations too? I don't know what is trivially doable, but for instance, setting an omega to the prim should be easy. It would be nice for instance for hypnosis thingies. Maybe this is something we should ask Rygel Ryba about. She must have an opinion on this. --Satomi Ahn 15:39, 10 March 2009 (UTC)

The relay should be just that - a relay providing gated access to viewer RLV commands. !vision breaks that. If you want a blindfold, give the user a blindfold. I am strongly opposed to !vision.--Sharie Criss 13:06, 27 March 2009 (UTC)

I don't want a blindfold but I like Ilana's idea of restriction camera cheats out of cages.

As far as I understood the idea of the relay specification the main goal is to not have hundreds of incompatible relays protocol, one for each world object vendor. Therefor I think it is a good idea that the !vision command is not a proprietary (vendor specific) extension only working with the ThinkKink world objects and the ThinkKink relay. The relay specification has already a mechanism to reject commands and tell the world object about this decision. In this case the spec even spells it out that !vision is an optional extension and it is okay to implement it by simply sending !ko without any further actions. While I don't like the idea to make proposals like this a hard requirement I think they should be accepted as optional extensions. I am afraid that rejecting such proposals (for which there is a demand in real world cases) will only lead to forks. In my opinion the Lockmeister/Lockguard rivalry is something we should work hard to avoid for the relay. It is already annoying extra work to support both Lockmeister/Lockguard. The relay protocol is much more complex than those, so supporting both the original and a fork will be a pain in the... --Maike Short 14:34, 29 March 2009 (UTC)

I 100% agree with Sharie: a relay should NEVER implement such commands as !vision. I spoke with Marine about it and she too agrees that !vision and !visionclear have nothing to do in a relay. I personally will always refuse to implement such features in my own relay(s). Henri Beauchamp 00:06, 7 April 2009 (UTC)

Hmmm, it would have been better if you could have added this comment back when the idea was under discussion. In an ideal world we'd have something like the !vision functionality in the viewer, that way every device under the sun that wants to restrict either touch or vision wouldn't have to attach a prim to my HUD. But, if this is an optional command, then no harm done and you don't have to implement it. We put it our relay which comes as an object on the HUD to give a reasonable and consistent way of restricting vision (blindfolds could use !vision also)and touch. After having 3-5 people a WEEK coming in to the store, blind, because other toys/devices/attachments were manipulating the windlight settings and then not restoring them when they were taken off... we wanted to do something that was a) consistent, b) documented, and c) non destructive of the SL experince. --Chloe1982 Constantine 22:04, 9 April 2009 (UTC)

I was not made aware about this new extension (neither was Marine !), although I am the developer of one of the major RestrainedLife compatible viewer (the Cool SL Viewer). This is why I discovered this "extension" by stumbling upon it when checking for specs on the Wiki and only worded my concerns "this late". --Henri Beauchamp 22:23, 12 April 2009 (UTC)

Wow. I have to admit that I am impressed that you dare to pull a Marine after your @putinv debacle. As far as I know you did neither get approval from Marine for @putinv nor did you warn any relay vendors that you are implementing such a dangerous command. I really do not want to have anything to do with Worms that spread from account to account using this Cool Viewer extensions any my relays. Changes to the relay spec, however, have been proposed and discussed on the Wiki for more than 10 month now. That is before new versions of the spec have been released, not just adding a hint about a new command after it was released. It is unfortunate that you did not notice this discussion in time, but I don't accept any blame for that. (I should have poked Marine through and will do so in the future). --Maike Short 20:53, 13 April 2009 (UTC)

!vision makes assumption that the relay is a HUD. It also duplicates the function of legit RestrainedLife blindfolds: if you want your device to blind its victims, simply give the latter a proper RLV blindfold (or blindfold-like) device. --Henri Beauchamp 22:23, 12 April 2009 (UTC)

The relay should only relay commands, and give useful information (!version, !who, and yes, !gender since this cannot be reliably be obtained via RL commands). --Henri Beauchamp 22:23, 12 April 2009 (UTC)

Yes, the required HUD is the main reason why it is spelled out that !vision is optional (although a relay may refuse any command for policy reasons anyway). I am neither aware of any "legit RestrainedLife blindfold" nor a specified protocol that will blind the wearer when the cam is moved outside a cage. As you know there it is not possible to "simply give the [victim] a proper RLV blindfold" without them to find it in their inventory and manually attach it. That's why you implemented the @putinv command and allowed objects to give items into the #RLV folder. A solution that would have been cool if it did not come with the security issues. --Maike Short 20:53, 13 April 2009 (UTC)

From my point of view the question is not whether world objects should be able to restrict the vision or not. But it is whether the protocol that is used for this purpose is specified in the relay spec and open for others to implement or a proprietary extension. Which quickly leads to the question whether it should be done on the relay channel (like @thirdview) or on its own channel. I can think of two possible outcomes: Either it is kept proprietary and we have lots of incompatible pseudo-blindfold-objects or it is openly specified but outside the relay-spec. In my opinion the second choice is the first step to get a second Lockguard like fork. This "Extended Relay Spec for more than just RLV" could do other improvements as well: For example it could reduce chat spam by collapsing multiple relay replies into one single message instead of one per command and using different channels for relay->object and object->relay. To be honest, I am really scared of a forked relay spec. That is the main reason why I have spend so much time on the relay spec and discussing with relays/world objects vendors during the last year. I am afraid, it will not be the last time that people want the relay to do more things than just be a gateway to the RLV. !(get)gender is a good example for this. Demand for !getspecies is to be expected shortly afterwards. --Maike Short 20:53, 13 April 2009 (UTC)

So now we have: You may ignore !vision. But if you implement it, you need to stick to the spec to be compatible. From my point of view this is by far the best solution possible. --Maike Short 20:53, 13 April 2009 (UTC)

!visionclear

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

--Ilana Debevec 10:44, 15 February 2009 (UTC)