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". !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. 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).

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