Official Input System 1.2 released: More fixes and PS5 controller support for Desktop

I just updated to this version for the dualsense support, but I already hit a roadblock

I am obviously doing something wrong, but I cannot figure out what!

I have this code to detect if its a playstation gamepad.

Code (CSharp):

1. playerInput.devices[0] is DualShockGamepad

I then added this to detect if its both DualShock or dualsense, but I get an error on build. I don't know why DualSenseGamepad isn't showing up.

Code (CSharp):

1. playerInput.devices[0] is DualShockGamepad || playerInput.devices[0] is DualSenseGamepadHID

Build Error:

Assets/Scripts/InputManager.cs(99,89): error CS0246: The type or namespace name 'DualSenseGamepadHID' could not be found (are you missing a using directive or an assembly reference?)

Any suggestions?

 

What's the build target? DualSenseGamepadHID is only available on some build target. Note that DualSenseGamepadHID is just a DualShockGamepad, though. So the first check alone is enough.

 

Thanks for the fast response!

I am building for iOS. The controller works, but I cannot detect that it is a playstation controller so I cannot serve the correct gamepad icons.

Is duelsense not supported for iOS yet in Unity? If not, will it be supported soon?

 

Okay, thanks for letting me know. Just want to put in a request for it as its extremely important

Is there any workaround to detect if it's a dualsense?

EDIT:

For anyone looking for a workaround, you can use this line of code to get the name.

Code (CSharp):

1. print(playerInput.devices[0].displayName);

 

Hi, I tried it but it doesn't work on my 2018 iPad Pro 12.9in (3rd Generation) on 15.1

Doesn't Work:

Code (CSharp):

1. if(playerInput.devices[0] is DualShockGamepad || playerInput.devices[0] is DualShock4GampadiOS)

Works:

Code (CSharp):

1. if(playerInput.devices[0] is DualShockGamepad || playerInput.devices[0].displayName.Contains("DualSense"))

 

Case ID: 1378308

 

Hi there. I'm sure I'm missing something obvious, but how do I upgrade the input system to 1.2.0? I'm on Unity 2021.1.16, and the InputSystem is on 1.0.2 (according to the PackageManager->UnityRegistry page).

Weirdly, the input system doesn't show up in the PackageManager->In Project page, nor is it listed in the packages.json file. Does it somehow use a hard-coded version of the package per Unity release?

 

Oh, OK, manually adding
"com.unity.inputsystem": "1.2.0"
to the packages json does the trick. Weird.

 

Wait what? Are you saying that the package versions that are available/recommended for a Unity version is not something that's fetched from Unity's package server, but something that's hard-coded in each Unity version?

So you can't test a version of a package for a shipped Unity version and say "well, this works, we can recommend this for that shipped Unity version", you have to ship a new minor Unity version?

That, uh, explains things, I guess? I've been wondering why packages that are supposed to be available isn't available yet. But also that seems kinda horrible and not the point of packages at all. Am I missing something?

 

Branch 2020- of Package Manager where you could see all version was way better than this "theorically idiot proof" system that prevent you to see new and in pre-release package

 

Sadly Unity listened to the criticism that packages break projects when people willy-nilly upgrade them. So they decided to only show packages if they are either "thoroughly tested" with the Unity version at hand or "it is experimental somewhat" and they need people to test things.
In all other cases you need to install the package manually and if you want a specific version, you need to specify the version too.

I pretty much hate this and I predicted this BS before even they made this move, when there was a debate about this. And everyone said I'm wrong, it will be much better...

 

Lol better for who

 

Dualsense Color & Rumble do not work!


This is color:

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.InputSystem.DualShock;
3. public class NewBehaviourScript : MonoBehaviour
4. {
5.     private void Start()
6.     {
7.         DualSenseGamepadHID dualSense = new DualSenseGamepadHID();
8.         dualSense.SetLightBarColor(Color.red);
9.     }
10. }

