What kind of AO do the system avatars have?

[Prokofy Neva]

So I read this article and several like it and I grasp that animations have classifications like "Priority 3" and "Priority 4". Some advertise that they have this feature, or can work with this feature.

So I got a set of animations that involve holding a teacup in two hands, looking at it, then drinking from it which has the description "Priority 3" and "Priority 4". I also have the basic "sip script" and sipping animations. And another "bento hands" kind of drink animation.

I made various things and I realize that if an avatar has an AO on, some of the things don't work. They could take off their AO. But you can't expect everyone to do that or know how to do that.

I find that some items -- the free "Sip 2.0" is one of them but also some more complicated ones - simply don't work with the stock avatar that you can choose from the library, unless you take off the AO.

What's odd is that the animation marked Priority 3 and 4 still doesn't work with the system avatar, although it works with other 3rd party AOs.

Why is that? How can it be fixed? Yes, I can contact the makers. But I also want to understand just what kind of AO the avatar has from the library, and why it doesn't work.

[Profaitchikenz Haiku]

As far as I know the system avatar doesn't have an AO to itself, it uses whatever you are wearing. If this is in the library, then once you have copied it from the library to your inventory folder it becomes another editable item (see final paragraph).

There are quite a few reasons for a pose to not work, you've found the main one, if an AO has a pose affecting the same joints but a higher priority then you won't see any change.

Secondly, if the animation is for some of the extra bones that bento introduced, you won't see any activity unless you have a suitable avatar. As far as I know (and I'm still a system avatar myself) this means I would need to get a mesh body with the bento rigging.

For facial expressions, which use built-in animations, bento heads will not animate. There are some AOs on the marketplace that monitor the animations currently playing on the avatar and start or stop a suitable bento one to replicate the facial expression that the system avatar is performing behind that alpha mask.

Back to the AO and animation priorities. Wear the particular AO, and edit it. Look in the contents tab, and you will expect to see masses of animations, a script (or two...) and a notecard giving the basic settings. Copy the notecard to your inventory and then look inside it. You should be able to find lists of animations to be played when the avatar is in various different states. Assuming your AO allows it, you can copy new animations to the contents and then alter the notecard so that these animations are played instead of other ones. By this method you might be able to substitute lower-priority animations and be able to take tea without having to divest yourself of your AO.

[Sabrina Tamerlane]

They should not need to take off their AOs, normally it should have an off button. At any time you can view what are the animations running by turning on the Animation info like so:

Also, the anim format has a global priority and a priority per bone which I have not experimented.

 

[OptimoMaximo]

28 minutes ago, Sabrina Tamerlane said:

Also, the anim format has a global priority and a priority per bone which I have not experimented

I assure you that per bone priority works for a single fact: there is no global priority in an animation. All joints in the list need to carry their own priority in order for the system to accept the animation, what the bvh uploader in the viewer and other external tools do is to set a priority that is being applied to all joints, regardless. That is how a global value is being set in the software to simplify the process of creating general purpose animations. 

Back to the OP question, what they're seeing is the result of the animation priority war i mentioned a few days ago in another thread. People produce animations with the intent of stopping other makers animation with the idea of their work being the protagonist, forgetting the principle behind content creation for a platform that allows and encourages customization. 

[Sabrina Tamerlane]

7 minutes ago, OptimoMaximo said:

I assure you that per bone priority works for a single fact: there is no global priority in an animation. All joints in the list need to carry their own priority in order for the system to accept the animation, what the bvh uploader in the viewer and other external tools do is to set a priority that is being applied to all joints, regardless. That is how a global value is being set in the software to simplify the process of creating general purpose animations. 

Back to the OP question, what they're seeing is the result of the animation priority war i mentioned a few days ago in another thread. People produce animations with the intent of stopping other makers animation with the idea of their work being the protagonist, forgetting the principle behind content creation for a platform that allows and encourages customization. 

This is an anim file, in red you can see the global priority, in orange the priority of a bone. I set them to be the same but definitely both exist, it's not only a BVH thing.

 

[OptimoMaximo]

3 minutes ago, Sabrina Tamerlane said:

This is an anim file, in red you can see the global priority, in orange the priority of a bone. I set them to be the same but definitely both exist, it's not only a BVH thing.

 

Yes, that is one of the things that were added in the header for the 1.0 version, when bvh uploads were introduced and euler angles were abandoned in favor of quaternions. To simplify the process, that was a value that got written at the beginning and copy pasted directly to all joints, since there was no way to supply such control in a easy and quick to operate manner (on the user end). Try to output an anim file omitting the per joint priority, and it won't work,as opposed to what a global variable is meant to provide by being global in the first place. You can override it locally but if not, the global should be the referenced value in the whole scope , that's what a global variable is for... But here it's not like that, it's a convenience feature to patch up the new version. If you're interested in the topic, read the docs about the 0.1 version, that is one of the introduced changes... I guess you know where to find it already as you developed your own exporter 😁

[Nalates Urriah]

@Prokofy Neva   

Its been a bit since I dove into animation tech. Classification is a term I think of as being applied to how the default animation system would see the animation. So, WALK, SIT, etc.

Priority isn’t what I would call a classification. The priorities are so that one doesn’t have to take off an AO for teacup holding animation to work. If an AO conflicts with an animation then the priorities of the individual animations are out of whack.

To make this easier for users some animators make animations in Priority 3 to work within in AOs and allow them to be overridden. They make the same animations in priority 4 so they won’t be overridden or will override. However, as I recall animations uploaded as ANIM rather than BVH can have higher priorities. So, it is possible for priority 4 animations to be overridden.

As pointed out, Bento has created new bones that can be animated. The Classic avatar does not have wings, hind legs, or a tail. Animations for those will not show movement on a Classic avatar without attachments.

