Issue with single hand animations being stomped on by turning or bumping

[Aviewer Alpha]

I've been playing with creating a animation that involves the right arm... basically only rShldr rForeArm rHand and the finger. I've tried creating this pose in anypose via BHV export as well as black dragon creator via ANIM export. I'm able to export this pose and import it again no issue but my AO seems to stop the animation playing temporarily while I turn or get bumped. I once I stand still again it starts on it's own and keeps going. I know I've seen other peoples poses that don't do this and I've even tried testing their no mod scripts forcing it to run my animation to confirm it's not a scripting problem. I feel like I'm missing something basic like some point/keyframe I need to include or something like that... MY AO, and very specifically it's turn, is priority 4. I've confirmed this with animation explorer in firestorm.... I've also tried uploading my animation as 4, 5, and even 6 and still see the same issue(Yes I know not to use 6 or etcetera it was for testing). I'm a bit at a loss... anything basic I'm missing?

Edited October 12, 2023 by Aviewer Alpha

[NiranV Dean]

Nothing you can do about that sadly. The Viewer treats priority 5,6,7 as 4 and animations with priority 4 that come AFTER will overwrite it. Something i might want to look into and fix.

[TomeoVe]

6 hours ago, NiranV Dean said:

The Viewer treats priority 5,6,7 as 4 and animations with priority 4 that come AFTER will overwrite it. Something i might want to look into and fix.

I'm not experiencing this.  Priority 4, 5 and 6 are distinct and operate as expected, they are not performing as a single priority (4).

I'm using Bento Buddy to export my animations, with the above priorities.

If I play a priority 4 and then a 5, the 5 does play.
If I play a priority 5 and then a 4 the 4 does not play.

The same combination with 6 and the others.

Using turn, walk, fly etc. do not appear to interfere with my above priorities.

Maybe I misunderstood what the issue is, I wouldn't mind being enlightened.

[Aviewer Alpha]

I suspect that can't be the issue. Other createra animations play correctly even when turning in the same viewer.

[CandySwirl76]

Hi Aviewer, It might just be the tools you're using that lack some functionality. We're able to make those work flawlessly with Bento Buddy. Those animation priority numbers are respected and do not get interpreted as all priority 4's above 4.

7 hours ago, NiranV Dean said:

Nothing you can do about that sadly. The Viewer treats priority 5,6,7 as 4 and animations with priority 4 that come AFTER will overwrite it. Something i might want to look into and fix.

I don't think priority level 7 exists, unless I missed something, Or if it exists somewhere it must've been
"hacked" in and don't register right... ^___^"

Edited October 14, 2023 by CandySwirl76
forgot something

[NiranV Dean]

According to the Viewer code it goes up to 7, technically 5 and 6 don't exist. They aren't defined, although since 7 is defined as the last they technically exist, just not specifically defined in the list (they are still automatically counted though). 5,6,7 are all overtaken by Priority 4 in an AO maybe i should have clarified that, playing a priority 6 does overwrite 4 and doesn't allow it to take over the 6, however using these in an AO does seem to be buggy.

Even my Poser which uses ADDITIVE_PRIORITY (7) is still overwritten by some cheeky face posing HUDs.

 

Edited October 14, 2023 by NiranV Dean

[Wulfie Reanimator]

3 hours ago, NiranV Dean said:

According to the Viewer code it goes up to 7, technically 5 and 6 don't exist. They aren't defined, although since 7 is defined as the last they technically exist, just not specifically defined in the list (they are still automatically counted though). 5,6,7 are all overtaken by Priority 4 in an AO maybe i should have clarified that, playing a priority 6 does overwrite 4 and doesn't allow it to take over the 6, however using these in an AO does seem to be buggy.

Even my Poser which uses ADDITIVE_PRIORITY (7) is still overwritten by some cheeky face posing HUDs.

 

They may not be defined explicitly, but the viewer (Firestorm at least) does respect priorities higher than 4 by allowing them to play even if new P4 animations start afterwards.

Edited October 15, 2023 by Wulfie Reanimator

[NiranV Dean]

11 hours ago, Wulfie Reanimator said:

They may not be defined explicitly, but the viewer (Firestorm at least) does respect priorities higher than 4 by allowing them to play even if new P4 animations start afterwards.

