Denypermission woes

Hi,

A lot of people have expressed concerns about the latest addition to the RLV, and to my HUD system : the @denypermission command. For the layman, that command makes you automatically deny all attach permission requests, making your restraints totally secure (they could be kicked off with easy scripting otherwise). First of all, please understand that this is not a trivial problem at all, in fact it is quite fundamental. Secondly, be sure that I am putting myself into this dilemma, and will do all I can to find a solution soon. No ETA, just as soon as possible.

Here are my views on the subject, though :

* When an object is locked, nothing, absolutely nothing should be able to kick it off until it is unlocked. Without @denypermission there is a way, and nothing else can fix it.

* @denypermission does not break content, but it certainly makes using several auto-attaching HUDs a pain in the ....... , to the point of making it next to impossible to bear.

* The whole rewriting of my HUD system was actually triggered by the introduction of @denypermission. I won't enter into details, but that was a very fundamental change. Now I have to revert that, and that doesn't make me a happy bunny.

* I do want to make my HUD system plugin-based (to have a user menu), but not so soon, it's too early. I need to discuss a few things first, and to think it all thoroughly. So making this command optional would not be possible right now.


So... @denypermission is not the way to go. It breaks content. It makes the experience a pain for the user. It eats your babies. There must be another way. At the time of this writing, here is the solution I'm thinking of :

-> To have the viewer automatically re-attach a locked item that had been detached by a script. Although not trivial, the latest functions I have added to the RLV make this possible (namely the ones that I created to add @getpath). The only problem is... what would happen if the item gets kicked off by another one that immediately locks itself ? We would have a forever loop, that would either crash the sim or at least lag the viewer badly (or both). I would like to find a way to "delay" the locking of an item that has been attached by a script. If I can do that, then there will be no need for @denypermission anymore (although it will stay here, it might be useful in some cases where we need ultra security, namely when nothing should ever be detached at any time).

(Edit : I have found an elegant solution, now to find the time to implement and test it...)


In a nutshell, yes I hear ya, @denypermission is evil. It is necessary, but maybe overkill in the way I use it in my products. So there will be an update to my HUDs again, if you're annoyed by the current behaviour. Just be patient, I have many other things to do atm.

Marine

PS : For those who wonder whether it is the same girl who got herself spanked by several people at SH today... yes ! It is the same one. I get spanked and then I write technical stuff. Bear with me. lol

A few words about 1.16.1

Hello there,

Just a quick post to talk about RLV 1.16.1 that will be due when Linden Lab release their SL viewer v1.22 as the official version.

Firstly, it has been confirmed that RLV 1.16 does NOT work with SL 1.22.9 RC. It certainly did with 1.22.8, but it seems to be crashing now. Just to make one thing clear, I can NOT publish a new viewer every time a new RC hits the shelves. Otherwise I would spend my time building viewers. As you might know, it is now more difficult for me to compile on Windows than before. So please be patient, and if you really can't wait, the Cool Viewer is the tool of choice for you.

Secondly, after many discussions about llGetAgentLanguage, I have decided to make it back the way it was before, that is sharing the language settings of the user, and not the version of the RLV. There are several reasons, ethical and technical, the latter defeating all the advantages of actually using that function. Namely, llGetAgentLanguage does not return the version right away after logging on. It starts with an empty string. That would have led the script to be forced to wait (with a llSleep or something) before checking the version.

Thirdly, there was a bug with @getpath which would give away the exact path to whatever piece of clothing the user is wearing (not attachments), whether they were shared or not. If the point of sharing outfits is to "expose" them, the point of not sharing them is to NOT expose them, that makes some sense.

Fourthly, @set/getdebug_avatarsex was not working at all. Really not at all. Fixed now (thanks Henri).

Fifthly (?), while 1.16 was hiding the names of the avatars around under @shownames, then first names, then last names (if any), it was a little too intrusive, and could really mess some messages up. Mo Noel, for instance, had that problem because her first name, "Mo", was getting replaced by "an agent" or something. This lead to very difficult to read messages... I would like to use regular expressions to make the replacement smarter, unfortunately this "string replacement" is a function that is called a lot in the viewer, so it has to stay very basic.

Sixthly (??), and that has only a loose tie with the viewer, some people have complained about the latest update to the blindfold, which hides names and location when locked. While I do believe that seeing the names over the heads is unrealistic, recognizing the "voices" is not, so I hear ya, and have issued an update to the RealRestraint_HUD objects. This means that if you are annoyed with that behaviour, you just have to update your blindfold, but also all your arms restraints (wrist cuffs, wrist shackles, wrist ropes, wrist straps), because the change takes place in the HUD. This only requires a "Type 4" update ("Extensions only"). Then to detach your current HUD (because it does not detach by itself), and let the updated object rez its new one.

Hope this makes things clearer. Have fun !
Marine