That Pesky Script Error Trying to Stop Animations - PERMISSION_TRIGGER_ANIMATION permission not set

[Prokofy Neva]

So I've known about this annoyance of Script trying to stop animations but PERMISSION_TRIGGER_ANIMATION permission not set for more than a decade, it's been on the forums frequently, i.e. as in this old thread from 2009 I can't find right now or this old thread and I get it -- it's a bug, or it isn't a bug, but it's about bad scripting, or whatever, it's a thing.

I don't don't need to know why it happens as this has been described endlessly.

What I'd like to know are two things:

1. Why does this script I am using do this? It has a line "stop anim". So what's up? Why isn't that happening?

 

default
{
    touch_start(integer detected)
    {
        llRequestPermissions(llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION);
    }
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_TRIGGER_ANIMATION)
        {
            llStartAnimation("warm hands by fire");
            llOwnerSay("Радиационная процедура идет");
            llSetTimerEvent(15.0);
        }
    }
    timer()
    {
        llSetTimerEvent(60.0);
        llStopAnimation("warm hands by fire");
    }
}
 

2. What would be a script that DOES NOT do this or the added line that would stop it doing this? And please, let's have none of this "go to jobs forum" etc. That forum never works, and those who do respond there aren't qualified. Yes, I'm able to hire scripters, I have some I've hired regularly and it's not a problem to hire them. But this is for the SL Public Land Preserve, open to the public, so I think, why aren't free scripts available that do this right?

I've found that it's really hard to get this working in general. I don't want a script that only animates me. That's not a challenge. What I want is one that has the ability to animate others when they come to a site I've developed. 

BTW the various scripts that promise to "Stop All Animations" work if you add them to yourself, and sometimes if you click on them -- but not always! So that's really vital to find, too.

The funny thing is, just testing on alts, I'm seeing they ARE NOT getting this annoying message. So I suppose I could just block the object and forget about it, but I'm tired of it. I want this to work and it should, given that it's a fairly trivial proposition -- animate an animation that is in inventory, either by just taking whatever is in inventory not by name, or by name and then STOPPING if you've put a time limit on it. 

I have a bunch of these animation scripts, some free, some paid for, and even paid a lot for. And it's funny how some of them do odd things like move the avatar up in the air after seemingly first putting him in the right position. And some have this error, and some don't.

Edited April 29, 2018 by Prokofy Neva

[animats]

  

    timer()
    {
        llSetTimerEvent(0.0); // not 60.0; that will make it run every 60 seconds. 0 turns it off
        if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) // something else might have turned it off
        {   llStopAnimation("warm hands by fire"); }
    }

That should do it. Your object may have had the permission to animate earlier, but may not still have it.

[Prokofy Neva]

No, that doesn't work at all and makes the whole script not work, as you'd know if you had actually tested it.

[Rachel1206]

I would ensure correct handling of animations by doing as below:

    timer()
    {
        llSetTimerEvent(0.0);
        
        //      Sanity check - did our avatar somehow disappear without saying goodbye?
        if (llGetAgentSize( llGetPermissionsKey()) != ZERO_VECTOR )
        {
            //  Never assume permissions are valid!
            if (llGetPermissions() & PERMISSION_TRIGGER_ANIMATION)
            {
                llStopAnimation(  MY_ANIMATION );
                
                //  Force looped frame animations to stop
                llStartAnimation("stand");
                llStopAnimation("stand");             
            }
        }
    }

Further use of the event attach( key id ) and check for valid key,  also ensure correct handling. And yes, lot of stuff and checks for something really simple.

Edited April 29, 2018 by Rachel1206

[Qie Niangao]

I don't know about this thing with starting and stopping the "stand" animation to "force looped frame animations to stop." I'm not aware that this is a problem, even. Is there any traceback to where this originated?

[Rachel1206]

12 minutes ago, Qie Niangao said:

I don't know about this thing with starting and stopping the "stand" animation to "force looped frame animations to stop." I'm not aware that this is a problem, even. Is there any traceback to where this originated?

Maybe I misunderstood the Wiki on llStopAnimation

[Qie Niangao]

Thanks, that's interesting. Void added that in 2011. I wonder when that condition obtains in the wild, trying to stop the only playing animation without another anim almost instantly being played automatically. She must have been trying to solve some problem, but I can't say I've ever noticed it myself.

[Innula Zenovka]

2 hours ago, Qie Niangao said:

I wonder when that condition obtains in the wild

I've certainly come across it.  It happens, as I recall, when you have a long looped animation that stops on a timer rather than when you move.     The reason, as it was explained to me, for this is that when you call llStopAnimation on a looping anim, it stops it from looping.    That is, it sends an instruction to your CPU/GPU to turn the loop off.  It doesn't, though, send an instruction to play any other animation to replace the previous looped anim.   That happens only when you move, thus causing the simulator to trigger the default animation for your animation state (which is promptly overridden by any AO you're using).  

You don't see this when you've been animated by something you were sitting on, because when you get up, stopping the animation, the simulator and your AO detect a change in your animation state.   But in something like this, where you're standing by the fire warming your hands, it could be an issue.

It's years since I came across it, so I may have some of the details wrong (or it may have been changed) but that's the way it was explained to me by (as I recall) Dari Caldwell, who knows a great deal about that sort of stuff.    

ETA:  If I have misremembered and messed up the explanation, that's my fault, of course, not Dari's

Edited April 29, 2018 by Innula Zenovka

[Xiija]

I may be way off here but....

It seems the situation is this,

Bob, Ted, and Ann come up to the campfire.

Bob clicks the fire and gets perms and is animated.

Next Ted clicks it, and the perms are evoked for Bob, and given to Ted, who now gets animated.

Lastly Ann clicks the fire and now has the script perms and gets animated.

When the script tries to stop Bob's animation, he no longer has the script permissions?

Mebbe keeping a list of the avi's currently using the fire & re-requesting perms before stopping the anim would work?

Also, i have a blank anim i use sometimes for stopping looping anims.. i think it is from MP?

"b43c9176-112c-944f-33fa-da2d275a9acf" ... you play it for a moment and then stop it - no more loop

Anyhoo, was just a guess,  Did i get close...?

 

Edited April 29, 2018 by Xiija

[Innula Zenovka]

1 hour ago, Xiija said:

When the script tries to stop Bob's animation, he no longer has the script permissions?

I don't think that can be it, since the script only knows about the last person to touch it.  

12 hours ago, Prokofy Neva said:

The funny thing is, just testing on alts, I'm seeing they ARE NOT getting this annoying message.

The reason Prok sees the message and not Prok's alts is that script error messages like that are visible only to the object's owner.

I'm not completely sure what's causing the message -- I'd have thought it would be the 60 second timer in the timer event, but Prok says no.   But I agree with Rachel that checking  the script actually has PERMISSION_TRIGGER_ANIMATION, and also that the avatar it's animating is still on the region, before trying to stop the animation should solve the problem.  

Edited April 29, 2018 by Innula Zenovka

[animats]

Just for fun, I created an object to do this.

Relax. Breath deeply.

Rachel's code checks for the avatar still being around. On vehicles, we check even more things before triggering an animation. There are moments during region crossings when avatar and vehicle are not linked normally. That's why you sometimes see "Can't find agent" script errors.  You have to defer animation changes until the region crossing is complete. But for a stationary object, you don't have to handle as many special cases.

[animats]

2 hours ago, Xiija said:

I may be way off here but....

It seems the situation is this,

Bob, Ted, and Ann come up to the campfire.

Bob clicks the fire and gets perms and is animated.

That's a good question. Dance machines in clubs handle that case. Both dancers touch the same ball, but they get different animations. The trick seems to be to have a separate script for each dancer. They all get the touch event, I think, but for each avatar, only one script requests animation permissions. That one has control of that avatar. The scripts have to coordinate on who requests permissions to make this work.

[Klytyna]

Usually when I see this error it's because the person being animated ISN'T THERE ANYMORE.

Somebody sits on a bar stool (no errors)

They stand up and walk away (no errors)

But...

If they just TP off the sim without standing (error cannot revoke anim perms because, revoke on who?)

If they just logout without standing (error cannot revoke anim perms because, recoke on who?)

...

Even the best code can have problems with the unexpected things users do.
 

[Innula Zenovka]

6 hours ago, Klytyna said:

If they just TP off the sim without standing (error cannot revoke anim perms because, revoke on who?)

If they just logout without standing (error cannot revoke anim perms because, recoke on who?)

That's not the way animation perms work, though.   The script retains the animation permissions unless it's reset, or it's granted a new set of permissions by someone else or by the existing permissions key.   Other than by having the script reset itself, that's the only way I know of to have the script revoke animation perms.    

 

Edited April 30, 2018 by Innula Zenovka

[Klytyna]

22 minutes ago, Innula Zenovka said:

That's not the way animation perms work, though.   The script retains the animation permissions unless it's reset, or it's granted a new set of permissions by someone else or by the existing permissions key.   Other than by having the script reset itself, that's the only way I know of to have the script revoke animation perms.

 

The error occurs when the script TRIES to stop anims on a person it has permissions for who isn't there, because of the way its coded, 

I've had this message Prok's talking about from a simple "sit positioner with optional anim" full perm script, when the sitter logged without standing, since I didn't write it and it doesn't happen that often, I didn't bother looking through the code to see why it does it.

If you tried to stop the anim in a script, and for example, instead of STORING the av key of the sitter in a variable and using that variable to stop anims when the item is no longer sat on, you just used a script command to get the key of the sitter every time you needed it, then when they tp out or log off, using that command returns a NULL key because they are NOT THERE ANY MORE.

 I was just clarifying WHEN the error happens, not how the scripts are written.

Just a further point... note that the error is a permissions error but specifically it's a STOP anim error. attempting to STOP anims on avatar 0000-0000-0000-000000 will throw a permissions error because that non person never gave anim permissions in the first place.

I don't write furniture scripts, you do, so how do you stop anims when the sitter isn't there? do you check to see if the sitter is present before issuing a stop anim command? I'm guessing some scripts don't check

 

Edited April 30, 2018 by Klytyna

[Innula Zenovka]

@Klytyna  Thanks for the clarification.   I agree that you'll get the script error if you try to stop the animation and the avatar who is the script's permissions key isn't on the region, but I was thrown by your use of the phrase revoke anim perms, which doesn't mean the same as "stop the animation," or not when I use the term.

You ask how I the animation when someone stands up.   Most of the time I don't bother, because the wearer's AO will do it for me when it detects a change in the wearer's animation state.  If I'm using a looping anim, then I'll check that llGetAgentSize(llGetPermissionsKey()) != ZERO_VECTOR) and, if it isn't ZERO_VECTOR, I'll call llStopAnimation() but that's not usually necessary.

[Prokofy Neva]

12 hours ago, Innula Zenovka said:

I don't think that can be it, since the script only knows about the last person to touch it.  

The reason Prok sees the message and not Prok's alts is that script error messages like that are visible only to the object's owner.

I'm not completely sure what's causing the message -- I'd have thought it would be the 60 second timer in the timer event, but Prok says no.   But I agree with Rachel that checking  the script actually has PERMISSION_TRIGGER_ANIMATION, and also that the avatar it's animating is still on the region, before trying to stop the animation should solve the problem.  

No, I didn't say the 60 second timer wasn't it; I said that the script as animat wrote it, which addressed more than the timing issue, *didn't work*.

So I tried taking out the 60 seconds at the second appearance, and it seems to work now. But I have to keep testing it because in my experience, if you leave the sim and come back, the annoyance can start up again.

[Qie Niangao]

Merely removing the 60 second timer will greatly reduce the likelihood of an error happening, although there still might be a problem it the toucher teleports out of the sim within 15 seconds of touching it. (In that case, it won't succeed in stopping the animation, but I'm not completely sure it will fuss about not finding the avatar on which it's trying to stop animations. Maybe.)

Anyway, it's just good practice to "protect" any call to llStopAnimations with the tests @Rachel1206 included.

[ I realize the following discussion belongs elsewhere, but maybe it's just some gaping hole in my scripting knowledge that everybody else already knows all about.] Further to the tangent about failing to stop a looped anim when there are no other anims replacing it, I found what may be the original jira for this with a similar workaround suggested by @arton Rotaru. The thing is, I'm still seeing the looped animation continue to play after llStopAnimation despite then starting and stopping the "stand" (or "stand_1") animation. Only starting "stand" does work, unsurprisingly, causing the stand anim to play even if seated. Anyway, I see how this condition arises if the script stopped the state-appropriate built-in animation, as danceballs stop "stand" and need to replace it when ending the dances, but I'm not sure I see utility in adding this to animation scripts in general -- especially if it doesn't work(?).

[Innula Zenovka]

On 4/30/2018 at 2:58 PM, Qie Niangao said:

Anyway, I see how this condition arises if the script stopped the state-appropriate built-in animation, as danceballs stop "stand" and need to replace it when ending the dances, but I'm not sure I see utility in adding this to animation scripts in general -- especially if it doesn't work(?).

You need it, I think, only when you stop the looping animation but the avatar's animation state remains the same.   So it's not normally (ever?) necessary when someone stands up from whatever they're sitting on.   However,  if you don't change your animation state, the simulator doesn't send the default animation for your state to your computer, so your computer doesn't know what to do, and just carries on doing what it has been doing.    Similarly, your AO thinks you're still sitting or standing, and has no way of knowing it should restart its own default for that animation state.

I can see it being a problem if you use experience permissions to animate someone who is standing.   I suspect that when you stop the looping animation and don''t send a new animation, I suspect the looped anim (a high priority one, anyway) will carry on until the avatar's typist touches a movement key.    

Edited May 1, 2018 by Innula Zenovka

[Wulfie Reanimator]

11 hours ago, Innula Zenovka said:

You need it, I think, only when you stop the looping animation but the avatar's animation state remains the same.   So it's not normally (ever?) necessary when someone stands up from whatever they're sitting on.   However,  if you don't change your animation state, the simulator doesn't send the default animation for your state to your computer, so your computer doesn't know what to do, and just carries on doing what it has been doing.    Similarly, your AO thinks you're still sitting or standing, and has no way of knowing it should restart its own default for that animation state.

I can see it being a problem if you use experience permissions to animate someone who is standing.   I suspect that when you stop the looping animation and don''t send a new animation, I suspect the looped anim (a high priority one, anyway) will carry on until the avatar's typist touches a movement key.    

I've not tested anything so I could be totally wrong, BUT, based on the animation explorer, the internal SL animation for any given state is always playing. This is why we have a priority system. Animations are applied in layers.

Higher priority (the looping anim) will override the internal animation and once it is stopped, I would make the logical assumption that the animation should get removed from the active animation list and stop overriding the internal animation as a result, which should then simply continue playing even without state changes. 

Edited May 2, 2018 by Wulfie Reanimator

[Qie Niangao]

1 hour ago, Wulfie Reanimator said:

the internal SL animation for any given state is always playing

I think that's correct -- unless that animation is stopped by a script. Then it seems not to resume until something causes the state to change. This is something lots of furniture does, with llStopAnimation("sit"), and (some?) danceballs do the same thing to "stand". As Innula points out, it doesn't matter with furniture because when you Stand to stop the furniture anim, that state change is enough to make a built-in "stand" play (until overridden by an AO or whatever).

The reason I was obsessing about this is that I was thinking about props that attach to avatars and cause them to sip a drink or eat a donut or whatever. I haven't been worrying about restarting a built-in anim when such props detach, but because they didn't stop the built-in anim, I don't think they'll cause a problem by not restarting one.

[Innula Zenovka]

2 hours ago, Wulfie Reanimator said:

Higher priority (the looping anim) will override the internal animation and once it is stopped, I would make the logical assumption that the animation should get removed from the active animation list and stop overriding the internal animation as a result, which should then simply continue playing even without state changes.

As it was explained to me (and as I recall it after several years) the problem is with the messages sent by the simulator to your viewer (i.e. your PC).   The simulator knows to stop looping the anim, and tells your computer to stop doing that, but apparently doesn't automatically tell your computer what else it should do (e.g. play the lower priority SL internal animation again).

[Wulfie Reanimator]

1 hour ago, Innula Zenovka said:

As it was explained to me (and as I recall it after several years) the problem is with the messages sent by the simulator to your viewer (i.e. your PC).   The simulator knows to stop looping the anim, and tells your computer to stop doing that, but apparently doesn't automatically tell your computer what else it should do (e.g. play the lower priority SL internal animation again).

It's not necessary for the sim to tell what to do after an animation stops. Animations are played client-side and the viewer has the data of all animations playing on all avatars. The sim should only need to send information about status changes and let the client do the "heavy lifting" locally. 

[ellestones]

another thing we can do to help with animation issues is check for agent who might be currently animated and stop their animation before requesting permissions from the next agent. Example:

string anim_playing = "something";

touch_start(integer num)
{
   
   if ((llGetPermissions() & PERMISSION_TRIGGER_ANIMATION) && (llGetAgentSize(llGetPermissionsKey()) != ZERO_VECTOR))
   {
       llStopAnimation(anim_playing);
   }
   llRequestPermissions(llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION);
}

 

Edited May 26, 2018 by ellestones
typo