Jump to content

Issue where llMoveToTarget causes one animation to override another.


Mabarial
 Share

You are about to reply to a thread that has been inactive for 2686 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hoy hoy!

 

I'm having an issue with some AOs where after being moved by an attached physical object using llMoveToTarget(), the AO's animation keeps playing over my own. Code here:

// Variables for the timer (bobbing motion.) //
float d=0.25;
float step = 0.8;
vector pos; 
float x=0; 
vector bobthrust;

// Variables for other calls //
integer count;
string anim;

// Functions //
animation()
{
    llStopAnimation("sit_generic");
    llStopAnimation("sit");
    llStopAnimation("walk");
    llStopAnimation("stride");
    llStopAnimation("falldown");
    llStartAnimation(anim);
}        

default
{
    touch_start(integer num_detected)
    {
        llRequestPermissions(llGetOwner(), PERMISSION_ATTACH);
    }
    attach(key avatar)
    {
        if (avatar)
        {
            anim = llGetInventoryName(INVENTORY_ANIMATION, 0);
            llRequestPermissions(avatar, PERMISSION_TRIGGER_ANIMATION);
            llSay(0, "Attached"); 
            pos=llGetPos();
            llSetStatus(STATUS_PHYSICS, TRUE);
        }
        else
        {
            llSay(0, "Detached");
        }
    }
    
run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_ATTACH)
        {
            llAttachToAvatarTemp(ATTACH_LHAND);
        }
        if (perm & PERMISSION_TRIGGER_ANIMATION)
        {
            llSetTimerEvent(0.5);
        }
    }
    
    timer()
    {
        x+=step;
        bobthrust = <0,0,llCos(x)*d+1>;
        llMoveToTarget(pos+bobthrust,0.8);
        animation();
    }
}

Pop this script and any animation into the contents of it, then click the prim, accept the attachment. While wearing an AO, the animation starts, then you start bobbing up and down, and then animation cancels and gets replaced by your default AO animations for falling. This only happens while wearing an AO.

Here's a video of what's happening:

 

The cube on the left just tells me the name of the animation playing. But you can see, the moment I disable my AO, the correct animation resumes playing. It doesn't happen for all AOs, and so I assumed this was an issue with AO makers using priority 4 animations. So I went and even made my own priority 4 animation for my item. Spent an entire day learning how and then making it perfect.

But it still gets cancelled. Even when recalling llStartAnimation() in a loop, the animation doesn't resume. But oddly, the animation doesn't fail if the cube doesn't move.

I'm a bit stumped on how to continue, and this is one of the last things holding me back from finishing my item. Does anyone know what's going on here?

Link to comment
Share on other sites

I've found a workaround by removing the animation() function and instead changing my timer to:

    timer()    {        if (count == 3)        {            llOwnerSay("3");            llStartAnimation(anim);        }        x+=step;        bobthrust = <0,0,llCos(x)*d+1>;        llMoveToTarget(pos+bobthrust,0.8);        ++count;    }

That causes the animation to start at 1.5 seconds into the timer, just after it passes where all the animation problems were occuring. However, it doesn't look as good as it would if the animation were playing the whole time. Is there a better workaround for this? I've even tried using  

llStopAnimation(llGetAnimationOverride("Falling Down"))

 but to no avail.

Link to comment
Share on other sites

If your AO is using animations that have a higher priority than the one you are triggering in your script, the AO will win every time.  You can use llSetAnimationOverride to replace the native animations "sitting", "walking", etc.  but that's what your AO is doing too.  Turn the AO off.

Link to comment
Share on other sites

The animations in the AO are of the same priority as the animation in the script, if not less. I uploaded the animation myself so I know it's priority 4. The item this is going in is going to be mass-used, so requesting customers to turn their AO off isn't really an option. If I have to go with my current workaround, I will, but it's not preferable.

Link to comment
Share on other sites

whats typically happening is that there are two timers that are not synched with each other, triggering same level animations
 
your timer in your script. and the timer in the AO
 
you will most likely find that while your 1.5 sec synch delay will work with some AO script timers from some makers. It wont with others
 
you get that glitch effect as each timer fires
 
pretty much the only way round this is to put your timer onto a really fast time. and then create a series of micro-length animations. and timestep thru them really quickly in a sequence. it will still glitch sometimes but not as much
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2686 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...