Input Management... is it better yet?

I'm curious if we're every going to see improvements on input management. The current input system is clunky, imho, and I have to create my own input management systems just so players can modify their controls in game. Looking at the feedback site this feature was voted on substantially YEARS ago, yet I've heard no word that anything is being worked on.

 

No, it's not better yet. It's being worked on but it will be a long time before we see any changes. http://unity3d.com/unity/roadmap/

 

Someone should buy isthenewinputoutyet.com - I have no funds for that, but someone should.

 

Only if they set a date for it, but never deliver. That's when it can become a meme.

You would think this would be mildly easier than the GUI to please everybody, so long as they don't rip out input and/or event. Especially event since I imagine no one want to even admit onGUI is a thing that still exists since it's status has been relegated to the editor.

 

I feel your pain. I got tired of waiting (5+ years) for Unity to fix it and wrote Rewired. It does pretty much everything you'd have wanted Unity's input manager to do and buckets more, plus it's based on native input so it supports more than 20 buttons per controller (useful for flight sims for instance). And now it even comes with a Unity GUI-based in-game control remapping system. There's a free trial on my website if you're interested.

 

OnGUI is super handy. I wouldn't plan to use it in production, but I find it really useful to be able to quickly slap stuff up on the screen while developing components.

Edit: Oh, typo!

 

The new GUI works pretty well, also.

 

They're very different things and both have their uses. There's nothing wrong with using OnGUI in production, either.

--Eric

 

Code (csharp):

1.  
2. void OnGUI() {
3.     GUI.Label(new Rect(0, 0, 500, 20), "Yeah, but it takes far longer than this.");
4. }
5.  

True, I've shipped many a project using OnGUI.

 

You're straight thug, master penguin.

 

But in a bizarre twist, including OnGUI code in production is pretty much the only way to do runtime configurable input.

Once I got used to the paradigm shift I find UI faster.

 

I'm just going to give a quick shoutout to InControl.
Originally we used it because it creates a uniform way of supporting several different controllers - key rebinding is just icing on the cake.

 

I find the new system far better for making fully-fledged game GUIs. If I just want a quick readout of internals for something, though, I'm far more likely to do a bunch of OnGUI labels. Mainly because I can do them in-place and they just magically appear on the screen, and when I'm done I just comment it out or delete the method. With the new system I have to generate the various bits and pieces as GameObjects and hook them up, and then I've got two places to delete stuff from, and so on.

 

No it's not. Check this out: Control Mapper

 

Hmm, I'm tempted to buy it just to pull it apart and see how it works.

My remappable input is pretty crude. It's basically just a wrapper for Unity's input, with a layer of misdirection.

 

Native code. If I recall correctly he's completely bypassing Unity's input system for the supported platforms.

 

As our Roadmap says; we are working on it. No ETA though, sorry!

 

I thought so. I was wondering if doing the same thing would help our battery obsessed friend. In theory you could simply stop everything until you picked up an input in your native thread.

 

You should definitely checkout Rewired Control Mapper and then coupled with Native Input (DirectInput or RawInput) on Windows. There is also Unity fallback (on platforms with Native support) if someone really needs that for a specific reason.

Rewired new Control Mapper works with the new Unity UI for remapping controllers which works great. You should get the Rewired free trial and at least check it out.