Again this doesn't seem to be the case when used in AO's. I have a particular case where my running and turning animations overwrite priority 5,6,7. Everything else however doesn't. I'm using a serverside AO. All animations are priority 4, standing too and they do not overwrite them. It seems very particular.

[BinBash]

Like any large code based project there are bits of code that never get called, disabled code and code that never was even implemented in the first place.  I'm sure there are methods to remove the clutter but I'm a programmer, among many other things, and don't find it useful these days to clean up unused code and often that same code serves as a reference so it can be helpful to myself, and others, to leave it in.

I suspect that the above is true for the official viewer code, which I happen to grab a copy of frequently, and I find myself in areas of the code that appear to be like others that I've worked with, which happens in my own projects as well, and I'll find my self scratching my head when my changes don't take effect, only to become aware that I've been editing the wrong section or file.  This can also happen when I'm searching for a bug, find it, but are unable to affect any change since I'm in the wrong section.

Speaking of "wrong sections" this looks like the old BVH code, addressing the usable 4 priorities.

I think everyone here is aware that the ".anim" (which LL are referring to as "internal animation format") file doesn't have a single priority, this header reference is just that, information.  Each joint has its own priority and how an application creates these priorities may be different from each other.  In the case of Bento Buddy we make a single priority most notable, in the exporter, and below that there are tools to alter each joint animation priority, of which all will contain the same one found in the animation exporter.  In this particular case the default export priority is always used unless the joint has the "override" flag on it, set in this special "joint priority" section.

Unless some code has been added to the viewer I suspect that, as always, one cannot determine the animation priority of any joint and, in fact, I can set the default priority to 0 and all joints to 6, and you'll probably be just as confused as the OP, and that other guy.

[Aviewer Alpha]

Are joint priorities actually stored in the text of a bvh then?

[Quarrel Kukulcan]

2 hours ago, Aviewer Alpha said:

Are joint priorities actually stored in the text of a bvh then?

BVH exports don't store any priorities or looping data. That's why you have to enter such information on the SL import panel.

[NiranV Dean]

On 10/16/2023 at 1:34 PM, BinBash said:

Like any large code based project there are bits of code that never get called, disabled code and code that never was even implemented in the first place.  I'm sure there are methods to remove the clutter but I'm a programmer, among many other things, and don't find it useful these days to clean up unused code and often that same code serves as a reference so it can be helpful to myself, and others, to leave it in.

I suspect that the above is true for the official viewer code, which I happen to grab a copy of frequently, and I find myself in areas of the code that appear to be like others that I've worked with, which happens in my own projects as well, and I'll find my self scratching my head when my changes don't take effect, only to become aware that I've been editing the wrong section or file.  This can also happen when I'm searching for a bug, find it, but are unable to affect any change since I'm in the wrong section.

Speaking of "wrong sections" this looks like the old BVH code, addressing the usable 4 priorities.

I think everyone here is aware that the ".anim" (which LL are referring to as "internal animation format") file doesn't have a single priority, this header reference is just that, information.  Each joint has its own priority and how an application creates these priorities may be different from each other.  In the case of Bento Buddy we make a single priority most notable, in the exporter, and below that there are tools to alter each joint animation priority, of which all will contain the same one found in the animation exporter.  In this particular case the default export priority is always used unless the joint has the "override" flag on it, set in this special "joint priority" section.

Unless some code has been added to the viewer I suspect that, as always, one cannot determine the animation priority of any joint and, in fact, I can set the default priority to 0 and all joints to 6, and you'll probably be just as confused as the OP, and that other guy.

 

On 10/22/2023 at 8:56 PM, Quarrel Kukulcan said:

BVH exports don't store any priorities or looping data. That's why you have to enter such information on the SL import panel.

Interesting, i suppose this answers a couple of my questions i could never figure out about both BVH and ANIM both which are incredibly undocumented in SL.

So what i get from this: Yes, bone priorities actually work (good to know so i'll add it to my animator) AND BVH not writing any of the crucial animation information explains the upload dialog, tho in my Viewer .ANIM has the upload dialog now too, to allow changing any value before upload. Though this does not explain why my Poser animation is overwritten by a select few face pose HUD's since the animation is created internally with priority 7 which simply shares its priority down to all bones automatically.