Possible v1.3 Feature: Revamp to anamation interface!

One of the most fascinating things I miss from the beta days was non-blended animations. llGetAnimation() worked like it was flawless, it could tell if I was dancing, flying, walking, standing, or smashing into the ground

I didnt see many things that took advantage of that feature, and by the time I got my grubby paws on it, blended animations were implimented. This totally short-circuited llGetAnimation(), causing it to report the lowest priority animation, if I was dancing, it would report standing. The change basicly killed off many ideas that it would have opened up.

I propose a revamp of the animation system for v1.3!

One:
An anamation listener (and appropriate removal/control functions).

integer llAnimListen(key avatar, string animation)

llAnimListenRemove(integer num);
llAnimListenControl(integer num, integer active);

This would allow for an animation event:

triggered_animation(key avatar, list animList)

animList would be the list of animations the avatar is currently undergoing, the first index being the highest priority animation, and the last being the lowest priority.

This interface would allow scripters and avatar customizers to further customize the appearence of our avatars.

Some things that may be able to be done were this implimented:

Fire breathing without chat spam.
Heart particles floating from the avatar when the kiss animation is performed.
Special script actions triggered when a string of animations is performed.
Object chat on a non-0 channel when the avatar performs a specific animation.
Cool scripted effects (particles possibly) that occur when specific animations are triggered.
Someone might even be able to script up a rough keyboard using the interface! (Assign a different animation for every keyboard key)

All this can be done without needing any chat said on the public chat channel!

Who's with me!
==Chris

honestly i'd be happy with just llGetAnimationName(); that'd jus return the NAME of the current animation, not the type

That'd be cool, but what if you've got several animations running currently (and as usual, only the top-most animation is being shown)?

i.e., what if my script wants to see if the AV is currently playing a dance animation?

I *could* be in the middle of a dance animation, but temporarily preempted it with a backflip. A function that only returns the *current* animation would then return that I'm playing the "backflip" animation, even though that's stacked on top of a dance move, so the logic would return a false, even though it should be true.

What would be optimal is a function that returns a *list* that represents the current animation-name stack =)

i.e, list llGetAnimationNames(void)
returns -> ["Standing","dance6","backflip"]

well quite simple when yer performing dance6 and you do a backflip, yer no longer performing dance6 i don't believe... you have a script runing thats going to resume it once the flip has stopped... but the actual dance animation is no longer currently being applied to yer avatar is it?

I'd say yes and no, technicly it only seems to "play" once, but if you do some dance moves, then backflip once backflip is done you can see the end of the dance move, so it goes dance -> backflip -> end of dance. So while it may not be "playing" the animation is still going on under the backflip.

Something like Kex described would be great.

Backflip blends with other animations. Trigger a backflip and dance1 or a roundhouse kick at the same time to see this.

Actually they do stack. =)

If you do a long dance maneuvre like dance 2, and backflip just as it's starting, you'll see dance2 finish once your backflip animation ends.

Some animations are state-oriented too and don't have an implicit ending (like sitting). There seems to be some kind of priority list too. That's why you have to stop the "sit" animation before you can see the "sit_generic" animation. They both will run at the same time, but if they do, "sit" takes priority.

Some gestures seem to take control of parts of your avatar, while leaving other parts "loose" to move around. Floating yoga, for instance, can be combined with just about any upper-body animation (wave, blowkiss, etc). Priorities can be mixed: sitting animates both your lower and upper bodies (e.g., the infamous "prissy" hand pose); and it allows the upper-body animations to be overridden (waving, clapping, etc work fine) but not the lower body (triggering dance moves allow the arms to "dance" but not the legs).

I suspect that one of the reasons it's taking so long to deliver custom animations is that coming up with an editor for all these options has to be a user-interface nightmare. We may wind up with something that looks more like a scripting language than a drag-and-drop 3D editor. And it suggests that creating animations will become another saleable craft skill, like building, scripting, clothing design, etc.

I say we get them to put a Chris Omega spellchecker in 1.3. We all know he needs it.

It has been said that when custom animations are implemented, creating them might require Poser. This would be unfortunate both because of the learning curve and the cost the the software.

I hope and doubt it will require Poser. This would make it even rarer for custom gestures to be made by people. It may require the Poser *filetype* or whatever animation file type poser uses, which would require LL to maybe get a license in order to use their program to save to that file type?

I dunno, I'm just guessing there.

Also another possibility why Sit takes over sit_generic may be a timer event, like if you sit down your avatar kinda moves on its own with random movements, a timer may triger these which in turn trigger the Sit animation over the sit_generic.

Again I'm just guessing there, could be totaly wrong.