New Input System for UI Touch Controls

[warped locust]

There is OnScreenControls or OnScreenButton Behaviour for this, but they are not too convenient because we are sending a keycode rather than the input directly like Vector2

Will there be more conventional way for this?
For building cross-platform (mobile included) this really slows mobile development, because sometimes there is a bug where OnScreenButton was sending LMB or RMB, make the other OnScreenControls stuck.

Please let us send the value (e.g Movement) directly rather than sending a gamepad Left Stick

[pulsar scroll]

Hi, The input is directed though the control paths (such as <Gamepad>/leftStick ) to provide a mechanism for the resultant systems to react. The Vector2 value in this case is passed to any behaviour listing to the action, so you do have the Vector2 value passed.

[warped locust]

yes this is not too conventional.

Because eventhough I build a mobile game, I still need to create a gamepad input actions which is a dirty workaround...

[pulsar scroll]

As for the bug with LMB (Left Mouse Button) interfering with other OnScreenControls, I would recommend raising a bug report with an attached reproduction case so we can investigate. If the UI is responding the the LMB as well as the game actions (which is quite viable) then I can imaging the systems may interfere with each other.

A work around could be for triggering an alternative input response that the UI doesn't process but your target system does.

Can I clarify my understanding of your request.

How are you imagine vector2 value to be passed to your own systems. Are you wanting to see this value directly on the On-Screen Stick component as a public field?

At the moment the control path route is used to allow simpler communication between systems (rather than having to query the on screen control directly)

If this is the request, my suggestion as a workaround would be to take a copy of the code in the package and implement your own variant for this case. Storing that data on the component as its triggered. E.g. here:
https://github.com/Unity-Technologies/InputSystem/blob/ab1b38a7b88a23a72fa519f66ed2fd345d85b373/Packages/com.unity.inputsystem/InputSystem/Plugins/OnScreen/OnScreenStick.cs#L189

[warped locust]

rather thans sending "Left Stick (Gamepad)", Why cant developers send "Move"?

[pulsar scroll]

Thank you, this ask is clearer. I'll take this to our internal teams for discussion as a feature request.

[fast quest]

Thanks @warped locust for reaching out. I understand it might be desirable to programatically trigger an InputAction like to that if I understand you correctly what you suggested would be to inject a Vector2 value into the Action?
To support that and circumvent the underlying sequence of a device control triggering a binding and a binding triggering an InputAction would make some of the functionality or guarantees provided by an InputAction visible via CallbackContext problematic unfortunately which would break the current concept a bit. For each InputAction performed event there is an associated CallbackContext containing additional information like underlying control etc. which would be difficult to populate in a consistent way if the source of the data was not a control. However you have the option of using any control that generates a Vector2 in this example.

If you check the source code for OnScreenStick you will notice it generates a Vector2: https://github.com/Unity-Technologies/InputSystem/blob/develop/Packages/com.unity.inputsystem/InputSystem/Plugins/OnScreen/OnScreenStick.cs#L189C25-L189C25

Also notice that the OnScreenButton and OnScreenStick components allow you to set what control to be used in the Inspector. Note that in the sample both keyboard and gamepad configuration is examplified: https://github.com/Unity-Technologies/InputSystem/blob/develop/Assets/Samples/OnScreenControls/OnScreenControlsSample.unity

The reason for doing it this way is also to be able to rely on a single action when desired to support both simulated gamepad (on screen) and actual physical gamepad at the same time.

Did this help in any way?

[warped locust]

https://github.com/StinkySteak/unity-custom-input-provider

Currently I wrap a simple OnScreenControl as a behaviour to send values easily.

But still weird to send gamepad axis rather than the input axis directly...

this for example

If I change the input action default E (ex: interact) to another keycode (lets say F), the mobile control wont work & I have to update them manually

[fast quest]

Thanks for sharing and I checked your code. When you say "mobile control wont work", are you implying rebinding the action to something else than E when the Custom Input Provider Button here is setup to generate E would break any reactions to Interact being triggered? If this is it, it would be expected. The whole idea with the OnScreenStick and OnScreenButton currently shipping with the Input System package is to mimic/simulate actual physical controls to allow touch controls and physical controls to be used interchangeably. So allowing rebinding the action for this scenario would not be recommended.

I think I misunderstood the question a bit initially. Am I right to interpret this as you are considering this inconvenient since:

• It would allow rebinding the action to controls not supported by the UI touch based counterparts?
• You consider it inconvenient to use a control e.g. "Keyboard [E]" that is also represented on physical keyboards and would rather like to be able to inject the control value "directly" or use a control that do not have any physical representation for this purpose?

[warped locust]

You consider it inconvenient to use a control e.g. "Keyboard [E]" that is also represented on physical keyboards and would rather like to be able to inject the control value "directly" or use a control that do not have any physical representation for this purpose?
Yes (main reason)

It would allow rebinding the action to controls not supported by the UI touch based counterparts?
I dont understand this one, could you elaborate?

[fast quest]

Great, for the main reason here then I would say that its currently how its designed and your options if you really do not want that would be to create a custom device+controls representing something that doesn't exist in reality. I would recommend looking at e.g. https://github.com/Unity-Technologies/InputSystem/blob/develop/Packages/com.unity.inputsystem/InputSystem/Devices/Gamepad.cs and make something small based on that. E.g. SimulatedOnScreenDevice instead of Gamepad with the required/desired Buttons or Sticks. Another resource on the topic is https://docs.unity3d.com/Packages/com.unity.inputsystem@1.0/api/UnityEngine.InputSystem.InputDevice.html.
However, I will make sure we take your request for consideration when doing future improvements to on-screen controls as @pulsar scroll also previously pointed out.

My comment about rebinding was related to changing the action bindings from e.g. E to F which wouldn't have to be done when developing it could be fixed? I guessed the "doesn't work anymore" part would be related to rebinding the actions. Otherwise, I am afraid I might not understand why it would be changed from e.g. E to F which would break the functionality?

(Rebinding as in in-game rebinding support if that is something you have in mind, not in the editor during development)

[warped locust]

I am afraid I might not understand why it would be changed from e.g. E to F which would break the functionality?
This yes, because it is not a hard reference to that input action