Jump to content

Animation override (Making a mele combat system in Second Life, Problem 3)


Estelle Pienaar
 Share

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

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

Recommended Posts

So in order to have the wand holding up in a mele fight, I have created wand holding animations that are added to the animations of the AO. These animations should be played when walking, running, standing and turning. The following snippet is what I have so far.

It does reliably realize when the animation state changes and always gives the correct message in chat, e.g. "You started walking". However the animations are not played reliably. I don't think that it is a problem of the animation priorities because they do play for all animations, just not all of the time.

Here is what I am experiencing:

(1) The "wand" animations plays reliably with "standing".

(2) The "wand" animation plays approximately 4 out of 5 times when "walking" or "running".

(3) The "wand" animation plays only when turning when coming from a "walking" or "running" state. It never plays when I have been "standing" before.

It's a riddle why the changes of the animation states are reliably called out in chat, but the animations are not played reliably.

key ownerK;
integer timernumber;
integer movementstate;
string gLastAnimation;
string newAnimation;
string Lanimation = "wand-attackV2";

default
{
    state_entry()
    {
        ownerK = llGetOwner();
        llSetTimerEvent (0.1);
    }
timer ()
    {

if (gLastAnimation == "0") {gLastAnimation = llGetAnimation(ownerK);}
else
  {
newAnimation = llGetAnimation(ownerK);
if (gLastAnimation != newAnimation) { 

 if (newAnimation == "Walking") 
            {
            llStopAnimation (Lanimation);
            llStartAnimation("wand- walkV3b");
            llOwnerSay("You started walking");
            gLastAnimation = "Walking";
            Lanimation = "wand- walkV3b";
            }

    else if (newAnimation == "Running") 

            {
            llStopAnimation (Lanimation);
            llStartAnimation("wand- walkV3b");
            llOwnerSay("You started running");
            gLastAnimation = "Running";
            Lanimation = "wand- walkV3b";
            }
 
    else if (newAnimation == "Standing")

            {
            llStopAnimation (Lanimation);
            llStartAnimation("wand-attackV2");
            llOwnerSay("You are standing");
            gLastAnimation = "Standing";
            Lanimation = "wand-attackV2";
            }
    
    else if (newAnimation == "Turning Left")
            {
            llStopAnimation (Lanimation);
            llStartAnimation("wand-attackV2");
            llOwnerSay("You are turning left");
            gLastAnimation = "Turning Left";
            Lanimation = "wand-attackV2";
            }
 
    else if (newAnimation == "Turning Right")
            {
            llStopAnimation (Lanimation);
            llStartAnimation("wand-attackV2");
            llOwnerSay("You are turning right");
            gLastAnimation = "Turning Right";
            Lanimation = "wand-attackV2";
            }
          }  
}

 

wand.png

Link to comment
Share on other sites

While writing this post, I had the idea that the script might get confused that I use the same animation for "Standing" and "Turning". So I added another copy of the same animation with a different name. I renamed the two instances of the same animation "wand-standing" and "wand-turning". Now the switch between "Standing" and "Turning works. However the following problem remains:

(1) The "wand" animations plays reliably with "standing".

(2) The "wand" animation plays approximately 4 out of 5 times when "walking" or "running".

(3) The "wand" animation plays NOW approximately 4 out of 5 times when "turning".

 

EDIT: I made now 5 instances of the 2 animations as "wand-walk", "wand-run", "wand-stand", "wand-turn-l", "wand-turn-r" to make sure that the reason for the animation sometimes not starting in some animation states is not due to using the same animation with the same name in different states. But the problem remains.

Edited by Estelle Pienaar
Link to comment
Share on other sites

7 hours ago, Estelle Pienaar said:

I don't think that it is a problem of the animation priorities because they do play for all animations, just not all of the time.

That would indicate to me that it ~is (very likely could be) a problem with animation priorities. If 2 animations which move the same bone are played at the same time, the one which is received as a signal by your viewer last actually moves the bone. Most AOs ~should use only priority 4 and lower animations*, so if your animation is priority 5, it's probably some other issue. If your animations are priority 4, perhaps add a slight delay before playing the animation.

*Although, do verify the priorities of the animations yourself; the official viewer, and most up-to-date TPVs can tell you animation priorities now.

  • Like 1
Link to comment
Share on other sites

You are right, one animation for walking and running with the wand was only priority 4. The other one for standing is priority 5.

I have set the timer to 0.25 seconds instead of 0.1 seconds. Now it works quite ok. 

However I realised that if I switch from turning left to turning right or from turning right to turning left, it will always fail to play (despite this animation being priority 5).

If I check with 

            list anims = llGetAnimationList(owner);
            if(~llListFindList(anims, check))

if the animation is playing during the turn it gives me a positive, but it is not visible.

It might be a problem specific to the Black Dragon viewer. Will check that later. 

Link to comment
Share on other sites

1 hour ago, Estelle Pienaar said:

if I switch from turning left to turning right or from turning right to turning left

from your code above it looks like those play the same animation. I haven't tested myself, but from other things you've mentioned, it's my working hypothesis that stopping an animation and then playing exactly the same one leads to issues. You could fix that by cleaning up your code a bit:

string gCurrentAnimation; // the animation that we expect the avatar to be playing because we started it and have not stopped it.

//...
state_entry()
{	llLinksetDataWrite("AnimState:Walking", "playThisAnimation");
    llLinksetDataWrite("AnimState:Turning Left", "PlayThisOtherAnimation");
    //...
    llSetTimerEvent(0.2);
}
//...
timer()
{   string animState = llGetAnimation();
    string wantToPlay = llLinksetDataRead("AnimState:"+animState);
    if(wantToPlay!=gCurrentAnimation)
    {   if(gCurrentAnimation) llStopAnimation(gCurrentAnimation);
        if(wantToPlay) llStartAnimation(wantToPlay);
        llOwnerSay("AnimState is: "+animState+"\n"+
           "Changing from '"+gCurrentAnimation+"' to '"+wantToPlay+"'.");
        gCurrentAnimation = wantToPlay;
    }
}

or so.

Link to comment
Share on other sites

15 hours ago, Quistess Alpha said:

from your code above it looks like those play the same animation. I haven't tested myself, but from other things you've mentioned, it's my working hypothesis that stopping an animation and then playing exactly the same one leads to issues. You could fix that by cleaning up your code a bit:

string gCurrentAnimation; // the animation that we expect the avatar to be playing because we started it and have not stopped it.

//...
state_entry()
{	llLinksetDataWrite("AnimState:Walking", "playThisAnimation");
    llLinksetDataWrite("AnimState:Turning Left", "PlayThisOtherAnimation");
    //...
    llSetTimerEvent(0.2);
}
//...
timer()
{   string animState = llGetAnimation();
    string wantToPlay = llLinksetDataRead("AnimState:"+animState);
    if(wantToPlay!=gCurrentAnimation)
    {   if(gCurrentAnimation) llStopAnimation(gCurrentAnimation);
        if(wantToPlay) llStartAnimation(wantToPlay);
        llOwnerSay("AnimState is: "+animState+"\n"+
           "Changing from '"+gCurrentAnimation+"' to '"+wantToPlay+"'.");
        gCurrentAnimation = wantToPlay;
    }
}

or so.

Thank you very much, I will look into it! 

What I can already say is, that it really works differently in the Second Life viewer. There I don't have problems when switching between turns and . But Black Dragon viewer never plays it in this case. On the other hand the Black Dragon viewer almost always shows the priority 4 walking animation (I'd say 95% of the time it works) while the Second Life viewer almost never shows it (I'd say 30% of the time it works).

I did not expect such differences between viewers. That means that I  additionally might have to create another priority 5 animation, probably.    

Link to comment
Share on other sites

On 5/26/2023 at 1:20 PM, Estelle Pienaar said:

Thank you very much, I will look into it! 

What I can already say is, that it really works differently in the Second Life viewer. There I don't have problems when switching between turns and . But Black Dragon viewer never plays it in this case. On the other hand the Black Dragon viewer almost always shows the priority 4 walking animation (I'd say 95% of the time it works) while the Second Life viewer almost never shows it (I'd say 30% of the time it works).

I did not expect such differences between viewers. That means that I  additionally might have to create another priority 5 animation, probably.    

The difference is only between BD and SL then mainly. It probably stems from the fact that BD's default turn settings are lower, the official default settings for turning are 30° so before any "turning" animation plays you need to turn away ~30° in any direction from the initial "center" to which the avatar will then readjust and turn, while in BD the turn threshold is all the way down to 2° meaning essentially as soon as you even as much as think about rotating in any direction you will immediately see the avatar start the turning animation. However, there might be some desync happening here due to you checking for the animation rather than using the server-side AO features, i have never used the old AO system so i don't know what exactly it does and how it works but i'd assume it checks clientside, whenever the client is playing the turning animation, this coupled with BD playing them much more than other Viewers might cause a desync somehow (although it shouldn't as you are using the LSL play animation command which is a synced command, so everyone should see you play it).

Edited by NiranV Dean
  • Like 1
Link to comment
Share on other sites

11 hours ago, NiranV Dean said:

The difference is only between BD and SL then mainly. It probably stems from the fact that BD's default turn settings are lower, the official default settings for turning are 30° so before any "turning" animation plays you need to turn away ~30° in any direction from the initial "center" to which the avatar will then readjust and turn, while in BD the turn threshold is all the way down to 2° meaning essentially as soon as you even as much as think about rotating in any direction you will immediately see the avatar start the turning animation. However, there might be some desync happening here due to you checking for the animation rather than using the server-side AO features, i have never used the old AO system so i don't know what exactly it does and how it works but i'd assume it checks clientside, whenever the client is playing the turning animation, this coupled with BD playing them much more than other Viewers might cause a desync somehow (although it shouldn't as you are using the LSL play animation command which is a synced command, so everyone should see you play it).

