We need the separate function calls in order to be able to let various devices and action maps choose to use a given event or not, and in case it’s used, it should not be available to subsequent handlers. This is a core part in the design of ensuring that the same input doesn’t accidentally affect multiple things at once (like controlling the character and a menu at the same time for example). I’ll leave René to discuss the performance aspects - he’s currently on vacation though.
FixedUpdate has to be called consecutively due to how a game loop works. We can’t call FixedUpdate evenly spaced in real time, in the middle of some frame rendering. But we will feed each FixedUpdate only with the events with timestampts going up to the time that the FixedUpdate corresponds to. This way they will work as if they were evenly spaced from an input point of view, even though they’re not.
I’ve yet to try this new input system out, I probably would have if it was actually getting updates that started to show it was worth implementing over the current input system… but I’ve never seen a single update since this thread started…
Its been over 3months already what is the progress of it now?
It appears the update to 5.4 breaks at least some part of the prototype.
I now get the following error from Unity when starting a scene.
get_isPlayingOrWillChangePlaymode is not allowed to be called from a ScriptableObject constructor (or instance field initializer), call it in OnEnable instead. Called from ScriptableObject 'ActionMap'.
See "Script Serialization" page in the Unity Manual for further details.
UnityEngine.InputNew.ActionMap:.cctor()
It hasn’t seemed to have affected input as far as I can tell (it appears to be working) but is a bit…scary to know something is probably broken somewhere.
I can understand the desire for an update on the status of the Input System!
The status is that we’re working hard on it. There’s still a lot of work to be done, especially given we’re a small two-person team.
One thing I should make clear is that the final system will not be directly a continuation of the prototype. As you know, the final system will have a brand new backend, as opposed to the prototype which is built on top of the current (old) input system. Furthermore, we’re still doing a lot of development and refactoring. All this means that
The final system will not be fully compatible with the prototype, but will be very similar in overall design.
It’s not viable for us to provide continuous updates to the prototype since we’re internally working on the proper release version, and doing updates of the prototype version would take resources away from that.
Some of the features we’re working on integrating support for at the moment are:
Haptics / rumble support. This is a major design addition when taking into account how it affects ActionMaps, and that the haptics/output capabilities of different devices are very different.
More flexibility in controls and control bindings. We heard you - you need to define modifier keys, key sequences, response curves etc. These features in themselves are not the important part in the work we’re doing now, but rather ensuring the bindings and controls framework is designed such that it’s easy to implement all these things and more, both for us and in user extensions. We’re also handling some other considerations for how the controls work while we’re at it.
There’s many other things than this too, but those are two of the big ones.
I want to thank you all for testing the new input system so much and providing detailed feedback. This has been a great validation for us that we’re on the right track and should go ahead full power with the proper release version of this, taking all your notes and suggestions into account as well.
This is not to say that we won’t be needing any more input from you. Once the proper version of the input system is in a sufficiently usable state, we’ll enter into a new period of close feedback cycles with all of you. But bear with us while we’re doing the work to get to that point. Thanks for your patience!
Phew! I was afraid it wouldn’t replace the existing system and get it’s own place in the editor, rather than being an extension to the current system. Thanks for reassuring me that that’s not the case, because this new system is awesome and the old system should go to h***
Is there a version of this for 5.4 to play about with? (Obviously not for a production release) Also what kind of feedback are you looking for with it?
Sounds good. I would like if a input layout was made such that a keyboard & mouse with simulated SW X-Box/PlayStation/Android Game Controller functionality, X-Box Controller, Play Station Controller, & Android Game Controller, and equivalent of those as a SW touch controller where auto-detected and the controller template shown to the player with a toggle switch a game start.
I downloaded and went through about 20 screens of the app explaining how to control and play a mobile game from Major League Baseball (Their Line Drive application) that was way over the top and so specific to their game those game controls were. Too much work so I uninstalled in about screen 20 of their game controller instructions.
Well, it seems it’s undergoing big redesign and not ready for beta testers. I will use the existing package as beta and see if that simplifies my task.
Thank you! Standalone keyboard player input is hard. We basically need the entire input system to be able to be bound with and without modifier keys for any action.
However, the biggest struggle that I’m running into right now is with localization of PC/Standalone input on international keyboards. I really want to make try to see if Unity can provide me with the localized keyboard character/name for the key press (in a cross-platform way) and allow me to bind layouts based on keyboard position. So that in the UI we can show the player via tutorial hey the OEMQUESTION keyboard command is a “/” character in the US an a “!” on a French keyboard. We want to support better localization, but it is hard and not cross-platform. We want to inform the user “Press {0} to open Journal” regardless of which keyboard localization they’re using. Or if we’re making a first person shooter that is defaulted to WADS controls are bound to to ZQSD by default. We need this support not only in the launcher but be accessible in-game player APIs so we can present the binder in a more branded/skinned way.
Allow binding to keycode and scancode (have inventory bound to “I”, movement bound to WASD-positions)
Get localized key name from keycode and scancode (scancode as well because we need to display the letter of the WASD-keys on non-QWERTY layouts; localized name is necessarily in system language)
Allow recognizing binding conflicts between scancode and keycode (there is preconfigured binding both to scancodes and keycodes; key binding dialog needs a way to recognize conflicts with both types of binding if user re-binds a command)
Necessary for lots of games to do key binding right, on Standalone platforms, and if possible at least on XboxOne and PS4 as well.
Oh, come on!!!
That’s the first thing that came to my mind when I read about the new Input System.
Having to ask people to download a driver is not cool, I was hoping the game would include a driver.
You can do it!
So, if I’m correct in thinking having a game include a driver would actually be down to the developer of the game itself and not the unity team. Especially since there are probably distribution licenses associated with the drivers in where they can only be downloaded from x site and not included for distribution…
It’s my impression driver installation is the responsibility of
Hardware manufacturers
The OS
The user
Having games begin to install hardware drivers on your system seems like it’ll open a can of worms. It’s possible I’m missing something though. If you have examples of games or game engines that do install hardware drivers, please start a new thread dedicated to discussing this and let us know about it there. Thanks!
This might be discussed, so ignore if I read over it but:
Hardware specific drivers are a no-go of course, but addressing the platforms’ hardware abstraction layer like a direct input to support rumble vibration on a gamepad should be pretty standard on any game engine.
