Scripting & Permissions

I have used several pose stands and never had the following error message:

PERMISSION_TRIGGER_ANIMATION permission not set

I'm not sure if this is a bug or just poor scripting. I think something in the preview though got stricter on permissions handling cause I'm not getting these errors in the general release. Anyhoos, just a warning to let peeps know about this and check their scripts in the preview grid. Check your AO's, vehicles, weapons and all.

I made this script for the pose stand that seems to work a-ok if anyone is interested:

default
{
    state_entry()
    {
        llSetSitText("Pose");
        llSitTarget(<0.00,0.00,1.00>, ZERO_ROTATION);
    }
    
    changed(integer change)
    {
        if (change & CHANGED_LINK)
        {
            key agent = llAvatarOnSitTarget();
            
            if (agent != NULL_KEY)
                llRequestPermissions(agent, PERMISSION_TRIGGER_ANIMATION);
        }
    }
    
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_TRIGGER_ANIMATION)
        {
            llStopAnimation("sit");
            llStartAnimation("turn_180");
        }
    }
}

Actually, in current Preview 1.9.0 (, I am finding that the animation is not stopped when you stand up.

I am testing with a "priority 4", "looped at 100%" sit pose.

[Edit]
I have since done some testing and found out why. If the animation script is NOT in the root prim it doesn't stop the animation automatically when you stand up.

Please fix.

If you don't make it so llStopAnimation doesn't generate an error message you're going to get millions of scripted objects that will NEVER be fixed.

Can you make some similar fix for explicitly granted permissions, so if I click on a ball in a club or on a beach to start dancing, and it's bugged, I don't have to sit on my "stop animations" box to stop dancing?

Maybe give us a window with all the permissions we've granted <i>anything</i> and we can select and revoke individual ones?

Can I ask *why* you felt the need to basicly break every piece of furniture or vehicle that uses animations? They worked just fine already, and other than allowing you to snip out a line of code, I don't see that this new system actually acomplishes anything.

If your going to break everything, I'd like a reason beyond "because we did"... I expect this to have fixed some earth-shattering permission issue or something. Right?

As it is, this is one of the most disripuptive changes I've seen in SL... So much relies on the old system that its not even funny, and in a lot of cases the stuff just *isn't* going to get updated, either because the creator no longer plays enough to care, or because they don't care to distribute a thousand updates when the problem isn't their fault.

If the messages show for llStopAnimation you're going to have to either back this whole change out like the one that nerfed llGiveInventory, or change it so that the messages don't show, because there's just too many objects in-world that call llStopAnimation after unsit.

I recall some Linden posting a concern about people's reactions to breaking joints. This is a much bigger problem than that.

I suspect it was to fix "I'm still sitting after I got off my vehicle" and other problems caused by buggy scripts... or working scripts hitting bugs in SL. I think they need to put a bit more thought into the solution.

If there's a relevant animation still playing after you hit the stand button, leave the button there. THEN withdraw permissions and drop the animations after you hit it a second time.

That will mean that working scripts won't be effected, and there will be an obvious way out of buggy scripts or scripts broken by SL bugs. I'd also like to have the ability to kill animation and other permissions explicitly when they're granted after (for example) touching a dance card.

You are of course shitting me?

This is a joke right?

The better part of my early scripting days were spent pouring over the documents to master the arcane correct way to handle permissions and include checks to make sure that scripts ran well without leaving spam..
(btw can I mention here that perms spam = ERROR MESSAGES - i.e. something is done in ERROR... i.e. INCORRECTLY)

So for my dilligence is said department - and trying to use LSL in the correct manner (that is scripts that run without ERROR messages), my good and just reward is that there is a chance that my stuff may well spam folks, whereas the piss poor stuff more than likely will not?

Please clarify.

Right on..

It's known as dumbing down, Siggy. You should be used to it by now in first or second life!
It's to offset the fact that each new generation get more fucking stupid.

Can't have poor lil users stuck in a sit position after they get off a badly coded vehicle, now can we? God forbid that anyone in that situation should have to put on a free animator and do a /stop all command and maybe IMing the creator a suggestion to improve their script!

Much better to fuck up every scripted thing in existence that uses animations without consultation!

Honestly, I'm actually surprised that LL don't have an error condition for putting default cubes on your head to save poor widdle noobies some embarassment.

You've Been Lindened!

Sounds like a great time to feed ALL scripting error msgs back to the script in an on_error function or something ANYTHING that lets the script recieve and process the error where it belongs instead of Say/Shout the error in main where it doesn't do anyone any good.(*blank look* who thought that was a good idea?)

I've been Lindwned

Okay.. this is going to be farking annoying then. Bad enough that my attempts to learn LSL results in error scripts, but when I learn to do it correctly, I'm STILL GOING TO HAVE ERROR MESSAGES? What the heck? Brilliant folks, just brilliant.

I guess the only good that will come from this is that it will be easier to spot properly written scripts, since they will be the only ones giving errors. Downside is that the poorly scripted ones will now be able to charge as much as the good ones. Great going. Why bother asking us about the joints? This was far more important!

Rule #1, out of Vektor's mouth, of QA:

"Don't break existing content."

I think I do understand WHY the behaviour is being changed (although I still agree with the consensus that it is bad to break existing content and offer an alternative below):

Permissions that are implicitly given on sit (controls, animation and camera) will currently stay UNTIL the script requests permissions again. It can be nefariously used... I won't describe how in detail as we get enough griefing already. Think about it next time you sit on something and wonder what the owner of that object could do to you until you relog

Anyway, I offer an alternate suggestion... instead of IMMEDIATELY removing permissions on stand/detach have the permissions time out... say give it a minute and THEN remove the permission from the script. That will keep all legitimate use of implicit permissions currently working and will prevent abuse of the implicit permission system. Any script that needs more than a minute (or any other sufficient amount of time... one minute was just a random integer thrown out) to make a call to llStopAnimation after the avatar stands is broken all on its own

That's a valid point. How many scripting errors are actually useful to end users? Although, I understand the need for end users to know that something has gone wrong. Sending error text to open chat seems like a bad idea. How about echoing error text in a floating bubble above the object, like the chat bubbles we have now? That would localize the error: we could see immediately which object was throwing errors. Maybe the bubble could show a general error and offer a "click for details" option.

In addition to the error bubble idea, I really like the idea of being able to handle errors internally. Most programming languages return numerical error codes for functions internally. We should have the ability to read error states internally.

Oh, and breaking existing, properly written scripts so they throw errors = WRONG.

EDIT: I tested this today in 1.9. It appears that the "floating error icon" idea with "click for details" has already been implemented. Bravo, LL. My only tiny gripe with the implementation is that the "script message" icon is weak. I think it's supposed to be an exclamation mark on a piece of paper. Clean up the icon (lose the paper. it's redundant. the exclamation is enough) and we have a winner! Does the system throw a big red X for fatal errors? Im gonna find out!

