Problems with Third Person Character Controller using Input System integration on mobile

[TDM GameDev]

I'm trying to work on getting the Third Person Character Controller set up in a new-ish project with the Input System integration, and I've got movement working fine with keyboard/mouse and gamepad, and even a gamepad on mobile. However, when any kind of touch input is used, the player runs at a dramatically increased speed. It seems like the player is moving (sort of) in the direction of the touch, but it's hard to tell. I've included links to two videos illustrating the issue in progress. One is from the editor, and the other is recorded from my phone in the Android build.

I don't particularly need to use the touch controls built into the Third Person Character Controller, because I have a reliable system I use with virtual joysticks and buttons. If the built-in touch controls handle camera rotation well enough, I could be convinced to use it, but I have no idea how well it's going to work because of whatever fluke is causing the behavior in these videos.

I don't know if it's important, but I'm using the Third Person Combat setup for the camera and player. Also, I did follow the instructions for setting up the integration.

 

[Justin]

This sounds like a sensitivity issue on the touch controls for the new input system. Unfortunately I am not too versed in the touch controls for the new input system so don't know where to adjust.

 

[TDM GameDev]

As far as I know, there isn't a "touch sensitivity" setting in the Input System. Even if there were, the problem occurs with a single instant click in the device simulator in the editor. Also, the Input Actions are what came with the integration package, so everything in terms of input and controls is what came out of the box.

I was hoping that if I couldn't get a good answer, I could at least be pointed toward some kind of movement speed modifier in the Input System integration package, or even just the original third person character controller package, to at least be able to override that value when touch controls are being used. I don't think that's an ideal solution, because it doesn't really resolve the problem, but if there's no way to get this to work with the new input system otherwise, I'll take the janky workaround.

 

[Justin]

On the PlayerInput component you can adjust the sensitivity of the mouse movements, which translates to touch inputs. You could give those settings a try. Beyond that on the character locomotion you can adjust the acceleration of the character.

 

[TDM GameDev]

I must be missing something. This is my PlayerInput component, and the Input System Settings in the Project Settings window:



The old Input Manager does have sensitivity settings:


But I don't see it for the Input System. Also, I was able to modify the Motor Acceleration values from .18 to .001 and got what was a lot closer to a normal run speed, which allowed me to see a problem that I only suspected existed until I could actually see it. Upon clicking (or tapping the touchscreen, as it were), the player begins to move and never stops moving. Again, this does not happen with the keyboard or gamepad controls. Here is a video:

 

[Justin]

This is my PlayerInput component

Ah, by PlayerInput I am referring to the base class of the UnityInputSystem component that is added when you add the integration.

But I don't see it for the Input System. Also, I was able to modify the Motor Acceleration values from .18 to .001 and got what was a lot closer to a normal run speed, which allowed me to see a problem that I only suspected existed until I could actually see it. Upon clicking (or tapping the touchscreen, as it were), the player begins to move and never stops moving. Again, this does not happen with the keyboard or gamepad controls. Here is a video:

It's tough to say without stepping through it. I would debug this by either outputting the movement parameters in CharacterLocomotion.Move, or by enabling script debugging and using breakpoints to determine the movement values. My guess is the values being passed into the locomotion are still really large.