Maximum Stacking Animations Test

heyas;

was wondering before how many animations would stack onto an avatar if you never took them off. i would THINK eventually you'd get to the maximum number of animations in the 'stack,' and then old ones would fall off.

i did a test, but i still dont know. i put all the looping animations i have into an object, and had it stack them on one at a time, keeping count of the llGetAnimationsList length.

i kept running out of animations before i lost any off the stack :( (IF there IS a stack, i still don't even know.) i got up to 211 animations stacked onto the avatar. it MIGHT top out at 256, but i dont have enough unique animations to get that high.

see, here's another thing i noticed doing this test... when you throw in several copies of the same animation, theyre stored with different names in the inventory (ie chickendance, chickendance 1, chickendance 2, etc.). when you put the same-but-differently-named animations on the avatar, the animation count doesnt' go up. apparently (i presume by the key??), sl knows which animations are the same, and if you put one on that is already on.... i'm guessing it takes the previous application out of the animation list and puts it at the end.

but... i'm just guessing.

and dang, that's a lot of animations on one avatar!!!

Is there a practical purpose to this information or are you just goofing around? Nothing wrong with goofing around, just want to know.

Poses count as animations right? Try going to the freebie areas and get all the poses and dances and animations you can find. Awaiting your results...lol.

um.... im sure i had a reason for this somewhere along the line...

i think it came from the ao priority thread, where i was wondering if previous animations could poke through when later animations got removed. or some such thing. oh! i remember!

in my tiny ao, the first thing i do is apply a limb lock to keep the limbs folded. i was wondering if that ever "fell off" and let p3 default anims unfold the avatar. and if i should periodically re-apply the limb lock, or if this would cause a hellishly insane stack of animations built up on the avatar.

and also a question whether ao's have to un-apply previous animations before applying new ones on state changes. im thinking they should.


it doesnt matter how long the animations are, as long as they loop. play-through-once animations get taken off the list soon as they are done. or... at least, one would think :X

dangit, now i'll have to try another test. :P


i would also think it MIGHT be important in understanding lag. i mean... if an avatar tps to your club and has 211 animations stacked on it.... do all those have to load into your client??!?!? even if you can only see the top two or three? man, that has to hurt.


hmm.... but maybe this is more of a scripter thing than an animator thing?

probably, and 'ouch' considering it'd be loading to all av's within sight

Thankfully I doubt that will ever happen?

A script replaying the same animation (by UUID) doesn't add to the list (you can watch the list not change in the viewer yourself, as well as the order of what is shown top down) and single-play anims drop right off.

So someone would have to collect or upload that many looping anims, to get them all to have different keys.

When you TP into a show with 100 AVs, plus however many are across the sim edge, all their anims get sent to your client now, along with each of their AOs' five poses (if they aren't on poseballs) and all the dance ball anims they are using (but those are not duplicated you can tell) which isn't that bad (especially compared to prim-heavy hair and things).

So I doubt it would be very different the other way around, everyone around would just see your anim-stacked AV in a T-pose for much longer before the anims all got sent and cached probably?

Right, the entry in your inventory is just a name, a set of permissions, and a key (UUID). (Well, maybe some other stuff, but mostly that.)

If you duplicate an anim and rename it, it keeps the same key. The system identifies the anims by key.

Wade through the client source code? There's no guarantee that the server doesn't enforce a limit, but you'd see it if the client app does.

In any case, your testing shows that the limit is high enough for practical purposes.