Feedback Input.GetKeyUp , Input.GetKeyDown, Horizontal, Vertical ??

hello guys,

what is the equivalent of

Input.GetKeyUp
Input.GetKeyDown

and

Horizontal (mouse) for headlook
Vertical (mouse) for headlook

on new input system?

thanks.


and what about android?? does exists UI controllers on this package or what?

 

@Rene-Damm Made a great talk at Unite Copenhagen, it released on Unity's youtube you should check it out to know the basics

 

you mean this?

i want clear answer :|

 

The video yes.

There is no "clear" answer as there is multiple ways of doing what you want, come requiring a bit more setup than other. But overall, I would highly recommend taking the time to learn and experiment, it's worth it !

 

As an exercise I've converted my free camera control script using the new input system. While everything works as it should, I'm still not sure I'm not overcomplicating things.

For example, my script has the drag feature: when you click a point on the terrain and then drag it, the camera moves according this drag movement, keeping this exact terrain point always under the cursor. Previously the drag mode was activated by Input.GetMouseButtonDown and deactivated by Input.GetMouseButtonUp.

In the new input system I still don't know how to easily differentiate button up and down events from each other, so I just read the raw value instead:

Here is a part of my Update method:

Code (CSharp):

1. var isDragButtonPressed = controls.Camera.Drag.ReadValue<float>() > 0;
2. if (inDragMode == false && isDragButtonPressed)
3. {
4.     inDragMode = true;
5.     // drag mode activated
6.     return;
7. }
8.  
9. if (inDragMode)
10. {
11.     if (isDragButtonPressed == false)
12.     {
13.         inDragMode = false;
14.         // drag mode deactivated
15.         return;
16.     }
17.  
18.     // do stuff in drag mode
19.     return;
20. }
21.  
22. // not in drag mode
23.  

It works but doesn't look elegant or easy to understand. The old version was more straightforward:

Code (CSharp):

1. if (Input.GetMouseButtonDown(button))
2. {
3.     inDragMode = true;
4.     // drag mode activated
5.     return;
6. }
7.  
8. if (Input.GetMouseButtonUp(button))
9. {
10.     inDragMode = false;
11.     // drag mode deactivated;
12.     return;
13. }
14.  
15. if (inDragMode)
16. {
17.     // in drag mode
18.     return;
19. }
20.  
21. // not in drag mode

I also don't like the fact that to check such simple thing as whether a key or button is currently pressed I have to write ReadValue<float>() > 0. Keys and buttons are either pressed or not pressed, they are bools or enums, not floats.

 

Docs

Docs

Set up input as described in docs. Use "Look" action.

 

There's no way of doing so using the polling API (which is a condensed API mostly there for convenience). Using callbacks, InputAction.started == press and InputAction.canceled == release.

Code (CSharp):

1. public static class MyExtensions
2. {
3.     public static bool IsPressed(this InputAction action)
4.     {
5.         return action.ReadValue<float>() >= InputSystem.settings.defaultButtonPressPoint;
6.     }
7. }

Something like this will probably make its way into the public API in one form or another.

 

i think it would be great if we assign just traditional keyboard and mouse to our scripts and then new input convert it to all of keys and gamepads and joystics based on defined map at build time !! i mean easy peasy

 

There absolutely should be a way to do this in a polling way. Polling is almost always the better way to structure your code. You don't want to have all input handling scattered around in different callbacks, for me this is an anti-pattern.

 

If this is truly the only thing, nothing stops you to put all the callbacks in one file...

I fundamentally disagree though.

 

Why do you think polling is inferior?
You can just have one `HandleInput()` function that deals with all input state and there is no ambiguity about order of function calls, having to memoize state between callbacks, no function call overhead, easier to read, easier to understand...

functions like

Code (CSharp):

1. public void OnMove(InputValue value)
2. {
3.     m_Move = value.Get<Vector2>();
4. }
5. public void OnLook(InputValue value)
6. {
7.     m_Look = value.Get<Vector2>();
8. }
9.  

(this is code from a unity blog post about the new input system)

are just superflous to have. `m_Move` or `m_Look` should just be local variables and there is no reason why you would wanna keep them across frame boundaries.

In the end it's a matter of taste I guess.

 

Pulling is basically a giant if-elseif or switch in an Update loop. Beside the fact that it is totally unnecessary code running in every frame (they are already polling where they should), it is cramped in a code path it doesn't belong.

Not to mention that the event-based format can be used across the application without extra Update event calls and without having reference to the Input system on the classes where you handle the actions. In other words, you can put the I in the S.O.L.I.D without the performance penalty of pulling.

I am not judging though, I too did created pulling systems in prototypes, sometimes it is faster (although when you have a small, common set of actions already, just import it in and fill in the blanks and add extra actions).

On the contrary. Having action handlers make your code more readable, you don't have to try to declutter one method for all your actions... The Single Responsibility isn't just for classes, it's for methods too (so you can put an S in the SOLID too). Make your code more readable. Especially when you have relatively high number of actions.