I’ve been doing some searches on the forums and I’ve read at least a couple of times that we should check for user input within the Update function. I’ve also read that any application of physics forces should reside within the FixedUpdate function.
After studying the 2D Walkthrough Video, at the 6:20 mark it shows that PlayerControl.js checks for horizontal movement input within the FixedUpdate function.
Is this kosher? Why did the programmer not decide to check for input within Update and then apply forces in FixedUpdate?
EDIT: Is this question better suited for Unity Answers? It seems that it might be…
The reason you typically get user input in Update is because it runs once per frame, where FixedUpdate does not - it runs per physics tick, and more or less than one of those may occur each frame. If your input is directly altering a Rigidbody it’s probably a good idea to keep in in FixedUpdate as it’ll then be in sync with the physics ticks.
Having said that, I’m not sure how input is checked internally, so I’m unsure what happens in this case when there’s not one physics tick in a frame.
It seems like this problem might be less apparent in the case of the Unity 2D Walkthrough, because the input that is checked in FixedUpdate is horizontal movement (i.e. not a single keypress, like a jump). Also worth noting is that the programmer chose to check for jump input in Update, if I recall correctly.
Can anyone confirm that I’m on the right track or am I missing something?
I think you’re right. That is the exact same conclusion I’ve come to.
If you are reading an analog, continuous input that you use to control something physics-related (like the intensity of an applied force) then it makes sense to read it every time the physics engine updates.
On the contrary, if you are reading just a one-time input (like a jump) which applies a single force, then reading the input on the update function is the best choice, so you can avoid input loss.
The only thing I don’t know is if you should put the force in the update function also, since it’s a one-time force application. In the example the Unity programmers have put the force application in the Fixed Update function, which seems to be working just fine, so I guess it could be good. But as the thread you linked says, you probably could put any non-overtime force application in the update also.
You’re on the right track. Tracking input in FixedUpdate absolutely can (and does) lead to input loss. With things like GetKey or GetAxis it may not be terribly important, but you’ll absolutely lose KeyDown/KeyUp events. It’s best to poll the input in Update and respond to it in FixedUpdate.
Not just input loss, but sometimes double input. I saw another post by a user that was having the opposite problem. He was attempting to use GetKeyDown in FixedUpdate. With Update it would only fire once but when used in FixedUpdate it seemed to have no concept of whether the event had already been fired and it fired multiple times.
More specifically, Input isn’t event based. It gets updated at the top of every frame before any MonoBehaviour logic is performed. If FixedUpdate is executed twice in a single frame then it will use the same Input state. This doesn’t happen with Update because Update will only ever run once in a frame.
If someone reading this. I’ve got sometimes double click problem with FixedUpdate. Especially with touch imput on iOS. Just use update function or void OnMouseDown() if possible if you are detecting collider click. But sometimes you get lag in imput if collider is moving.
If you’re going to check for input in FixedUpdate, I haven’t had much trouble with the methods that return true when held down, though when quickly pressing the key or button it could get missed. The ones you definitely need to use in Update are any of them that have “down” or “up” in the name, such as GetMouseButtonDown, as they only return true for a single frame, and you have no guarantee that FixedUpdate will be called that frame or that it won’t be called multiple times that frame.
I found this thread as I have done a lot of research about what the best method is. Most people tend to say that input should be checked in Update and any physics actions that are a result of this input should be done in FixedUpdate.
Then I read this (Unity - Scripting API: Rigidbody.velocity) on the Unity website and noticed that they check for input in FixedUpdate, but I’m going to use Update for checking input and FixedUpdate for the action and see how it goes.
The example code in Unity’s Scripting Reference pages don’t focus on best practices, they focus on learning. That said their examples typically take the shortest amount of code needed to show an example of how to use the topic of the page.
If they worried about making the example code follow best practice, it would likely just confuse people trying to learn about the topic of the page. Best Practices are usually covered in blogs, and through Tutorials>BestPractices
Found this thread because I also just “discovered” that checking for one-time inputs (Input.anyKeyDown) in FixedUpdate will miss inputs. Interestingly, the link above (on December 12, 2019) takes you to the 2019.2 reference, which does put the polling in the Update method, setting a flag that is checked in FixedUpdate (this is a change from the sample code provided with 2019.1 and earlier versions).
Note that the flag system could, in an extreme situation, still miss an update: if, somehow, the user pressed the “Jump” button on two frames that called Update between two calls to FixedUpdate, FixedUpdate would only react to the most recent press; the earlier one would be ignored. A better fix might be to replace the flag with an integer counting presses, and have FixedUpdate loop on that, repeating and decrementing until it was zero (or, just set it to zero and multiply all effects by the number of presses).
They’re gutting the whole input system and making a new one (which is event-based and won’t have any of these problems) so it’s probably not worth attempting to fix edge cases in the old system.
Heh. While I will welcome any improvements, I really wish they’d put more effort into creating better documentation for the existing product before improving the product itself. But, I digress.
I agree that excessive worry about this is unwarranted. I made my observation because the problem addressed in this thread can be a bit subtle if one is not conversant with the timing of Update versus FixedUpdate. That same timing issue is why Unity’s “fix” in the 2019.2 doc still isn’t a real fix. Might never matter for this particular issue, but I do enjoy a thorough discussion of edge cases, as sometimes the concepts have application elsewhere.
Where did you learn that they are going to have an event-based system? I’d like to stay informed about that.
I sort of feel you may misunderstand what the “LTS” releases are? Because this statement doesn’t make sense. LTS = Long Term Support. It takes the last sub-version of the year, freezes all features and API, and just provides the minimum required compatibility updates and stability bugfixes. Wishing for 2019 LTS before 2019 is over is… a strange request.
(And they almost certainly will come out with 2019 LTS, but not until well into 2020. 2018.4 LTS came out in May 2019.)
Are you just saying that you wish 2019.x was more stable, or something?
2019 LTS (2019.4.x) will release around the same time as 2020.1, and will essentially be bug fixes for the yet to be released 2019.3 (with different rules for check ins).