Animation priorities?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Animation priorities?

Craig Berry-2
I've noticed that if you have a base animation override package
attached, so that your walk, stand, sit, etc. are customized, it's
unpredictable whether an animation run by some other attachment will
work or not.  Usually it's clear which one should have a higher
priority than the other, but there doesn't seem to be a way to set
this.  Am I missing something?

--
Craig Berry - http://www.cine.net/~cberry/
"The road of excess leads to the palace of wisdom." - William Blake
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Kelly Linden
Craig Berry wrote:
> I've noticed that if you have a base animation override package
> attached, so that your walk, stand, sit, etc. are customized, it's
> unpredictable whether an animation run by some other attachment will
> work or not.  Usually it's clear which one should have a higher
> priority than the other, but there doesn't seem to be a way to set
> this.  Am I missing something?
>
>  
Animations when uploaded can have a priority set.  Unfortunately the
built in animations also have priorities so it may take some high
priorities to override the defaults for AOs, and it may just be simpler
to give them really high priorities.  I haven't actually dealt with this
in detail so someone else may know more specifics.  There is currently
no way to set by script the priority of an animation.

 - Kelly
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

ordinal.malaprop
In reply to this post by Craig Berry-2
When you upload an animation you can set its priority; body parts not  
affected by the animation won't be moved, but an equal or higher  
priority for a part should override any existing animation.


On 28 Aug 2007, at 00:13, Craig Berry wrote:

> I've noticed that if you have a base animation override package
> attached, so that your walk, stand, sit, etc. are customized, it's
> unpredictable whether an animation run by some other attachment will
> work or not.  Usually it's clear which one should have a higher
> priority than the other, but there doesn't seem to be a way to set
> this.  Am I missing something?
>
> --
> Craig Berry - http://www.cine.net/~cberry/
> "The road of excess leads to the palace of wisdom." - William Blake
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/ 
> secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Baron Hauptmann
So what happens if you have a priority 4 animation in an AO and encounter a scripted object that tries to animate you with a different priority 4 animation?  Is it predictable which will win?
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Argent Stonecutter
In reply to this post by Craig Berry-2
From: Kelly Linden <[hidden email]>
> Animations when uploaded can have a priority set.  Unfortunately the
> built in animations also have priorities so it may take some high
> priorities to override the defaults for AOs, and it may just be  
> simpler
> to give them really high priorities.  I haven't actually dealt with  
> this
> in detail so someone else may know more specifics.  There is currently
> no way to set by script the priority of an animation.

Since the UI window for setting the priorities and looping for an  
animation already exists, how hard would it be to allow someone with  
an animation to open up that window on it and view (and, if  
permissions allow, modify) those settings? That would solve a lot of  
people's problems with animations... I realize that this would  
involve creating a new asset the first time this is done to a copy of  
an animation, so you probably wouldn't allow scripts to do it, but it  
should be technically easy... no?

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

ordinal.malaprop
For that matter, simply allowing people to see the priority, length  
and other details of an animation would be amazingly convenient. I  
already write the priority and length into the name of animations  
that I upload - "fiddle with gadget p3 2.0s loop" - but if you don't  
do that immediately you are out of luck, and for other people's  
animations, even if they are full-mod you can't tell.

Scripts being able to find this out would be even better, and, for  
that matter, being able to find out the length of sounds would be  
handy too.

On 3 Sep 2007, at 21:06, Argent Stonecutter wrote:

> Since the UI window for setting the priorities and looping for an  
> animation already exists, how hard would it be to allow someone  
> with an animation to open up that window on it and view (and, if  
> permissions allow, modify) those settings? That would solve a lot  
> of people's problems with animations... I realize that this would  
> involve creating a new asset the first time this is done to a copy  
> of an animation, so you probably wouldn't allow scripts to do it,  
> but it should be technically easy... no?

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Bibi Book
2007/9/3, [hidden email] <[hidden email]>:

> Scripts being able to find this out would be even better, and, for
> that matter

