Actually you are on to something there but maybe extend to allow override of any of the parameters in an animation (fps, transition, loop etc). If I were coding this enhancement I'd use a list to provide parameters - see my earlier comment (one being a timer - play for Float secs which will loop or terminate the animation early with maybe a suspend script option, and another being switch to next animation (like you can do with llSetLinkPrimativeParams)).

Jasdac Stockholm This is a massively overlooked and important thing, and I'm gonna blame the bhv uploader. When uploading an animation, it prompts to set "the priority" and just bamfs that number onto all animated joints. And here we are today with the general impression that animations have "a priority" when they can priorities per joint. I assume this request intends to set all joints called for in the anim, not sure.

Plausibly need to be able to do something like the llSLPP functions, to get/set priority per joint or "LINK_SET" to write a priority value to all joints in the anim or somesuch.

(Also overlooked, stacking animations; eg, running a priority 3 torso/head animated, then simultaneously run a p5 with wrists/fingers animated)

Mars Tamale that would be... beyond awesome. Really. After twenty years of user-generated animations (available since June 2004!), the ability to would be a delightful treat!

Indeed, as it can be seen, the "original" default animations from 2004 are actually quite well done in that regard (and possibly in that regard...). They have priorities set relatively low and work together with each other, so you can walk and type, for instance, and get both correctly working together. This is something I carefully considered, long, long ago, when I was experimenting with my own animations, and the result was exactly what I wanted — such as, say, visually raising your hand when sitting down.

