permissions ... wtf?

LL recently changed how permissions work. Is there any word on if it's a bug that will be squashed any time soon?

How many images like the one below are being uploaded?

Wow that totally sucks. What exactly has happened to the permissions?

Indeed. More info, please.

I had to fix several scripts already that were getting permission errors (including some that were derived from Linden scripts), and *some* of my AOs now require approval dialogs.

I'd REALLY like to know what the actual changes were.

I have several objects being partly broken by the changed (added) permission event. It seems to effect any object with either a change (unsit) or attach event call. An extra 'run_time_permissions' event is generated. Probably because the 'camera' permissions are revoked, even if they aren't being used.

While this seems the logical step to take after (automatically) revoking permissions on camera. The issue is that a lot of scripts logically assume the 'run_time_permissions' event generated is generated by one of their OWN llRequestPermissions calls, not by an automated revoke permissons call. A call usually done, in the 'sit' or 'attach' event code.

The general effect is that a lot of items will now trigger the code, used to be triggered after a succesful 'sit' or 'attach' event. Causing systems to take new controls, start animations or whatever is being done in the 'run_time_permissions' event.

This breaks a LOT of content. (Vehicles, AO, chairs etc.)


The scripting fix is to assume that llRequestPermissions on animations, controls etc always go through after a successful attach or changed event and move the logic from 'run_time_permissions' to these events.
Alternatively (and probably cleaner) is to add an llAvatarOnSittarget() check and/or an llGetAttached() check before running any code in 'run_time_permissions' event.



This again is a move done by LL staff where I assumed they didn't actually think through or test the consequences. My suggestion would be to not trigger 'run_time_permissions' events for revoke/requests which are automated at this moment. As it is very hard to get information about the call triggering the event, and this is not backwards compatible with the currrent mechanism.

There also is a serious bug where if you drop instead of detach an attachment that animated your AV, there's a permision error rised and the animation continues to be applied to your AV. I've seen several people stuck dancing forever because of that, and it affects a number of my newest products too

[Edit]instaposted by Damanios

yes. i have been working hard on releasing a new 2 person motorcycle and was getting errors on sit/stand and was driving me crazy so finally tested some other vehicles i had including planes, cars , bike, and boats every vehicle returned errors on sit/stand so yes this change has basically caused errors in every vehicle in the game.

I'm asking LL QA about this for further insight--Web, Damanios, and eltee all asked in SL Answers about it, it looks like.

Thanks everyone for the info!

Relevant links from SL Answers for your convenience:

I disagree.

The fix I made, and recommend, is to check the permissions you're being granted in run_time_permissions(integer perms) are the ones you are expecting. This was already technically required under the old scheme.

What is new is that it seems that permissions are not being automatically granted in some cases. I do not understand why I should ever need to respond to a permissions dialog for animation permission in an attachment, and I would like Linden Labs to explain how this happens.
You should already be tracking (on change events) or testing llAvatarOnSitTarget() before using permissions granted by sitting, and similarly you should be doing the same thing with change or llGetAttached() for permissions granted by changing. It is possible to have permissions on an avatar that is not attached or linked to you, which leads to amusing things like having one person sit on a vehicle and another being animated if you do something liike the scripting fix Damianos suggested.

I suspect that happens if a child prim in an attachment requests the permissions. But that's a guess, and I agree, I don't see why it should be that way.