This is Rumble:

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.InputSystem.DualShock;
3. public class NewBehaviourScript : MonoBehaviour
4. {
5.     private void Start()
6.     {
7.         DualSenseGamepadHID dualSense = new DualSenseGamepadHID();
8.         dualSense.SetMotorSpeeds(1f, 1f);
9.     }
10. }

Dualsense is connected via cable -wired-. Why is that?

 

I don't see a fix for GetTimeoutCompletionPercentage bug report #1377009
Code line numbers probably have changed - I posted this for 1.1.1

GetTimeoutCompletionPercentage doesn't work

Always returns 1.0. Seems to be sampling a different time than what's used to initialize the starttime
Unity.InputSystem\Packages\com.unity.inputsystem@1.1.1\InputSystem\Actions\InputAction.cs : 1371
Code (CSharp):

Code (CSharp):

1. var duration = interactionState.timerDuration;
2.     var startTime = interactionState.timerStartTime;
3.     var endTime = startTime + duration;
4.     var remainingTime = endTime - InputRuntime.s_Instance.currentTime;
5.     if (remainingTime <= 0)
6.       timerCompletion = 1;
7.     else
8.       timerCompletion = (float)((duration - remainingTime) / duration);
9.  
10.  

when breaking into the code 'remainingTime' is something like -1200.0
Looks like timerStartTime is an offset from some value whereas `InputRuntime.s_Instance.currentTime` is the current realtime value.

Specifically timerStartTime is set by :
Unity.InputSystem\Packages\com.unity.inputsystem@1.1.1\InputSystem\InputManager.cs : 3447
Code (CSharp):

Code (CSharp):

1. var currentTime = m_Runtime.currentTime - InputRuntime.s_CurrentTimeOffsetToRealtimeSinceStartup;

The fix is to fix the remainingTime calculation to use the same offset time value used for startTime
Code (CSharp):

Code (CSharp):

1.  
2.     var duration = interactionState.timerDuration;
3.     var startTime = interactionState.timerStartTime;
4.     var endTime = startTime + duration;
5.     var remainingTime = endTime - (InputRuntime.s_Instance.currentTime - InputRuntime.s_CurrentTimeOffsetToRealtimeSinceStartup);
6.     if (remainingTime <= 0)
7.         timerCompletion = 1;
8.     else
9.         timerCompletion = (float)((duration - remainingTime) / duration);
10.  

 

Is there a function to detect any key on any device was pressed, yet?

e.g.

Code (CSharp):

1. using UnityEngine;
2. public class NewBehaviourScript : MonoBehaviour
3. {
4.     private void Update()
5.     {
6.         if (Device.current.AnyKey.wasPressedThisFrame)
7.         {
8.             //Do something..
9.         }
10.     }
11. }

 

https://forum.unity.com/threads/check-if-any-key-is-pressed.763751/#post-7429070

 

That's cool! What about color and rumble on the Dualsense? Is it implemented yet? I can do the functions as mentioned but it doesn't work /:

 

IDK, I do not own Dualsense and I don't care about it at all.

 

In InputSystemUIInputModule, if I disable it while holding down the move key, the cursor keeps moving when I enable it next time.
The problem seems to be that the m_NavigationState is not reset.

 

Hi,

Do you will support Stadia Controller ? Actually the Input Debugger shows the device correctly, but there are many issues. Running the InputDeviceTester the right stick is not recognized at all, and when I use commands like Gamepad.all / Gamepad.current always returns null. I'm using the new version 1.2.0 with Unity 2020.3.20f1

 

Hi,

would you mind giving an update on when we are getting proper SteeringWheel-Support, which as a class had been in at some point (0.2) and has been absent ever since?

 

Actually, it's connected via cable -wired- Not Bluetooth and still not working!

What am I doing wrong? Is my code "wrong"? Because it's the same way I did it with Dualshock 4 that made it work! But it's not working with the Dualsense though ..

Again, it's connected with cable -usb-c to usb-c- not Bluetooth .. thank you!

Edit: Tried usb-c to usb-a, still, not working!

 

We tried upgrading on 2020.3.17, and hit this warning. We have warnings-as-errors enabled, so it's a blocker:

Code (CSharp):

1. Library\PackageCache\com.unity.inputsystem@1.2.0\InputSystem\Plugins\UnityRemote\UnityRemoteSupport.cs(284,49): error CS0252: Possible unintended reference comparison; to get a value comparison, cast the left hand side to type 'string'
2.  

we see it's fixed in github (https://github.com/Unity-Technologies/InputSystem/commit/79f50b1f252414abd57b3a2caa82f3d551d9bc11) - any word on when that reaches package manager?

 

Yeah, sure it's my pleasure! I reported it right away!

I have 2 dualsense gamepads: The Red & The Black (none is the standard black and white)

The Red: CFI-ZCT1W
The Black: CFI-ZCT1W

I think they're the same model number as yours!

Edit: I forgot to mention that I own a PS5 and updated my dualsense gamepads to their latest software. Only saying just in case.

 

VirtualMouse still not working with this update? I thought it was to be fixed in 1.1.2, (which became 1.2.0?)
I updated to 1.2, opened the Gamepad Mouse Cursor scene, added mouse delta to the stick action, and left button to left button action and I still get wrong behavior, the cursor on screen moves now, but at random long intervals leading it to not move at all, and is unusable
Video:

Edit: I've tried this in a completely clean 2021.2.0b12 and it still doesn't work so its not my environment or example being incorrect. 1.0.2 is the LAST working version of the new input system, 1.1.0 is the only version available in the beta version of unity, and that version has weird input issues with the virtual mouse as well, it jumps around at random intervals with no smooth input at all.

 

* If I upgrade to 1.2 on 2021.1.23 or .28 I get mouselook drift. It never resets back to resting at (0,0). Once you move on an axis you're going to drift some amount forever. Pretty straightforward code built on top of StarterAssetsInputs first person controller. Action: Value, Control: Vector2, Binding: Delta [pointer]. Just reading out the Vector2. Works fine on package version 1.0.2. Move and look with sticks, which are controls under the same action(s), work fine (360 controller, wired)

