Search Unity

Check for User Input in FixedUpdate?

Discussion in 'Scripting' started by reinfeldx, Dec 3, 2013.

  1. reinfeldx

    reinfeldx

    Joined:
    Nov 23, 2013
    Posts:
    85
    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...
     
    Last edited: Dec 3, 2013
    SaSha_K likes this.
  2. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,321
    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.
     
  3. reinfeldx

    reinfeldx

    Joined:
    Nov 23, 2013
    Posts:
    85
    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?
     
    sandolkakos likes this.
  4. kurai

    kurai

    Joined:
    Jan 9, 2012
    Posts:
    110
    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.
     
    I-am-Lawrence likes this.
  5. KyleStaves

    KyleStaves

    Joined:
    Nov 4, 2009
    Posts:
    820
    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.
     
  6. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,562
    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.
     
  7. KelsoMRK

    KelsoMRK

    Joined:
    Jul 18, 2010
    Posts:
    5,466
    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.
     
    SaSha_K likes this.
  8. radokhlebov

    radokhlebov

    Joined:
    Mar 13, 2015
    Posts:
    14
    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.
     
    SolutionsGameDev likes this.
  9. elseforty

    elseforty

    Joined:
    Apr 3, 2018
    Posts:
    188
    checking for inputs in a fixedupdate is a bad idee , it has to be in an update!
     
    Last edited: Jul 4, 2018
  10. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    7,253
    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.
     
  11. jzzja

    jzzja

    Joined:
    Sep 28, 2017
    Posts:
    42
    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.
     
  12. JoshuaMcKenzie

    JoshuaMcKenzie

    Joined:
    Jun 20, 2015
    Posts:
    824
    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
     
  13. jzzja

    jzzja

    Joined:
    Sep 28, 2017
    Posts:
    42
    Thanks JoshuaMcKenzie
     
  14. stevensrmiller

    stevensrmiller

    Joined:
    Oct 20, 2017
    Posts:
    183
    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).
     
  15. StarManta

    StarManta

    Joined:
    Oct 23, 2006
    Posts:
    7,071
    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.
     
  16. stevensrmiller

    stevensrmiller

    Joined:
    Oct 20, 2017
    Posts:
    183
    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.
     
  17. StarManta

    StarManta

    Joined:
    Oct 23, 2006
    Posts:
    7,071
    There's this blog post (though they've been talking about it in various places for years, this is probably the most complete summary)
     
  18. stevensrmiller

    stevensrmiller

    Joined:
    Oct 20, 2017
    Posts:
    183
    Thanks. That looks very promising. Wish they'd come out with a 2019 LTS release. So many nice features in 2019.
     
  19. StarManta

    StarManta

    Joined:
    Oct 23, 2006
    Posts:
    7,071
    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?
     
    Joe-Censored likes this.
  20. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    7,253
    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).
     
unityunity