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/<255'255'255>/0.0/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)

STOP spreading FUD !... Marine WAS aware about @putinv and I DID discuss about it with her before implementing it in the Cool SL Viewer as a proof of concept and PRELIMINARY feature (meaning I never made ANY assumption on the fact this feature would finally be implemnted in this form or even implemented at all). As for it being a "debacle", please read Marine's blog and you will see how wrong is this assertion of yours. As for coming on late on this topic, I don't accept blame for it: if you don't keep the author of RestrainedLife (Marine) informed, do not be surprised that they come back to you saying your work does no suit them. Henri Beauchamp 08:10, 16 April 2009 (UTC)

I am not going to post any private IM discussion to a public place. Period. // According to [1] @putinv was not a preliminary feature, it was released, active by default in RestrainedLife v1.16c. Putting your users with enabled RestrainedLife and a relay (perhaps one of mine) at risk of being used as hosts for an account jumping worm. My point is not that it is dangerous to use Cool Viewer while !vision is not. But that you should be a good example of communication your changes before you demand to be informed by others. We try to do things different for the relay spec. Because of this open approach most relays work rather fine and compatibilities issues have been greatly reduced since the original version of the spec. Although there are far more relays out there than RLV compatible viewers and we are missing an active maintainer of the spec. // The blog post I read clearly says: "The inventory offer must also trigger the dialog box with the Accept/Decline/Mute buttons" [2]. I am not a native English speaker but from my point of view this is the exact opposite of "Allow/prevent to auto-accept given sub-folders into the #RLV folder: @putinv:<UUID>=<rem/add>" [3]. --Maike Short 17:21, 16 April 2009 (UTC)

 

I have all the private IMs logs with Marine too, and could demonstrate that she was OK with the principle *before* I made it a *preliminary* feature in the Cool SL Viewer. And AGAIN, you are spreading FUD since in (1) there IS PRELIMINARY SPECIFICATION clearly shown: can't you read, or are you just trying to badmouth me ? Since your behaviour is so outrageously one of a liar an dishonest person, I am not going to discuss things further with you. Henri Beauchamp 08:38, 17 April 2009 (UTC)

Henri, please calm down, sleep a night, and read this discussion again. My point is that you implemented @putinv without talking to common relay makers first. But at the same time you expected an extra invitation to the open discussions about the relay spec. This does not fit together. Writing "Preliminary specification" above an already implemented and released feature does not change anything about the risk you put your and our users at. I would have liked to have a chance to filter @putinv before people are at risk. Whether this risk is specified "prelimiary specified" or not at all specified is rather irrelevant. Oh, and please stop insulting me. --Maike Short 17:34, 17 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)

I disagree that it duplicates the function of blindfolds (legitimate or not). What it does is make them easier to build. The easiest part of the blindfold is putting a texture across the HUD, everything else, the control mechanisms, the choice of textures, that is what makes a blindfold. --Chloe1982 Constantine 09:49, 14 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)

Henri, I'm sorry you feel like this, but I will point out a couple of things. We originally developed this as a MOUSELOOK ENFORCER, nor for blindfolds or anything like that. We hung a prim on the back of our relay so we didn't have to make the users use up ANOTHER ATTACHMENT POINT to handle mouselook. After looking at several issues, we decided to make it a meta command and let the relay handle it (one less listener on an AV). Since it was a RELAY ISSUE (not passed to the VIEWER) where else should we have put the discussion but on the Relay Development Wiki? We found this could be used for other situations as well, distorting vision, darken, put a hard wire mesh on someone so they couldn't cam out to get around it.. it's a MOUSELOOK element. Second, you say "!vision makes assumption that the relay is a HUD". Durn straight it does.. says so back in the very beginning - "Implementation : using a small microprim that hides on the back of our RelayHUD". Say again, save an attachment point on either the AV or their viewer. Third, "It also duplicates the function of legit RestrainedLife blindfolds". Not necessarly. If I stick you in a box and turn out the lights, you're blind. Does that mean the box should hand you a blindfold, that if you are restricted the right way, you can't put it on (prevented from wearing things or something on the attachment point you can't detach???). How about if I want to just 'shade' things a bit (wire mesh) or you're a rotten little snit subbe and go out of mouselook and I just want to blind you totally? Stop and hand you a blindfold that you could refuse to wear??. This is a restrictive mechanism that is at the AVATAR LEVEL, not an attachment they wear. Fourth, since this is a RELAY restriction, we didn't go NEAR the VIEWER to implement it.. we have enough people come in the store every week that are totally bumfuggled from a device messing with the windlight settings and not restoring them and they are permanently blind, this can be reset if they safeword out. Fifth, we could have left this a deep dark secret mechanism (admittedly that was what we did when we fist implemented it, with a separate listener, etc...) but decided IT WAS USEFUL FOR THE COMMUNITY, so we put it forth for discussion and OPEN DOCUMENTATION. Sixth, "Compatibility - since this is a metacommand, relays that don't support this should ignore it" --Ilana Debevec 21:13, 13 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)

I'm 100% with you on being concerned about a fork in relay implementations. I had this concern the moment I found a need to wear one of two relays.. each of which had an extension that made them necessary. I also think that the !vision option gives us some choices... e.g., it can be used for a straight blindfold, or to implement a complete "no touch" using a transparent prim.. it means that I might no longer end up with a case of prims dueling over where on my HUD they want to attach their prims! --Chloe1982 Constantine 21:05, 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)

-

Very sorry for arriving so late, thank you Maike for pointing me to this page. In a nutshell, !vision and !visionclear are two proprietary commands that have nothing to do in a spec like this one. Henri is absolutely right in saying that the relay is just that, a relay. It is a gateway to the viewer, nothing more. It must *not* handle anything else that a script can do. Besides, changing the Windlight settings is already doable through the standard relay... I am afraid I will have to remove that part from the spec to avoid confusing future relay (and furniture) makers...

Marine Kelley 17:02, 14 April 2009 (UTC)

Item 1 - pro⋅pri⋅e⋅tar⋅y - manufactured and sold only by the owner of the patent, formula, brand name, or trademark associated with the product. (points back up to full documentation of the command, scripts to implement same and release to the community). Nope it isn't one of those.

Item 2 - "the relay is just that, a relay. It is a gateway to the viewer, nothing more. It must *not* handle anything else that a script can do." As it it written, it IS a gateway to the viewer, since I don't know of a way for a piece of furniture (or anything else) to affect the viewer visibility (prim attached to the viewer) other than take up an additional attachment point on the viewer or the avatar. So, yes it is a gateway. Done in a way that makes it easier on the user (doesn't take up an attachment point on the screen or on the avatar) and tries to save on resources (no extra listeners), works on any viewer (see item 4) and provide consistent and SAFE way to handle various situations that won't screw up the user's experience (see item 3).

