Check for User Input in FixedUpdate?

Hi everyone! I'm new around these here parts!

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...

 

I'm pretty sure it's fine.

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.

 

Thanks for the reply, angrypenguin.

In response to your last point, wouldn't there be occasional input loss? I did some more digging and found this post that might address the issue: http://answers.unity3d.com/questions/409507/eliminating-input-loss.html

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.

 

checking for inputs in a fixedupdate is a bad idee , it has to be in an update!

 

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 (https://docs.unity3d.com/ScriptReference/Rigidbody-velocity.html) 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

 

Thanks JoshuaMcKenzie

 

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.

 

There's this blog post (though they've been talking about it in various places for years, this is probably the most complete summary)

 

Thanks. That looks very promising. Wish they'd come out with a 2019 LTS release. So many nice features in 2019.

 

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).

 

Frustratingly, the Quick Start guide to the new input system, uses FixedUpdate in its example, seemingly unnecessarily.

https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/manual/QuickStartGuide.html

The explicit use of it here in a "quick start" example seems to endorse this approach as the "proper" way of doing it. They could have easily used "Update" instead if they wanted to. So this just adds more confusion.

I found this page here which shows how you can change the Input System to use Fixed Update or not. But the default appears to be Dynamic Update (the usual "Update" function). So why the example doesn't use plain old Update is baffling.

 

Are the GetKeyDown-related issues still present in the new input system? It's not hard to imagine a way to code an input system so that it doesn't break. Maybe they wrote that example deliberately to let experienced people know that input in FixedUpdate works now.

Or maybe someone clueless wrote the documentation.

 

After trying in FixedUpdate, Yes, button down events were missed, and also - the fact that you can change a setting for it to work in FixedUpdate or not, which is set to not by default, is further evidence that the instructions should not be written like that. (Already gave feedback via link on page.)

 

The setting you are referring to is not to make it work in FixedUpdate. Is to make it query input in fixed intervals of Time.FixedDeltaTime. Two different things.

 

This "fix" is as broken as putting the GetButtonDown inside of FixedUpdate. It (don't always) works exactly the same.

 

If that's the case, then I guess there's even less reason for the example to use FixedUpdate. I was using that as one reason as to why they might've done it that way.

 

I apologise for chiming in on this thread, but I have been struggling with this question for days now, and only yesterday posted a related question (again, apologies for linking to a different, and (in my normal fashion, extremely verbose) question):

https://forum.unity.com/threads/frame-rate-user-input-issues-60hz-monitors.881098/

In short, I am having problems where it feels like input is getting processed at slightly different times depending on the frame rate when using Update(), which made me go down a very long path......

If anyone reading this want's to chime in with advice on the linked issue, please, please feel free!

Cheers,

--Mike--

 

I was looking for this one specifically! I'm an absolute beginner, and I wanted to check for inputs in the update and apply the physics (add force) in the fixed update based on the input.

Having experience working on other languages, I have thought of some ways to achieve this using boolean - I just don't know if this is a good solution or if there is a better way of doing this. I don't feel that it's right putting code (conditional statements) in the fixed update, as I believe that I only should only put physics in it.

This may be too much to ask, but can you please explain this "poll" and give some general, simple example to illustrate this. If not, can you refer to some materials to read about this "poll".

Thank you in advance!

 

In this context, "poll" is another way of saying "check the status of" the input. In the comment you quoted, the person is saying it is best to check the status of an input in Update and apply any corresponding physics FixedUpdate.

 

Don't check for input.mousePosition in fixedupdate ! it gives wrong information