Jump to content

On Detach - Animation purge prevention


Kyrah Abattoir
 Share

You are about to reply to a thread that has been inactive for 1748 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

This is an oldie but a goodie. I still can't understand how to prevent it reliably. We have all encountered it I'm sure.

  1. Your scripted attachment is playing some animation loop.
  2. You detach it.
  3. Your detach code executes just fine and stops the animation...
  4. All the animations currently affecting the avatar are stopped.

Attachment animation scripts are supposed to be simple right? pretty much scripting 101? Something like:

string anim = "someanimname";
integer has_perms;
default
{
    attach(key attached)
    {
        if(attached)
        {
            llRequestPermissions(id,PERMISSION_TRIGGER_ANIMATION);
        }
        else if(has_perms)
        {
            has_perms = FALSE;
            llStopAnimation(anim);
        }
    }
    run_time_permissions(integer perms)
    {
        if(perms & PERMISSION_TRIGGER_ANIMATION)
        {
            has_perms = TRUE;
            llStartAnimation(anim);
        }
    }
}

But no, it doesn't work (at least not with all animations). And when it does, it's not in 100% of the time.

The docs state that animations will be purged anytime you detach an object and do not stop animations attached to it, but it will still happen regardless, depending of the animation. Also I only care about standard permission behaviors, so I'm ignoring the weird Firestorm permission options.

So my questions to you fellow seasoned scripters are:

  • How do you prevent this?
  • How do you prevent this RELIABLY?
  • How do you prevent this regardless of the animation?

WARNING: If you think this is a simple noob problem, think again. I've either been completely stupid for my 15 years of LSL scripting, or there is a real issue with the SL animation system.

Edited by Kyrah Abattoir
Link to comment
Share on other sites

my understanding of the general problem is that when we play a animation on the same level as the system animation then our animation somehow replaces the system animation. When we stop our animation then the animation system doesn't always resolve itself. Our animation can continue and sometimes our avatar gets stuck in some static pose

what I have found with animation in the attach event is to start a system animation before stopping our animation. Example mod:

string anim;
integer has_perms;
default
{
    attach(key attached)
    {
        if(attached)
        {
            llRequestPermissions(attached,PERMISSION_TRIGGER_ANIMATION);
        }
        else if(has_perms)
        {
            has_perms = FALSE;
            llStartAnimation("stand");
            llStopAnimation(anim);
        }
    }
    run_time_permissions(integer perms)
    {
        if(perms & PERMISSION_TRIGGER_ANIMATION)
        {
            anim = llGetInventoryName(INVENTORY_ANIMATION, 0);
            has_perms = (anim != "");
            if (has_perms)
                llStartAnimation(anim);
        }
    }
}

 

edit add:  I just added the llGetInventory line in there so i could more easy test different anims by drag drop

 

Edited by Mollymews
added somehow as i am not totally sure about this
Link to comment
Share on other sites

More info needed, I think -- in particular, are the animations  looping, how long are they,  and what priority are they?   While I'm not sure the priority is a big issue here, when I have this issue it's normally to do with a looping, or at least a lengthy, anim.

As I understand it, the problem is that llStopAnimation stops the animation but it doesn't (rather counter-intuitively) cause anything else to happen, so if the animation loops your GPU will keep on looping it until given further instructions -- either you move, and your AO or the default animations kick in, or you explicitly tell it to start a new animation.

A non-looping animation should, at least in my experience, either continue until its end after you remove the attachment (so possibly up to 20 or 30 seconds, which is a long time in this context) and then leave you in the final frame until something else happens to start a new animation, or you move, which should over-write the old animation immediately

So I when I run into this,  my first response is very like Mollymews' above.   Until you move, neither your AO nor the viewer realise your animation state has changed. They think they you're just standing, and for the simulator and your GPU and CPU know, the animations they've been told to start and stop control your facial expression or something.   They don't know it's been making you dance or jump around.   

I think, in fact, the llStartAnimation("stand"); call is all you need because the second call, llStopAnimation() probably won't have time to fire before the attachment returns to your inventory.  That doesn't matter, because the documentation is correct is saying the object is going to lose permissions to be unable to do anything once its inside your inventory (though it will retain animation permissions unless you cancel them by resetting the script or overwriting them with a new set of perms).   The important thing is to tell the simulator what you want to happen after the attachment is gone, which has to be a positive instruction, so not "stop playing this" but "start playing something else".