As for the "properly written scripts should not throw errors" debate, I may have switched sides. All my "properly written" scripts include a permission check before stopping animation. Those scripts dont error. The scripts where I neglected to check permissions before stopping animation DO error. So, which ones are "properly written?" You guessed it: the scripts that make the check are proper. The others were taking advantage of poor error checking. /dons flameproof suit/

hmm for those who recive error messages now in 1.9 and did not before ...
i think you mistake something if youre thinking you properly scripted, you "allways" should check your permissions bfore you try to do anything that needs permissions, none of my scripts were broken as mine do that, do you check youre permissions as you should ? so dont talk bout broken scripts by LL, sure they changed behavior but you forgot that rule ! you took a flaw as granted.

Yikes! I can't believe they're going to do this! Sheesh...

The behaviour of permissions has now changed. It used to be that they were persistent except under certain circumstances - those have changed, and rather irrationally.

If global variables suddenly stopped being persistent, would it be a scripting error not to have checked that they hadn't all been reset whenever referring to them?

Are you sure? I checked my scripts against 1.9 this morning. All my "properly written" scripts include a permission check before stopping animation. Those scripts dont error. The scripts where I neglected to check permissions before stopping animation DO throw errors. So, which ones are "properly written?" You guessed it: the scripts that make the check are proper. The others were taking advantage of a poorly designed system. /dons flameproof suit/

Why should granted permissions persists after an avatar has detached or unsat from an object? How was that behavior rational?

I understand that much existing content may break and never be fixed. That does suck. But, to me, the new behavior is more correct and rational.

To help offset all this existing content throwing errors, a new script error reporting system has been implemented. Errors now show up in an icon above the object. This is a MUCH better system and I'm glad to see it done this way. This is a better system, even if existing content wasnt broken. Kudos to LL.

No, that bit's not what I'm saying is irrational, that's quite sensible - what I'm saying is irrational is the fact that the permissions are lost BEFORE the event of detaching or unsitting. If the permissions were fine until the end of the attach() or changed() event, it wouldn't break anything - the animation stopper would still have permissions, as it should really, it could stop the animation itself quite legally.

Now, one could debate the semantics and assumptions here for a while I suppose, "what does it mean to detach or unsit?" etc - but when making an implementation decision I would have thought that the rational course of action would be to take the course that meant that the fewest existing scripts were broken, and which still achieved the desired objective (to remove animations that had not been removed by scripts). Which is to have the permissions and animation cancelled after the event not before it. Everyone would be happy then.


edit: The script error thing I actually prefer the old way, because you can instantly tell what the error is without having to click on anything, but I'm not bothered either way there to be honest.

Ah. I see what you mean, Ordinal. When the changed() event fires for an unsitting avatar, should granted permissions remain valid within the changed() event, or should the permissions have already been revoked at entry to the event?

That's a darned good point and I didn't realize that's how the new functionality had been implemented. I understand (and endorse) LL's intent to clean up permissions automatically upon detach. But, I now realize that the point they chose to perform the cleanup may be troublesome. It's true that checking for permissions will cover the situation, but I see your point. Thanks for opening my eyes on that.

A question I have is where else in the script's execution life-cycle could the cleanup be made? Perhaps the entry to the changed() event is the only place where they could shoehorn the cleanup. Or perhaps moving the cleanup to the exit of the changed() event would allow the cleanup without breaking existing content.


Another question (and one I'll test and report back on) is when the permissions are revoked, does run_time_permissions() fire as an event?

Or does run_time_permissions() only fire in response to a llGetPermissions() and llRequestPermissions() calls?

Maybe I've had too much coffee this morning.

If I'm understanding these changes correctly, I think LL may have just worded the changes a little vaguely.

So a script that checks if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) before every call to either llStopAnimation or llStartAnimation will still function properly, correct?

A truly well written script would make these checks - there's no telling when an avatar will log out, move into another simulator, get pushed 1000m away by a griefer... all of these revoke permissions, but don't trigger a run_time_permissions(integer perms) event for the permissions change.


IMO, run_time_permissions should be invoked EVERY time a permission changes, even in the scenerios I mentioned above.
==Chris