Is there a way to tweak the input angles that is used for "Just turning" the sprite character?

zinvolspel

I wonder If there is a way to change the angles of the "Just turning" option.
What I've got here is a 8 direction movement 2D sprite character in a 3D environment with direct control.

The only problem I encounter here is with using the analog stick to move the player, the sprite is turning a little bit too early. It has already turned before the stick has made a change of 22.5 degrees. So for example right now, when the analog stick has only changed about 8 degrees, the player is still moving upward (until an analog stick change has been made to 22.5 degrees) but my sprite has already turned into the upward/right animation.

Am I missing something or was the "Just turning" option just not designed for use with direct input from analog stick? Do I need to setup the handling of the animation manually in this case?

ChrisIceBox

You're using "Sprites Unity" as your animation engine?

It may be that the input settings in Unity's Input Manager just need tweaking, so that they snap more/less according to the "real world" input value.

Otherwise: the angles that a character faces are hard-coded, but with "Sprites Unity Complex" you have control over how the angle affects animation.

See the Manual's "Character animation (Sprites Unity Complex)" chapter. The "Body angle float" parameter will range from 0-360. Since this mode involves using Blend Tree / Animator transitions to control which "facing" animation gets played, you can tweak parameter values to get things looking better for your situation.

zinvolspel

Your answer certainly helped me. I tried doing it the "Sprites Unity Complex" way and it works exactly like you said, it just takes a bit more time to fill in all the transitions.

But when I got this working, I might be able to match the movement with "Just turning", but I'm still not sure if this is the way to do it. I just think it is sort of strange that the "Body angle float" doesn't really match up with the input that I'm using for movement. I'm measuring it with a method like this:

private const string HorizontalInput = "Horizontal";
private const string VerticalInput = "Vertical";
float angle;
///

    private void DebugInputAngle()
    {
        float x = Input.GetAxisRaw("Horizontal");
        float y = Input.GetAxisRaw("Vertical");
        if (x != 0.0f || y != 0.0f)
        {
            angle = Mathf.Atan2(y, x) * Mathf.Rad2Deg;
            Debug.Log(angle.ToString("F4"));
        }
    }

If these two angles in the end do not happen to match up in a usable way, I might have to find another way to do this. Maybe writing the input in another way.. Because I don't really need analog input at this point, but I do want to be able to use the joypad. Anyway, in the weekend there will be time to do some more research. Thank you so much.

ChrisIceBox

AC relies on GetAxis, as opposed to GetAxisRaw, for reading the Horizontal/Vertical inputs - which may account for the difference. The character's turn speed is also a factor, too.

You can, however, remap the inputs to read GetAxisRaw via a custom delegate. See the Manual's "Remapping inputs" chapter as well as this tutorial:

You could try defining an InputGetAxisDelegate that returns Input.GetAxisRaw if the "axis" name is "Horizontal" or "Vertical", and Input.GetAxis (the default behaviour) otherwise.

zinvolspel

Somehow I now wonder if a controller can make the difference in AC's and Unity's input. Mine is a Gamecube controller/Mayflash/Rewired on Mac, but it would be very strange if that would be the case I guess..

GetAxisRaw and GetAxis didn't make a difference in this case.

I tried making it work with the Unity sprites complex setup, but the axis didn't match up in a usable way, it's like they're using their own relation arcs within the 4 main directions of their protractor, if that makes any sense. Also I had a problem with setting up the angle conditions around the zero/360 point of the angle. I could not use the direction conditions, because they weren't exactly matching my movement, and using negative angle conditions wasn't enough for me to solve this problem I guess.

I tried to delegate AC's axis input to the input I got in the Kinematic Character Controller script. But I don't really see why that would make a difference since they both are using GetAxis. So that, and it being maybe a bit too advance for my scripting abilities made me give up on that as well after a while.

Now I'm thinking about scripting the turning of the animations within the character controller script. I have done this before so it's worth a try. Or I might first try hooking up another controller if I can find one, just to be sure..

Ok this might be getting too long. Anyway thank you very much for your input