Cannot believe that this isn't a problem for all animator.. So there must be an answer

[Zen Muliaina]

I Have spent a long time creating an animation set that lasts about 30 sec. And it works perfect..UNTIL... The user has an AO on!!.

I use priority 4 as this is a one off animation and needs to be top priority. But it seems everyone else uses P4 in their AO animations. I initially of course override the AO as I am at P4 too but then asynchronous to my animation the AO changes its animation and bang mine is gone!!

There must be a way of stopping this other than telling the user to turn their AO off which as we know they don't read or do or forgotten how to!!!. How can I use P5 or P6

Thanks for any responses.

PS the new set of animation override functions do not help as they only modify the default (SL) animations

[Innula Zenovka]

I'm a scripter, not an animator, but I work very closely with my animator friend and business partner, and have done for the last 5 years or so.    So I know a bit about the problem.

I always, or almost always, do whatever I can to turn off by script the user's existing animations and AO, though a lot of modern AOs (including the built-in Firestorm one) are smart enough to know when something you're sitting on wants to play an animation, so it's often not necessary).    Using the lockmeister "bootoff" and "booton" commands will turn  off and on a lot of AOs (including Firestorm). 

We very rarely release anything with an animation priority higher than 3, and we've not had any complaints.     I'd strongly recommend working with a scripter on this one rather than trying to use even higher priorities.

[Zen Muliaina]

Thanks Innula, I will look up the lockmeister commands. I do my own scripting but speicialise in HUD's rather than animations. Just as an aside, the animation is a "standing" and is triggered with a attach not a sit, But if the lockmeister commands turn the AO off then it shouldn't matter :-)

[Innula Zenovka]

Since it's an attachment, I'd try this too, in the run_time_permissions event.   Depends on the AO, of course, but with most AOs, I think, if the wearer's animation state doesn't change, the AO won't see any reason to trigger a new animation.    So looping through all the wearer's animatins and stopping them normally does the trick, at least in my experience:

		if (permissions & PERMISSION_TRIGGER_ANIMATION){			key k = llGetPermissionsKey();			list l = llGetAnimationList(k);			integer max = -llGetListLength(l);			do {				llStopAnimation(llList2Key(l,max));			}			while (++max);			llStartAnimation(myanim);		}

 

[Zen Muliaina]

Thanks Innula,  for the response, it gave me the idea I needed to implement a bullet proof animation regardless of the AO or animation that is currently running and with my own priorites.