Update March 26th: This article now includes the links to the relevant wiki pages for the new capabilities, as released on March 25th. Also, permissions to animate an avatar are only auto-granted when a prim using the new capabilities is attached to the avatar (PERMISSION_OVERRIDE_ANIMATIONS), otherwise explicit permission required.
Note: article title revised to better reflect contents
At the Beta Server meeting on Thursday 21st March, the Lab informally announced the forthcoming arrival of a server-side Animation Override (AO) system utilising LSL commands.
Coded by Kelly Linden, this new capability is not seen as a replacement to existing AO systems, but rather as a means of making them, in Kelly’s words, “Do a significant portion of their work easier and smoother.”
Overview
The new system utilises a series of new LSL commands, which can be placed in a script located in a prim which has permission to animate your avatar, much like current AOs (granted automatically if the prim is attached to your avatar). However, the advantage with the new calls is that they are keyed directly into the server’s animation states, unlike current AOs, which operate somewhat in conflict with the server’s animations states.
For example, with current AO systems, moving your avatar (i.e. walking) causes an update to be sent to the server, which initially tries to run the default animation required (i.e. the infamous “duck walk”). However, the AO script also detects the state change for your avatar, and then instructs the server to replace the default animation information with the required animation.
With the new system, rather than trying to run the default animation and then have an AO tell it what it should be doing, the server simply replaces the default animation with the required animation, thus vastly simplifying the process.
The new capability is currently available for testing on a number of regions on Aditi (CCMTEST17, CCMTEST22, CCMTEST23, CCMTEST26, and CCMTEST29, all on project channel DRTSIM-201), and it should be deployed to a Release Candidate channel during week 13 (week commencing Monday, March 25th).
Additional Notes
- The new calls should be compatible with existing AOs, assuming appropriate priorities are used
- Items such as idle animations and swimming animations are handled separately by the viewer, and so are not covered by the new calls
- This capability does not require an viewer-side changes at present, although it is likely that a future update will be made to the viewer to allow the Stop Animating Me menu option to reset animation states set using the new calls
- Seats and poseballs should continue to use trigger animations
- Poseball type objects should use llStopAnimation(llGetAnimationOverride(“Sitting”)) instead of llStopAnimation(“sit”) in order to work smoothly with the new calls.
Animation States
The animation states specifically covered by the new LSL calls comprise:
- Standing
- Sitting
- Ground sit
- Standing up
- Crouching
- Walking
- Crouch walking
- Striding
- Running
- Turning right
- Turning left
- Jumping
- Pre-jumping
- Taking Off
- Hovering
- Hovering Up
- Hovering Down
- Flying
- Flying Slow
- Falling Down
- Landing
- Soft Landing
LSL AO Calls
The following LSL calls have been defined for use with the above animations.
llSetAnimationOverride(string anim_state, string anim);
- Sets the animation that will play for a given AO state, where: string anim_state is the name of the animation state being overridden (e.g. Walking), and string anim is the animation to be used
- Requires a new runtime permission – PERMISSION_OVERRIDE_ANIMATIONS
- Once an animation override is set for a given state, it is preserved for the rest of the session, unless reset (see below)
- As the animation states are purely server-side, they get cleared on a relog.
llGetAnimationOverride(string anim_state)
- Gets the name of the animation currently set for state
- Requires either PERMISSION_OVERRIDE_ANIMATIONS or PERMISSION_TRIGGER_ANIMATIONS.
llResetAnimationOverride(string anim_state);
- Will reset the animation for the given state to the default
- Includes a special “ALL” state, which will reset all animation overrides to their defaults
- Requires new runtime permissions PERMISSION_OVERRIDE_ANIMATIONS.
[New addition, March 26th]. Note that PERMISSION_OVERRIDE_ANIMATIONS Only be auto-granted for attachments, otherwise explicit permission required.
Testing and RC Deployment
As mentioned above, there are a number of test regions available on Aditi where the new AO calls can be tired out by scripters and TPVs, and the new capabilities should be arriving on an RC channel in week 13. Any issues found with the capability should be reported via a JIRA, and, if deemed appropriate, raised at the Simulator User Group meeting on Tuesday, March 26th.
Inara Pey: Living in a Modemworld 
Reblogged this on The Lionheart Times.
LikeLike
“Poseball type objects should use llStopAnimation(llGetAnimationOverride(“Sitting”)) instead of llStopAnimation(“sit”) in order to work smoothly with the new calls.” – Anyone else smelling tons of broken content?
LikeLike
What’s going to get broken by stopping the animation by name? I’m sorry but — as someone who works very closely with an animator — I don’t immediately see why this should worry me.
LikeLike
Firestorm has an AO built into the Viewer, and now I am wondering just how this communicates with SL, and whether it can be adapted to work with the new system. Many AOs use the open source ZHAO code. I expect that to be quickly sorted, but individual AOs, just as Pose Balls will, are going to need well-informed changes.
Broken content is inevitable. Past history is not encouraging. We’ve been rid of the need for script-in-every-prim solutions for a long while, and they are still out there, still in use.
LikeLike
As an expert on LSL, I was quite worried at first when I read the headline that LL, as I thought they’d make a programmatic replacement.
But now that I read more into it with the article, this actually lets us replace the animations in the existing original AO system – which means we can finally free ourselves from the animation priority dilemma.
This is a very significant step forward as it means we have arrived at a tipping point where we can utilize per-joint priorities safely and predictably.
By replacing the original animations with better and lower priority animations we can now have the whole priority range at disposal.
I’ll have to whip up my AO experiments into shape again and turn it into an next-generation opensource project.
(I once made an AO with a custom scripting language where you could define much more subtle and complex movement states as well as animation transitions, e.g. sprinting forward from standing would give a stand-to-run transition, running forward quickly and turning left would give a subtle lean animation — the experimental AO was an outrageous success btw, I have never felt so much physical presence and weight to my avatar before that it really gave me more intimate control and immersion — the problem I couldn’t figure out at the time was the complexity stemming from trying to deal with animation priorities from the original viewer AO and user education necessary to overcome it)
LikeLike
Mea Cupla: I’d intended to revise the “system” in the article title with “capabilities” prior to hitting the publish button – then forgot, Blame it on the lateness of the hour when I finally did Press the piece. I’ve now made the necessary update.
LikeLike
I don’t see how this could do somethgin similar to orakul or vista where there’s more than one walk and every time you start walking a different animation is used….
LikeLike
I started playing with the new functions on Aditi yesterday, trying to rewrite a ZHAO-II AO to use the new stuff, and found it pretty easy. It actually makes switching between different walks and sits a lot easier than it used to be.
The great thing is that you don’t have to keep on checking to see what the avatar is doing (standing, walking, sitting or whatever) every second or so, and then stopping the default SL animation and playing the one you want. Instead, all you do is tell the viewer, once, to tell the server to play whatever animation it is when you’re walking.
Changing the stand every n seconds or switching walks every time you walk is very easily done. I’ve not finished yet, but I can see I’m going to end up with a single, much simpler, script than the ones I’ve been using and one that uses a lot less resources than before.
LikeLike
That’s pretty much the idea behind the new capabilities :).
I’m no animator, so have not tried the code myself, but I’d imagined it’ll lead to a much leaner, cleaner AO (allowing for those animations beyond the scope of the new capabilities), code-wise.
LikeLike
If this works as I expect, there will be huge incentive to update both AOs and seating surfaces, so furniture can *effectively* suspend AO-originated animations, instead of the kludgy and confusing current methods. (Also improved efficiency of server-side AOs is welcome, allowing the sim “context” to influence the override in a straightforward way, of which context “sitting” is only currently the most common.)
So, while I don’t foresee *broken* content, I see a tremendous amount of it being rapidly replaced as obsolete, lacking very desirable new functionality.
LikeLike
Of course everyone will replace their L$1000+ furniture because of that… NOT!
LikeLike
Heh. Well, if they aren’t using an animation engine that can be upgraded with a drop-in replacement–or if they were silly enough to buy no-mod items–then it was obsolete from the start. In any case, these new LSL functions shouldn’t make such furniture any more crippled than it is already.
LikeLike
YAY. yeah sounds more like badly designed AO content (in this case way too many priority 4 animations out there) will matter less, and content designed to animate (furniture here) has a better chance of working as intended.
and YAY on 3 new particle effects too!! I was so excited last post i forgot to mention it lol.
LikeLike
Wait, wait! LL is about to break every poseball in Second Life!? Good lord, what are they thinking???
LikeLike
I don’t think so, Lindal. As I understand the project, old poseballs (and furniture and pose engines and etc) will continue to work the same as always, but the new functionality allows them to stop whatever animation the AO is using for the “Sitting” animation state (for AOs using the new functions). There’s a kind of partial precedent for something like this in the Lockmeister protocol’s “booton”/”bootoff” commands, but many current AOs don’t handle that protocol. (Even more tangentially, the “sit” internal animation is automatically replaced by “sit_female” for avatars based on a female shape, yet llStopAnimation(“sit”) stops the “sit_female” animation, too.)
LikeLike
As someone who was just about ready to start working on putting AO animations into the Firestorm viewer vs. continuing with my years-old Huddle contraption, this is very interesting to me. I’m wondering if it’s still worth the time when I don’t yet know which of my animations will even be working well with the new system. I read a discussion last night concerning priority of animations and had never thought about it before – that’s how little I know of animations. Is there a way to tell what priority the animations are from the animation file itself, or is it embedded in there someplace and only the creator knows?
LikeLike
It’s embedded, but you can figure it out for yourself using Develop / Avatar / Animation Info while the animation is playing.
LikeLike
I don’t see how this new LSL affects the animation priority.
LikeLike
We can’t use low priority animations due to the default linden animations.
So the idea would be that this allows us to get rid of them entirely from the system, which frees up the 1 to 3 range.
LikeLike