That would be my initial approach.    Best of luck!

I agree it's not at all intuitive -- it took me years to find the solution and only then because Dari Cauldwell, one of my many kind mentors in LSL, explained the nature of the problem to me, and told me it took her ages to work it out, too.

(ETA:  For newer scripters -- take it from me, if it's a scripting issue that both Kyrah and Dari think is tricky then you can be assured it really is a stinker of a problem!).

Edited by Innula Zenovka
  • Like 3
Link to comment
Share on other sites

Welcome to the weirdest ever bug from hell.
llStopAnimation will stop all animations on detach instead of only the specified animation if the attached objects instance key is lower then your avatar key. Yes really  lol.

Thus, you cannot prevent it from happening.

Bug report: BUG-225288 - llStopAnimation is stopping all animations on detach instead of only the one specified.

  • Like 1
  • Thanks 4
  • Haha 2
Link to comment
Share on other sites

46 minutes ago, Whirly Fizzle said:

Welcome to the weirdest ever bug from hell.
llStopAnimation will stop all animations on detach instead of only the specified animation if the attached objects instance key is lower then your avatar key. Yes really  lol.

Thus, you cannot prevent it from happening.

Bug report: BUG-225288 - llStopAnimation is stopping all animations on detach instead of only the one specified.

You've got to be *****ing kidding... REALLY?

My theory was that it was related to ease-out on some animations preventing that animation from finishing in time, causing the system to freak out, killing all reunning animations.

Why is there even a "kill all running anims" behavior to begin with anyway?

Link to comment
Share on other sites

I could maybe understand if it was the animation's key that caused this... like if there was an old assumption that animation uuids would be within a defined range and anything outside that is considered a problem and thus triggers recovery code to purge all animations (just to be safe).

But to have the trigger be the host object's key being lower than the avatar's key.. I can't imagine what tangled relation those two must have in the code.

  • Like 1
Link to comment
Share on other sites

I'm mainly trying to avoid messing with other people's items if possible. I already use some animation checking code (which i really need to rewrite) but a real solution would be so much better.

Edited by Kyrah Abattoir
Link to comment
Share on other sites

9 hours ago, Whirly Fizzle said:

llStopAnimation will stop all animations on detach instead of only the specified animation if the attached objects instance key is lower then your avatar key. Yes really  lol.

i would never have worked that one out in a million years

Link to comment
Share on other sites

1 hour ago, mikka Luik said:

From that '20/Aug/18 1.03 PM We're going to confer with the relevant stakeholders to determine how to go forward with this report, thanks!' - and then what happened?

 

That "confer with relevant stakeholders" line was brought up after that mass logoff issue a few weeks back before they continued working on the issue.

To me it sounds like passing the ball of responsibility to someone else.

This bug has been brought up in the Server UG a few times and no one has committed to fixing it.

The "higher" your key, the better chance of you running into this bug.

My partner has it happen all the time since their key starts with "f".

This bug is one of the reasons I've had to add timed starting of animations in everything I wear. The other reason is for starting animations after random use of "Reset Skeleton & Animations" in Firestorm.

Link to comment
Share on other sites

1 hour ago, Lucia Nightfire said:

My partner has it happen all the time since their key starts with "f".

pressf.jpg

In all seriousness, this isn't the first time I've heard of this bug. Probably brought up by Whirly in some older thread. I can't even begin to speculate what kind of programmer design decision would lead into this, but for those who are wondering how a key/UUID could be "higher" or "lower" than another, it's because UUIDs in Second Life are just a kind of number.

For example;
00000000-0000-0000-0000-000000000000 would be "0"
00000000-0000-0000-0000-000000000001 would be "1"
00000000-0000-0000-0000-F00000000000 would be "263882790666240"
And so on.. these numbers get very big and aren't/can't really be practically represented (to humans) with just 0-9.

Edited by Wulfie Reanimator
  • Like 2
Link to comment
Share on other sites

On 6/14/2019 at 2:56 PM, Whirly Fizzle said:

Welcome to the weirdest ever bug from hell.
llStopAnimation will stop all animations on detach instead of only the specified animation if the attached objects instance key is lower then your avatar key. Yes really  lol.

Thus, you cannot prevent it from happening.

Bug report: BUG-225288 - llStopAnimation is stopping all animations on detach instead of only the one specified.

My flabber is completely and utterly ghasted 😲

  • Like 1
  • Haha 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1748 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...