User-Defineable, Replaceable Default Animations

Name: User-Defineable, Replaceable Default Animations. (Stand/Sit/Walk/Fly/Run etc)
Category: avatar
Subcategory: animation
Author: Michi Lumin
Prop Date: 2005-04-13

Feature Detail
Allow residents to define and replace their own stand, run, sit, walk, and fly animations with uploaded ones. Integrate this into the UI, similar to the old Gesture pulldown. Example, a UI page with assignment slots for STAND: Stand.bvh. WALK: NewWalk.bvh., etc. Also, release existing animations as .BVH files.

Feel free to discuss this feature request further...

Got my vote. Big plus if the walking/running animation speed can vary with velocity, as with the current default walk/run.

And earlier still:

a **really old** thread <-- thats right , over a year ago!

Ya know this seemed the first logical step after custom animuploads... AO devices only exist because it was noticed there was something missing..

We've had at least 2 positively driven threads, where the discussion was over pretty quick because just about everyone just said 'yeah... thats a good idea'...

Discussing it further will probably get only a few replies of 'yeah, thats a good idea' -- threads that don't have controversial issues to debate tend to go that way.

Hopefully the vote system will get it a bit more attention, but honestly - it's a good idea, and it just makes sense.

Siggy.

Obviously, yes! I want this! But I would also like to see a way for a scripted avatar to replace these animations reliably. In other words, with the user's permission, a script should be allowed to replace stand.bvh, NewWalk.bvh, etc. Not just the user through the GUI.

If that's implemented, then huzzah! Hip hip hooray! Hear hear! Yahoo! And hot damn!

My understanding of it would was that these selected anims would become the 'default' for your av, and thus should still be able to be overridden, stopped, started, etc. as they currently are.

That being said...

