Search Unity

  1. Going to #UniteBerlin? Bring a buddy & get 25% off the 2nd ticket! More info here.
    Dismiss Notice
  2. Famed game designer and creator of The Sims, SimCIty, and Spore is looking for a 3D artist to join their team. Join the challenge.
    Dismiss Notice
  3. Unity 2017.4 has arrived! Read about it here.
    Dismiss Notice
  4. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  5. Magic Leap’s Lumin SDK Technical Preview for Unity lets you get started creating content for Magic Leap One™. Find more information on our blog!
    Dismiss Notice
  6. We've opened a new World Building sub-forum to faciltate all your world building discussions! Drop in and ask any ProBuilder, ProGrids, or PolyBrush questions.
    Dismiss Notice
  7. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Correct way(s) to handle input; Docs contradictory?

Discussion in 'Documentation' started by Deeeds, Mar 30, 2018.

  1. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    154
    In the Script Reference, under Input, down the page:

    My question: If this is the old way of handling input, what's the new way?

    The position on the page is strange, the complete lack of context for "this" and the total lack of links to any current (not legacy) means of input handling are all poor form for a game engine proud of its documentation. This same quote appears in older versions of the docs, too.
     
  2. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    2,919
    As @Rene-Damm said in the other thread, that line's bogus. It seems to have been copied from here.

    The Input class is definitely the way to read input.
     
  3. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    154
    THANK YOU!

    Does this mean there's no prebuilt and generated events to listen to, that I always have to do an "if this input, then do this..."?
     
  4. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    2,919
    That depends. There's five different kinds of inputs when talking about Unity - four for gameplay, and one for editor scripts:

    - KeyCode, as seen in Input.GetKeyDown(KeyCode.Space)
    This system checks if a specific keyboard key is pressed down. You also get messages from controllers, with names like KeyCode.JoystickButton1.
    - "Buttons" as seen in Input.GetButtonDown("Fire")
    This works exactly like KeyCode, but uses the buttons set up in the Input Manager. This system also allows for some rudimentary rebinding, if you use the ugly, ugly default Unity launcher, as these keys show up in the "input" section.
    You also have to use this system to get access to a joystick axes (axises? axii?).
    - Touch, as seen in Input.GetTouch(0). This is only relevant for smartphones, and gives you data about where the user's fingers are.
    - the UI system does it's own Input handling through events. This is named the "Event System". It uses the same inputs as defined in "Buttons". In that case you create a button, assign a method to that button's OnClick, and then the method gets called when the button's clicked.
    - When you're creating editor extensions like editor windows and custom inspectors, there's a system based around the Event class. This naming is not confusing at all. This works very differently from the other systems, as the editor doesn't update at a steady framerate, but rather whenever you interact with it.


    Finally, if you're making games for consoles, they generally have their own Input API that Unity's input API may or may not work with.
     
    Deeeds likes this.
  5. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    154
    Does the UI System have a lower or higher latency than "buttons", keycode and touch?
     
  6. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    2,919
    I believe that behind the scenes, they're based on Input.GetButton, so there should be no difference. Whenever you add a Canvas to the scene, it'll add a "standalone input module", which references which buttons the UI cares about, and those buttons are the ones from the input manager.
     
    Deeeds likes this.
  7. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    154
    Thank you very much!

    This is very helpful/useful to know. Planning where to go, how to start and structure, etc.

    Cheers!!!
     
  8. Deeeds

    Deeeds

    Joined:
    Mar 15, 2018
    Posts:
    154
    sorry to bother you @Baste. I'm still very confused about input handling on iOS.

    In the manual: https://docs.unity3d.com/Manual/script-TouchInputModule.html

    The above is said to be deprecated/obsolete, that one should use the https://docs.unity3d.com/Manual/script-StandaloneInputModule.html

    But nowhere does this mention touch input.

    What am I supposed to do, just to read touches on the left and the right of an iOS device, (as flipper touches in a pinball game), with the lowest possible latency?