Better would be:
1. Being able to change settings inworld - but they may not do that as
we pay for every additional upload.  _and_
2. discovering/setting it in a script in addition

Bibi
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Richard Nelson-6
In reply to this post by Craig Berry-2
Animation priorities are baked into the asset, and have an upper limit of  
LL_CHARACTER_MAX_PRIORITY, which is 7.  The asset actually stores the  
priority as a 32 bit integer, and the viewer code applies no explicit  
clamping.  However, due to the use of an enum, we would have to modify the  
viewer to properly accept large values.

I feel that increasing the number of priority "slots" will not actually  
solve any problems (even assuming we'd remap the range to add slots in  
between the existing ones).  The goal is to have a few slots with  
reasonably clear semantics (low - incidental animations, medium -  
locomotion animations, base character behaviors, high - gestures, very  
high - locked poses), but I have yet to document that anywhere,  
unfortunately.  I think a good start would be to replace the priority  
spinner in the animation upload dialog with a dropdown box that labels the  
options.

When two animations at the same priority level are triggered, the one to  
be triggered most recently wins, modulo the granularity of a server  
timestep.  If two same priority animations are triggered within a single  
server timestep, the asset UUID is the deciding factor.

We've wanted a way to open existing animations and modify the attributes  
but, as mentioned, this would result in creating a new asset every time a  
change is committed.  I think a more scalable approach would be to allow  
the triggering of animations at priorities specified via LSL.

llStartAnimation("anim", HIGH_PRIORITY);

I think it's important that animations still keep an intrinsic priority,  
but this would be a simple way to add the flexibility you want.

R.

On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry <[hidden email]> wrote:

> I've noticed that if you have a base animation override package
> attached, so that your walk, stand, sit, etc. are customized, it's
> unpredictable whether an animation run by some other attachment will
> work or not.  Usually it's clear which one should have a higher
> priority than the other, but there doesn't seem to be a way to set
> this.  Am I missing something?
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Joe Etten
Oh this would be a very wonderful addition to the llStartAnimation() function. I'd vote it up so long as it just ignored the baked setting. However, with so many animated objects out there, I am sure it would cause havoc.

On Jan 8, 2008 3:01 PM, Richard Nelson <[hidden email]> wrote:

We've wanted a way to open existing animations and modify the attributes
but, as mentioned, this would result in creating a new asset every time a
change is committed.  I think a more scalable approach would be to allow
the triggering of animations at priorities specified via LSL.

llStartAnimation("anim", HIGH_PRIORITY);

I think it's important that animations still keep an intrinsic priority,
but this would be a simple way to add the flexibility you want.

R.

On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry <[hidden email]> wrote:

> I've noticed that if you have a base animation override package
> attached, so that your walk, stand, sit, etc. are customized, it's
> unpredictable whether an animation run by some other attachment will
> work or not.  Usually it's clear which one should have a higher
> priority than the other, but there doesn't seem to be a way to set
> this.  Am I missing something?
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters


_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

ordinal.malaprop
Two enthusiastically-raised thumbs from my direction as well, and I  
imagine any scripter dealing with animations that you care to name. Of  
course, it requires that the AO itself use the priority parameter. But  
I'm sure that wouldn't be too hard to do.

Given that LSL doesn't seem to support default parameters, this  
function would need a new name... llStartAnimationPriority?

On 8 Jan 2008, at 20:28, Joe Etten wrote:

> Oh this would be a very wonderful addition to the llStartAnimation()  
> function. I'd vote it up so long as it just ignored the baked  
> setting. However, with so many animated objects out there, I am sure  
> it would cause havoc.
>
> On Jan 8, 2008 3:01 PM, Richard Nelson <[hidden email]> wrote:
>
> We've wanted a way to open existing animations and modify the  
> attributes
> but, as mentioned, this would result in creating a new asset every  
> time a
> change is committed.  I think a more scalable approach would be to  
> allow
> the triggering of animations at priorities specified via LSL.
>
> llStartAnimation("anim", HIGH_PRIORITY);
>
> I think it's important that animations still keep an intrinsic  
> priority,
> but this would be a simple way to add the flexibility you want.
>
> R.
>
> On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry <[hidden email]>  
> wrote:
>
> > I've noticed that if you have a base animation override package
> > attached, so that your walk, stand, sit, etc. are customized, it's
> > unpredictable whether an animation run by some other attachment will
> > work or not.  Usually it's clear which one should have a higher
> > priority than the other, but there doesn't seem to be a way to set
> > this.  Am I missing something?
> >
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Jacob Warwick
In reply to this post by Joe Etten
Any word on a llName2Key? The external database doesn't have newer residents, or at least not on the teen grid. 

