Sl internal Animation priority changed???

[Helm Anton]

What the hell has happened to SL animation priorities??

A priority 1 animation stance locks and wont let sl internal walk or run over ride it?  This happened about a week ago when i noticed my priority 3 stances stopped allowing normal sl walk to over ride them when i move, now they all just slide locked in stance, i tried uploading at priority 1 and same thing o.O  has LL changed the internal sl walk and run prioroties to 0?

[Phil Deakins]

I don't see any change. For things to change on your screen, data needs to be received. I suspect the problem is in your connection.

[Helm Anton]

I wish that were the case.  But i had it verified by more then 1 person.  There is some thing that has changed with the sl walk and run animation priorities. Im in a sim were your not allowed Ao's in combat..so the weapon animation stances are at a priority that allows sl walk to over ride when moving, but i see everyone sliding now, and so do they.

[Qie Niangao]

You all haven't switched viewers, have you?  Because all animation is viewer-side; the server just plays a kind of middle-man role in spreading animation information among observers, and sending gentle hints about what animation an individual viewer's avatar should be playing for everybody else to see.

You're not all trying to use viewer-side AOs, right?

If you haven't already used it, there's a handy way to see in detail what animation your viewer thinks should be playing on your AV: Develop / Avatar / Animation Info.

[Perrie Juran]

I've been having this problem also. 

When I turn off my A/O I appear on my screen to 'slide' rather than walk.

Friends tell me that to them I am defaulting to the duck walk when I turn my A/O off.

So I think it is client side.

After a period of time I will see the duck walk again.

So my guess is that something is causing a slow response in the viewer, but it hasn't bothered me enough to mess with it.

[Helm Anton]

No it has nothing to do with the viewer.  4 different viewers tested now with same result.  I even uploaded some priority 1 stance animations and gave them to poeple with different veiwers...all with same result.  LL has changed the internal walk and run prioroties and left the internal 180 degree turn set high to over ride all.  I wish LL would announce such major changes as it effects everyone who makes animation in SL, and seeing its us animators who give sl  its LIFE then alittle communication would be nice.  Also who going to pay for all the animations that need to be redone now??? LL???

 

If sl walk and run priority is set to 0 then stands and stances can be set to 1 , walks to Pri 2, sits to Pri 3 and pri 4 for any other objects animation to over ride active AO's.  pity its come so late with so many creators already set the animations to over ride sl walk and run when it was set to pri 2-3.

 

Can someone from LL please confirm this priority change.

[Cerise Sorbet]

It most likely is a viewer change, the stock animations are stored in files shipped with the viewer and not fetched from the server.  There is a debug setting, UseNewWalkRun, you can try. This tells the viewer to use the new V2 or old V1 walk and run assets. Switch this to FALSE and see if your old objects revert to their old behavior, then you may have a better idea where the trouble is happening.

[Helm Anton]

Cerise i owe you one.  That was the problem, i had no idea there was another set of internal anims with lower Priority.  Ty HEAPS!!

[Phil Deakins]

Well... even though your problem has a solution, I disagree that the priorities have been changed. I use LL's current V3 and my AO, and the AO walk overrides the default walk. In fact I don't see the sliding effect that you describe at all. I have seen it briefly from time to time but it's always been to do with the failure to receive data and nothing to do with LL changing the priorities.

The fact that I use the current V3 and see no such problem means that LL has not changed the default priorities, and all those animations you mentioned do not need to be changed. In fact, I don't see how changing the default anims to a higher priority would cause sliding anyway. It would simply mean that the default anims get used more often. Not sliding.

[Helm Anton]

Well there are two sets of internal animations now.  The new set is the defualt set, it will not over ride even priority 1 animations, therefore they are at priority  0.  if you have a stance or stand thats set to prioroty 2 or 3 and you try to walk you will slide locked in that pose, as the sl defualt walk (the new one) is a lower priority..therefore is over riden by the pri 2 or 3 stance, just as a walk in an AO is set to priority 3 and the stands to priority 2 or you wouldnt walk. (the new viewer walk and run is also more animated than the older ones..no more duck walk).

