Detach animated obj = stop ALL animations?

[Pamela Galli]

For four years I have used two animations at once in my dining sets -- the chair has a dining conversation animation in progress when a glass of wine (or whatever) is worn, and the second animation overrides the right arm movement of the sit animation.

However I am making a new dinner set and find that this no longer works. If I detach the wine glass, the avi suddenly pops up out of the chair and floats frozen in a sitting position above it.  Also if I do not detach but wear something else instead, same thing. 

It does not matter if my AO is on or off. 

 

Now, this is not consistent -- about one time in four, the object detaches or is replaced and the avi continues to sit in the chair.

 

Does anyone have any clue what is happening or can anyone point me to someone who might?

[Innula Zenovka]

What's different this time from the previous times you've done this?   Drinking and/or sitting animations? Script in chair?  Script in glass?

[Pamela Galli]

---

Innula Zenovka wrote:

What's different this time from the previous times you've done this?   Drinking and/or sitting animations? Script in chair?  Script in glass?

---

That's just it -- nothing is different. I have used the same animation and script in the food with the same chair animation with three different scripts.  Never had this happen before.

[Innula Zenovka]

That's really odd.     I can speculate about what might be causing it,  though not about why it's suddenly started to happen, but without knowing more about the scripts and the animations concerned it would just be guesswork.     I'll gladly take a look at the scripts in-world if you would like, and see if there's anything that jumps out at me.   

[Pamela Galli]

Innula that is very very kind of you. I will send a chair and wine glass to you.

 

 I can only conclude this is a new bug. I just tried this with an older chair and wine glass, with the same results. If so, until this is fixed not only is 4 weeks of work down the drain but 3/4 of a sim filled with dining sets. 

[Pamela Galli]

Update: Innula could reproduce but not as frequently, so that made me hopeful. I made a bug report.

[Pamela Galli]

My bug report already got an inquiry from Whirly, asking me to try the Viewer 3 (I am on Firestorm). Almost the same effect, on this time the pop up came not on detach but on reattach. 

 

BTW -- I have 68 dining sets listed on the slm. Almost an entire sim full of them.

[Pamela Galli]

Maestro has reproduced the effect or some variation of it, with other animations, which fail to behave as expected 50% of the time for him. The bug priority is Major.

[Medhue Simoni]

I can only add that I started seeing this about a year ago, but I can't say exactly when. It was never a big issue for me so I didn't pay much attention to it.

[Pamela Galli]

Maestro said 50% of the time when he tried running and shooting at the same time today, it failed. Whirly saw it  fail 70%, which is about what I saw. Innula though only saw it 10%. 

 

Although you can't read the bug report Whirly has added a JIRA on the Firestorm site.  
   [ https://jira.secondlife.com/browse/BUG-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=346258#comment-346258 ] 

 

 

[Medhue Simoni]

First, I must say how completely ridiculous it is that we can't see the bug report.

Earlier today, I was talking with a customer that has purchased gun animations from me and he told me that his team decide to not use the shooting animation, as it failed at times. They just use the aim animation, without the shoot anim. I've made my own combat system using the exact same animations, and the last I checked, it worked flawlessly. When I had the conversation with the customer today, I didn't think much about it other than something went wrong with how they were doing things. I'm going to go inworld now and test out my system to see if anything like this happens.

I also wonder if it is the long running animation bug that adds T frames to the beginning of animations that is causing things to fail. Then again tho, I don't know why I'm bringing this up as LL won't fix the Tframe bug, and I can't even read or help with this current bug.

[Medhue Simoni]

Ok, I ran some tests on a bunch of different kinds of products. These were just preliminary tests, but I did notice some things.

First, I saw no problems at all with my guns and the interaction of all the different animations that make the gun work. When sitting in an animated chair, and then detaching and attaching the gun over and over again, I rarely had the sit animation fail. This was like 1 in every 10. The chair has a number of sit animations in it, so I tried it all on quite a few. Some failed maybe slightly more than others, but it was still rare. I never ended up floating above the chair when it did fail. This could be because of my default sit position in the script, which is only slightly sitting back in the chair.

2nd, I tried some different animated foods in that same chair. Again, the failures were rare.

3rd, I tried the foods in an animated sit ball. With the gun, again very rare. Then, I tried an animated beer bottle. On this 1, I never had a failure, but the beer bottle holding animation would continue to play after I detached it, and this happened most of the time.

Ok, so based on all this, what do I think is happening, or what could be causing the inconsistencies? I don't have a clue, lol. Well, I can guess, since every animation was made by me. I would guess that the length of the sit animation has something to do with how often it fails. I don't make single frame poses. If some1 is using a single frame pose, then that would mean the pose is looping extremely quickly, which could be why those fail much more often. I definitely think the animation length has alot to do with how often the sit fails. I would guess that the failure is occuring exactly when the animation loops. This would be why a single frame looping sit pose would fail 70%, while mine only fail 10% of the time or less.

Some other things that I do probably different than most, is in my attached foods or guns, I only animated the part that needs animating. I would suspect that if you animated the whole body, for both the sit and the attachment, then it might fail more often. I suspect this as when I attach something, most of the body is still being animated by the sit, not the attachment. The attachment only animated the arm and sometimes the head.

I would really need to do a proper test, with all brand new animations of different lengths and animated parts to really know if I'm on the right path. Like I said tho, this was just a quick set of test with chairs and attachments that I already had. I think the beer bottle animation continuing to play was weird and should not happen, but I want to look at the coding to see if a stop animation function is in there or not, and how that affects it all.

As far as the guns and shooting animations, I saw no problems. I will talk with my weapons customer tomorrow morning and I'll flush out if any of his problems are related.

[Qie Niangao]

I don't think it's especially caused by any properties of the animation in the attachment. It happens when the attachment pushes a priority 4 single-frame looped anim of my own contrivance, or a priority 0 built-in "stand" animation. (FWIW, the sit I was testing with was my own priority 3 single-framed looped anim.)

So far, I've only been able to trigger it when adding the attachment, not when removing it. I agree that it's frustratingly intermittent. The seemingly identical conditions will trigger it maybe every other attempt for a while, then not again for ten attempts, so any pattern is hard to discern.

As far as I can tell, it only happens from within the attach() event. That is, even in an attached object, I can't trigger the bug from touch-start().

A few times now, I've gotten the lost sitting animation to magically recover when I right-click something as if to edit it. 

My hunch is that something happens in attach() that causes the automatic "stop all animations in sat-upon object" that's usually triggered when standing up--until something "reminds" the viewer that the av is still sitting. (Well, maybe not, as there's a report in the Phoenix jira that anims in other attachments (AOs) can also get lost, just as those in sat-upon objects.)

