Scripting & Permissions

Yes, that seems to be the case, and it's the fix that I'll be applying.

However, as I mentioned on the "wtf" thread, I deliberately *don't* have a permissions check on detach for any object that needs an animation stopped, because you literally need every millisecond it appears. When something goes back into inventory, half the time you end up keeping the same animation *anyway*, even having the llStopAnimation call right first in the detach event (and that problem's been getting worse, even over the time I've been scripting). Now, this new change is a useful fix for that problem, even if it's a bit of a kludge, but if it just fired *after* the attach(), that would mean there were no errors.

The other things that you've mentioned either don't cause permissions loss or are also accompanied by an attach() or changed() event, where you just request them again, as you should. I've never had any problems with them with scripts that don't constantly check permissions, either as sit objects or as attachments.

edit: oh, and yes, run_time_permissions should definitely be called whenever permissions change, I agree.

Nope. It doesnt fire upon detach in 1.8. This does seem like an oversight.

Omg

From my testing in 1.9, run_time_permissions() now fires upon detach. It appears that the Lindens may be following this thread.

It appears that permissions are still being automatically removed BEFORE a changed() event, so scripts that attempt to stop animation without checking for permission *are* going to generate errors. The errors just cause an ignorable icon to show above the object and are pretty benign. If thar be Lindens lurking here, could you give any insight into why permissions are revoked before change() and not after? Thx!

I'm playing with the new run_time_permissions() functionality, to see what I can do with it.

There Is No Way On This Earth I Am Running Around Fixing Everything That Gives Out Errors Because Of What I've Just Read!

My Account Is Just Gonna Be Spammed To Hell With People Thinking I Owe Them A Fix For Something Thats Not My Fault.

Yes Thats Capitals, Yes I'm Shouting, Stick A Linden In Front Of Me.

We hear your concerns and we're looking at how this is affecting ya'll. I'll be in touch soon

I have an extremely popular item that unsits and av then animates them - in fact its intrinsic to how it works - and quite legal to do under LSL.

Not a hack - not an exploit - I get permissions - unseat the av then run an animation. after x amount of time I stop the animation.

I go through all the correct checking for perms before stopping and starting said animations.

If I GET permissions - I should be able to hold those permissions until revoked.

I'm going to check it tonight after work.

If this is the case I stand by my original statement of 'rewarding lazy scripters while breaking content of those who play by the rules'

I'll make that simple - if it busts my diving board I'll forward all my customer requests to you.

Noooo! Pick Kona, he's got a tougher skin.

Anyway, I talked to the developer on the case, and we have an idea on how to fix it. I'll keep ya'll posted.

Could it not just be moved to after the attach() or changed() event, rather than before. That way you're still able to force the cleanup, but those that wish to retain the control over cleanup for whatever reason can do so.

Ok, here's the fix to the fix that fixes your fix:

We will only automatically take away permissions for the camera, since that is why this fix was being put in in the first place. We are trying to prevent "camera griefing" -- or taking the camera and not giving it back! In the process we hit every permission, and after some thought, fire bombs raids on the Lab and constructive criticisms from you all, we decided that was a bad idea.

Thanks for your concerns, and see you in Preview!

Thank you Brent.

As I understand it, we don't have a way to detect the end of the detaching callback (yet). So for now, the fix is crippled. In the future we may try to fix it the right way, but not for Wednesday's release.

Ah, that's kind of what I'd thought earlier to be honest as it's the only reason I could think of as to why it had been put in before the event fired.

No Kona is a friend of mine - I'll pick whoever it inconveniences the most.

Okies - thanks - that sounds very reasonable.

You can understand the concerns though - this is behavior that I explicitly asked about as far back as 1.2. Breaking content that follows the rules - while fixing content that doesn't (stopping animations in this case and revoking perms) I can't see as a 'good thing'.

Especially when you have probably a thousand instances of an item in world that follows the rules laid down.

Perhaps a better/easier way to revoke permissions? Make it easier to turn off all perms and stop all anims that a scripter can invoke?

Update: just had a friend test it in preview and email me.. and verily it is fuckered right up.

Seeing there is no fix for it - I'll see what wednesday brings.

For now I'll take down all my diving board vendors and forward all refund requests and customer support - as I said I would.

I like to keep abreast of changes and updates - I test things based on what the release notes say will change.. springing a last minute fundemental change in how premissions work (not perceived - not accepted - but actual verified by LL behavior) is uncool.

A very humble thankyou to LindenLabs and Brent Linden

Everyone stop panicking!

We're fixing the fix. A new update should be available today.

translation: Don't worry about it, it like it never existed.

*flashes you all with the red blinky thing from Men In Black*

What are you doing here? You were about to tell everyone how kewl Brent Linden is, and how you wouldn't ever possibly think of complaining to him about anything

LOL

Ok being at work and having to go on second hand info passed to me via gmail is incredibly frustrating.

If we are having a miscommunication of whats going on - then you have my sincere and humble appology - but as you can imagine the thought of facing a madcap runaround world on Tuesday followed by having my IM's and Email clogged for possibly weeks (apart from the having to take down one of my #1 items - that I can live with anyways) - does frazzle my already messy hair and puts a fire under my ass.

Again - if all is well and fixed you have my apologies for any heated statements I've made.

Some of my old scripts use a flag that tells the script they requested and got permissions, instead of calling llGetPermissions(). This was on the theory that integer == TRUE would be faster and take less memory than ((llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) != FALSE. That flag stays set until the script cleans up after itself on dettach. IE, some of my scripts which are technically correct but built with efficiency based on a logical assumption, will break because that logical assumption changed.

I would suggest that either the error messages generated be rerouted so as not to make the object appear broken to the end user, or the permissions release delay idea be implemented.

Phew! We've been UnLindened.

Ok - thats from the latest 'Preview Update' thread.

Can someone give me the a definitive 'this is how its gonna be' - because it kinda flys in the face of what Brent said - and if it IS then it means that the 'everything is gonna be fine' isn't the case.

And I really want a heads up on this as soon as I can.

Siggy...
I went in to the preview to check all my pose scripts as I was reading this thread. I also checked my copy of the delux diving board and had no issue with either.

Phew, I am glad they've fixed the fix. Like Ben Stravinsky, I was starting to get nervous.

Er, how do we log onto the preview grid? I've never done that.