.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Yacobheimer125 Voom
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-

On Jan 8, 2008, at 3:28 PM, "Joe Etten" <[hidden email]> wrote:

Oh this would be a very wonderful addition to the llStartAnimation() function. I'd vote it up so long as it just ignored the baked setting. However, with so many animated objects out there, I am sure it would cause havoc.

On Jan 8, 2008 3:01 PM, Richard Nelson <[hidden email]> wrote:

We've wanted a way to open existing animations and modify the attributes
but, as mentioned, this would result in creating a new asset every time a
change is committed.  I think a more scalable approach would be to allow
the triggering of animations at priorities specified via LSL.

llStartAnimation("anim", HIGH_PRIORITY);

I think it's important that animations still keep an intrinsic priority,
but this would be a simple way to add the flexibility you want.

R.

On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry <[hidden email]> wrote:

> I've noticed that if you have a base animation override package
> attached, so that your walk, stand, sit, etc. are customized, it's
> unpredictable whether an animation run by some other attachment will
> work or not.  Usually it's clear which one should have a higher
> priority than the other, but there doesn't seem to be a way to set
> this.  Am I missing something?
>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Joe Etten
In reply to this post by ordinal.malaprop
Oh well I think we should make it excruciatingly long.. Maybe llStartAnimationPriorityOveridizationer(). But I suppose the shorthand llStartAnimationPriority() would work.. Though I'd prefer llStartPriorityAnim() or llStartAnimPriority(). The former being the one that seems to be more human readable to me.

On Jan 8, 2008 3:42 PM, <[hidden email]> wrote:
Two enthusiastically-raised thumbs from my direction as well, and I
imagine any scripter dealing with animations that you care to name. Of
course, it requires that the AO itself use the priority parameter. But
I'm sure that wouldn't be too hard to do.

Given that LSL doesn't seem to support default parameters, this
function would need a new name... llStartAnimationPriority?

On 8 Jan 2008, at 20:28, Joe Etten wrote:

> Oh this would be a very wonderful addition to the llStartAnimation()
> function. I'd vote it up so long as it just ignored the baked
> setting. However, with so many animated objects out there, I am sure
> it would cause havoc.
>
> On Jan 8, 2008 3:01 PM, Richard Nelson <[hidden email]> wrote:
>
> We've wanted a way to open existing animations and modify the
> attributes
> but, as mentioned, this would result in creating a new asset every
> time a
> change is committed.  I think a more scalable approach would be to
> allow
> the triggering of animations at priorities specified via LSL.
>
> llStartAnimation("anim", HIGH_PRIORITY);
>
> I think it's important that animations still keep an intrinsic
> priority,
> but this would be a simple way to add the flexibility you want.
>
> R.
>
> On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry <[hidden email]>
> wrote:
>
> > I've noticed that if you have a base animation override package
> > attached, so that your walk, stand, sit, etc. are customized, it's
> > unpredictable whether an animation run by some other attachment will
> > work or not.  Usually it's clear which one should have a higher
> > priority than the other, but there doesn't seem to be a way to set
> > this.  Am I missing something?
> >
>
>
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters


_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Argent Stonecutter
In reply to this post by Craig Berry-2
I think it's probably time to open up all the animation parameters to  
scripting. This had been discussed a couple of years ago, but the  
Lindens shot it down by saying that ragdoll physics was coming. Well,  
it's not coming any more... so, how about:

key id = llAnimation(string anim, integer pri, vector off, rotation  
rot, float rate, integer mask, integer flags);

Start animation on avatar at priority _pri_, applying offset _off_  
and rotation _rot_ (as in llSitTarget) with the playback speed  
multiplied by _rate_. _mask_ specifies the joints that will be  
animated, defaults to all joints if zero. _flags_ will allow  
overriding things like the looping. id is returned to apply to the  
next calls:

llSetAnimation(key id, integer pri, vector off, rotation rot, float  
rate, integer mask, integer flags);
llCancelAnimation(key id);

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

ordinal.malaprop
Seems fair. What about using a list to set these, a la  
llSetPrimitiveParams et al, which would be more generally expandable?  
llAnimation([ANIM_ON, TRUE, ANIM_PRIORITY, 3, ANIM_OFFSET, <0.0, 0.0,  
0.0>, ANIM_ROT ... ])

Actually, introducing more constants like this is a bit dangerous now  
I think of it - I use quite a few "pseudo-constants" which begin with  
ANIM_. So they'd have to have better names. But you get the idea.

On 8 Jan 2008, at 21:24, Argent Stonecutter wrote:

> I think it's probably time to open up all the animation parameters  
> to scripting. This had been discussed a couple of years ago, but the  
> Lindens shot it down by saying that ragdoll physics was coming.  
> Well, it's not coming any more... so, how about:
>
> key id = llAnimation(string anim, integer pri, vector off, rotation  
> rot, float rate, integer mask, integer flags);
>
> Start animation on avatar at priority _pri_, applying offset _off_  
> and rotation _rot_ (as in llSitTarget) with the playback speed  
> multiplied by _rate_. _mask_ specifies the joints that will be  
> animated, defaults to all joints if zero. _flags_ will allow  
> overriding things like the looping. id is returned to apply to the  
> next calls:
>
> llSetAnimation(key id, integer pri, vector off, rotation rot, float  
> rate, integer mask, integer flags);
> llCancelAnimation(key id);
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Craig Berry-2
On Jan 8, 2008 1:29 PM,  <[hidden email]> wrote:
> Seems fair. What about using a list to set these, a la
> llSetPrimitiveParams et al, which would be more generally expandable?
> llAnimation([ANIM_ON, TRUE, ANIM_PRIORITY, 3, ANIM_OFFSET, <0.0, 0.0,
> 0.0>, ANIM_ROT ... ])

I like that; in addition to better matching existing practice, it
makes it easier to store packaged option sets on single variables.

--
Craig Berry - http://www.cine.net/~cberry/
"So we struggle and we stagger, down the snakes and up the ladder, to
the tower where the blessed hours chime."
  - Leonard Cohen, "Closing Time"
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Seagel
In reply to this post by Craig Berry-2
What about this?
llSetAnimParams(["66864f3c-e095-d9c8-058d-d6575e6ed1b8", 4, TRUE, <0.0, 1.0, 0.0>, 0, 0, 0.03, 0.03]);
string name, integer priority, integer loop, vector loop_inout, integer hand_pose, integer expression, float ease_in, float ease_out 

On Jan 8, 2008 3:42 PM, <[hidden email]> wrote:

> Two enthusiastically-raised thumbs from my direction as well, and I
> imagine any scripter dealing with animations that you care to name. Of
> course, it requires that the AO itself use the priority parameter. But
> I'm sure that wouldn't be too hard to do.
>
> Given that LSL doesn't seem to support default parameters, this
> function would need a new name... llStartAnimationPriority?
>
> On 8 Jan 2008, at 20:28, Joe Etten wrote:

>
> > Oh this would be a very wonderful addition to the llStartAnimation()
> > function. I'd vote it up so long as it just ignored the baked
> > setting. However, with so many animated objects out there, I am sure
> > it would cause havoc.
> >
> > On Jan 8, 2008 3:01 PM, Richard Nelson <[hidden email]> wrote:
> >
> > We've wanted a way to open existing animations and modify the
> > attributes
> > but, as mentioned, this would result in creating a new asset every
> > time a
> > change is committed.  I think a more scalable approach would be to
> > allow
> > the triggering of animations at priorities specified via LSL.
> >
> > llStartAnimation("anim", HIGH_PRIORITY);
> >
> > I think it's important that animations still keep an intrinsic
> > priority,
> > but this would be a simple way to add the flexibility you want.
> >
> > R.
> >
> > On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry <[hidden email]>
> > wrote:
> >
> > > I've noticed that if you have a base animation override package
> > > attached, so that your walk, stand, sit, etc. are customized, it's
> > > unpredictable whether an animation run by some other attachment will
> > > work or not.  Usually it's clear which one should have a higher
> > > priority than the other, but there doesn't seem to be a way to set
> > > this.  Am I missing something?
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

ordinal.malaprop
That would not be as good, I'd say, as it is still basically a  
positional parameter list. With the [PARAMETER1, value1, PARAMETER2,  
value2] format at least there is the option of changing or ignoring a  
parameter, and it's also more familiar based on other functions.

On 8 Jan 2008, at 22:49, Seagel wrote:

> What about this?
> llSetAnimParams(["66864f3c-e095-d9c8-058d-d6575e6ed1b8", 4, TRUE,  
> <0.0, 1.0, 0.0>, 0, 0, 0.03, 0.03]);
> string name, integer priority, integer loop, vector loop_inout,  
> integer hand_pose, integer expression, float ease_in, float ease_out
>
> On Jan 8, 2008 3:42 PM, <[hidden email] > wrote:
>
> > Two enthusiastically-raised thumbs from my direction as well, and I
> > imagine any scripter dealing with animations that you care to  
> name. Of
> > course, it requires that the AO itself use the priority parameter.  
> But
> > I'm sure that wouldn't be too hard to do.
> >
> > Given that LSL doesn't seem to support default parameters, this
> > function would need a new name... llStartAnimationPriority?
> >
> > On 8 Jan 2008, at 20:28, Joe Etten wrote:
> >
> > > Oh this would be a very wonderful addition to the  
> llStartAnimation()
> > > function. I'd vote it up so long as it just ignored the baked
> > > setting. However, with so many animated objects out there, I am  
> sure
> > > it would cause havoc.
> > >
> > > On Jan 8, 2008 3:01 PM, Richard Nelson <[hidden email]>  
> wrote:
> > >
> > > We've wanted a way to open existing animations and modify the
> > > attributes
> > > but, as mentioned, this would result in creating a new asset every
> > > time a
> > > change is committed.  I think a more scalable approach would be to
> > > allow
> > > the triggering of animations at priorities specified via LSL.
> > >
> > > llStartAnimation("anim", HIGH_PRIORITY);
> > >
> > > I think it's important that animations still keep an intrinsic
> > > priority,
> > > but this would be a simple way to add the flexibility you want.
> > >
> > > R.
> > >
> > > On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry < [hidden email]>
> > > wrote:
> > >
> > > > I've noticed that if you have a base animation override package
> > > > attached, so that your walk, stand, sit, etc. are customized,  
> it's
> > > > unpredictable whether an animation run by some other  
> attachment will
> > > > work or not.  Usually it's clear which one should have a higher
> > > > priority than the other, but there doesn't seem to be a way to  
> set
> > > > this.  Am I missing something?
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Kubota Homewood
I agree with Ordinal, you might as well use positional parameters.

Using the tagged list is probably the most flexible.  It also means  
you can do things in any order, so you can build up the parameters  
needed:

        list animParams = [];

        animParams += [ANIM_ON, TRUE];
        if (override_prio != -1)
                animParams += [ANIM_PRIO, override_prio];

And so on.  If you really wanted to go gaga you could essentially put  
animation sequences directly in the list:

        animParams += [ ANIM_PART, ANIM_LEFT_FOOT, duration, <rotation>,  
<translation>, ...];

Okay, maybe a bit over the top for dances and things, but might be  
nice if you just want to, say, give a quick wave :-)

