koobas.hobune.stream
Cant get rid of animation delay in Mecanim
Hey, guys! I am trying to get rid of delay when my gameobject goes from state FireFlyStrafe back to state FireFlyIdle. I checked a lot of issues with animation delay but still can't make my own work as planned. Here's code I use to control states and pictures of transitions between states. I am flipping strafe animation in my code.
using UnityEngine;
using System.Collections;
public class FiryFlyAnimCtrl : MonoBehaviour {
private Animator anim;
bool facingRight = true;
bool set = false;
void Start()
{
anim = GetComponent<Animator>();
}
void Update()
{
float move = Input.GetAxis("Horizontal");
anim.SetFloat("SpeedHorizontal", Mathf.Abs(move));
if (move > 0 && !facingRight)
{
Flip();
}
if (move < 0 && facingRight)
{
Flip();
}
}
private void Flip()
{
facingRight = !facingRight;
Vector3 scale = transform.localScale;
scale.x *= -1;
transform.localScale = scale;
}
}
Hey since you disabled "Has exit time" this should work.
Under your conditions try set less and greater 0 so it will start exactly != 0 and not 0.1.
And why do you use: Mathf.Abs Is there a special reason for absolute values?
anim.SetFloat("SpeedHorizontal", Mathf.Abs(move));
If it still has a delay i would make a bug report to unity about this!
ps: I find it better to declair variables that you always use out of scope.
float move = 0
I would declair it outsite of the Update() scope because of memory alloc. And garbage collect thingis :)
@Dev6_RC thanks for reply! I have solved this problem recently by triggering animation straight with buttons input not horizontal input. I haven't yet figured out why horizontal input makes state transition delayed but I am working on it.
I think you can just use :
Input.GetAxisRaw("Horizontal"); ins$$anonymous$$d of Input.GetAxis("Horizontal");
And this should fix a lag! ;)
I know this is old, but the "Has exit time" tip helped me so it's still useful!
That said, declaring move outside of Update has no benefit, and has potential downsides. floatis a value type so gets created on the stack* - no GC alloc. And it's generally good practice to give vars the absolute $$anonymous$$imum scope required to do their job. Otherwise you can end up modifying state when you didn't mean to.
Of course, if it was a reference type, declaring as a member and re-using to avoid GC alloc is totally valid - but that's an optimisation you should make later. Optimisations like that generally come at the cost of making your code less straightforward (i.e. harder to read, understand, maintain and refactor) and should only be made when you need them.
*yes, I know, not strictly always 100% true, but when it's not, it's because the compiler knows better than you so don't try to second-guess it.
Click on the transition, you'll see two boxes. The top (and left most) is the state you're transitioning from and the lower one it the target state. Drag the bottom box all the way left until it matches the top one and makes sure under (just below 'Has Exit Time') that Transition Duration is set to zero as well.