Item 3 - "changing the Windlight settings is already doable through the standard relay..." - an undocumented (officially) interface to the viewer that could change or be removed at the whim of the Lindens, and can easily be screwed up by badly scripted devices (as evident by the people we have come to the store with their vision borked by things that, even when DETACHED and (supposedly !release'ed) STILL HAVE THEIR VISION MESSED UP, EVEN WHEN RELOGGING. Very Dangerous. Also, can boinking the Windlight settings let you apply a texure of your choice (like wire mesh, or the such)?

Item 4 - "changing the Windlight settings is already doable through the standard relay..." - unless of course you are running a viewer WITHOUT WINDLIGHT (see: Boy Lane's Coolviewer implementation 1.19.0.5 R54 (legacy and fast non-Windlight renderer) or anyone that just disables Windlight). This method works on ANY VIEWER on ANY PLATFORM.

Item 5 - "to avoid confusing future relay (and furniture) makers..." - fully documented and marked OPTIONAL, specifically says 'requires a HUD'.. so what's confusing? Note word OPTIONAL.

Item 6 - does this mean you'll be implementing something similar within the 'viewer proper' (@vision?) with the same capabilities, in a safe, reliable method?

--Ilana Debevec 02:05, 15 April 2009 (UTC)

You assume the relay must be a HUD, that renders useless any script that the user is supposed to insert into a restraint (or that the maker has already inserted into the restraints they sell). If you say that would not be a problem because that command is optional, then I can't agree since this is a standard. There is no question of having "mandatory" and "optional" commands. That would only make furniture scripts more complicated as they would have to check whether your relay can support such and such command. And if not, provide the appropriate relay I suppose. As for Windlight, it is very unlikely the Lindens would remove that feature now. And no there is no question of a @vision command in the viewer. What a script can do, the viewer won't.

Another thing : making a prim that blocks your view and/or clicks and stays there is less trivial than it sounds. There are many ways the user can get cheat around the HUD so it has to periodically (very often) check that its shape, color, texture, rotation, hole size etc have not changed, and if so snap back to the default shape and size. It requires a fast timer to do so and a standard relay should not implement one just for this kind of command. I highly suggest using a *proprietary* HUD that would work only with that furniture, also because no two furniture makers will want the relay to have the same texture or respond the same to clicks etc. In a word, the relay is just a script, here you are wanting it to be an object by itself. That would be shifting the concept too much for just one feature.

--Marine Kelley 07:34, 17 April 2009 (UTC)

I wholeheartedly agree with you on that first point: to me, it looks like a lame attempt to impose a relay over the others with the argument that it would support more things or be "compatible" with given toys. Since one can't wear/use two relays because of cross-talk, they obviously have only one alternative: either use a standard relay (or the relay script in their collar, cuffs or whatnot) and be unable to use furniture requiring !vision, or use a relay with !vision and have to remove their other relay (or even their collar, cuffs or whatnot if the relay is in there). It is very clear to me that this !vision feature is a major point of incompatibility and conflicts. As such, it must be removed from the specs. Henri Beauchamp 09:15, 17 April 2009 (UTC)

It is removed from the main page now, but not from the spec of the ThinKink relay. It is perfectly ok to have custom relays handle more commands than the spec, but this way it does not make all current relays stop being compliant with this spec by not implementing !vision. Sorry if it upsets some people, but I think this is the best solution.

Case closed.

--Marine Kelley 09:37, 17 April 2009 (UTC)

Thank you for your insightful and helpful comments! --Chloe1982 Constantine 16:02, 17 April 2009 (UTC)

Adding any !commands increases processing time on the relay, which lowers its performance. Since relays are a "router" to the viewer, they should simply be directing the flow of information, not trying to process it. Process intensive code would be best handled by the viewer, such as changing windlight settings to get the same !vision or @vision operations, or verifying @commands for validity. --Da Chrome 20 December 2011

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