Input class vs standalone Input module vs event system vs Input manager vs manual vs google v reddit

TL/DR /Just questions for people who don't want to read a rant (understandable):

1. The standAloneInputmodule - What is it for & why?
2. Please provide examples of how to use standaloneinputmodule.
3. Please provide examples of where standaloneinputmodule should not be used (in relation to input or event system)
4. I am confused about which does what among the Input class the baseInput class the standalone input module and event system & could use some simple explanations to compartmentalise these apparenlty seperate entities that I can remember & apply usefully.


/The more ranty version I stabbed out of my keyboard earlier:

Sit rep: Confused about the right way to handle user input 'stuff' in unity de jour (its nearly June in 2017 if that helps because god knows the answers are going to be different next year).

So, I want to have a situation based mouse/pointer that gives the user feed back on what they can & can't do in various situations. I also want a bunch of other similar input stuff that 'seems' to relate to this 'stanalone input module' thing (that name is far too long UT). But it also seems to overlap or conflict with with the input class or event system or both.

Also this module thingy works nothing like other unity systems & you have to do the c# equivilant of standing on one leg while whistling the national anthem to use the thing.

There is no simple explanation of what the hell the thing is designed to do, or why its there, or what it replaced. There are no real world useful examples of how to use it and there is just buckets of older depricated stuff that used to be there but now just makes searching for answers for 'todays' unity input stuff impossible.

My questions about the (sigh) StandAloneComplex input module only get more granular - like -
why the hell am I overriding/extending/plastering some inaccessible script inside unitys guts to use this thing?
Should I use update() in my (custom??) expounded module? whats this Process() method for? etc etc?

But mostly the question that I found myself shouting at the monitor was 'Where are the ***king instructions unity team?'

Sorry ppl - I get ansty when my time is wasted on entirely avoidable issues that I have no control over.

 

Can you be more specific about what you're trying to do, exactly? Most of this is a rant so it's hard to figure out what it is you want and what is not working out for you. I understand you are frustrated, but try to put that aside so its easier for people to help.

 

Hey there thanks for your patience, I'll edit the sucker & make it less ranty. Simple questions then:
1. I really need a comprehsive guide to handling input in unity 5.6 & the manual isnt helping - where is it?
2. Given I want dynamic mouse/pointer events that change things in the app - should I use/extend/make a custom version of the StandAloneInputModule for this purpose?

Lots of other questions but they are just comming from the lack of info on the topic.

 

Hi, I feel your pain on this so much, because I was there all last night trying to make sense of Unity's cryptic documentation regarding input + events, but I think I can now help you out on the basic ideas.

Real quick background on my specific project needs so you know where I'm coming from: Up til yesterday, I've avoided Unity's UI system, instead using animated sprites and my own coroutines that checked for input via Unity's input manager. This worked fine for me, because all I had to worry about was a title menu with two buttons: Play or Quit, plus I like my UI in world space (I know, I know. this can be done with Unity's UI system too).

Here's my title menu in game:​

That is from the demo. I'm currently making this game into a commercial release, which means I'll need options menus, inventory menus, save data, etc. I attempted this with my tried and true method from above, but the amount of possible input combinations (pc or mac? controller or keyboard?) combined with a lot more button options became overwhelming for my simple system. I needed a less messy, better written, more user friendly solution.

So, to shed some light on your overall frustration: "what are all these different input components for, because Unity sucks at explaining them, but I feel like I could use them if I wasn't so lost."

• Here's my simple explanation:The basic function of the Standalone Input Module seems to be that it streamlines Input Manager Inputs, specifically to be understood by Unity's Event System, so that it knows when to navigate UI Buttons or call events.

I created a new project just to figure all this out last night, with out knowing any of this and just watched lots of tutorials, but eventually I got the hang of it at around 5:30 am. It's actually very powerful because you can call custom public functions on any gameobject. This is done by most people via UI interaction, but you can do it in world space via raycasting at Gameobjects with colliders too. And the best part: you don't have to add any special code to your script for the Event System to interact with it, you just need to have public functions in your script (which in the case of UI buttons, will appear on a drop down menu under OnClick()).

I'm still wrapping my head around these concepts (like I think "OnClick()" really just means when a button is successfully pressed by any kind of input), but it sounds like your mouse input idea would work very well with only the basic functionality that I described. I'd highly recommend looking at Unity's official beginner UI tutorials from way back in Unity 4.6 days when these systems were first released. It's a great place to start understanding Unity's strange logic regarding input + events. Hope this helps!

 

I'm in a similar position; there's this 'new' EventSystem but even after 2 years the documentation seems half-finished, and it's not clear whether it's only for GUI operation or whether it handles more general input as well.

For example, say I want to catch any click on the screen anywhere. This document implies that simply having an EventTrigger in the scene somewhere will do this. - https://docs.unity3d.com/ScriptReference/EventSystems.EventTrigger.html

However, I have one of those in the scene and it never receives events. I can click on one of the new Unity UI Button objects and it works, so obviously the EventSystem is operational - it's just that the EventTrigger doesn't seem to do what it claims it does.

A further example of how the documentation is lacking: if you look in the Input section of the Manual (https://docs.unity3d.com/Manual/Input.html) and go to the Mobile Device Input section, they talk about using the Input class. But if you go to the Scripting part of the docs to read about the Input class (https://docs.unity3d.com/ScriptReference/Input.html) it tells you that "This component relates to legacy methods for drawing UI textures and images to the screen. You should use Unity’s up-to-date UI system instead." So it's hard to know how we're supposed to proceed.

Any hints on how best to handle arbitrary mouse clicks and screen presses in 2017 are much appreciated!

 

1. The input class is the underlying input and is not related to UI. The input class is where you map inputs for actual game control, or querying the state of a button, or whatever.

2. Unity UI and GUI are not the same thing. Whenever GUI is mentioned it typically refers to IMGUI, the name for the immediate mode ui typically used to build the Unity editor itself, tools and debugging. GUI is not designed to work with event system.

3. Unity UI is the name for the runtime game friendly UI, and is designed to work with event system. Typically this is called UI or Unity UI not GUI or IMGUI.

4. The confusion is Unity's fault. It could have been avoided but Unity decided it would be fine. Regardless, since then, Unity's taken pains to rename the GUI to IMGUI, which should reduce confusion.

 

Okay, I think that just confused matters more for me than actually resolving them. Like I said, the Input docs page says "this component relates to legacy methods". I don't particularly care which legacy methods they are - I just care about whether Input is still the main way to handle input or not, especially input that is not at all related to clicking/pressing user interface widgets like buttons. To repeat, I'm not interested in UI right now, just in handling input.

 

Input is the main way to handle keyboard input, joypad input etc. I would recommend an Input Manager such as Rewired or InControl. Both are the only options in my view. These handle all controllers, such as xbox, ps etc. Note: I am referring to https://docs.unity3d.com/Manual/class-InputManager.html

The input managers are designed to make it a smooth and easy process, otherwise you'll just have to handle it yourself.

This thing has nothing to do with user interfaces, and never will have anything to do with user interfaces. It's job is to map input to something you can check and deal with. Such as querying if a button was pressed. It doesn't do anything else.

The options I mentioned above are cheap, but they're the way you dominate the decade old unity input beast. In future, make a new post instead, or you'll get misunderstood. Typically most threads are already pretty confused as confused people tend to post more.

TLDR.
https://docs.unity3d.com/Manual/class-InputManager.html <<< this is used for unity input, period.

I've locked this thread because it's basically just a mess with no sanity to it. If you still have input problems, make a new thread.