Animations Fixes That Have Been Implemented (and fixes for those)

heyas;

okay, the lindens fixed us so that when we teleport, every animation tha was applied to us by stuff is taken off. therefore, if you teleport with your horse or other rideable critter attached... its screwed up. yay.

here's the fix:

changed(integer change)
{
if(change & CHANGED_TELEPORT)
[do your animation apply here]
}




now.... in relation to this, sorta.... why oh WHY does THIS work:

llStopAnimation(llGetInventoryName(INVENTORY_ANIMATION, HEIGHT));
llSleep(0.2);
llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, HEIGHT));

and this doesnt?

llStopAnimation(llGetInventoryName(INVENTORY_ANIMATION, HEIGHT));
llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, HEIGHT));


come to think of it... why the blazes doesnt THIS work any more???

llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, HEIGHT));


this is reapplying a pose that is supposedly already on the avatar, but has been overridden by another high priority pose.




and... i think i must blame myself. i am, after all, the one who said 'how many animations can get stacked on an avatar?' and devised a test to see that... well, it pretty much isn't any limit. and then i said 'if over 200 animations can be stacked on an avatar walking around... are our clients downloading all that animation information???'

well, if preventing animations from piling up on avatars helps reduce lag... that's good, but at least TELL me so i can fix my scripts! (and HOW!?!??!) grr!

Ums, it doesn't work that way?

/me waves to Blood!

afaik, there's been no change to the examples you gave.

If you try a llStartAnimation with one currently running, nothing changes since, well, nothing is changing! The animation simply continues to play...

Whenever I've had a stop and start immediately together of the exact same anim (IE, do nothing), nothing has happened. I've always assumed it was smart enough to see nothing was going to change?

We did a lot of testing of this, there's some animation forum threads about it from several months ago that I believe you had commented in at the time too!

Anyways, if you watch the viewer's Animation Info, you can see the difference with the llSleep added in, as the stop will remove the animation from the list of what's playing on your avatar, so then the start will bring up a new instance.

Your final example however should work, it just wouldn't be seen anywhere but the Anim Info list, since the higher priority anim would be shown instead? (But of course, if the pose is already running, wouldn't doing another start of a pose already on your av be moot?)

ah, but...

you see, i'm trying to REAPPLY a previously applied animation, due to another script applying another other animation over top (and overriding) my previously applied animation.


so...

A: play animation 1, priority 4
B: play animation 2, priority 4 (overriding animation 1)
C: try to start animation 1, but it is already playing so don't re-play it...

results in... playing animation 2, and no sign of animation 1.


that's my problem.


it USED to work. i USED TO be able to press my 'reapply' animation button, and it would... reapply the animation, now at the top of the stack. now, it apparently is not.

Playing with this a bit, I'm pretty sure something has changed fairly recently, in addition to a change that happened over a year ago. As I recall, it was once possible to restart an animation from the beginning by just pushing it back on the avatar without even stopping it first. I believe that this changed, and then for a while it was possible to restart it by just stopping it and starting it again. Now, that seems to be broken--not sure as-of when--and there needs to be a gap between stopping and starting in order to get it to restart. I have no idea how much faith to put in the magic number of 0.2 sec delay.

It's my impression that this all started breaking down a little over a year ago when they "refactored" the deactivateMotion code in the viewer... see jiras VWR1217 and SVC-318. And to see the current state of apparent developer confusion about how animations should work after teleportation, see VWR-6744.

Looks to me that some AOs and sync'd animations could have taken a hit (again). But it's all very confusing. For example, I *think* I'm seeing a high-priority single-frame looped animation getting reapplied on top of another high-priority built-in animation without having to be stopped first, which is counter to Blood's observation.

heyas;

qie, maybe its 'built in' animations vs applied animations? how did the built in one get applied? via script, or via the engine?


okay, i dug out my animation stack test. im not sure exactly what the results mean, as they're a little shaky.

i applied 211 animations to myself before i ran out. some got taken off, i DO think they are ones that are NOT looped.
i then started the test from the beginning again, and adding the first animations (RE-adding, i should say) did not raise the 211 number of animations on me.


okay, i see what's going on now. the animations the engine detects as already being played are not being re-added to the animation stack. therefore, the last highest priority animation is 'stuck' on the avatar.

qie, i'll look at the jira things and see what i can add.

...if i can find them. well i can find VWR1217 if i search for SVC-318 and vice versa. both appear to be closed/resolved. i cant find VWR-6744 at all :/ jira links, qie, jira LINKS! ;)



for those curious, this is the animation stack test. just throw it in a box and click it. its not very neat; it's just quick and dirty. also throw in a few hundred looping animations!

integer ON = FALSE;
integer nA = 0;
integer anims = 0;


default
{
    on_rez(integer orn)
    {
        ON = FALSE;        
        llRequestPermissions(llGetOwner(), PERMISSION_TRIGGER_ANIMATION);
         anims = llGetInventoryNumber(INVENTORY_ANIMATION);

    }

    touch_start(integer total_number)
    {
        if(ON)
        {
        llOwnerSay("Stopped.");
        ON = FALSE;
        llResetScript();
        }
        else
        {
            ON = TRUE;
            llSetTimerEvent(1.0);
        }
    }
    
    run_time_permissions(integer perm)
    {
        llOwnerSay("You have "+(string)(llGetListLength(llGetAnimationList(llGetOwner())))+" playing.");
        llOwnerSay("Click to start Animation Stack test.");
    }
        
    timer()
    {
        list lAnims = llGetAnimationList(llGetOwner());
        llOwnerSay((string)llGetListLength(lAnims)+" playing. Adding one.");
        nA++;
        
        if(nA >= anims)
        {
            llOwnerSay("Ran out of animations.  Click to stop & again to reset.");
            llSetTimerEvent(0.0);
            return;
        }
            
        llStartAnimation(llGetInventoryName(INVENTORY_ANIMATION, nA));
        llOwnerSay("Started "+(string)nA+" Animations."); 
    }    
}

i didnt find this exact situation reported on the jira soooo....

pimp my jira:

https://jira.secondlife.com/browse/VWR-9410

Right. The closed ones I cited are of historical interest about when this all started falling apart, as I recall. Maybe somebody remembers clearly what exactly changed at that point. The one about what happens after teleporting should be found at:
http://jira.secondlife.com/browse/VWR-6744 (I hope).

Voted for VWR-9410.

Looking in more detail at what I was doing, I now remember I played a nasty trick: I actually have two identical priority 4 looped animations (the same bvh, uploaded twice to get two different UUIDs [Edit: or maybe just copied in Inventory? I forget]), which I keep pushing on top of each other on a fairly tight timer, stopping the one underneath before pushing it back on top. I scripted that back in February and March of this year, so the inability of an animation to override itself has been around at least that long.

The earliest I worked with this was for a friend's wedding last Autumn...when the flowers she wanted to carry included a bad priority 4 pose...

I obviously could play a pose of just one arm to get them to match, but the flower's ao would override it, and replaying my arm pose did nothing as we already talked about. My anim's properties: Friday, November 23, 2007, 8:26:38 PM

So I guess that's why it doesn't feel like a new issue to me?

/me just voted for both, 6744 caused me big problems last night and this new one would be convenient and save L$

It could be that there is another animation with a higher priority currently playing and you need to stop that one first.

hmm...

well, i haven't noticed it til now, then. because when i created my 'reapply' button, it used to work. um... i forget when that was. :/ :igh::


dumb question #1: and they aint fixed it yet?? :X

I moved to that method back in August of 2007, so it's been in place at least that long too.