(That last part is mostly a joke, with a kernel of an idea :-)

        -Kubota
        "Using heavy machinery to do delicate tasks"



On Jan 8, 2008, at 4:57 PM, [hidden email] wrote:

> That would not be as good, I'd say, as it is still basically a  
> positional parameter list. With the [PARAMETER1, value1, PARAMETER2,  
> value2] format at least there is the option of changing or ignoring  
> a parameter, and it's also more familiar based on other functions.
>
> On 8 Jan 2008, at 22:49, Seagel wrote:
>
>> What about this?
>> llSetAnimParams(["66864f3c-e095-d9c8-058d-d6575e6ed1b8", 4, TRUE,  
>> <0.0, 1.0, 0.0>, 0, 0, 0.03, 0.03]);
>> string name, integer priority, integer loop, vector loop_inout,  
>> integer hand_pose, integer expression, float ease_in, float ease_out
>>
>> On Jan 8, 2008 3:42 PM, <[hidden email] > wrote:
>>
>> > Two enthusiastically-raised thumbs from my direction as well, and I
>> > imagine any scripter dealing with animations that you care to  
>> name. Of
>> > course, it requires that the AO itself use the priority  
>> parameter. But
>> > I'm sure that wouldn't be too hard to do.
>> >
>> > Given that LSL doesn't seem to support default parameters, this
>> > function would need a new name... llStartAnimationPriority?
>> >
>> > On 8 Jan 2008, at 20:28, Joe Etten wrote:
>> >
>> > > Oh this would be a very wonderful addition to the  
>> llStartAnimation()
>> > > function. I'd vote it up so long as it just ignored the baked
>> > > setting. However, with so many animated objects out there, I am  
>> sure
>> > > it would cause havoc.
>> > >
>> > > On Jan 8, 2008 3:01 PM, Richard Nelson <[hidden email]>  
>> wrote:
>> > >
>> > > We've wanted a way to open existing animations and modify the
>> > > attributes
>> > > but, as mentioned, this would result in creating a new asset  
>> every
>> > > time a
>> > > change is committed.  I think a more scalable approach would be  
>> to
>> > > allow
>> > > the triggering of animations at priorities specified via LSL.
>> > >
>> > > llStartAnimation("anim", HIGH_PRIORITY);
>> > >
>> > > I think it's important that animations still keep an intrinsic
>> > > priority,
>> > > but this would be a simple way to add the flexibility you want.
>> > >
>> > > R.
>> > >
>> > > On Mon, 27 Aug 2007 16:13:57 -0700, Craig Berry <  
>> [hidden email]>
>> > > wrote:
>> > >
>> > > > I've noticed that if you have a base animation override package
>> > > > attached, so that your walk, stand, sit, etc. are customized,  
>> it's
>> > > > unpredictable whether an animation run by some other  
>> attachment will
>> > > > work or not.  Usually it's clear which one should have a higher
>> > > > priority than the other, but there doesn't seem to be a way  
>> to set
>> > > > this.  Am I missing something?
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
>

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: Animation priorities?

Argent Stonecutter
In reply to this post by Craig Berry-2
I like the list idea.

I think there's probably not a lot of parameter combinations that you  
need to set separately. For example, you can usually set the offset  
and rotation together.

Since llStopAnimation uses the animation name as the key, we might as  
well keep doing that instead of creating an id. And we can probably  
get by with one call... llStart... rather than llSet..., so it starts  
and gets its params in one message. The client can just treat extra  
Starts as overrides.

The prefix ANIM_ is probably pretty overloaded, but LLANIM_ is  
unlikely to be an issue, and it's also a useful precedent.

llStartAnimationParams(string anim, list params);
[LLANIM_TARGET, vector off, rotation rot]
[LLANIM_PRIORITY, integer priority]
[LLANIM_LIMITS, float rate, integer loops]
[LLANIM_MASK, LLANIM_MASK_LEFT_HAND|LLANIM_MASK_RIGHT_HAND|...]


_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters