Walk animation not playing when gun attached

[Stephan Gaudio]

Hello, maybe somebody can help me. I built a gun. When attached, the script asks for permissions and then starts the "hold_R_handgun" animation. That is an internal linden animation and it is automatically replaced by "aim_r_handgun" in mouselock. Now while being in mouselock and walking around, the walk animation does not play anymore. The legs just don´t move while the avatar is moving. What did I do wrong and how can I fix this?

[Freya Mokusei]

Thank you Freya, but according to http://wiki.secondlife.com/wiki/Internal_Animations "aim_r_handgun" has priority 2 and the standard walk has priority 3 for pelvis and legs, 0 for everything else.

[Freya Mokusei]

I don't know at what point the failure is occuring; it could be that the Wiki is inaccurate, that the animation has been replaced (this happens occaisionally), or that the walk is still being suppressed by the aim animation for some other reason.

The reason for my suggestion was that by uploading these animations yourself, you can see AND control which body parts are affected by the animation. And uploading is the only way to see or change the animation's priority.

 

[Emma Krokus]

Perhaps this is an SL glitch?

It's happened to me where my upper body plays the animation but my legs remain static... - I was also using the same internal animation though it was to hold a lamp.

Emma

[Stephan Gaudio]

After further testing I have the strong impression, that this may be related to the Vista Animations HUD. It is turned off, but maybe doesn´t stop all related animations appropriatly when being turned off. When wearing a very basic standard avatar, there are no problems. Now another question. When uploading an animation, I can just set a global priority. Is it possible to set the priority just for specific body parts?

[Da5id Weatherwax]

---

Stephan Gaudio wrote:

...Is it possible to set the priority just for specific body parts?

---

Yes it is, but you will need to use a tool to make it that can export to the internal .anim format instead of .bvh and upload it using a viewer that can do so. This is a capability that many TPVs have had for a while, simply skipping the bvh to anim conversion when an anim format file was being processed through the bulk upload process. In the anim format priority is a per-bone property.

[Stephan Gaudio]

Thank you Da5id:)

[Stephan Gaudio]

OK, I did some further testing with 2 friends and I am pretty sure now that it is a problem with the Vista Animations HUD. When it is turned on, no gun animation is working, that is fine, but when it is turned off, the legs don´t move when walking around in mouselock. Maybe the script does not stop all AO animations when it is turned off. So when I detach the AO completly, the walk and gun animations work like they are supposed to.

[Medhue Simoni]

It's a bug. It started happening about 6 months ago to a year ago. This only happens when you use the default walk. If you use one of your own walks, or an AO walk with the right priorities than it won't happen. You can write a jira for it, but LL is very slow at fixing an animation bugs.

[Stephan Gaudio]

Thank you Medhue:) So I suppose I need to advise my customers to turn off and detach all AOs or deliver the gun with a complete own AO with higher priority. Writing a Jira won´t help. There are still open Jiras that I reported back in 2007;)

[Medhue Simoni]

---

Stephan Gaudio wrote:

Thank you Medhue:) So I suppose I need to advise my customers to turn off and detach all AOs or deliver the gun with a complete own AO with higher priority. Writing a Jira won´t help. There are still open Jiras that I reported back in 2007;)

---

Well, there is where SL has all kinds of issues, and it is truely sad. What makes SL even remotely viable is the standardization of everything. That's when the customer gets variety and choice, when the core is standardized and the artist can just sit back and be creative without worrying about compatibility issues. SL has the most amazing animation system created, but because of total neglect and lack of information or best practices, it has many problems.

Even if you didn't have this current bug to deal with, there would still be issues with holding something and AO. This is because the vast majority of AO creators either don't care about using the right priorities or they don't totally understand what priorities they should use. This is not to say all AO creators suck accept me, as even I have AOs where priorities aren't totally correct. Plus, for a turn to work correctly, it currently has to be priority 4, which will interfere with your hold also. So no AO, except made by you, can possibly work correctly. The biggest concern, of course, are the walks and runs. These should always be priority 3. There was also over a year where all walks and runs had to be priority 4, because of LL changing the defaults, which apparently did not have the right priorities. This is why I have AOs with walks and runs being priority 4. I just haven't gotten around to correcting them, and no1 has complained. Probably cause they don't understand the problem.

As far as getting the bug fixed, I think the only way this is ever going to happen, is if some1 spends their time to hold LL's hand and pester the lindens every single chance they can. You basically have to goto every single User Group Meeting and keep bringing the problem up and pointing Lindens to the jira. Unless you are winning to constantly hound them, the jira will never be addressed. Let me know if you plan on hounding LL, as I have a list of animation bugs that could be brought up, lol.

[Stephan Gaudio]

Thx Medhue! I just read that the Lindens are planning script-less AOs. Maybe they take the chance and also fix some other issues around animations now.

[Medhue Simoni]

Don't count on it! It's likely they will simple copy the firestorm AO code.

[Dz Delicioso]

The new AO functions only seem to give you the option to set a default animation that will be used for each of the animation states...   This IS NOT a functional AO replacement..  There is no way to specify a sequence of stands.  Some posters have claimed that it will also solve the problem of animation stutters ( as the wrong animation starts and THEN the one you want).

Being able to set a new default stand will not solve this problem..  Everytime you want to change stands  you will need to set a new default, and without the ability to "force" the new stand animation into cache before it is started,  the stutters will continue.   This new solution will also NOT provide the ability to combine animations  that has been a standard feature in AOs  since ZHAO-II.   An additional script will still be required to start the second animation over the base.