A bunch of new bones were added to the face and ‘classic’ body. But Classic facial expressions are NOT animations as we are talking animation. They derive from a morph system, which does change the facial expression and can be used for some animation but, the two systems are very different. The morph system is parametric and does not require an animation file. Also, the Classic face does not use the new bones. Animations using the new bones will not affect the Classic face.

There is also the problem of AO conflicts between new and older style AO's. I find mixing the two can stall both and confuses the system. The avatar often skates rather than walking. Firestorm's built-in AO is particularly sensitive to having another AO attached.

On 10/17/2020 at 12:10 AM, Prokofy Neva said:

What's odd is that the animation marked Priority 3 and 4 still doesn't work with the system avatar, although it works with other 3rd party AOs.

That sentence is confusing. An avatar and an AO are very different… which I know you know… so I assume you mean priority 3 and 4 animations you have don’t work with your avatar but other AOs with priority 3 and 4 animations do work? Yes, no?

As others have said, this may be a thing in the individual animation because of which bones they chose to animate.

If you mean the same animation doesn’t work on the avatar (play animation) but if placed in an AO it does… then something else is going on. I would need more info to explain it. So, if the animation works in any one case then the animation works. The problem is elsewhere.

[Prokofy Neva]

On 10/29/2020 at 2:30 PM, Nalates Urriah said:

@Prokofy Neva   

Its been a bit since I dove into animation tech. Classification is a term I think of as being applied to how the default animation system would see the animation. So, WALK, SIT, etc.

Priority isn’t what I would call a classification. The priorities are so that one doesn’t have to take off an AO for teacup holding animation to work. If an AO conflicts with an animation then the priorities of the individual animations are out of whack.

To make this easier for users some animators make animations in Priority 3 to work within in AOs and allow them to be overridden. They make the same animations in priority 4 so they won’t be overridden or will override. However, as I recall animations uploaded as ANIM rather than BVH can have higher priorities. So, it is possible for priority 4 animations to be overridden.

As pointed out, Bento has created new bones that can be animated. The Classic avatar does not have wings, hind legs, or a tail. Animations for those will not show movement on a Classic avatar without attachments.

A bunch of new bones were added to the face and ‘classic’ body. But Classic facial expressions are NOT animations as we are talking animation. They derive from a morph system, which does change the facial expression and can be used for some animation but, the two systems are very different. The morph system is parametric and does not require an animation file. Also, the Classic face does not use the new bones. Animations using the new bones will not affect the Classic face.

There is also the problem of AO conflicts between new and older style AO's. I find mixing the two can stall both and confuses the system. The avatar often skates rather than walking. Firestorm's built-in AO is particularly sensitive to having another AO attached.

That sentence is confusing. An avatar and an AO are very different… which I know you know… so I assume you mean priority 3 and 4 animations you have don’t work with your avatar but other AOs with priority 3 and 4 animations do work? Yes, no?

As others have said, this may be a thing in the individual animation because of which bones they chose to animate.

If you mean the same animation doesn’t work on the avatar (play animation) but if placed in an AO it does… then something else is going on. I would need more info to explain it. So, if the animation works in any one case then the animation works. The problem is elsewhere.

It's a simple matter. I have a coffee pot and cups with temp attach scripts that work on system avatars with no AOs, but also avatars who have various store-bought AOs. So these cups have sip animations of course.

The problem is that the avatars in the library, when they get the cup, do nothing. The animation doesn't work on them. The cup goes in their hand, but flops to the side -- they don't sip and go up and down. They have to take off their library AO for it to work.

I have tested this with various alts and friends. There are some new bento animations that have priority 3 and 4 advertised that are work regardless of whether you have a resident-made AO. But again, the library system avatars and their AOs do not work with these cups. I have tried different kind of attachment scripts and different animations -- it doesn't work on them. I'm on the regular viewer as are my alts of course, but I also had friends try who are on Firestorm.

So my question was: what is the AO on the system avatars, what brand, what type, with what features, such that it won't work with an animation that claims it can override AOs (and does with other non-library AOs).

Edited November 1, 2020 by Prokofy Neva

[Rowan Amore]

10 minutes ago, Prokofy Neva said:

It's a simple matter. I have a coffee pot and cups with temp attach scripts that work on system avatars with no AOs, but also avatars who have various store-bought AOs. So these cups have sip animations of course.

The problem is that the avatars in the library, when they get the cup, do nothing. The animation doesn't work on them. The cup goes in their hand, but flops to the side -- they don't sip and go up and down. They have to take off their library AO for it to work.

I have tested this with various alts and friends. There are some new bento animations that have priority 3 and 4 advertised that are work regardless of whether you have a resident-made AO. But again, the library system avatars and their AOs do not work with these cups. I have tried different kind of attachment scripts and different animations -- it doesn't work on them. I'm on the regular viewer as are my alts of course, but I also had friends try who are on Firestorm.

So my question was: what is the AO on the system avatars, what brand, what type, with what features, such that it won't work with an animation that claims it can override AOs (and does with other non-library AOs).

Pull one out of your library and see what's going on with it?

[Prokofy Neva]

3 hours ago, RowanMinx said:

Pull one out of your library and see what's going on with it?

I don't see how that is helpful. The AO's are made by a Linden. There is no way to look inside of them like a script. It is what it is.

[Mollymews]

by observing it seems

- the Linden newbie AO stand animations appear to be Priority 3

- the AO scripted animations overriding the standard animations

when we play a Priority 3 sipping animation and then the AO replays a Priority 3 stand animation over the top of our sipping animation, the later played animation takes control when animations have the same priority

the solution is to use Priority 4 sipping/holding animations as when a Priority 4 animation and a Priority 3 animation are playing simultaneously the Priority 4 animation retains control of the bone(s)