User-Defineable, Replaceable Default Animations

From what I understand, AO systems consume almost rediculous amounts of sim reosources per each one,

That used to be the case, but the "check ten times a second" AOs have become obsolete, and the people using them are no more likely to upgrade to this than to upgrade to ZHAO.

On the other hand, perhaps it was the development of low lag versions of Franimation and its descendants like ZHAO that led the Lindens to put this on the back burner again?

The thing is, there are some animations you CAN'T override. No AO can react quickly enough in a moderately loaded sim to prevent bits of a built-in animation from playing before they stop it and play their own. You can't stop the typing animation, because if you do, your agent is considered not to be typing, and the AGENT_TYPING status can't be polled to determine when you stop, so there's no clue as to when the animation should be stopped.

Some animations are hooked directly into avatar behaviors, and stopping them screws up your avatar (Examples: prejump and jump, stand, falldown, etc).

My avatar floats off the ground on hover-boots, and lots of built-in animations have priorities which screw this up. It's not possible to stop the turnleft and turnright animations quickly enough to prevent my avatar from bobbing to the ground every time I turn. The only solution was to use a priority 4 hovering animation playing all the time, which has its own problems (ie many gestures break).

That said, it seems to me that, for example, the basic walking animations are specially tuned to work with the varying speed of an avatar and with backward walking. I wonder how they can generalize that behavior to any walk animation that someone uploads.

Absolutely. I mentioned this earlier. My point was that the Lindens don't care about this (and the other problems) nearly as much as things like "AOs cause massive lag"... so once that was alleviated (even if not fixed) this could easily have became a lower priority.

The "tuning" of the basic walking animations is a real problem for small or unusually proportioned avatars, by the way. I'd be happy to lose that if it would keep my otter from bobbing around weirdly on his short legs.

Why the proposal is a good idea.

First: AO's are hacks, and don't cover every instance, and don't respond well in laggy (crowded) environments. People want to dance. I've seen an AO with more than thirty scripts. !!! Ow.
Second: AO's are widely free. It's not going to hurt any economy and people still - want to dance. AO's just won't be active /for the default stuff/.
Third: I've seen problems with the animation queue crash my client. (no I haven't documented them well enough to submit a bug report, it's a rather complicated scenario with what is likely a race condition, and I have a life.) Animations don't get handled right by my client or perhaps too many get requested from the asset server to be handled at once, my client barfs. I'd like a StopAllAnimations to not only handle stopping all the animations that are being handled by the server, but also allow the server to gracefully inform my client and all other clients to stop all other animations but X animation that was already loaded - improving bandwidth considerations and lag, server and client side.

Downsides:

People who use ZHAOs or other AOs where it cycles through five (or more) animations so that the AV doesn't look boring - will still use their ZHAO or there's going to be a market / method for concatenating one or more animation files into a larger animation file - which, honestly, is not going to have a very large top size because there's an exploit waiting to happen right there (Here, please hold my 7 MB default animation... No.)

People will still use AO's for user-defined dance routines.

Can you imagine walking into a room where you have to load forty different arbitrary default stand animations /plus/ forty different arbitrary sit animations /plus/ forty different arbitrary walk animations /plus/ forty ... That bandwidth eat could get really out of hand, not to mention the load on the asset servers / bandwidth serving those 8000 copies of animations for /a single dance floor/ - /before even loading any of the active dance animations/.

oh heck yes! Having written my own AO and talked to Francis about hers, I think I can safely say we would both be overjoyed if we could ditch them and use a built in method.

There are a few things that need to be included in a Linden solution however. The ability to change animations from script and to have those changes apply immediately. For instance if I set a new walk animation while walking it needs to change immediately rather than waiting until I stop walking and then start again. That should address the issues of dynamically enabling and disabling animations, and randomizing animations (ie multiple standing poses)

Would you need to have some info about the default animations, such ashow long one cycle lasts, in order to avoid some of the trial and error of making a suitable replacement?

Would this not have a sizable improvement to simulator performance with multiple avs? An AO is a very common attachment and probably contributes a fairly sizable number of instructions when you have a large amount of avs around.

I'm also all for it as it could be made client side to give totally smooth AOs.

Ideally, we should be able to specify this for ourselves. For a walk animation, we should be able to specify where each step starts and where it ends, to aid SL in getting the timing right like it does for the built-in walk animations. Maybe they could use the loop in/out%, but I'm not sure if that's enough information.

*bumpity*

Lindens? We still want this.

How long has this idea been ignored?

Seems to me a like a no-brainer, what with all the load problems.

c'mon - give us the chance to make our "custom" avatars customizable!

The original discussions began 6/04. here is it 1/07 and yes, one might as well conclude it has been shelved and is no long something that is either in the pipeline, on the drawing board, or under consideration by LL.

*shrugs* just more of the same...

edited: the original discussons, AS I REMEMBER THEM, began 6/04. no doubt there were probably active discussions earlier.

*gives the thread it's 6 month kick*

*finds thread in the back of the fridge, checks thread for an expiration date, sniffs thread, and bites into thread anyways*

What effect will Mono have on the customizable default animations idea?

It's likely that Mono will further prevent this argument, sadly. I personally would prefer it to be in the client, rather than the server, better UI, easier to set up, etc.

What would Mono have to do with this? Mono is server side scripting. This feature would be completely client side. Mono would have no effect.

And yes, please, been asking for this for years.

If it reduces the load on the server from AO scripts, that reduces the need/urgency for this feature? I think that's what Ice was getting at.

And I don't see how the feature would be completely client-side. If my av switches to a new animation, my client would have to send a message (with my new animation) to the server so it could tell all the other clients so they can play the new animation as well. Otherwise I'd be sitting on my screen but everyone else would see me standing, and so on.

Or does the server send everyone around me all of my registered animations, so they know which one to play when my av's state changes? That would add to the lag each time a new person entered the room, similar to loading his prims/textures/etc.

I'm not really sure how this was meant to be implemented, so if this post doesn't make any sense, let me know

I have a seawolf dragon and the animations tend to glitch alot

Wow. If there were real functions to change avatar animations, instead of needing whole scripts just to handle that one thing, that would be absolutely amazing. The old AOs would still work, nothing would break them. The only change would be that people would be able to make and sell better functioning and more efficient ones.

Mono increases the cost on the server for AO scripts: they use more memory, and they take much more CPU time to marshal and unpack on sim crossing or teleporting.

Edit: whoa, necro. Sorry, but the point stands.