Unfortunately, as soon as I started to buy animations from the professional animators (and who hasn't?), all my old animations, naturally, have stopped working. And I had so many of those!

Also... there is this strange "war" against having the avatar eyes tracking the cursor (see the release notes of the latest SL Viewer, which now have an option to turn that off). From the earliest days of animation overriding, the first thing everybody did was to glue the head in place. And I always wondered — why? One of the most fun and spontaneous things in SL was the cute way avatars would self-animate themselves as their typist was directing them. Jerky? Silly? Well, perhaps, but you could that there was a human behind that avatar, doing human-y things.

Since early on, well, we just rely on pre-programmed animations, with little direct control over what they do — and, perhaps more to the point here, without knowing how well they will work together with animations from other vendors.

Mine, for instance, are set at such a low priority (and even just for the joints I need to move, not of them) that they will basically get ignored by animations except LL's original ones. Granted, I upload them at a much higher priority; but that would defeat the whole purpose, right?

So... yay! I hope the 'Lab is listening to us animation fans and willing to give us the proper tools to tweak the animations we expensively bought so that they work together in the way want.

Then again...

If all TPV viewers incorporate their own viewer-side AO (no need to lag the area with scripts!), with the upcoming Lua-scriptable viewer... will all the above become essentially a moot point?

We'd just handle priorities at the level, no matter what priority the animation creator it should be run at.

Yes this whole area needs a refresh

RestrainedRaptor Resident can 110% agree with this, or at least let us set it wherever animations are played (i.e. gestures, scripts, viewer based animations)

RestrainedRaptor Resident I was about to comment this. I'd say it would be nice to have both options 'object properties' and 'script'. I play a lot of animations directly from my inventory, if they are mod I'd love to be able to change their priority. But then for no mod animations I'd like to be able to script their priorities if I include them in an object.

RestrainedRaptor Resident I also agree with that: at this stage, changing the default priority of the we have dearly bought would go a long, long way to deal with animation issues we have . It wouldn't fix , obviously, but it would fix things. Granted, the animation asset would have to have modify permissions, and very likely be copyable as well, so that we could buy one animation and set it to different priorities, depending on the AO we would be wearing and the other animations it contains...

Kristy Aurelia Maybe only when the newest animation being played with the highest priority can "push" the animation list down by a level. Otherwise, if newest animation isn't the highest, it just add to it and keep all current animations as is.

Vincent Nacon Then you end up in a situation where, for example, an AO and a dance hud are alternating control. Or, in some cases, 2 AOs.

(When I wear a 'taur body, the 'taur AO only animates from the waist-down, leaving my upper body for an ordinary AO to control. For this to work properly, the animations in the ordinary AO need to be lower priority - at least for the joints waist-down.)

Kristy Aurelia what you're essentially saying is: "look, worthless resident, we, the animators, are the ones who know what is for you, so stick to the priorities have defined, because that's the only way everything will work together". And to the rightful reply that we might have combinations of animations from creators, the answer is a laconic "that's fault; buy in exclusiviy, and you will have problems".

In other words: that's what we have now. The "guidelines" are set by each animator for their own products. They couldn't care less what "others" do, that's not concern. What they do is to carefully plan their own animations so that work well together; if they happen to work with animations from other animators, hey, more power to you, but nothing is guaranteed.

Obviously, what each animator that is best for them might not always coincide, and that's where we get the mess we have today. I have lots of my own silly animations which I haven't been able to use in over a decade now — they're still tied to many gestures — simply because there will always be some other animation with higher priority, . Even setting my own animations all at priority 6 is no guarantee that they will still work — there will be conflicts with animations having the same joints set at the same priority, and so the end result is not necessarily foreseeable (and possibly not even consistently displayed on other viewers).

That said...

The point here is to break away from the dictatorship of animation creators who think they know what is best for their customers. Note that they're also covering their own backs: by setting the priorities as they do, they can make sure that everything works as intended, and therefore don't get reports of conflicts on their tech support lines. They can simply ask the resident to stop using the animation from a different vendor and see if it works. It does? Good, then the problem is with the vendor! You need help to get working together? Tough luck — you won't get kind of support from .

This feature suggestion attempts to at least correct some of those issues, by allowing residents to figure out what is best for avatar, and fix it appropriately — without needing to rely upon vendor's tech support. If they wish, they can set all their joints and all their animations at priority 6 and just sell them that way. Their customers would simply have a way to fix , and if it broke everything, why, then it's only the customer that is to blame, right?

I'm always for empowering users to create their own mess if they want :) — as opposed to reserve that power to a Selected Few which are supposed to think what is best for us, insignificant content consumers.

Gwyneth Llewelyn No, what I'm saying is "Look, you, animator, don't make all your animations priority 6 for your AO just because it is way easier now". I don't want animation creators setting all their animations to max priority for no reason. And keeping specific animations at specific agreed upon values, will lead to better compatibility for everyone.

If everyone agreed that priority 3 is walk animation, as set by some sort of official guidance, then if you're making an animation, you can made a decision... should my animation override walks? No set it to less than 3, yes? - set it more than 3. Oh the animation is a walk? Set it to 3.

Kristy Aurelia I hear you, but... how do you propose to these 'agreements'? Who sets the guidelines? 'The community'? Linden Lab? One of the User Groups? (Is there an Animator User Group?)

Also, as we all know, guidelines are meant to be :)

Gwyneth Llewelyn LL could do it, just like there is a wiki page about PBR materials, there could be one about animations, and if people follow it, its great, if they don't... oh well... if they don't and it is obviously a case where they should, that gives a customer something to point at and say "hey your creation should probably follow this thing LL said".

Or to just say it plainly - adult items in SL have a use case for Priority 6 animations, vast majority of AOs and furnitures tend to use animations of lower priority, and almost everything works fine. So while I would love ability to specificity animation priorities, I feel like a bit of guidance would help to maintain the current order of things, and not require me to add scripts that have timers to restart animations because some other animation was used with too high of a priority when it shouldn't have been.

Also worth noting... glTF has animations, but does not have priorities. So depending on how that stuff gets implemented, priorities might be replaced with a completely different system.

Kristy Aurelia Well, fortunately, updating the doesn't require Linden Lab's assistance 😊 Any resident can do it, that's the easy bit.

In fact... !

Not by me, of course. This was written back in 2011 by Coaldust Numbers. It extends the following page:

... which was written in 2009 by @Avimote Dreamscape.

A more recent article focuses on the changes for the Bento skeleton:

In fact, there is a rather large section (= category) just for animations:

(and there is also information regarding animesh, of course, which is related but, well, different)

