odd behavior on unsit

Hi, a friend has a problem. she made an animation (in qavimator) uploaded it (prio4) and put it in a poseball.
It worked correctly. This is important! The animation behaved correctly!

A few days later she tried the anim again
Now, on 'unsit' the animation 'stops' (more like it is interupted) very briefly (the actual 'hop-of-ball-anim) but then it -continues- for something like 2-3 secd. -after- the avi has unsit.
What could be the reason for this behavior?

A description of the animation:
The animation is
*a slow sit for a mermaid
*looped
*uploaded as prio4


What we has tried already with bad result:
*Playing the animation directly out of the invenetory
*Trying in several locations (sims, sandboxes)
*Replacing the animation in the poseball
*other animations play correctly in the problem-ball (eg scripts are transparent to the problem)
*Off. client and RC-client

So the problem seams to be isolated in/to the actual animation, but what could alter a working animation? she now worries about her other animations.. Could they go 'corrupt' too..

Has anyone seen this happen earlier?
Are there any solution?

tyia
Ab

Is this a looped animation? A looped animation will play to the end if you stand up in the middle of its cycle.

Hi Deira , thank you for your interest.
I doubt that can be the problem. The animation has elegebly worked correctly on that same poseball. If it is a 'ani-end-event' isue, the problem should have been present from the very beginning
BR
ab

Does the pose ball script explicitly use llStopAnimation at unsit time? Some scripters skip this step and expect the viewer to handle it, but that method is not always reliable.

Hi Victoria, well -i have not seen the script, but i have seen that another animation running from that same script behaves as expected and correct.
Also as i said abowe, the strange animation running 'standalone' from inventory (clicked and choose 'Run in world') STILL does not stop emediatly when stop is chosen.
To me that means that the faulty mermaid animation is faulty independent of the script -eg the script is transparent in respect to the artefact.
..and has acordingly to the creator worked correctly for a few days.. :/

It resembles a april-fool-joke, but is not one.

I have had this happen to a couple of my things in the past. The animation file gets corrupted or something. I re-uploaded the BVH file and the problem went away.

So I would suggest that. It will cost 10 Lindens, but well worth it if it corrects the problem.

...so it has happennd before :/ -oki, thats actually one of the things i wanted to know and hoped this post could enlightend
-Yes a re-upload is ofcause worth a try, but the.. what if this was an animation that she had bought.. then what -screwed i surpose
If anyone else has anything please do post
BR
ab

out of curisoity, could it be the priority setting on the uploaded animation. could be something else if conflicitng with the prioritys

Ichago Dougall, i have had that thought, but it is not posible to make a conclusive answer. if it as a test was uploaded in say prio3, then there are no way to force the fail. Rem, it USED to work correctly, and then failed.
It is a sl m y s t e r i e ... <irrie music goes here>

I do feel concerned about this sort of thing - sometimes it does seem that new client releases bring back old bugs. When it worked correctly before, was it on a previous release of the client software?

afaik it was the same client. there was only 2 days between the correct and the incorrect behavior -so same client, and yes, it is subject for concern.. What if other animations suddently 'misbehave' ..especially the ones that are sold to others.. :/
Think about that.. It would prompt certain people to roleplay as lawyers.. <Brrrrrr>
-no, jakes aside, a messup in the animation system could be a serious isue
BR
ab