Talk:Run time permissions

From Second Life Wiki
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)


It's bad practice, because requesting permissions with llRequestPermissions is supposed to be asynchronous. Whether llRequestPermissions grants the permissions immediately in auto-grant cases is an implementation detail (unless LL says otherwise). If the implementation changes in the future, you might end up with a broken script.
--Blackheart Laval 16:16, 28 November 2010 (UTC)
PERMISSION_DEBIT is not one of the auto grants, but SVC-5239 makes a great case for checking always. Bugs like to sneak in at the least expected points! For Stickman's old dilemma, it can work to run things that don't really need permissions from inside the run_time_permissions event, then the delays do not get in the way. Make it a function call if that kind of commingling makes you itchy :) --Cerise Sorbet 19:07, 28 November 2010 (UTC)