Talk:Run time permissions

From Second Life Wiki
Revision as of 20:09, 20 June 2008 by Stickman Ingmann (talk | contribs) (Asked a question regarding the validity of circumventing this event call)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

It is said that one should use the run_time_permissions() event instead of relying on auto-granted permissions. I'm wondering if there is a particular bug regarding it, or if this is just a general blanket rule with worthy exceptions. That is my question. Allow me to expound to avoid misunderstanding, and restate the question.

For example, when putting llRequestPermissions() in the attach() event, under an if (id != NULL_KEY), you are essentially guaranteed to have auto-granted permission.

In addition, when you have additional processing that takes places in the attach() even, such as items with script delay, the run_time_permissions() event won't be triggered until those are done. If you're playing an animation, changing the camera, or whatever, those won't happen after all the script delays and processing are finished.

But if you do this:

default {
   attach(key id) {
      if (id != NULL_KEY) {
         // Anything within this if statement should only occur
         // when permission will be auto-granted.
         llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION);
         llStartAnimation("super cool animation");
         // imagine lots of delays and processing in here
      }
   }

It will work fine. (Note: leaving off llRequestPermissions() results in no permissions being silently granted.) Whereas the "proper" way:

default {
   attach(key id) {
      if (id != NULL_KEY) {
         llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION);
         // imagine lots of delays and processing in here
      }
   }
   run_time_permissions(integer perm) {
      if (perm & PERMISSION_TRIGGER_ANIMATION) {
         llStartAnimation("super cool animation");
      }
   }

Will result in the super cool animation being triggered after all of the script delays and processing, which in some cases is not ideal.

So is this an exception to the rule? Or is this still bad practice? That is, has anyone ever experienced failure in this regard?

The only case of failure I can think of is attaching the item, then quickly detaching it before the attach() event can finish running. Generally only certain functions (like llSleep()) or extremely long processing time will cause an attachment to finish the detach without exiting the current event first.

--Stickman Ingmann 20:09, 20 June 2008 (PDT)