If you are using Flight Controllers with Unity you are already dead in the water since most of the best controllers (e.g. HOTAS systems like ThrustMaster's Warthog) already exceed the Unity 20 button count easily. Take CH FighterStick for example. You have over 30 buttons and then 3 modes which gives you over 90 combinations. I think CH says there are 176 combinations on the FighterStick controller. Then you need to find a customer (i.e. the final end users) who will actually map all of the functions on a controller the same way. Thankfully Rewired Control Mapper solves that problem nicely.

Just looking at Elite Dangerous game as a guide, it is so nice to see customers so willingly spending $300-$600 just on Flight Controllers. I like customers like that who are so willing to invest in good controllers for a game/simulation. But the customers never seem to map their controllers in the same way either. If you have customers spending that type of money on controllers you better hope you can at the very least detect all of those controllers so the customer can remap them.

Thankfully Rewired does an amazing job of supporting the best Flight Controllers automatically and more importantly not just detect but all of the details of all 30+ buttons of each controller. Then you have Rewired Control Mapper to handle all of the remapping of the controller too.

I am surprised more people have not tried Rewired and see if it works for them. Especially with the free trial version of Rewired available to test it out before purchasing.

 

I usually have 1 ongui label somewhere for debugging, but I love setting up the new stuff. I recall hating it very strongly in the initial release, but I figured it out now. The first hour of every project is making sure the GUI is setup right lol

Can't you defined an array / list / whatever of acceptable keys and then have your classes that receive input have some public KeyCode references? Then you could rebind keys as long as your game could listen for input.

I have yet to try this But I assume it could work. KeyCode jump = listenForAcceptableKey();

 

If you only use the keyboard that works great. Alas that approach doesn't support mice or joystick axes.

 

I'm less worried about which to use, so much as which is UT seriously supporting. I can't see anyone actually trying to retrofit a new input system onto the old OnGUI, which is also to effectively to say it's at the end of it's life. It'll be kicked down the road some for the editor and that's it. Unless they decide to cut it out of the engine and move it purely to the editor, it's just going to sit where it is and rot.

 

It's been like 4+ years guys. C'mon now...

 

10 you mean. But the Input manager is fine for games as evidenced by the wealth of published games already. It's hardly broken or unusable. But it can be improved. Thus, a lower priority.

 

4 years? What event happened 4 years ago that you are basing your wait from?

 

The creation of the feature request in the feedback site, if my memory is correct. Either way I'm just being playful. I don't ACTUALLY jab with memes, haha.

 

The area where it is long in the tooth is controller support. Keyboard/mouse and touch inputs work but with controllers (especially on PC/Mac/Linux) there are issues.

As mentioned earlier in the thread, Rewired and InControl (both excellent assets) exist for this very reason to replace the Unity API with their own.

I also have an asset (currently under review should be out within two weeks) that will auto generate the best possible controller support within the Unity API in under 5 minutes from your already existing keyboard/mouse controls so no code needs to get changed. This "best possible" gets you 100% of the way there on consoles, android, IOS, etc. but on standalone within the Unity API you can only hit about 80% market coverage because certain controllers conflict with each others mappings.

 

But the question shouldn't just be "can it be made to work?", should it?

 

How many of those games are using Unity's input system and how many of them are using third parties?

 

Just look for the key binding options.

 

You could iterate over a list of acceptable keys. But that limits you to using only keys on your list. I guess you could iterate over the entire KeyCode enum. That just seemed painful to me.

The only way I discovered within the Unity API to listen for an arbitrary key code was checking Event.current.button inside if OnGUI. It's robust enough for my little games.

But if I needed something bigger I'd probably just go to the store as others are suggesting.

 

Problem is, even just having a single OnGUI method in one of your scripts (even if empty) will cause the legacy GUI system to run and generate memory allocations every frame. Polling every KeyCode each frame is preferable, especially on mobile (assuming you want keyboard support on mobile).

 

I'll have to profile this and see. My nieve assumption was OnGUI would not cause issues if it was disabled most of the game. It only gets switched on during the actual key binding process.

Either way I've still got a ton of processing power to spare, so it's not a big issue for my current projects.

 

True, if you turn off the Game Object or disable the Monobehaviour it will stop the allocations. If it's only running during keybinding, either way would likely be fine.

 

There are no keycodes for controller axis (left stick, right stick, triggers, dpad). There are also no standards an xbox controller trigger might be axis 3 but a bluetooth controller trigger might be axis 7. They also conflict with eachother within the Unity API making things a bigger mess and GetJoystickNames is not reliable.

Rewired and InControl use their own API to get around this, but within the Unity API it's not possible to support all controllers.

Rebinding keyboard within the Unity API is also not possible. The lightest weight would be a wrapper around it that either polls the keycodes like guavaman suggested, the more expensive suggestion that bored mormon suggested, or something like CInput where they essentially have every input in the inputmanager and then use their api to reroute accordingly.

 

Yeah, my solution is key board only. It wraps Unity's input. I basically recalculate the axis each frame based on the key codes I feed it.

I didn't realise controllers could get so messy.

 

But unity does that, right? Can you store that event and add it to your acceptable keys function for in game input? Is that what third party solutions do?

 

Controllers are a huge, insane mess in Unity, especially when you're talking multi-player and cross platform. There's some info on it on my site under the section "Problems With Unity Input". (There's a LOT not mentioned there too that I discovered while developing Rewired, and a slew of different woes on each platform.) And many, many forum posts on this topic stretching back years and years (many of which are mine : ). What greggtwp16 mentioned is just the tip of the iceberg. Of all the systems in Unity, it has to be the most broken.

 

Sadly, for axes, using Unity input, there's no alternative but to set them up in the input manager. The worst part is how slow calling GetAxis is due to the use of strings. It's pretty heavy on mobile if you have a lot of axes.

 

Yes, believe me I'm aware of this I recently submitted an asset of my own to the store for input that's soon to be live (http://ladmertech.com/auto-gamepad-generator/). It doesn't cater to the same audience as your product, it's more for those that chose not to support controllers, that now can throw it in after the fact, in less than 5 minutes.

As for the strings, declaring the strings as public const in a constants file and passing them into GetAxis should mean that they are always in memory and no allocations are happening after the first time with no GC. Or are you referring to something else?

BTW, love your product I've used it for a long time when I need full controller support.

 

Thanks for the link! Looks interesting. I'll check it out when it's available.

One thing I noticed in your technical deep dive video around 4:20, you state:

This isn't true of Rewired. Rewired's player-centric system means you assign any kind of input to your Player, then you get the input from the Player instead of the controller and input becomes source-agnostic. There is no need to write separate keyboard and joystick code at all. A simple player.GetAxis("MoveHorizontal") will get the axis value whether the source is keyboard, mouse, joystick, or even a touch controller set up through a Custom Controller. There's even an optional mouse movement mode where it can be treated like a joystick of sorts.

It's not GC I'm concerned with, it's simply the speed of string comparisons. Android and iOS devices are very slow at string comparisons. This is easy to benchmark by comparing how much slower joystick button polling is through Input.GetAxis vs Input.GetKey. GetKey only works for the first 4 joysticks however.

Thanks, glad you like it!

 

Yeah, I guess I should have stated that clearer. What you state is true, but I'm approaching the entire product from the perspective of someone who has used Unity's input API for the keyboard/mouse (obviously it's the whole point of the product). They would not be able to then with rewired reuse that code since rewired is a different separate API. That's what the "other" meant.

Now, if they are just starting writing their game and used rewired from the start what you describe is true. That's just not where my product is coming from since it's essentially an automatic remapper for controller off the Unity API, which allows you to get controller support without changing code or using another API. Essentially, I think we are in totally different spaces. I view mine as a "hey I didn't support controllers and now I get to throw it in with little effort" (or had an oversight and don't want to redo things). Rewired, essentially is full support (hot pluggable, vibration supported, etc.) which is great for a multiplayer game with that in mind from the start but you have to plan accordingly.

Essentially, I feel there are a number of PC games that don't currently support controllers at all that can now easily click a few buttons and they can use controllers just fine.

Or at least I hope so, otherwise it won't sell well.

 

I think I get it now. They've already got keyboard code (assuming it uses GetAxis and not GetKey), now they want to add controller code without having to change their existing Input calls or add another API along side their existing code for joystick support. From the video it sounded different. Thanks for clarifying.

True, but it's super easy to change existing code to use Rewired for a single player game. Do a simple find and replace of "Input.GetButton" with "ReInput.players.GetPlayer(0).GetButton" and the same for GetAxis in all your code and that's it. (Assuming you've set your Actions up already.) Of course, it's cleaner looking if you cache your Player object in your script first.

 

No, it's not an "event". Axes have to be polled via the Input class, have to be set up in the Input Manager in the Editor and can't be modified at runtime. 3rd party solutions get around that by either adding entries for every possible input and writing their own layer on top of that, or by writing their own lower level input systems and not using what's built into Unity.

 

That's what I was thinking of. I don't vocabulary correctly frequently. It's a big problem at my job where I don't know any officials names for anything but when it gets explained to me it's something I've been doing for 2-5 years.

 

Just for fun I profiled it:

Code (csharp):

1. // Keyboard polling: 9.504352E-06 s / frame
2. // (as timed, avg of 1000 frames, profiler reports 0.00 ms)
3.  
4. private int[] values;
5. private bool[] keys;
6.  
7. void Awake() {
8.     values = (int[])System.Enum.GetValues(typeof(KeyCode));
9.     keys = new bool[values.Length];
10. }
11.  
12. void Update() {
13.     for(int i = 0; i < values.Length; i++) {
14.         keys[i] = Input.GetKey((KeyCode)values[i]);
15.     }
16. }

Code (csharp):

1. // OnGUI: 0.02 ms (as reported by profiler), 336 bytes GC / frame
2. void OnGUI() {
3.     // there is no code in here
4. }

Keyboard polling is more efficient.

 

Never would have expected that. I may just have to upgrade. If I ever get to the point that 0.02ms on my menu screen bothers me.

 

@guavaman wow that's really interesting and useful! Kind of amusing that OnGUI has that kind of 'performance hit' with no code in it haha.

 

I know. It's important to know that if you're writing a game or a plugin that needs to be cross platform. Mobile platforms simply should not have a call to OnGUI enabled unless absolutely necessary. If you don't know about the GC penalty, you won't know to disable them and might do something like:

Code (csharp):

1. void OnGUI() {
2.     if(noGUIStuffNecessary) return;
3.     // GUI code
4. }

But if you do that, you're still going to incur the penalty. What you have to do instead is have your OnGUI code in another MonoBehaviour and AddComponent it and or enable/disable it as needed.

 

Couldn't you just put it in a directive?
http://docs.unity3d.com/Manual/PlatformDependentCompilation.html

ie.
#if UNITY_EDITOR
void OnGUI() {
...
}
#endif