allowed animation is blocked by AO

Hi, i have a small toy that asks an av an animation request.
The av accepts and the animation is initiated, but then the avs AO kicks in and overrides the permitted animation.
Can that be avoided? or.. How can an AO be overrided
BR
ab

There might be a better way, but I just turn off my AO.

The only way I know is to make sure that the animation is uploaded with a higher priority than your AO's animations. If you aren't the animation creator, though, you're hosed on that.

Jesse Barnett's AO overriding poseball script works for me -- maybe it could be adapted for your purposes? http://wiki.secondlife.com/wiki/AO_Overriding_Pose_Ball

Yeah, this can get messy for arbitrary AOs. The problem is that some now have a "seamless sit" feature that cycles through a series of sit animations (as is common for stand animations). In that case, clearing the AO's animation when the script gets permission to animate doesn't prevent the AO from later pushing another animation on top, and if it's the same priority as the one the script wants to play, the new one wins.

The trick I've played in the past is to use a priority 4 animation, and an asset copy of that animation, and push and remove them alternately on a timer. This approach is not exactly low lag, but it works regardless of what the AO is doing or what animations are in it.

If all AOs and animation-overriding toys obeyed a protocol to stop when asked by another script (as some do), this would be much more elegant. But file that in the Porcine Flight Insurance category.

@Rolig- yes, but some users may not like to do that, and it is also a litle lame to have to ask a user to do that before a gadget eill work

@Jack- yes, i was on to that later yesterday, here an somewhat interesting question apears: What will 'win' an animation in an AO or an animation pr request if BOTH has the same (or even highest 4 ) priority -gues i have to make some eksperiment

@Innula, thank you for that link! That looks very interesting in general and perhaps also posible to shape into something for my current problem

@Qie -ahh- yes, but then i face a new problem. the animation is a oneshot ie it is stoped in a fixed posistion. It would not work kicking it in from the start.. one idea you give me would be to make 2 seperate animations one with the initial motion and one with the fixed posistion (fp) and have the fp kicked in over and over.. hmm

Botton line is that the (some) AOs apearently has a faulty way to cope with permitted animations.. too bad

Thank you All for all your inputs!
BR ab

The script is pretty small and you will be able to see how to get the av's animation list and stop all of them before applying your animation. It is actually pretty easy to do and I never understood why it isn't the defacto way for all Pose Balls or even Sex Beds etc.

It will work in all cases except for what Qie described. In a case where the AO does uses "seamless sit" the user is just gonna have to learn to turn it off. No use in having two scripts fight constantly every 0.1 seconds to control the av.

the other solution is get a better AO . i have a modified version of the zhao2 called zhao seamless sit. it checks if what you sit on is playing an anim, if not it plays it's own sit

of course with that, you can't play your own sit if you don't like the one in what you're sitting on. i keep a copy of the ao in the regular zhao

Most products in SL are like that. Poseballs etc. that attempt to disable AOs only work with AOs that follow the convention, and there isn't a universal one. There is the AutoZHAO convention for ZHAO, but most ZHAO-based HUDs don't include that feature.

Last one played wins.

You're trying to place blame here, when the truth is it's just not a simple problem to solve. For example, scripts can't know when permission is granted to a different script -- and even if it did, what to do about that would depend on the situation. Any solution requires either considerably more processing on the part of the AO, or a universal convention. Until you've worked on an AO script, it's probably wise not to throw stones at AOs. The most common one is ZHAO, and it's a difficult bit of work very well done.

However, Jesse's right that it's a good idea to stop all animations when starting your own. My poseballs do that, though I don't believe I ever added that to MLPV2; perhaps I should. Just keep in mind that it doesn't work in all situations. It's the best compromise between simplicity and effectiveness.

When does it check? Does it re-check later, in case the sitter didn't accept permissions right away?

i think it just checks if you're playing an animation other than the default sl sit, which of course you know most/all pose scripts turn that anim off before starting an anim

it's still open source and free if you want to get one and look at it.

http://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=593983

and then a girl's preloaded one with hug,kiss, and tp/lm functions

http://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=911467

Yep, the animation script in the Tiny version of Moewe has to keep re-overriding the Tiny animations.

Yep, the animation script in the Tiny version of Moewe has to keep re-overriding the Tiny animations.
I modded Franimation 1.6 to do that each cycle, and to also re-override walk periodically, but I didn't send it in to Francis Chung soon enough or something because Franimation 1.7 didn't have the fix. Most of the AO's in world now are based on Franimation 1.7, I may be the last person using Franimation 1.6 because I just can't stand having the "duckwalk" return as I'm wandering around.

Ah, priority escalation. I simply LOVE it. LOL. Unfortunately some AOs take the same approach of stopping all other animations. It's a tight juggling act between "overriding" and being stubborn. Heh. Make YOUR timer faster? May not work for dynamic animations (which you'll see start and stop and start and stop but never play for very long).

This is one of the reasons I've always hated that common statement that "there are a lot of good AOs out there." Bah! There is a lot of CRAP out there, and maybe a COUPLE of people thinking about polite script interaction. Paranoia usually encourages me to, "roll my own."

Yep, that's exactly what the seamless sit patch tries to do, one of those wonderful ideas that seem so obvious after the fact, yet no one thought to do it before. The patch has a couple of minor bugs but the idea works really well in practice.

what are the bugs? i just noticed something odd, i was standing on a pose stand for a long period of time and it switched the lower body to the ao sit, but the upper body was still in the turn_180 pose

Three I found in the copy I've been playing with: it doesn't really re-check once you've sit down on something, so sit-target hopping, a slow pose script, or a script that includes the default sit as an option can fool it; it ignores when you explicitly use Sit Off (it looks like that may be intentional); and it doesn't check if the avatar is sitting before the CheckSit function is called (doubt that this would actually give unwanted behavior, but it's doing work when it doesn't have to).

But whatever, everything has bugs on the first cut. The idea is still great.

(edit to add: turn_180 is an odd animation, the overall priority is 5 and should override everything, but the lower joints were given a lower priority so other sits can peek through like that.)

Note also that a lot of animations used for sitting (and "sitting" for other poseballs and furniture) aren't looped. So anything that tries to play nice with furniture is probably going to have to check for other played animations quickly for a brief period just after sitting, and if any interesting animations are found, will have to give up animating until the avatar stands up again. I haven't looked at the actual implementation being discussed, but it might make the erroneous assumption that if an animation hasn't played for a certain period while sitting, overriding is fair game.