koobas.hobune.stream
The question is answered, right answer was accepted
GetAxis being missed in FixedUpdate work around?
I feel like I'm having a colossal brain fart right now, but I can't figure this out.
void FixedUpdate()
{
moveHorizontal = Input.GetAxis("Horizontal");
moveVertical = Input.GetAxis("Vertical");
jump = Input.GetAxis("Jump");
movement = new Vector3(moveHorizontal, 0.0f, moveVertical);
rb.AddForce(movement * speed);
if (canJump)
{
rb.AddForce(0, jump * jumpHeight, 0);
}
}
Player movement works fine but jumping is buggy. If I apply the force to jump in FixedUpdate, it gets missed sometimes if the player is jumping a lot, and also, for some reason, if the player is moving diagonally(Like maybe GetAxis is being overloaded with three buttons being pressed?!).
But if I move it to Update, a. I'll have frame rate related issues in the build, right? And b. the jumping works perfect except every once in a while the player jumps much higher, which I believe is the result of the force being added twice. Maybe I'm interpreting it all wrong? I don't like using GetAxis or Unity's physics engine, there's too much going on under the hood.
Two golden rules:
Always listen for input in Update.
Always apply physics functions in FixedUpdate.
To achieve this, all you need to do is separate your code:
float jump;
Vector3 movement;
void Update() {
float moveHorizontal = Input.GetAxis("Horizontal");
float moveVertical = Input.GetAxis("Vertical");
movement = new Vector3(moveHorizontal, 0.0f, moveVertical);
jump = Input.GetAxis("Jump");
}
void FixedUpdate() {
rb.AddForce(movement * speed);
if (canJump) {
rb.AddForce(0, jump * jumpHeight, 0);
}
}
Oh gosh, it seems so obvious now. It worked like a charm. Thank you.
Actually this recommendation is not quite right. It's perfectly fine to read state data in FixedUpdate and should be read there. Otherwise you will have one frame delay since FixedUpdate is called before Update.
However one-time-events like button down / up events, mouse clicks always need to be handled in Update. You also can apply one-time-forced in Update. There's no need to route it to FixedUpdate.
Also jumps are usually one-time velocity boosts so using the normal AddForce doesn't make sense since it will divide the force by deltaTime since it's ment to be applied every frame. So for the jump button you usually would use Input.GetButtonDown("Jump") inside Update and not getting the virtual axis:
void Update() {
if (canJump && Input.GetButtonDown("Jump"))
{
rb.AddForce(0, jump * jumpHeight, 0, Force$$anonymous$$ode.Impulse);
}
}
void FixedUpdate() {
float moveHorizontal = Input.GetAxis("Horizontal");
float moveVertical = Input.GetAxis("Vertical");
movement = new Vector3(moveHorizontal, 0.0f, moveVertical);
rb.AddForce(movement * speed * Time.deltaTime);
}
Note: Force$$anonymous$$ode.Impulse applies a one time impulse that takes the objects mass into account. You could also use Force$$anonymous$$ode.Acceleration which ignores the mass of the object.
I would add to Bunny83's comment that mouse axis values (deltas) and axis values that use the gravity/sensitivity system to ramp those values up/down over time should also not be queried in FixedUpdate.
Fixed Update can run multiple times per frame or zero times during a frame depending on the current frame rate and the set fixed update rate. Unity only updates its input system one time per frame, before either Fixed Update or Update run. Any value you obtain in Fixed Update is just going to be the exact same value Unity set when it updated its input system at the beginning of the frame. If Fixed Update runs 5 times during that frame, you'll get 5 copies of the same input value. While this doesn't affect GetButton calls or GetAxis calls for absolute axis values (joysticks), it does affect all other input values that you would want to be updated anew each frame. Unity did not design their input system to be used in Fixed Update.