* Any attempts to track down this DualShock bug? I get this on every combination of unity version and input system package version. Tried 2021.1.23, .1.28, and .2.3. If you use Bluetooth instead of wired mode it goes absolutely haywire (No, I'm not using the specific dongle that is called out in the docs as unsupported. Just built in laptop Bluetooth). I'm just on a Windows 10 laptop with a standard, official, came-with-the-PS4 DualShock 4 controller.

(Nothing to do with the Steam speculation in that there. Did a clean restart where Steam was never active)

You say you """"support""" DualSense but I fear it's the same kind of """""support"""" this other extraordinarily common controller is receiving. Even if it's a 0.5% edge case that's a non-starter; publish a commercial game like this and you appear to your users as unprofessional. If 20% of players own this controller and 1-in-200 get this bug that's 1-in-1000 paying customers you're telling "uh, yeah, you have to do some crazy thing to get my game working [e.g. DS4Windows] because I built this game in Unity".

Going on 1.5 years now. Might we see progress by the 2 or 3 year mark?

 

Any update guys on the dualsense lightbar & rumble?

Edit: Any update yet?

 

Does anyone have the save rebinding script for 2021.1 and the 1.01 input? Cant find the preview version for that one and 1.1 only works with 2021.2

 

1.2.0 has released without fixing PS5 gamepad rumble & color .. it's incredible and mind-blowing

There's clearly an API for this, but for some magical & mysterious reason it doesn't work .. only god knows what the source of the problem is!

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.InputSystem.DualShock;
3. public class Test : MonoBehaviour
4. {
5.     private Controls controls;
6.     private void Awake()
7.     {
8.         controls = new Controls();
9.     }
10.     private void Update()
11.     {
12.         if (controls.Player.Press.triggered)
13.         {
14.             print("Pressed!");
15.             DualSenseGamepadHID dualSense = new DualSenseGamepadHID();
16.             dualSense.SetLightBarColor(Color.red);
17.         }
18.     }
19.     private void OnEnable()
20.     {
21.         controls.Enable();
22.     }
23.     private void OnDisable()
24.     {
25.         controls.Disable();
26.     }
27. }

https://ibb.co/bK6ggw2

https://ibb.co/KXdHyc5

https://ibb.co/YBHZ9Jr

You can see dualsense detected the press (working), but HID (lightbar) doesn't work ..

 

There is a PS3 emulator called RPCS3(which is developed by a very small but dedicated team), and it's got dualsense controller support waaay before Unity did. And guess what? It's got full support of it (including color & rumble) EVEN over bluetooth! Rewired got the support also before Unity ..

While we get a partial support of it and ONLY in desktop(currently).. I really feel a bit jealous tbh..

 

Still no reply for this?
Edit: So, it works when the game is built, of course, however it does not work in editor no matter what I try, locking the cursor, setting it invisible, changing the input system settings in preferences. Really makes it difficult to test, not really viable for active development.

 

I need a tip on how to detect if a gamepad was actually connected.

For now, I just tried to check for Gamepad.current, but it was always not null even if PS4/Xbox Series gamepads are disconnected. I also noticed that Gamepad.current.enabled is always true even if InputSystem.onDeviceChange triggered with state Disconnected/Removed/Disabled.

This looks strange and unexpected.
My goal is to notify the user in the case gamepad becomes available in the game.

There is a clear indication about connected
and disconnected state of the gamepad in the system report

But Gamepad.current returns are not null for both cases and added/enabled properties are always equal to true.
Same for InputSystem.devices. If I search through the collection and found an device which is Gamepad or name contains "gamepad" or "gampad" (is it actually a typo?) it's property enabled will always return true.

I also notes that InputSystem.onDeviceChange behaviour is inconsistent. I do not argue for sure, but it looks like
change state Disconnected sometimes returned when a device was actually just connected.

Does someone manage to solve the same task?

Environment: macOS 12.0.1 (21A559)
Unity: 2020.3.24f1
InputSystem: 1.2.0
Tested gamepad: Sony PS4 / Microsoft XBox Series

 

@Schubkraft is there a list of supported Pen devices? I just tried to install my old Wacom Graphire 3. It surprisingly works with Windows Ink on Windows 10 including pressure sensitivity. I didn't expect that. So I tried in Unity, but Pen.current always returns null. Is there anything I need to do? Or should it work and should I report a bug?

I was using the Input System 1.2 package. I tried both keeping the list of Supported Devices in the Project Settings empty as well as adding Pen explicitly. Nothing worked.

 

There are two ways to read pressure

For editor tools
https://docs.unity3d.com/ScriptReference/UIElements.PointerEventBase_1.html

And with the new input system, for runtime.
https://docs.unity3d.com/Packages/com.unity.inputsystem@1.2/manual/Pen.html

 

When will PS5 Dulasense be documented? Is it in the works? Because there's no API currently. I want to access special features like haptic feedback, and I can't seem to find the way to do that.

 

I'm trying this on Windows PC. Is there a plan to support special features like haptic feedback in the future for PC?

 

Well... perhaps a bit niche in Unity because there's been a decade of no support for pen devices. This isn't a complaint, just an observation if Unity's using analytics to detect. From looking at forums and our own needs over the years we'd all but given up ever believing pen support would come, so it's with surprise even I find there's pen support now!

This is good because I plan on using it extensively for our own tools, something I'd given up on before. I think Unity would do well to add it to their terrain tools / vertex painter stuff too.

 

I see. That's a bit sad. One final question, please: Can't we develop an open source API for this without using their own API? That way there would be no "violation". Thank you.

 

It's working for sure !
Yes indeed it would be great if terrain tools officially suppors pressure now, for both brush radius/ opacity. User can then select wich one to use for pressure, or use both.
https://docs.unity3d.com/ScriptReference/UIElements.PointerEventBase_1.html
https://docs.unity3d.com/ScriptReference/UIElements.PointerEventBase_1-pressure.html

This is for editor tools not for runtime
For runtime use the new input manager