Owner-based On/Off-Switch for Permissive-Command
Okay since i just talked to Lulu about it i will now post my own wish here, although i don't even know if many people experienced this problem so far.
To start with the background, my Master uses the LULU-system as ownership-collar, so at least the collar (and therefor the HUD/uHUD) are meant to be permanently locked.
The LULU-HUD, once locked, sets a Permissive-Restriction (explanation can be found below), which negates every exceptions done from other products.
That alone is no problem maybe, unfortunately the command does not care about who locked the Collar, or who locked the item with the negated exception.
Two examples i have experienced so far, surely there can be found more:
1)
My Master loves to keep an MD-Collar locked on me as second collar, to have some exceptions handy to him as well as having a 2nd option within his hands when the LULU-collar/HUD is unlocked due to updating, reseting or similar things.
This Collar also sets a sendIM-exception, so that (usually) i can just play with my neat RR-Stuff and let strangers gag me even with IM-block and still have the direct emergency-line to my Owner, so that he always can stay informed about my situation when he wishes to.
RR-Gags don't set a secure IM-block by themselves.
But the LULU-HUD (locked by my Owner) declines the exception put on the MD-collar (locked by my Owner) and makes IM-Block from RR-Gag (locked by Stranger) to first priority.
2)
Recently i tried out the Selective Hearing System from LSI, that works together with an OC-Collar.
I did resize one collar and put it on my ankle (look's nice), this OC-collar is owned and locked by my Owner and sets a rcv-chat-exception for him.
The Hearing itself, although it is a plugin within the collar, uses an own HUD to apply the rcv-chat-block and is also locked by my Owner.
Well, the LULU-HUD simply kills the OC-collar exception, only letting the block in place, where my Owner got no exception for now.
I know that there, especially in the 2nd case, the maker of the plugin better should have sent the restriction through the collar itself or applied an own exception on the HUD, so its an issue that comes up especially because of this.
But to be honest i'm sure, that there are other times and examples as well i did not experience so far or can't remember, so i really would like an On/Off-Flag for the Permissive-Command, that only can be used by the Owner (surely).
/wolfie
Allow/deny permissive exceptions : "@permissive=<y/n>"
Implemented in v1.21 When denied, all restrictions turn into their "secure" counterparts (if any). This means an exception to a restriction will be ignored if it is not issued by the same object that issued the restriction. Using non-secure restrictions (the original ones, like @sendim, @recvim etc) and not using @permissive allow the avatar to benefit from exceptions issued by different objects.
Warning : Using this command (or any secure version of the original commands) may silently discard exceptions issued by different objects (it is even its primary purpose), hence some products may appear to cease working while this restriction is in effect. For example, a product that allows the avatar to always be able to send IMs a particular friend will not be able to overcome a @sendim_sec or a @permissive command sent by another object, and will look like it is broken.
from:
http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI
Like Idris, I did not think that @permissive had global effects that shut out everyone else, at least not according to a cursory reading of the API notes. Thanks to Wolfie for the detailed clarification, and to Idris for investigating this.
This will be fixed in the next 7.4.12 air patch.
-
Idris Georgia commented
My reading of the permissive setting in the RLV API, was not that it had global effects. Unfortunately, after discussing it with Marine, I discovered it is global. Hence, it's having more of an effect in the Lulu hud than expected. My suggestion is to remove permissive, and change any non-secure instructions in Lulu gear to the secure versions, That way Lulu gear won't affect any restrictions outside of it's own.
-
Anonymous commented
This shouldn't take too long to implement. Please have a look at it, as the permissive restriction stops my owner from using the LULU on me.
-
Anonymous commented
i agree and support this. i cannot play with my Lulu set as i wear an OC collar and the exceptions list is ignored totally so my owner told me not to wear these again until this permissive thing is fixed. and it should be fixed asap because i am not the only who can't use Lulu as a direct result of this setting.
-
Myggen Resident commented
As a new user of LULU, I agree that this permissive setting bothers me quite a bit. Some may like it, so letting the owner decide is a good way to make both camps happy.