Having accompanying LSL functions to be able override, replace, change defaults without having to rely on hacks (such as the ludicrously set timer event I've seen in just about every AO) would also be a HUGE bonus.. I agree.

Yes, it's really beyond debate, this should've been added along with custom animations, or very shortly afterwards.

Functions:
llPlayAnimation
llSetAnimationOverride
llGetAnimationOverride
llGetAnimationOverrideList
llSetAnimationOverrideList

----

llPlayAnimation(string animation, float speed)

string animation = animation name to play
float speed = Speed at which to play the animation, all the times in the animation would be mutliplied by this
if speed were 2.0 then the animation would take twice as long to execute

----

llSetAnimationOverride(string animation, integer override)
string animation = animation name (passing a null string would remove any override)
integer override = animation override constant
#define ANIMATION_OVERRIDE_NONE 0
#define ANIMATION_OVERRIDE_AIM_L_BOW 1
#define ANIMATION_OVERRIDE_AIM_R_BAZOOKA 2
#define ANIMATION_OVERRIDE_AIM_R_HANDGUN 3
#define ANIMATION_OVERRIDE_AIM_R_RIFLE 4
#define ANIMATION_OVERRIDE_ANGRY_FINGERWAG 5
#define ANIMATION_OVERRIDE_ANGRY_TANTRUM 6
#define ANIMATION_OVERRIDE_AWAY 7
#define ANIMATION_OVERRIDE_BACKFLIP 8
#define ANIMATION_OVERRIDE_BLOWKISS 9
#define ANIMATION_OVERRIDE_BOW 10
#define ANIMATION_OVERRIDE_BRUSH 11
#define ANIMATION_OVERRIDE_CLAP 12
#define ANIMATION_OVERRIDE_COURTBOW 13
#define ANIMATION_OVERRIDE_CROUCH 14
#define ANIMATION_OVERRIDE_CROUCHWALK 15
#define ANIMATION_OVERRIDE_DANCE1 16
#define ANIMATION_OVERRIDE_DANCE2 17
#define ANIMATION_OVERRIDE_DANCE3 18
#define ANIMATION_OVERRIDE_DANCE4 19
#define ANIMATION_OVERRIDE_DANCE5 20
#define ANIMATION_OVERRIDE_DANCE6 21
#define ANIMATION_OVERRIDE_DANCE7 22
#define ANIMATION_OVERRIDE_DANCE8 23
#define ANIMATION_OVERRIDE_DEAD 24
#define ANIMATION_OVERRIDE_DRINK 25
#define ANIMATION_OVERRIDE_EXPRESS_AFRAID 26
#define ANIMATION_OVERRIDE_EXPRESS_ANGER 27
#define ANIMATION_OVERRIDE_EXPRESS_BORED 28
#define ANIMATION_OVERRIDE_EXPRESS_CRY 29
#define ANIMATION_OVERRIDE_EXPRESS_EMBARRASED 30
#define ANIMATION_OVERRIDE_EXPRESS_LAUGH 31
#define ANIMATION_OVERRIDE_EXPRESS_REPULSED 32
#define ANIMATION_OVERRIDE_EXPRESS_SAD 33
#define ANIMATION_OVERRIDE_EXPRESS_SHRUG 34
#define ANIMATION_OVERRIDE_EXPRESS_SURPRISE 35
#define ANIMATION_OVERRIDE_EXPRESS_WINK 36
#define ANIMATION_OVERRIDE_EXPRESS_WORRY 37
#define ANIMATION_OVERRIDE_FALLDOWN 38
#define ANIMATION_OVERRIDE_FEMALE_WALK 39
#define ANIMATION_OVERRIDE_FIST_PUMP 40
#define ANIMATION_OVERRIDE_FLY 41
#define ANIMATION_OVERRIDE_FLYSLOW 42
#define ANIMATION_OVERRIDE_HELLO 43
#define ANIMATION_OVERRIDE_HOLD_L_BOW 44
#define ANIMATION_OVERRIDE_HOLD_R_BAZOOKA 45
#define ANIMATION_OVERRIDE_HOLD_R_HANDGUN 46
#define ANIMATION_OVERRIDE_HOLD_R_RIFLE 47
#define ANIMATION_OVERRIDE_HOVER 48
#define ANIMATION_OVERRIDE_HOVER_DOWN 49
#define ANIMATION_OVERRIDE_HOVER_UP 50
#define ANIMATION_OVERRIDE_IMPATIENT 51
#define ANIMATION_OVERRIDE_JUMP 52
#define ANIMATION_OVERRIDE_JUMPFORJOY 53
#define ANIMATION_OVERRIDE_KICK_ROUNDHOUSE_R 54
#define ANIMATION_OVERRIDE_KISSMYBUTT 55
#define ANIMATION_OVERRIDE_LAND 56
#define ANIMATION_OVERRIDE_LAUGH_SHORT 57
#define ANIMATION_OVERRIDE_MOTORCYCLE_SIT 58
#define ANIMATION_OVERRIDE_MUSCLEBEACH 59
#define ANIMATION_OVERRIDE_NO_HEAD 60
#define ANIMATION_OVERRIDE_NO_UNHAPPY 61
#define ANIMATION_OVERRIDE_NYANYA 62
#define ANIMATION_OVERRIDE_PEACE 63
#define ANIMATION_OVERRIDE_POINT_ME 64
#define ANIMATION_OVERRIDE_POINT_YOU 65
#define ANIMATION_OVERRIDE_PREJUMP 66
#define ANIMATION_OVERRIDE_PUNCH_L 67
#define ANIMATION_OVERRIDE_PUNCH_ONETWO 68
#define ANIMATION_OVERRIDE_PUNCH_R 69
#define ANIMATION_OVERRIDE_RPS_COUNTDOWN 70
#define ANIMATION_OVERRIDE_RPS_PAPER 71
#define ANIMATION_OVERRIDE_RPS_ROCK 72
#define ANIMATION_OVERRIDE_RPS_SCISSORS 73
#define ANIMATION_OVERRIDE_RUN 74
#define ANIMATION_OVERRIDE_SALUTE 75
#define ANIMATION_OVERRIDE_SHOOT_L_BOW 76
#define ANIMATION_OVERRIDE_SHOUT 77
#define ANIMATION_OVERRIDE_SIT 78
#define ANIMATION_OVERRIDE_SIT_FEMALE 79
#define ANIMATION_OVERRIDE_SIT_GENERIC 80
#define ANIMATION_OVERRIDE_SIT_GROUND 81
#define ANIMATION_OVERRIDE_SIT_GROUND_CONSTRAINED 82
#define ANIMATION_OVERRIDE_SIT_TO_STAND 83
#define ANIMATION_OVERRIDE_SLEEP 84
#define ANIMATION_OVERRIDE_SMOKE_IDLE 85
#define ANIMATION_OVERRIDE_SMOKE_INHALE 86
#define ANIMATION_OVERRIDE_SMOKE_THROW_DOWN 87
#define ANIMATION_OVERRIDE_SNAPSHOT 88
#define ANIMATION_OVERRIDE_SOFT_LAND 89
#define ANIMATION_OVERRIDE_STAND 90
#define ANIMATION_OVERRIDE_STAND_1 91
#define ANIMATION_OVERRIDE_STAND_2 92
#define ANIMATION_OVERRIDE_STAND_3 93
#define ANIMATION_OVERRIDE_STAND_4 94
#define ANIMATION_OVERRIDE_STANDUP 95
#define ANIMATION_OVERRIDE_STRETCH 96
#define ANIMATION_OVERRIDE_STRIDE 97
#define ANIMATION_OVERRIDE_SURF 98
#define ANIMATION_OVERRIDE_SWORD_STRIKE_R 99
#define ANIMATION_OVERRIDE_TALK 100
#define ANIMATION_OVERRIDE_THROW_R 101
#define ANIMATION_OVERRIDE_TRYON_SHIRT 102
#define ANIMATION_OVERRIDE_TURN_180 103
#define ANIMATION_OVERRIDE_TURNBACK_180 104
#define ANIMATION_OVERRIDE_TURNLEFT 105
#define ANIMATION_OVERRIDE_TURNRIGHT 106
#define ANIMATION_OVERRIDE_TYPE 107
#define ANIMATION_OVERRIDE_WALK 108
#define ANIMATION_OVERRIDE_WHISPER 109
#define ANIMATION_OVERRIDE_WHISTLE 110
#define ANIMATION_OVERRIDE_WINK_HOLLYWOOD 111
#define ANIMATION_OVERRIDE_YES_HAPPY 112
#define ANIMATION_OVERRIDE_YES_HEAD 113
#define ANIMATION_OVERRIDE_YOGA_FLOAT 114

----

string llGetAnimationOverride(integer override)
returns the key of the animation registered to that override constant

----

list llGetAnimationOverrideList()
Requires PERMISSION_TRIGGER_ANIMATION (or some new permission like PERMISSION_ANIMATION_OVERRIDE)
Returns a strided list, a single stride [ANIMATION_OVERRIDE_*, animation]

----

llSetAnimationOverrideList(list overridestride)
takes a strided list exactly like that returned by llGetAnimationOverrideList.

So I guess this one is in limbo, again?

More likely it's one of the few they are seriously considering.

And this is really very basic, in my opinion. Why we haven't been given this ability already really baffles me.

So, is there any reason they shouldn't prioritize this? Because there's no good reason that comes to mind besides pushing 1.7 out the door first.

I guess it's a matter of what gets delayed to do the work. Depending on who you ask there's a lot of 'more important than those other things' items. Round up ten random people and ask them which of the planned features is most important and should be worked on before the others, and you'll probably get ten different answers. People are people, after all.

Mind you, I'd really like this feature myself.

But, of course, making one feature come first, means something else has to be second. And so often in software development, it's the smaller simpler things that get pushed back to make way for bigger, more complicated things.

LL say they're trying a new development model out, where features can be developed with some independence from each-other. We and they will all have to wait and see how well or poorly that works out.

Well. I brought this up in 1.2.6. I was told it'd be done and a moot point by 1.3. Actually it completely lost impetus because 1.3's BVH's would be a cure-all.

Then I was told that animation would be rolled out in two phases: what we have now in 1.3, and then this part as a followup in 1.4. The latter I was told specifically by Philip, and I'm sure there's a few townhalls that document it.

Later on in 1.5 I was told it was "on the drawing board."

Then 1.6 came around and I was told that it was not being looked at, and to propose a vote. So I did, and it's gotten many votes.

The rest is history.

I can't see this as being a big time sink. I may be wrong, but most of the functionality is there. I think it's just been forgotten about.

That all comes as no surprise. I was here when animations first went in. Crazy stuff.


I think this is a pretty necessary evolution, though. And with them giving thought to basic avatar stuffs again, I see this as highly likely.

I like this idea too, being able to control your default positions.

I would also like to see some more express animations:

EXPRESS_TALK_EMOTE : This would make your lips and tongue move in a visually talking way when you actually hit enter to type something in say. The time it would last could be linked to the length of the string you type and begin when you hit enter. It could be used in place of or with the typing visual.

EXPRESS_LICK_LIPS : This would be in addition to Express_tongue_out which makes your eyes squint and look like you are making a yukky face. This would be a nice sexy lick, runing the tongue sensually along your lips with your mouth open, from right to left, or left to right, and back again.

Lovepeace

Well, strangely enough, *weather* was accepted for development, and *this* one still says "We will look into it and update the proposition if it is do-able"...

How can it not be do-able? (Or less do-able than in-world weather???)

Again, when they forced all of the females to sit demurely in 1.2.6, I was told repeatedly and EXHAUSTIVELY that I should shut my complaint-hole because this very feature I proposed was eminent.

Not so much, I guess.

Every reason I was given for not optioning the *forced* female sit change was "Well, custom animations are coming. in 1.3. Well, that's the second part of custom animations, and it's coming in 1.4. Well, it's on the drawing board for 1.5. Well, it's not on the drawing board. Well, we'll look at it. Well, it might not be possible - but weather is!"

Don't get me wrong. I like weather. I do. But come on, already, Linden. How on earth is this either -not doable- or negatively impactful?

(I'm going to post this to hotline since this nook is gathering dust.)

This will be a feature that puts animation overider businesses <those that arent made free already> out of the biz or will change things for people who make them. Personally i'd add three more items to list to overide. Sword stance/wep attack 1/wep attack 2

Reason is, this will help animation creators be able to do more then flimsy hold lmb lok left attk look right attk, this will add a little more depth

AO's dont work in noscript. They're essentially a hack, and can cause problems whenever you're seated on a vehicle or something else tries to animate your avatar. This is not a new idea, it's functionality that was planned and then put by the wayside. I've had an "AO" for this since 1.2.6, and it's crap.

I don't see how it'd put AOs out of business: the AOs do a few things that this wouldn't -- the sequenced animation, the controls, scripting and functionality. The AO makers would simply have to use this (correctly implemented) system instead of relying on priorities and kludge overrides.

That's been the only argument I've heard out of this: It'll put AO sellers out of business. (I dont think it will.) But AOs developed out of a need, a shortcoming. I dont think that shortcoming should be maintained just to support a business model that grows out of that shortcoming.

That, and AO's simply don't work well.


EDIT: From what I've heard, MOST AO's are usually free. (the devices.) It's the animations that are sold, and cost money. This would have NO EFFECT on that business. Everyone who is selling animations now could continue to. Apparently most folks use Flipper's or WetIkon's AO's which as far as I know, do not charge for the AO device itself, but for the animations.

That is true michi, i never meant that every business with them would be done for, only that it would change the reason for having the AO, if we can change our sitting a way we want, then no need to use an AO to re-RE convert i guess was my point

While I don't use it, the Wet Ikon AO is free, and I've given it to 10 people that I know of.

Michi has a very valid point that this would have no negative economic impact (probobly positive in that people would have /more/ reason to use the built in AO).
I for one, don't use an AO because I don't like the fact that scripts for most AOs take a lot of resources for something the client could do. (since the client is aware of agent state, client could handle an AO with no detriment to server processor)

1. Sims would have less to process.
2. It's mostly trivial for clients to process an additional event on agent updates.
3. There is no lost of revenue for AO creators (since most are free now and given with animations)
4. This was originally planned!

Plus it's annoying to have your AO take a second to kick in, and to have to come up with hacks to turn your AO off when sitting or not use a sitting anim.

Don't forget we need llAnimationTarget(string animation, vector pos, vector rot) so that people with funny-shaped avs can avoid floating in the air or sinking in the ground...

Huh. Golden oldie thread. Seems Michi was correct; the hype train fizzled out on this one.


But.

Something like this is really basic. An AO is, as described, a pretty messy hack with potentially large lag output. Nice that they're free... nicer to not need them at all.

And it would be nicer still to get a release date that counts for features like this.

Please?

I was just musing about this today.

I want it, if only to have more swimmy animations perstock while swimming!

Please implement this.
It would reduce lag in a big way, since so many people who now use AOs wouldn't need to.

Please???

>>>>yawn<<<<

Another great feature the Lindens fell asleep on.

Indeed. From what I understand, AO systems consume almost rediculous amounts of sim reosources per each one, and a significant percentage of SL's population uses them. I don't personally just because I don't like to fumble with the notecards and because I know about the lag issue that comes with them. If user-defined animation sets were implemented as part of the game you'd see a lot more people using different posture than the default.