I would like to address two run-time permissions which don't make any sense to me, and seem to cause more trouble than they are worth:
PERMISSION_TRIGGER_ANIMATION
PERMISSION_TAKE_CONTROLS
How many of us have been annoyed at the constant "Object attempted to animate avatar but PERMISSION_TRIGGER_ANIMATION was not set" error?
I really don't see why we have a permissions system in place for an object WE OWN to request permission to do something as harmless as animating our avatar, meanwhile anyone or any object can orbit us at anytime without requesting permissions.
Now, I want to make it clear, I do NOT want run-time permissions to be added for llPushObject. I prefer fewer permissions and more accountability. But I do think this makes a good example of how these two run-time permissions don't really make a lot of sense in the grand scheme of things.
The animate and control run-time permissions would have made a lot more sense if an object owned by us were able to trigger animations on another avatar, or collect their input controls. As far as I know this isn't possible, so these permissions seem quite frivolous. Since these permissions only work within objects that we own, we could easily "deny permission" to any object that wants to animate our AV or take our controls, by detaching or derezzing it.
Now, I realize it would probably be difficult to rip this stuff back out of LSL, so I really don't want to ask for something quite that drastic. What I would like to ask is if it would be too much trouble to add an option in our preferences for each of these two run-time permissions, so that they are always automatically approved?
In addition, would it be possible for scripts to somehow be less "spammy" when they don't have permission to do something? Perhaps instead of spamming, the virtual machine should trigger a special event when it can't get permission. Then it will be up to the script author how to handle unobtained permissions, perhaps by llInstantMesage to the owner, or by just resetting the script or closing down timers.
Thanks for reading.
-- Kex