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.”
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).
- 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.
The animation states specifically covered by the new LSL calls comprise:
- Ground sit
- Standing up
- Crouch walking
- Turning right
- Turning left
- Taking Off
- Hovering Up
- Hovering Down
- Flying Slow
- Falling Down
- 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.
- Gets the name of the animation currently set for state
- Requires either PERMISSION_OVERRIDE_ANIMATIONS or PERMISSION_TRIGGER_ANIMATIONS.
- 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.