Calling All Animators!!! Vote/Watch this Turning Animation Jira bug

[Medhue Simoni]

I've known that this bug existed for years now, but I always hate dealing with jira issues and waiting for any activity at all, especially for animation issues. This issue tho, should be an easy fix. Oz just showed some activity on the Hands Spread bug, so maybe we can get this issue fixed quickly.

Basically, the issue is that the default turning animations' priorities are too high. They can ONLY be overriden totally by a priority 4 animation. This causes issues whenever some1 holds something and is using an AO with turn animations. Both animations will likely use priority 4 animations, and the turn will always override the hold animation, as it is triggered when needed.

The proper priority for a turning animation would be a priority 3, just like walks and runs. This would allow a cup or drink creator to use a priority 4 animation for their hold animation, and it all should work correctly. Of course, some creators have resorted to using script to continuously play the hold animation over and over, but this causes more lag issues and is unneccessary if the proper animation priorities are applied. Also, the script fix is not full proof unless the timer on the script is really low, which causes even more lag. Imagine a whole sim full of people holding a simple cup, or a flag, or whatever.

 

Here is the jira, please watch it. https://jira.secondlife.com/browse/BUG-3864

[Medhue Simoni]

I've known that this bug existed for years now, but I always hate dealing with jira issues and waiting for any activity at all, especially for animation issues. This issue tho, should be an easy fix. Oz just showed some activity on the Hands Spread bug, so maybe we can get this issue fixed quickly.

Basically, the issue is that the default turning animations' priorities are too high. They can ONLY be overriden totally by a priority 4 animation. This causes issues whenever some1 holds something and is using an AO with turn animations. Both animations will likely use priority 4 animations, and the turn will always override the hold animation, as it is triggered when needed.

The proper priority for a turning animation would be a priority 3, just like walks and runs. This would allow a cup or drink creator to use a priority 4 animation for their hold animation, and it all should work correctly. Of course, some creators have resorted to using script to continuously play the hold animation over and over, but this causes more lag issues and is unneccessary if the proper animation priorities are applied. Also, the script fix is not full proof unless the timer on the script is really low, which causes even more lag. Imagine a whole sim full of people holding a simple cup, or a flag, or whatever.

 

Here is the jira, please watch it. https://jira.secondlife.com/browse/BUG-3864

[Pamela Galli]

I have dealt witht his bug, too -- we are blocked frommseeing the JIRA,,tho.

[Trinity Yazimoto]

---

Pamela Galli wrote:

I have dealt witht his bug, too --

we are blocked frommseeing the JIRA,,tho.

---

And its pretty unpleasant to be accused to try to violate smth everytime we try to open a jira.. they could simply say its not availble for us instead of having this big message saying we are trying to make some violation !

[Medhue Simoni]

FUDGE!!! I forgot!

[Medhue Simoni]

Since no1 can see the jira, I will give a report.

I got 2 sessions of Meastro and I going back and forth. He tests and can't reproduce. I make another suggestion, and give him my animation. He tests, and can't reproduce, but this time he gives me a simple script to test with. The thing is, he closed the jira.

So, I test my turning animation with his script. Before, I was testing it inside my AO system and the ZHAO II. I test this new set up, and it works, but I still see some strangeness. Meastro mentions that maybe the AO systems are overriding the turns in a different way. Of course, I know my AO system does things in different ways, but I don't see why it matters. My AO system overrides the turns by sensing when you rotate, instead of overriding the default. This is actually a much better way to override the turns, as the animation kicks in instantly, instead of delayed like the default. The way my AO does it, I also get fly turns and swim turns. Again tho, this should not matter if my turn animation is a higher priority than the default.

After scratching my head for a bit, I turn on the animation display thing that shows which animations are playing. I turn and notice that actually 2 default animations are played when you turn. 1 is the turn left or right default, and the other is the walk_adjust default animation, which is said to be a priority 2. Ok, now things are starting to make sense. The weird thing is, if you override the actual default turn, the walk_adjust animation doesn't play. With my system not directly overriding the turns, but simply playing animations overtop of them, the default walk_adjust will still play.

My conclusion is that the default walk_adjust animation has a priority problem. I did a test where I only overrided the walk_adjust with my priority 3 animation, and the default walk_adjust still bled thru. This means the walk_adjust was the problem the whole time.

Like I said, Meastro closed the jira, so I was not even able to comment on the jira to tell him what I found. That said, I was able to add an image to the jira, which allowed me to post a comment with the image. I don't know if LL will reopen the jira tho, or if I should open another jira. See tho, despite Meastro doing what he can, this is sooooo much fricken work for me. lol