Allow starting an animation with a specific priority
tracked
Mars Tamale
There are many animations out there which were uploaded with a low / default priority. These are fine provided other overlayed animations running at the same time don't override their actions. It would be useful to be able to change that priority when starting the animation.
eg: llStartAnimationPriority("animation", 6);
Log In
Honey Puddles
Imagine how much simpler it could be to just adjust the priority of AO animations within the script OF the AO?
Got some cheesy old animation you love, but it's uploaded at P1? fiddle fiddle with the script, and Booom it's working as intended in your project.
I recently ran into a similar issue spending days curating a collection of animations from various stores, only to discover too late that I'd built an AO that was 80% P4.. which renders the hugger I use, practically useless.
Imagine just having a setting in the AO script that said "integer animPriority = 3";
Please can we have this? pretty pretty please? 🧁🍫🍭🍬🍧🍨🍦🎂🍩🍪🍰
Jasdac Stockholm
I'm curious how this is going to work in practice since .anim doesn't do priorities per animation, but rather per joint.
Journey Bunny
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
Another thought would be going one step deeper, allowing animation priority change by joint. Often with things like cuffs etc we don't care so much about certain bits of the animation but the wrists (for example) must comply with the cuffed animation. So we could have a LSL function that took an animation to start, a list of attachment points & priorities or all points & a priority. But like Kristy said earlier this becomes a push down stack so may be overridden by script with the next animation... Caveat Emptor.
eg: llStartAnimationPriority(string animation, list params)
params is stride 2 [Attachment_point, priority (1-6) ...... ]
This may encourage people not to abuse overriding priorities but then it wont matter much anyway as the next person may override it. On the plus side it may encourage people to think more carefully about the default priority to upload animations as it wont matter so much (if they are scripting their use).
Thought needs to be given to how we handle default animations. My thoughts are that they may be raised or indeed lowered by script.
Maestro Linden
tracked
nickvrtis Resident
I like the idea. But I think we should also be able to get a list of the priority of the current animations. This way, we could start the new one without just setting it at 6.
Mars Tamale
Yes this whole area needs a refresh
RestrainedRaptor Resident
I think I'd rather see LL give us the ability to
change
the priority of an animation, if the item is modifiable.nulshift Resident
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)
Bastbar Barbosa
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.
Kristy Aurelia
It would be quite handy, but... I'm a bit worried that everyone would just end up using 6 for everything.
Would definitely need some sort of guidelines, on what type of animations should use what priority, like: idle stand 3, walk 4, hold purse 5, etc.
Vincent Nacon
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.
V
VriSeriphim Resident
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.)