I propose the following API:
key llStartAnimationOptions(string animation, list options);
key llStartObjectAnimationOptions(string animation, list options);
Params:
animation: The name of the animation to start
options: An option list, in the same style as llSetPrimitiveParams and other such functions.
Return value:
A key which can be passed to llStopAnimation to cancel the animation. When animations are started in this way, they are not uniquely identified by their name in the way that traditional animations are. There can even be multiple copies of the same animation running. So this key is needed toi identify an instance of the animation.
Options:
[ANIMATION_RATE, float rate]: A multiplier applied to the rate of the animation, so 2.0 plays at double speed, and 0.5 plays at half speed.
[ANIMATION_OFFSET, vector offset]: Offset the root position of the animation by the given vector. Defaults to 0.
[ANIMATION_SCALE, vector, scale]: Scales the root position of the animation by the given vector. Defaults to 0.
[ANIMATION_PRIORITY, integer priority]: The priority of the animation. If not specified, defaults to the priority set at upload time.
[ANIMATION_LOOP, integer loop]: If TRUE, the animation is looped. If FALSE, not. If not specified, defaults to the setting at upload.
... ditto for overriding other upload options.
JUSTIFICATION:
It is currently very difficult or impossible to use off the shelf animations purchased from other creators in scripted objects. The relative timing between animations has to be just right. The scale of the animation has to match the size of the object, meaning creators often have to resize their objects to match the animation rather than their own vision, and it's impossible to make an animated object resizable without screwing up the animations. When layering animations, you have to just hope the creators uploaded them with the right relative priorities, but you always get that one creator who decided that if you're catching a ball you legs should be exactly in this position at the max priority, so the avatar stands up awkwardly when the catch anim is played, and so on.
These options are intended to return some control over how an animation is used to the user of that animation, so that it can be adjusted to match a build.
Of the upload options that can be overridden, the most important are the priority (to layer animations reliably) and the in percent or frame. The latter can be used for all sorts of interesting tasks, like resynchronizing animations in the middlke of playback by restarting them with a different input frame; or selecting just portions of longer animations to use in specific contexts.