The older versions of the SL walk and run are set at a highier priority (3 ), there fore they will over ride a stance or pose set to Pri 2 or 3 allowing you to walk and not slide when you move (Im not talking about AO's here).

 

Your right about not needing priority change as its a new set of animations with lower priority that was the issue , but with these two options you can control what priority sl walks and runs you use to suit.  if you dont want any sl walk to over ride any animation then use the new set, if you need the sl walks runs to over ride a pose or stance then use the older set.

[Phil Deakins]

I read about the two sets of default anims a few posts up. I hadn't heard of it before. So I've just switched to each set and neither affects my AO's walk. If it's a widespread problem, I'm very surprised that we haven't heard anything about it here until your post. How long has it been happening to you?

---

Helm Anton wrote:

Well there are two sets of internal animations now.  The new set is the defualt set, it will not over ride even priority 1 animations, therefore they are at priority  0. 

if you have a stance or stand thats set to prioroty 2 or 3 and you try to walk you will slide locked in that pose, as the sl defualt walk (the new one) is a lower priority..therefore is over riden by the pri 2 or 3 stance

, just as a walk in an AO is set to priority 3 and the stands to priority 2 or you wouldnt walk. (the new viewer walk and run is also more animated than the older ones..no more duck walk).

The older versions of the SL walk and run are set at a highier priority (3 ), there fore they will over ride a stance or pose set to Pri 2 or 3 allowing you to walk and not slide when you move (Im not talking about AO's here).

---

That's not true. What you're saying is that, to change animations, you must start a higher, or perhaps equal, priority one than the one you are in. If that were true, you'd soon run out of animations that can be started. Once a priority 4 is started, you're stuck with 4s or slide, and that's not the way it works.

In your example, when you're standing, you are in stand animation - its priority doesn't matter. When you start to walk, the system knows (from your keypresses) to stop that stand animation and start a walk animation. The priority of the previous (stand) animation is irrelevant, so its priority can't cause you to slide in it. Whatever is causing your slides, it can't be the higher priority of the previous stand animation. The system isn't such that only starting a higher or equal priority animation can stop the previous one, or once you'd started a priority 4 animation, you'd have to relog to do anything other than 4s. 

[Helm Anton]

Yes you are right in what your saying about stands walks in AO's.  What im saying is the reason the walks are set to Pri 3 were to over ride the OLD sl walk animation, if you walked with pri 2 you had sl walk interferring....now with the new set thats not an issue and walks could be set to pri 1 if you use the new sl walk run animations.  The slides have nothing to do with Ao's as i said earlier.  They are to do with weapon stances run by scripts in the weapons.  With the new anims you slide in stance, with the old ones you dont, problem solved.

[Qie Niangao]

Ahem. It's not actually necessary to speculate about these things when there are real, knowable facts readily available. Turn on animation info (as I mentioned above) and watch what happens.

When the new system walk is working normally, what plays are built-in animations "walk_new" with priority 0, and "walk_adjust" with priority 2.

With UseNewWalkRun turned off, the walking animations are "walk" with priority 0, and "walk_adjust" with priority 2. (Granted, these are the old animations within the new viewer, but we can be pretty sure that the walk anim has always been priority 0. See this very old lslwiki page for reference.)

So there has not been a change in priority with the new walking animations.

If not animation priority, then what? Unfortunately, for that, I can do no better than speculate. Maybe somebody can test these, or actually knows the answer.

 

• Could be that the old and new walks lock different joints, thus differently interfering with some funky, antediluvian, 0-priority weapon anim. (Seems very unlikely to me.) (Incidentally, do we actually have evidence that switching back to the old walk anim cures this problem? If not, can we put this old/new system anim thing aside until there's some reason to think it's relevant?)
• Could be that all that sliding is due to some change only incidentally related to animation. For example, the Lindens are constantly tweaking the delivery of scene rezzing data (textures, sculptmaps, mesh, parametric prim geometry, etc), trying to patch around the damage done by sculpties. All that data competes for bandwidth with animation.  I've certainly seen the viewer pipeline lock up long enough to slide around a bit while first rezzing into a sim; don't know if that's the same phenomenon as the OP's experience.
• Could be that something else has changed such that there are simply more animations trying to play at the same time. There's a limit of around a dozen, IIRC... I'm too lazy to look this up, and I've frankly forgotten what happens when the limit is reached, but I vaguely recall it being less than graceful. The fact that we're talking about weapons here--traditionally the worst scripting on the grid--leads me to suspect a scripter may not have been too fastidious about conserving animation slots.
• Could be something altogether different.  Obviously.

[Loki Eliot]

Greetings Programs, It's kinda strange that today i set out to research animation priorities for making animation & Pose overiding objects.

Instead i find the priorities are not doing what i expect them to do from info on SL Wiki. Then friends on Phoenix viewer say they are seeing correct resaults while i on the official LL viewer are not. 

Then i search the forum and find this thread.

So ive made a video to show that the UseNewWalkRun default Animation for Walk & Run has a different priority to what it used to be and will break content that relied on the old priority. Wether this is a mistake or intentional by LL has yet to be said.

http://twitvid.com/XLASK

note: Phoenix users do not see the new anims that replace the duck walk.

Jira on the issue 

[Helm Anton]

thanks for confirming that, what you see in your video is the same problem i and a heap of others were having.  i also got confirmation from a AO maker in sl that yes the priority has changed.  With the old walk and run the sl walk over ride his pri 2 stands, with the new walk theres no over ride, its a priority change pure and simple.  It has nothing to do with weapons scripts or anything else as the amimation stances will lock wether played in or out of a script with the new walks with Pri 0.  If the old sL walk pri was 0 then it wouldnt over ride a pri 3 stance, the fact that it does tells me its pri 3 reguardless of what anything else says or any info that states the old walk is pri 0 is simply inaccurate and proven false in practice....though it could be said that the hip and leg joints are set to pri 3 in the old walk as the upper portion of the av wont be animated when you walk..So more accurate to say the hip and leg joint pri has changed in the new walk.

 

As i said using the old walk fixes this locked in stance issue.  One other thing i did notice with all the testing ive done is that with the new walk pri 0..some stances or stands will lock all but 1 or 2 limbs when you try to walk so that limp is flapping about lol...not a good look, almost like joint pri over ride which is something i havent seen before and points more to the joint priority change.

 

Could we have the animation uploader updated so that we can set indervidual joint priorities please LL? .  that would be like xmas and would get rid of the fists to open palms bug too ...i hope ..

 

[Cerise Sorbet]

Hi, a few notes.

It is good to remember that for the built in animations, the prorities are set individually per joint. The "base" priority number we can see in the debug display is for reference only, it doesn't really tell the whole story and can in fact be completely different from the per joint settings. User created animations can use this per-joint system too, but it is extra work and not really documented, so rarely used.

Most animation overrider scripts actually stop the default walk before they run their own replacements, and for that reason most people won't see any problems if the default walk's per-joint priorities have changed. It will only present a problem in an edge case like in this thread, where a user animation has overlayed motions on the defaults.

[Cerise Sorbet]

---

Helm Anton wrote:

Could we have the animation uploader updated so that we can set indervidual joint priorities please LL?

.  that would be like xmas and would get rid of the fists to open palms bug too ...i hope

..

 

---

We can do this now, but the interface is poor, or maybe it's better to say that there is no interface. We can change per joint priorities with manual changes to app_settings/anim.ini  I am searching and failing to find good documentation for this file, except for the viewer source code. If I remember right, you just have to add a line, for example priority=4 to each joint section you want to change.

[Loki Eliot]

For me , I want to create an object that causes the user to stand in a mighty pose while holding a weapon in mighty way. When user walks the top half of the body remains in mighty pose while the legs use default walk then return to mighty pose when stop walking.. Now I'd have to add a load of extra scripting to get this to work. I t's all well and good noting how little this may effect the over all AO creators, but this is a change that has no reason yet effects what I and some others want to accomplish. What benefit has there been for the change if intended? If none? Then this is a bug that needs fixing, why? Because it presents a problem and breaks a system me and others have been using prior to now. So here we are being vocal about this issue in the hope LL will notice and fix it for us minority content creators :-)

[Helm Anton]

Thanx for your reply, Yes im aware there are ways of seting joint priorities through the source file, I also know you can set up to pri 6 through this code also, but there seems to be a reverse of any priority set above 4 back to 4...if you set to that pri 5 or 6 something in the sl code wont allow it and basicly your pri 4 wil over ride a animation youe set to 5 or 6 through changing the code line, though this is a good thing IMO, and i wont ever use it as i have no need to.  I will how ever try to set the hands to pri 4 to hold fists and see how that pans out.

personaly i think the animation options creators have in SL is awesome, but it could be top of the line allowing creators greater flexibility which only enhances peoples experience in SL

 

Thanx again for the info

[Helm Anton]

The only way I know to do that is to make your stance or animation and set to priority 2 or 3 ( i use 3 as 2 wasnt quite strong enough for me), use the old sl walk priorities.  Your stance or animation will play and when you walk the upper body will stay in animation while the lower half is animated by the sl walk

 

Thats how i do all mine for weapon stances.

[Qie Niangao]

I see the video: thanks, now I kind of get what's happening here, but there's a piece of this puzzle that I still can't make fit: In the Jira description, and as I've understood this thread throughout, there's such a recent onset of the problem: "in tha last week or less" per the jira, that was created only this past Thursday.

But AFAIK, the new walks were introduced in an early release of Viewer 2, well over a year ago, maybe two. If this is something that started happening in the past couple of weeks then I'd agree that it's an actual bug. If it's more like two years old, there's probably more content (unintentionally) dependent on it than there is broken by it.

And if it really is just a couple of weeks old, as described, I just don't understand how it can be due to the priority of animations (per joint or otherwise) that have been around for so long.

[Loki Eliot]

@Qie 

I totally understand, it's very strange. I only came across this issue because i decided to try and make a new weapon.

I wanted to have the weapon activate a brave standing pose. Setting brave standing pose to 0 results in being overidden by internal standing pose. Setting it at priority 1 resaults in brave standing pose overiding internal walk making the avatar slide along in the brave pose while trying to walk. 

So why has'nt anyone said anythign before now?