I’m trying to create a player movement script and, for the most part, I think I have something that works. He moves where the input tells him to go and he’ll turn in that direction. The problem, however, is that when there’s no input detected, he’ll only point to one of the 4 cardinal directions even if he was moving diagonally. I tried using a Logitech controller’s joystick to see if the problem still existed and, while sometimes he would remain at the angle he was left at, most of the time he’d still end up at one of the cardinal directions.
Here’s a video explaining what I mean:
And this is the code I have currently
public class PlayerController : MonoBehaviour
{
CharacterController cc;
float turnVector;
Vector3 movement;
void Start()
{
cc = GetComponent<CharacterController>();
}
///*
void Update()
{
movement = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical"));
if (movement != Vector3.zero)
//if (movement.x > 0.01f || movement.z > 0.01f)
{
turnVector = Vector3.Angle(Vector3.forward, movement);
if (Input.GetAxis("Horizontal") < 0)
{
turnVector = -turnVector;
}
}
transform.eulerAngles = new Vector3(0, turnVector, 0);
cc.Move(movement * Time.deltaTime);
}
//*/
void LateUpdate()
{
}
}
If you were to actually look at the input values when stick was centred, you’d see a little fluctuation from zero. Just set the movement to Vector3.zero if the absolute value of the input Values are small… maybe less than 0.2 or so.
Not sure if this is overkill, but make another Vector3 detecting the input direction, but use GetAxisRaw instead. Use that in your “if” statement checking for movement instead.
I tried something like that and, while it’s closer to what I want, it still won’t stay at the exact angle it’s suppose to. If it’s suppose to be at 135 degrees it will sometimes be 116 degrees.
Oh sorry, do you want exactly the 8 directions, nothing between? Normalize your vector. There is a normalize method, I believe on vector 3… sorry I’m on mobile in a hotel, can’t confirm at the moment.
Sorry if I’m not completely understanding what you need.
I think a way of putting it is that it seems the input is WAY too sensitive. What I meant by what I said before is that, if I know for sure it’s at 135 degrees and I suddenly stop, the input slowly scales back down and causes the angle to shift from that.
Ahh ok. That might be a little tricky maybe. I’m guessing that as the stick is released the input values might deviate a bit from the angle you had it at or something. Going to have to think on that , a little. Maybe you might have to do something like if the vectors magnitude is less than it was in the last frame, ignore it?
Or maybe even just ignore it only if the magnitude is less than a specific value ( experiment to figure out the value) if the suggestion above is a bit too extreme.
Yeah, I’m trying the magnitude thing right now and that’s what’s causing what I described when I said that, If it’s suppose to be at 135 degrees it will sometimes be 116 degrees.
Wasn’t there a way to make Input.GetAxis snap back to zero if it’s not detecting any input from that axis? Because there’s something called “Snap” in the in input settings and I have it checked, but it’s not doing anything.
So you meant just using GetAxisRaw instead of GetAxis. I tried that, but it not only doesn’t work, but the turning doesn’t happen as smoothly as it does with the normal GetAxis which is the reason I’m using it in the first place.
It’s not turning that’s the problem though. The problem is I need it to stay at the angle the character is theoretically suppose to be facing this way. In theory, I can’t see how GetAxisRaw would allow me to do anything but increase the number of potential directions the character can end up facing from 4 to 8.
GetAxis values gradually change, which is what is causing this problem in the first place.
GetAxisRaw values can only either be 0 or 1.
I’m not asking you to change from using GetAxis to GetAxisRaw, I’m simply recommending to use GetAxisRaw on a completely different Vector3 to check if the player is moving the toggle stick.
This suggestion was a fair bit different than the one you did. I think my suggestion is a bit hoakey of a workaround though and there must be a better way, tbh. But it might work.
As for snap, the manual says that is for keyboard/mouse. You can try adjusting dead (dead zone) maybe. I think I suggested that through code earlier, but the input manager is easier by the looks of it.