Lindens revise these pages from time to time, but it's as close as it gets to a list of "recommendations".

Do animators follow them? Of course not. Do they even them? Well, I would suspect that most don't even there a SL Wiki, much less that it contains a rather extensive number of articles on animation.

Note that the discussion about the validity of the SL Wiki as being "authoritative" in its recommendations is almost as old as SL itself; the archived old forums will probably still have that endless (and mostly inconclusive) discussion somewhere.

---

That said, I'm curious about how exactly glTF animations will be implemented in SL, and how (or if) they will work with existing BVH animations. Then again, nothing prevents LL to their own standards-compatible extension to the glTF format including the BVH-style priorities for the joints. We shall see what they come up with, but I would expect them to add several extensions to glTF, not only for animations, but for many other things which are specific to SL.

Gwyneth Llewelyn Oh, so it would appear my concerns are already addressed... I was not aware there was a page about it already.

Gwyneth Llewelyn

I wrote several (most?) of the articles on the Second Life Wiki about the animation system.

I wrote them because the information was not available elsewhere and I was currently debugging several problems in the animation system of the viewer.

I have not made much in Second Life for many, many years, though I may be interested in at least playing with the Lua scripting if Linden Labs does not abort it midway like they did C# scripting.

So I guess that means I should not have much skin in this game.

But I warn you, the animation code was subtle when I last looked at it. Even the Lindens do not know how it is supposed to work. I distinctly recall getting in an argument with one about what ease out do to work correctly, and what it did do until they made an incorrect change to it. They did finally undo that change after others complained about the corrupted playback.

The internal format actually stored which joints are animated (controlling this, so that one does not accidentally animate a joint, when uploading was obnoxiously hard) and they can each have separate priority. There is also a whole priority for the animation that is displayed to the user but is not inherently associated with the actual internal priorities used for playing animations. The displayed animation priority is a in several Linden Labs provided animations. Those cases are documented in my Wiki articles. It is vital to know this stuff to be able to properly override the built-in animations, so it is not just tech geek gibberish and trivia.

Not knowing this stuff is why animators tend to animate all joints and upload all animations at max priority, breaking mixing in the process... It's the 'make everything no mod and put resizer scripts in every prim because I heard (the lie that) it stops copybot' cargo culting of the animation world.

...

...

There were (are?) claims on the wiki that were incorrect. I recall someone saying that the raw (internal) animation format used Euler angles. It actually used normalized quaternions. You will care about the difference if you try to make a raw animation format uploader (as found in most third party viewers)! Another claimed that the lossy compression performed on animations tends to cause visible corruption. I tested it, and this was not so, and then they tried to 'correct' one of my wiki articles on this topic to make it incorrect. Their real problem was almost certainly not understanding how the priorities system actually works, which make your animations look corrupted. Mind you, things the compression could corrupt animations at the time because the viewer corrupted various things while converting BVH files to the raw animation format and there were bugs in the playback code.

Since then, much has changed. There are a whole set of bones that didn't exist when I was writing my articles. I do not claim to understand the new code, and I do not want to have to try to understand it again. I only did so because I could not get the viewer to upload my animations without corrupting them. After going through all the necessary legal rigmarole, it took Linden Labs to correct the bugs I found, explained, and sent them patches for. This has a lot to do with why I quit making anything for Second Life.

Anyone making changes foolishly could disinform a lot of people.

Merge and update carefully...

P.S.

Someone smeared my https://wiki.secondlife.com/wiki/BVH_Frame_Rate page as misinformation last year because they didn't understand that while, yes, you can record more rapid movement in an animation than 45 FPS, nothing in the simulator will ever move faster than that (the simulator max frame rate is 45 FPS), so why would you waste the space? It's not like you could need to realign an appendage to keep it touching a moving object faster than that because the object cannot move faster than that. Everything is already interpolated on playback, so higher animation frame rates do not make for smoother motion. This is what I mean about people 'fixing' things they don't understand. Beware the misinformed anti-misinformation police!

It appears I could not revert the corruption or even notify the perpetrator of their error if I wanted to because Wiki authoring access is now restricted to a blessed few.