I was going to post something like that. But I'm not sure that will work in all cases. Depends on what you've set up in the error handling path (and assuming I'm understanding this right). Consider this script snippet:

... llRequestPermissions(... PERMISSION_TAKE_CONTROLS);

run_time_permissions(integer perms)
{
  if (!(perms & PERMISSION_TAKE_CONTROLS))
  {
    llOwnerSay("You must grant control permissions for this script to work.");
    llResetScript();
  }
}

Legitimate code, IMO. And the assumption is that the event is only triggered when permissions are explicitly requested by the script, which is also legitimate (again, IMO). But apparently, what is happening is that the event gets triggered on its own (and the theory seems to be that this is related to camera permissions), without the script having requested any permissions of any kind.

So what is needed instead is probably...

... llRequestPermissions(... PERMISSION_TAKE_CONTROLS);
permissionsPending = TRUE;

run_time_permissions(integer perms)
{
  if (!permissionsPending)
  {
    // Spurious event
    return;
  }

  permissionsPending = FALSE;

  if (!(perms & PERMISSION_TAKE_CONTROLS))
  {
    llOwnerSay("You must grant control permissions for this script to work.");
    llResetScript();
  }
} 

At least, that's my understanding of what's happening, based on these posts. I agree, you should check what permissions came in in the run time permissions handler, and I do that in all my scripts, always have. But I'm not sure that will work completely.

Or I've misunderstood the issue, or your explanation, or both

In this case, there's a problem in the design of this code. Since all permissions have to be requested at once, if at any time the HUD needed to request any other permission (for example, to run an animation) the code would have misbehaved and you'd have to redesign it.

Program defensively! Probably the HUD script should have done something like requesting all required permissions when it was attached, and then tracked or tested them before detaching when the "X" was clicked right in the touch event.

To fix the problem in the short term, simply provide a 0-cost vendor for the updated HUD. There's no risk to doing that. If someone gets it who doesn't have the avatar, all they'll get is a cute HUD that doesn't do anything... it's got no values, and people picking up copies of the HUD don't represent lost sales.

In the long term, why not simply open-source the HUD control script. The HUD code doesn't represent anything that will cost you any competitive advantage. The same is true for things like the "blink" scripts in just about everyone's furry avatars. Keeping them secret just prevents people from customising them, it doesn't give you an advantage over other avatar creators or lead to any additional sales.

Incidentally, I applaud Whinge Languish's intention of open-sourcing the twitch code for his forthcoming rabbit avatar.

Okay, I'm still not quite sure what this is going to affect, but we need solid answers kinda nowish.

Honestly. I, and many other people here, are professional programmers, and I know that if I put in a change in an update that coincidentally screwed a bunch of functions that my customers were using that previously worked without even telling them, I'd be chewed up and spat out, and I'd deserve it.

I agree wholeheartedly. I ahve had to remove 80% of what I sold in SL from sales due to this problem. IF they can't fisx it then this upgrade, as every one before it was premature. I'm getting really tired of paying a large amount, more than in any other 3D Chat to be a stinking beta tester.

And what do you do when the requested permissions aren't granted? Your code snippet doesn't show that. I'd love to learn a better way to do this. I can see your method working in the cases where the user refusing to grant permissions has no effect on the script, or isn't something that needs to be explicitly handled.

Take another example - a game machine, where the owner is asked for debit permissions, and permissions aren't granted. The script simply cannot function without those permissions. The options are to reset the script, nag the owner repeatedly for permissions, or print an error message and go into some non-working state where the owner has to reset the script manually. What have I missed?

All of those will break if the permissions event is triggered without permissions being requested. Your code snippet... if you have a catch-all else case at the end, that will get triggered if the event gets called autonomously with camera permissions, even if your script doesn't do anything with cameras.

In this case the permissions are always granted automatically.

If the permissions aren't granted automatically then my code looks more like this:

key requestor;
key passenger; // or customer
integer setup;
setup() /// called from state_entry, on_rez, touch, change, or other initial event...
{
  setup = 1;
  // other initialization code
  if(requestor)
    llRequestPermissions(requestor, ... all required permissions...);
}

finish()
{
  passenger = MULL_KEY;
  requestor = NULL_KEY;
  setup = 0;
}

is_setup()
{
  if(!setup)
  {
    setup();
    return 0;
  }
  if(passenger == NULL_KEY)
  {
    llInstantMessage("You can't frobozz the wakalix."); // or whatever
    return 0;
  }
  if(requestor && passenger != requestor)
  {
    setup();
    return 0;
  }
  // other tests
  return 1
}

//...
run_time_permissions(integer perms)
{
  if(requestor && (permission & PERMISSION_FROBOZZ))
  {
    passenger = requestor;
  }
}

//...
touch_start(integer n)
{
  requestor = llDetectedKey(0);
  if(!is_setup()) return;
}

If a new guy touches the controller, it'll get permissions. If they refuse 'em, it'll tell them off. It's easy to add timeouts in here, request permissions multiple times, if the guy decides to play for money, add timers...

The testing is always done in response to a user's direct action. All run_time_permissions do is validate stuff. The state of the program is in states and variables, not events.

I want to join your club and to get informations.
My donation is this.

OK, that kinda makes sense. Thanks for posting that. If I'm reading it right, no action will be taken when the person clicks the 'Deny' (or 'No' or whatever) button on the permissions dialog. The check for passenger/customer not being set will happen on the next input/trigger. Did I get that right? So...



It'll tell them off the next time they try to do something. I'm wondering if there's some situation where you'd absolutely need to react to the permissions being denied.

Anyway, once again... thanks. I hadn't considered doing it this way. It does make sense to me - it's better to not depend on when/why an event might get generated.

First, pardon for the replicated post--didn't want to narrow our communication range here.

These recent postings all detail related experiences, so to connect them:
/139/b0/97398/1.html
/139/d2/97502/1.html
/139/ee/97281/1.html
/139/ae/97520/1.html
/54/f2/97438/1.html

Second, I'd like to apologize for the sheer frustration this has caused. As we have a history of doing--see Known Issues--we like to fix something like this agilely, sometimes quicker than a timeframe can be discussed, as was the case just the other day with the llXorBase64Strings problem.

To confirm, "llReleaseControls should fail silently if you do not have permissions", allowing for automatic revocation of permissions for animations and soforth, has JUST been fixed internally. Which means, pending verification, should be addressed in the next version of Second Life ASAP.

I witnessed amazing teamwork today in coordinating everything together.

Help is on the way, please be assured we very much care about things like this!

Agreed, a good practice but this will not solve the problem in this case.



What seems to happen is that extra events are triggered when a person unsits or detaches an item. (I haven't checked if this is always the case, or just in child prims)
The permissions flag will still contain all the permissions requested and granted. So checking this will not fix the problem.

What we need to know if this is a 'real' event triggered by llRequestPermissions or a 'rogue' event triggered by an automatic permissions change (llReleaseControls?).
This either requires to statefully track the permissions flow using a global, as in ziggy puffs code example. Or try to determine the moment that the run_time_permissions event is triggered (sit or unsit/attach or detach or other moment). A possibility for this is checking other status info, like is an avatar sitting, is the object detached.
This is basically what i suggested by checking for llAvatarOnSittarget etc.



[/QUOTE]

Agreed, except where it used to be enough to check this in the actual 'changed' event, it is now also required in the 'run_time_permissions' event. (It's not necessary to request permissions if nobody is actually sitting on the specific prim). Next to that. Checking on global variables used for tracking is useless, as there is no code executed to change these before the run_time_permissions event is triggered.

Actually, thanks for reading, but the whole point becomes moot, as it's being fixed by LL

(yay!)

As far as I can determine, the warnings are generated at the point where the avatar delinks from the object. IOW, I have permissions galore to do what I will on my boats except get off the things. Clicking the 'stand up' or 'release controls' buttons creates the errors.

I am at my wits' end to capture this event and handle it; as the avatar is no longer attached, there's sod all I can do. Run-time is over. Fini. llAvatarOnSitTarget() is a null key. llGetOwner() isn't, but the errors (there are two of them, each time) have come and gone, and it's way late for me to toddle about asking for permissions on behalf of a boat owner no longer linked to her boat. Not that I haven't tried. Which is how I know.

I've even tried commenting out llReleaseControls(), and all other code executed in the event that the changed function determines that there is no one linked to the boat. I've been at this for some time; the errors are generated at the point of de-linking.

I don't know why anyone would need controls permissions to stop interacting with something, but it appears they do now. I can only assume this is a side-effect of some kind, and will disappear in the fix Torley mentioned.

ok, so does this mean the fix will come out in next update, possibly next wednesday? I mean isn't this problem serious enough that once you have the fix tested as working, that it be rolled out like right away?

As far as I could find, the problem with Mood mixer was in the control keys only.

In the past, the script would remember that it had given keys in the start event (which runs the first time MM is worn by a new owner) and this was persistent from session to session

Not only does it forget now, it also needs one of two things to occur before it "smoothly" allows permissions to be regranted.
A) llResetScript
or B) llReleaseControls

So in short, all I had to do was add code in the attach event
when wearing I ask for permissions and when detaching I release controls.

I assume that the error is a bug that is causing cameras to keep controls if you reset a script. Apparently camera controls are released either manually [CAMERA_ACTIVE, 0] or by the act of standing. The two are suspiciously similar in this regard although it could be a coincidence.

Right. It's pretty rare that you need to take action when permissions are denied... all you need to do is know whether you have them or not.

If you're doing something where time is critical, you probably should have already requested the permissions you need, because you don't know how long that permission dialog will sit there on the user's screen.