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

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.

 

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.

 

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

 

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.

 

Does the UI System have a lower or higher latency than "buttons", keycode and touch?

 

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.

 

Thank you very much!

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

Cheers!!!

 

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?