[Pamela Galli]

This is what Maestro said:  It appears that when avatar-animating attachments are removed, the sim sometimes stops playing more animations than it should.

 

I pasted the wrong link above -- Whirly copied everything to the Firestorm Jira here:

http://jira.phoenixviewer.com/browse/SVC-6

 

[Pamela Galli]

---

Qie Niangao wrote:

I don't think it's especially caused by any properties of the animation in the attachment. It happens when the attachment pushes a priority 4 single-frame looped anim of my own contrivance, or a priority 0 built-in "stand" animation. (FWIW, the

sit

 I was testing with was my own priority 3 single-framed looped anim.)

 

So far, I've only been able to trigger it when 

adding

 the attachment, not when removing it. I agree that it's frustratingly intermittent. The seemingly identical conditions will trigger it maybe every other attempt for a while, then not again for ten attempts, so any pattern is hard to discern.

 

As far as I can tell, it only happens from within the attach() event. That is, even in an attached object, I can't trigger the bug from touch-start().

 

A few times now, I've gotten the lost sitting animation to magically recover when I right-click something as if to edit it. 

 

My hunch is that something happens in attach() that causes the automatic "stop all animations in sat-upon object" that's usually triggered when standing up--until something "reminds" the viewer that the av is still sitting. (Well, maybe not, as there's a report in the Phoenix jira that anims in other attachments (AOs) can also get lost, just as those in sat-upon objects.)

---

The other anomaly I have found is that after the avi has popped up, if I edit something in front of her, her arm flies backwards and gets frozen like that. 

[Medhue Simoni]

Again this jira crap is ridiculous. So is every1 except the jira creator locked out, or do people that LL likes get special favoritism? If this is true, then it's just wrong all the way around, especially to those that sell products.

I just want to say that it does do the same for AOs but this is not really an issue, as AO stands have timers that will play the next animation after the given time period. If your time is set to 30 seconds, then I can see it being annoying. I also saw issues with sits and sitgrounds.

 

[Pamela Galli]

That's why I am posting about the issue everywhere I can -- there is no other way to tell if anyone else is affected by a bug now. Also why Whirly copied it over to the Firestorm Jira.  

[Innula Zenovka]

It's also being mirrored at SLU's jira subforum

This is exactly what people said  was going to happen at the time this change to the jira was brought about -- here's a bug that's important to animators,  scripters and furniture makers, and inforumation about it, and discussion of it, are spread over at least 4 different places now, rather than all being handled by a simple note in the wiki with a reference to the jira.

[Pamela Galli]

Yes. Posting about the problem all over the place is one thing, but follow up posting the JIRA info and comments (and my own observation that if this bug has been around for a while, failing at 50-70% of the time, I think after making six dozen dining sets over almost five years, I would have noticed it) is another.