koobas.hobune.stream
Is It Bad To Have Your Jump In Update()?
Is it bad to have your jump in the Update() method/function? Currently I do, and everything seems to work correctly, but the reason why I'm asking is because I'm curious and I was wondering if there is any performance issues with that. Also, I recently changed my jump to if (grounded && Input.GetMouseButtonDown(0)) {, and it works fine, but when I press the pause button the Player obviously jumps a little, but when I press the resume button the Player goes flying in the air, hits the top wall, and dies. Why is that? Does the Update have anything to do with it? Since my pause button uses Time.timeScale the Update is not affected so that's why I ask this question.
It is just a matter of experimentation of Update and FixedUpdate because it dependes in a lot of factors. It is relative to the amount of code and the Unity Settings in Time and Physx. If you are aiming to mobile then just build and take notes of your results.
About the Time.timeScale not affecting Update it is wrong. Time.timeScale affects EVERYTHING in the Unity Universe.
Thank you, and sorry I didn't know it affected everything. I read many post and a lot of times they said that it didn't affect the Update.
This answer is technically incorrect.
Update will still run while Time.timeScale is 0
Time.deltaTime will return 0, so anything that relies on this value will stop
FixedUpdate will not run if Time.timeScale is 0
There is no need for experimentation on Update versus FixedUpdate. The docs are quite clear on what each function does. And a little bit of logic will let you know what belongs in each method.
Well, well. Im green answering i guess. Let's see. If the PLAYER is moved by a character controller, forces with AddForce or just the transform directly or with translate the ecuation is NOT so simple and of course, the player is affected by the time.TimeScale and then, time affects everything RELATED to the player, what the players see and does. It is not technically incorrect to say that time affects everything. It does so, you are wrong but i see your point.
About not needing experimentation, well, ask that to the guys in Black $$anonymous$$esa ;)
But, your answer completes $$anonymous$$e so, thanks for the help.
A lot depends on how you jump. General rules
Everything that uses physics or RigidBody should go in FixedUpdate
Everything in update gets called every frame, so should be as efficient as possible
Anything that needs to be affected by timescale should use Time.deltaTime
This is wrong. It depends on cpu miliseconds and feeling of the animation. It is not the same to use physx with a rigidbody affected by gravity or a rigidbody without gravity.
Come on.
@DBar - I'm not sure what you are specifically calling out as wrong here. I provided a pretty generic piece of advice to a pretty generic question.
But if you want the detailed answer:
Physics in Unity runs at a set frame rate. FixedUpdate is called just before the physics engine updates. Hence any changes that affect the physics engine need to run in FixedUpdate.
Update runs as fast as it can and is called just before the visual update cycle. Game logic and input controls normally go here. Anything that needs updating at a high frequency.
Back to the OP, if jump is a physical effect and uses force then the jump should be executed in FixedUpdate. On the other hand if jump is a visual effect and just moves the transform around then it should be in Update. Either way input should be captured in Update.
This is all independent of hardware performance or any aesthetic considerations. I'm not sure where your knowledge of Unity comes from, but I suggest getting a lot more time on the tools before you start calling me out on my answers. The most common reason for jump coding to fail (jumping twice as high, or missing jump inputs) is because the logic is in the wrong method.
I'm no expert (in fact i'm quite green behind the ears) but things like "Jump" should be in the FixedUpdate function.
