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