I am still playing around and changing the script, but I have not been able to fix this particular part. As soon as I think that the script cannot be changed anymore, I will make a full perm version of script and animations for you available, so that you can test yourself. It is very well possible that the difference stems from the lower threshhold before playing the turn. 

 

Link to comment
Share on other sites

On 5/25/2023 at 9:17 PM, Quistess Alpha said:

it's my working hypothesis that stopping an animation and then playing exactly the same one leads to issues.

So after some more testing, my experience has been that it seems to be the contrary. The animations need to be stopped by the script, even if they should continue to run in another state and then be called again. That makes it much more reliable. If I do not stop the previous (same) animation from another animation state, it will often time not play in the new animation state (even if it is a higher priority). Moreover: If I test with the script with llGetAnimationList( key avatar ); , I will get a positive response saying that the animation is still playing, but it is not.

One more remark: It is strange, that I can check for playing animations only by their keys while I can start animations only by the string name. Or is there a way to start an animation by its key and not its name? But this question is at this point rather theoretical, since the function llGetAnimationList seems not to be reliable anyway. I have given up on that step. I just stop the old animation and call for it in every animation state update, even if that is quite inefficient. But it works (for about 95% of animation state changes).

Link to comment
Share on other sites

14 hours ago, Estelle Pienaar said:

I am still playing around and changing the script, but I have not been able to fix this particular part. As soon as I think that the script cannot be changed anymore, I will make a full perm version of script and animations for you available, so that you can test yourself. It is very well possible that the difference stems from the lower threshhold before playing the turn. 

 

It's certainly weird. Before i made my own server-side AO i used Oracul AO which also had turn left/right animations (and just like most AO's i had those filled with animations) and they worked fine (at least locally for me), in fact they worked too good, often times playing longer than necessary (which made other people see me play the animation when i wasn't spinning for them, e.g spinning in place or spinning animation wise but not physically). This could even be done on purpose by constantly drag-looking around in small circles, forcing the rotate animation to keep playing.

  • Like 1
Link to comment
Share on other sites

You can see what anims are running by turning on Developer->Avatar->Animation info.

animinfocropped.png.d1d420f368dc095ed1d0d19ff9127517.png

Works for animesh, too.

You can watch the AOs work.The number at the end is the animation priority. Not sure what the * means. That should help distinguish between animations not running and animations preempted by higher priority animations.

  • Like 2
Link to comment
Share on other sites

Just one update: Everything works find apart from playing animations when getting from the Animation State "Standing" to Animation State "Turning", despite the animation being priority 5 and it being displayed in Animation info. Also I can not reproduce what I said before. It is not working in all viewers, there is no more difference between SL or BD viewer. I think I will open a JIRA.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 300 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...