Mouse Delta Input

I don´t read all the posts, but I have a simplier solution:

1. private void OnEnable()
2. {
3. {
4. _inputActionReferenceAiming.action.performed += ctx => look = ctx.ReadValue<Vector2>();
5. _inputActionReferenceAiming.action.canceled += ctx => look = new Vector2();
6. 
   
7. _inputActionReferenceAiming.action.Enable();
8. }
9. 
   
10. }

 

Is anyone else getting a situation where the horizontal mouse delta is roughly double the vertical?

I simply accumulated the Mouse.current.delta.ReadValue() into a Vector2 and outputted in the Debug.Log. Then I added a circle to the UI to make sure I am measuring the same thing vertically and horizontally.

If I go vertically up to the edge of the circle, I get a value of roughly (0, 70).
If I go back to the center I get (0,0).
If I go horizontally right to the edge of the circle I get roughly (140,0).

 

After reading through this thread and hacking away, I'm still stuck.

I feel like I must be missing something simple.

Before

Code (CSharp):

1. private void Update() {  
2.     Vector3 mouseMove = new Vector3(Input.GetAxis("Mouse X"), Input.GetAxis("Mouse Y"), 0);
3.     // doSomething
4. }

After:

Code (CSharp):

1. public void OnMove(InputValue input)
2. {
3.    Vector2 inputVec = input.Get<Vector2>();
4.    moveVec = new Vector3(inputVec.x, 0, inputVec.y

);

private void Update() {
Vector3 mouseMove = moveVec; // ??
}

What should I be doing to convert from Input Manager to Input System?

 

Ive tried the new input system a few months ago, and i gave up on the mouse problem, now months later the problem still persists, none of the solutions proposed here by other users or by unity staff solved the problem, even the demos included on the package have the same jittery behavior.

 

Same problem here. v1.0.1 and mouse position is jittery. Is there any ETA for the fix? This critical problem been reported months ago and still not resolved, that's sad =(

 

After reading this post I'm cancelling our conversion to the new input system. We rely on stable mouse positions and I don't see a way around this. I don't understand why multiple mouse move reports are received in a single frame, this seems pointless, at least without some way of signalling the final one. Does Mouse.current.position (which we would use at first), update several times a frame as well?

 

I am also getting wierd behaviour with the Deltas, both mouse and pointer.

Regarding accuracy, they both seem to go out of sync, if you mess to hard with it. Like swipe your fingers/mouse around eratically, it seems to really get bad. Only way to properly reset it, is to reload the scene or restart the application it seems.

My main problem isnt the wonky accuracy, it's the fact that the Deltas dont reset to 0, as is described here;
https://docs.unity3d.com/Packages/c...er.html#UnityEngine_InputSystem_Pointer_delta

99.9% of the time they reset to + or - 1.0

In my case, this leads to some objects im Translating according to the Delta to slowly "glide" in whatever direction the Vector resets to. I can Math.Clamp or If() my way out of the problem, but that makes it wonky in other ways.

I recently started using unity again, and wanted to test out the new input system, but i must say, i would not recommend it. You will most certainly run into some issues with the deltas at least.

 

These numbers seem to work good with the mouse (need to do more testing). But how do I only apply them if the user is using a mouse & keyboard? Using these values with gamepad makes it move very slow.

 

So if you print "Event" at the beginning of your OnLook(InputValue val) function and you print "Update" on your Update() function you get like 8+ "Event"s for every 1 "Update".

My assumption is that there is actually a game loop that fires faster than the Update() loop in C++ and when you Get<Vector2>() the value of Mouse.delta that tells it to "reset" delta back to zero and start accumulating again until you Get<Vector2>() it again. Can anyone confirm my assumptions are correct?

If so, the only two proper ways to get the mouse input working properly with no stuttering would be to...
1) On the event, accumulate a vector2 and clear it in LateUpdate. As long as your code requiring the delta is in Update() it should work. You may lose some accuracy if an update fires between Update() and LateUpdate(), if that's even possible. I don't know because I'm assuming there is a C++ gameloop and I'm unaware of how it fits in... This would be the "proper" way because it uses events which the new inputsystem seems to be based entirely on but it may have unnoticeable accuracy issues and is less efficient because you're accumulating values that are being accumulated for no reason...
2) Just use the classic pooling method and ask what the Delta is in your actual Update() function... Kind of messy because you have to make manual code that is only relevant if the player is using a mouse but...

edit: I just tried doing this to confirm if it is reset when you get the value and it is not. So I have no idea how the event resets itself...does it reset itself after the end of the event? When/how does delta go back to 0,0 and start accumulating again?

val.Get<Vector2>();
InputTurn += val.Get<Vector2>();

edit2:

I've done this and it causes extremely stuttery mouse movements especially when I set my turn speed/sensitivity high. I tried not using inputs and just set my "input" to a constant and it is extremely smooth - something weird is going on with Delta readings - it does not work.

 

Do We Know If this has been fixed ? I have been looking everywhere and Mouse Position is doing exactly what you described here, it resets so quick that when I try to rotate a GameObject based on mouse position it twitches and unless I move the mouse "Blazing Fast" it won't be fast enough to rotate it. I am even questioning if I may be using the ActionsMap wrong ? I am attaching my script at the bottom just in case anyone wants to look at it, this works with the old input system so I know it has something to do with the events.

Player Script --

Code (CSharp):

1. using System;
2. using System.Collections;
3. using System.Collections.Generic;
4. using UnityEngine;
5. using UnityEngine.InputSystem;
6.  
7.  
8. public class Player : MonoBehaviour
9. {
10.     Rigidbody2D rigidbody;
11.     public GameObject bulletPrefab;
12.     public Transform bulletSpawn;
13.  
14.     public float movementSpeed = 2f;
15.     float vertical;
16.     float horizontal;
17.     float rotationInputX;
18.     float rotationInputY;
19.  
20.     Vector3 mousePosition;
21.     Vector2 mousePos;
22.  
23.  
24.     void Awake()
25.     {
26.         rigidbody = GetComponent<Rigidbody2D>();
27.     }
28.     // Start is called before the first frame update
29.     void Start()
30.     {
31.      
32.     }
33.  
34.     // Update is called once per frame
35.     void Update()
36.     {
37.      
38.         Vector2 moveDirection = Vector2.right * horizontal + Vector2.up * vertical;
39.         rigidbody.position += Time.deltaTime * moveDirection * movementSpeed;
40.         /*mousePos = Mouse.current.delta.ReadValue();
41.         mousePos *= 1f;
42.         Debug.Log($"Mouse Position {mousePos}");
43.         */
44.      
45.  
46.  
47.  
48.  
49.  
50.     }
51.  
52.     void FixedUpdate()
53.     {
54.         Vector2 worldPoint = Camera.main.ScreenToWorldPoint(mousePos);
55.         Debug.Log($"world Point = {worldPoint}");
56.         Vector2 difference = rigidbody.position - worldPoint;
57.         Debug.Log($"Difference  = {difference}");
58.        // difference.Normalize();
59.         Debug.Log($"Normalized Difference  = {difference}");
60.  
61.         float desiredRotation = Mathf.Atan2(difference.y, difference.x) * Mathf.Rad2Deg;
62.         transform.rotation = Quaternion.Euler(0f, 0f, desiredRotation + 90);
63.  
64.  
65.     }
66.  
67.  
68.  
69.     public void OnMoveInput(float horizontal, float vertical)
70.     {
71.         this.vertical = vertical;
72.         this.horizontal = horizontal;
73.  
74.     }
75.     public void OnShootInput(float fireBtn)
76.     {
77.         float fireValue = fireBtn;
78.         if(fireValue == 1)
79.         {
80.             Instantiate(bulletPrefab, bulletSpawn.position, bulletSpawn.rotation);
81.         }
82.     }
83.  
84.     public void OnRotationInput(float rotationInputX, float rotationInputY)
85.     {
86.         this.rotationInputX += rotationInputX;
87.         this.rotationInputY += rotationInputY;
88.  
89.  
90.  
91.         // Rotation
92.  
93.         Vector3 worldPoint = Camera.main.ScreenToWorldPoint(new Vector2(rotationInputX, rotationInputY));
94.         Debug.Log($"world Point = {worldPoint}");
95.         Vector3 difference = new Vector3(this.rotationInputX, this.rotationInputY, 0) - worldPoint;
96.         Debug.Log($"Difference  = {difference}");
97.         difference.Normalize();
98.         Debug.Log($"Normalized Difference  = {difference}");
99.  
100.         float desiredRotation = Mathf.Atan2(this.rotationInputX, this.rotationInputY) * Mathf.Rad2Deg;
101.         transform.rotation = Quaternion.Euler(0f, 0f, desiredRotation + 90f);
102.  
103.     }
104. }
105.  

InputHandler ---

Code (CSharp):

1. using System;
2. using System.Collections;
3. using System.Collections.Generic;
4. using UnityEngine;
5. using UnityEngine.InputSystem;
6. using UnityEngine.Events;
7.  
8. [Serializable] public class MoveInputEvent : UnityEvent <float, float> { }
9. [Serializable] public class ShootInputEvent : UnityEvent <float> { }
10.  
11. [Serializable] public class RotateInputEvent : UnityEvent <float, float> { }
12.  
13.  
14. public class InputHandler : MonoBehaviour
15. {
16.     public MoveInputEvent moveInputEvent;
17.     public ShootInputEvent shootInputEvent;
18.     public RotateInputEvent rotateInputEvent;
19.  
20.     PlayerControls _controls;
21.  
22.     private void Awake()
23.     {
24.         _controls = new PlayerControls();
25.     }
26.     void OnEnable()
27.     {
28.         _controls.Player.Enable();
29.         _controls.Player.Move.performed += OnMovePerformed;
30.         _controls.Player.Move.canceled += OnMovePerformed;
31.         _controls.Player.Fire.performed += OnShootPerformed;
32.         //_controls.Player.Fire.canceled += OnShootPerformed;
33.        _controls.Player.Look.performed += OnRotationPerformed;
34.         //_controls.Player.Look.canceled += OnRotationPerformed;
35.     }
36.  
37.     public void OnMovePerformed(InputAction.CallbackContext context)
38.     {
39.         Vector2 moveInput = context.ReadValue<Vector2>();
40.         moveInputEvent.Invoke(moveInput.x, moveInput.y);
41.         //Debug.Log($"Moving Input: {moveInput}");
42.     }
43.  
44.     public void OnShootPerformed(InputAction.CallbackContext context)
45.     {
46.         float shootInput = context.ReadValue<float>();
47.         shootInputEvent.Invoke(shootInput);
48.  
49.     }
50.  
51.     public void OnRotationPerformed(InputAction.CallbackContext context)
52.     {
53.      
54.         Vector2 rotationInput = context.ReadValue<Vector2>();
55.        /* rotationInput *= 0.5f;
56.         rotationInput *= 0.1f;*/
57.         Debug.Log($"rotationInput = {rotationInput.x} , {rotationInput.y}");
58.         rotateInputEvent.Invoke(rotationInput.x, rotationInput.y);
59.  
60.  
61.     }
62. }
63.  

 

Not sure if I'm misunderstanding something (or something changed in the meantime), but from my understanding, the delta value should not be multiplied by Time.deltaTime to be framerate-independent.
Here's my reasoning, assuming the mouse delta returns the accumulated movement relative to the mouse position in the previous frame: comparing for example 30fps and 60fps and assuming the mouse is moved at a constant speed, it would travel twice as far between two frames (two consecutive Update() calls) in the 30fps case than in the 60fps case. With 30fps I thus get a vector with double the magnitude of the one returned at 60fps. Using it to e.g. rotate the camera would consequently result in the same rotational offset after the same (real world) time.
I tried this in a project using the new Input System to implement a mouse look mechanism after noticing the perceived mouse sensitivity change when capping the framerate at 30fps via

Application.targetFramerate = 30;

. Sure enough, I had multiplied the mouse delta value with Time.deltaTime and since removing it, I get the same rotational movement regardless of whether the framerate is capped or not.

 

I just tested it out in my game last night and you are right, it seems to work now, independent of framerate, even if not multiplied by Time.deltaTime.
I\m very sure I have tested this too previously where it didn't worked like that - so I think they have fixed it somehow.

 

I also had input jitter problem with mouse delta, so I made some tests and found that reducing my mouse polling rate has huge impact to jitter amount. On default my mouse polling rate it 1000hz, reducing to 500hz has no effect, reducing to 250hz has huge impact to jitter amount, but it's not totally gone. I had to reduce polling rate to 125hz and now my character can rotate smoothly.
Also, getting rid of SetCallbacks() and my IInputActions interface was boosting performance a lot...

Edit:
Reading values on Update()

Code (CSharp):

1.     private void Update()
2.     {
3.         _lookVector = _defaultControls.FirstPerson.Look.ReadValue<Vector2>() * Time.deltaTime;
4.         DebugGraph.Log("Old", _lookVector);
5.     }
6.  

125hz

1000hz

 

I moved to the new input system and got super jittery mouse movement as described here. The two magic multiplier numbers fixed it, somewhat; it still jitters, and now that it's not going all over the place you can notice that vertical movement is faster than horizontal movement.

This is really unacceptable. However it was being done before was fine and should at least be documented for porting ease, the two magic numbers are not enough.

 

Is anyone experiencing this problem but only when the game view is in focus? lol. I followed all these tips and get crazy stuttering, but when I click off the game view it doesn't stutter as much. It might be a 2021.2.2 thing.

 

So I was struggling with this issue for at least a week or 2 wanting to pull out my hair because it seemed like no matter what I did, it just kept persisting. Only fix I saw was rolling back in version control to before the new Input System, but I think I finally fixed it for myself with just trying random solutions that were unrelated.

For me what finally fixed it was disabling VSync (Application.targetFrameRate = -1), and after testing in editor and build it worked so much better, the only new issue was the sensitivity changing depending on framerate, which I quickly fixed by dividing the input by Time.deltaTime and giving it a new multiplier value.

It's still does drop sensitivity a tiny bit when dropping frames, but nowhere near the ridiculous jitteriness that it used to cause.

I'm not sure if this will work for others, but I really hope so, as it was causing me a lot of issues for a bit!

 

I was wondering why I was getting reads of 0,0 for mouse position and delta, but only in the editor of one machine. Turns out, "simulate touch with mouse" was ticked on in the input>debug window. Do a check if this is your issue.

 

TY Sir. This was bugging me for quite a while and your solution fixed my problem. I changed the VSync count to "Don't count". I believe, however, unity was syncing rendering with the display, was affecting the input system polling of the mouse position. I was not using delta.

Anyway thanks again.

 

Here is how my problem goes...

My setup is like:

1. I have a Camera Rotation action called "Rotation" which can be seen in the screenshot.



2. I have 2 bindings for Rotation action. First one is from Mouse Delta and the second one is from keyboard (page up/down, etc)

3. In the Update loop, I read the value of this action and multiply it with Time.deltaTime (with some additional multiplier value).

Code (CSharp):

1.  
2. var RotationDelta = RotationSpeed * Time.deltaTime * RotationInput.action.ReadValue<Vector2>();
3.  

Side note: I have the same problem with the Dolly (Zoom) action which is reading from Mouse Scroll (Wheel) because mouse wheel returns a "delta" value similar to Mouse Delta used in Rotation action. At the end, I applied the same solution to both Rotation and Dolly actions.

The problem of my setup described above is that... the camera rotation via mouse and keyboard works almost perfectly in Editor Play Mode but when I build the game and run it on full-screen, the camera rotation via mouse gets crazy fast which is not usable.

After experimenting with various things, I finally figured out that multiplying the Mouse Delta value with Time.deltaTime is the cause of the problem. Basically, Mouse Delta returns a "delta" value and it should NOT be multiplied with another "delta" value like Time.deltaTime.

But... simply removing the deltaTime multiplication in the code isn't a solution for me because... the keyboard binding assigned to the same input action still needs the deltaTime multiplication to be able to run smoothly regardless of the rendering frame rate.

Since Mouse Delta doesn't need the deltaTime multiplication and keyboard binding needs the deltaTime multiplication, I can't just solve this problem in my script where I read the action value and calculate the RotationDelta variable.

Finally, here how my solution turned out to be... I implemented a custom input processor called "MultiplyWithDeltaTimeProcessor" just to be able to multiply the value of keyboard binding with deltaTime. This way, I can make sure that mouse binding doesn't get multiplied by deltaTime but keyboard binding does.

Code (CSharp):

1.  
2. using UnityEngine;
3. using UnityEngine.InputSystem;
4.  
5. #if UNITY_EDITOR
6. [UnityEditor.InitializeOnLoad]
7. #endif
8. public class MultiplyWithDeltaTimeProcessor : InputProcessor<Vector2>
9. {
10.     public override Vector2 Process(Vector2 Value, InputControl Control) => Value * Time.deltaTime;
11.  
12. #if UNITY_EDITOR
13.     static MultiplyWithDeltaTimeProcessor() => Initialize();
14. #endif
15.  
16.     [RuntimeInitializeOnLoadMethod]
17.     static void Initialize() => InputSystem.RegisterProcessor<MultiplyWithDeltaTimeProcessor>();
18. }
19.  

And this is how I attached the processor to the keyboard binding only:


Now the camera rotation speed via mouse movement works exactly the same in both Editor play mode and built game application running in full-screen mode.

I wanted to share my findings here so, I hope it helps other people in the future.

 

For anyone interested, from what I read this is not a bug but intended behaviour to make this work on multiple OS.
Here is what has worked for me and what should make the behaviour the same as `Input.GetAxisRaw()`.


You multiply only `Delta [Mouse]` in `Preprocessors` by `0.05`, so you don't have to do this in code where it can break your other input sources.

In code you don't multiply this value by `Time.deltaTime`, it's not a framerate dependent value.


If you need your movement or whatever which is framerate dependent to work smoothly, you can multiply that movement by `Time.deltaTime`, not the delta value itself (you could technically do this, if you know how to do it correctly, but I don't recommend it, it doesn't make much sense in clean code either).

(Why did I write about multiplication by `Time.deltaTime`? - because in some post before it says that it needs to be multiplied by 100 because "the Delta Time value is very small" - that is going to create bugs. `Time.deltaTime` is a dynamic value, it can be very small but it can be insanely big as well, depending on your framerate. If you want to speed up your camera rotation or whatever, just multiply those values in code by a `speed` variable or smth like that, see example below.)

 

This is exactly what my setup looks like, but the X sensitivity is about twice what the Y sensitivity is. Are you encountering the same issue?

 

Fair to say the prevailing position is this is not correct for mouse pointer deltas, and would result in mouse sensitivity that is dependent on framerate? If so, can I suggest editing the post so people who happen to see it without reading the rest of the thread don't get confused?

I independently noticed this framerate-dependent rotation speed while doing some control prototyping, and when doing a sanity check, found that even the Input System demos still multiply mouse deltas by Time.deltaTime, which might contribute to this misconception.

I reported Case 1420228 to suggest changing the demo to handle mouse pointer input differently from gamepad/keyboard input.

 

The problem is with Pointer.delta itself not only actions.

If you compare the change in Pointer.position with an accumulated change of Pointer.delta by polling them in Update() they don't add up. Reported Pointer.delta is larger than what the actual movement is.

I've reported it with a sample project (Case 1426511).

 

For my case, I am using Visual Scripting and I don't see the accumulation at all. When I move the mouse very slowly, no matter how much, the event listener never triggers. But the `Cinemachine Input Provider` catches those movements. I don't know what's wrong. I read the whole post but, no luck for me.

Edit: I'll probably switch back to C# and manually poll the inputs

 

The solution is to not rely on Unity's new input system because it is half baked. Use Rewired from the asset store instead: i've been using it for two years and I haven't had a single issue with it.

 

OK，this fvcking issue also exists in Unity 2020.3.33 && InputSystem 1.4.1
this is my code

Code (CSharp):

1. // Transform delta to UI Space
2. Vector2 delta = obj.ReadValue<Vector2>();
3.  
4. // Set UI Pos
5. this.CurrentEditingNodeGraphView.position += new Vector3(delta.x, delta.y, 0);

this is the effect, is not sync to my mouse pos


but when i change delta to manual get delta

Code (CSharp):

1. Vector2 delta = Vector2.zero;
2. Vector2 currentMousePos = Mouse.current.position.ReadValue();
3. // Record Last Frame Mouse Pos
4. if (LastPos == -Vector2.one)
5. {
6.     delta = Vector2.zero;
7. }
8. else
9. {
10.     delta = currentMousePos - LastPos;
11. }
12. LastPos = currentMousePos;
13. // Transform delta to UI Space
14. delta = TransformHelper.GetVector2InFGUI(delta);
15. this.CurrentEditingNodeGraphView.FuiNodeGraphView.self.position += new Vector3(delta.x, delta.y, 0);

it works....


So the incorrect delta value is not a so-called OS adaptation, but a real bug, please fix him

 

@Rene-Damm

I can't believe this is still a thing... this post was created on Mar 18, 2019

 

At first I wanted to write that is still doesn't work, but it does and in a very weird way.

I tried accumulating values after each performed callback, read in Update and clear in LateUpdate, but it still have clear jittering compared to old input system.

Mouse.current.delta works just fine.
I also noticed that reading actions.Map.Look.ReadValue<Vector2>() works fine too.

And then I compared the actual values.

So, Input.GetAxis == Mouse.current.delta if you unscale Axis by input settings sensitivity, accumulation after each performed event is off, it's not even a scaling problem.
Reading value exactly from your input map in update have the exact result as old input and mouse.

Then I thought, stop, reading value from input map shouldn't work, because it's exactly as reading last value from performed callback, you are ignoring all deltas and picking last one, so I compared values and it's true, but it's exactly right way equal to old input if you scale it properly.

Accumulation doesn't matter, so I don't even understand why performed callback is fired multiple times per frame, because these middle values are useless, you should use the last one or read from map directly.

This is super weird, but I'm glad I finally managed to fix it and hope it will help other people to understand what is really going on.

 

Still have that problem. WHen using delta mouse with vsync it is really jittery, when using gamepad works perfectly smooth. I don't understand why there is not official info about it in the documentation. This is like basic feature that every game use and people have to figure it out on their own how it work. I love your work Unity team but please update Your documentation, so if there is some intended behaviour we could some kind avoid that

 

this is wrong, you NEVER want to multiply mouse input by Time.deltaTime. Mouse Input is already in delta

 

I just stopped by to thank @Rene-Damm for the missing 0.5f multiplier - because id seen the input system previously had a sensitivy of 0.1, id tried that, but it was like someone gave a mouse square wheels and i was getting mighty mad.. suddenly multiply it by 0.5 and smooth AF.. who knew.. so sure, ive set the new input system to preprocess it to multiply by 0.05f and tada.. happy code now.. what a waste of time ive had finding that.

 

Sorry for necro, just wanted to say, there's still weird behavior here.

Works great.

Code (CSharp):

1.     public Vector2 turn;
2.     public float sens = 3;
3.     public Transform objToTurn;
4.     public float yClamp = 60;
5.  
6.     void Update()
7.     {
8.         turn.x += Input.GetAxis("Mouse X") * sens;
9.         turn.y += Input.GetAxis("Mouse Y") * sens;
10.         turn.y = Mathf.Clamp(turn.y, -yClamp, yClamp);
11.         if(turn.x > 360)
12.         {
13.             turn.x = 0;
14.         }
15.         if(turn.x < -360)
16.         {
17.             turn.x = 0;
18.         }
19.         objToTurn.localEulerAngles = new Vector3(-turn.y, turn.x, 0);
20.     }

V is a much larger value here, but there's crazy stutter even on minor movement, as v is moved by 1 units per frame instead of the normal .05f.

Code (CSharp):

1.     public Vector2 turn;
2.     public float sens = 3;
3.     public Transform objToTurn;
4.     public float yClamp = 60;
5.  
6.     void Update()
7.     {
8.         turn += v * sens;
9.         turn.y = Mathf.Clamp(turn.y, -yClamp, yClamp);
10.         if(turn.x > 360)
11.         {
12.             turn.x = 0;
13.         }
14.         if(turn.x < -360)
15.         {
16.             turn.x = 0;
17.         }
18.         objToTurn.localEulerAngles = new Vector3(-turn.y, turn.x, 0);
19.     }
20.  
21.     Vector2 v;
22.     public void OnLook(InputAction.CallbackContext value)
23.     {
24.         v = value.ReadValue<Vector2>();
25.     }

Added magic numbers, works great again, as it brings v down to .05 units per frame of movement.

Code (CSharp):

1.     public Vector2 turn;
2.     public float sens = 3;
3.     public Transform objToTurn;
4.     public float yClamp = 60;
5.  
6.     void Update()
7.     {
8.         turn += v * sens;
9.         turn.y = Mathf.Clamp(turn.y, -yClamp, yClamp);
10.         if(turn.x > 360)
11.         {
12.             turn.x = 0;
13.         }
14.         if(turn.x < -360)
15.         {
16.             turn.x = 0;
17.         }
18.         objToTurn.localEulerAngles = new Vector3(-turn.y, turn.x, 0);
19.     }
20.  
21.     Vector2 v;
22.     public void OnLook(InputAction.CallbackContext value)
23.     {
24.         v = value.ReadValue<Vector2>();
25.         v *= 0.5f;
26.         v *= 0.1f;
27.     }

 

Interesting, so. I took the 0.1 nomal sensitivity, and the 0.5 magic number given, and came up with 0.05, if i set my

I now have perfectly smooth movement. Im guessing the more you then multiply that by the greater the jumps in movement maybe.

 

Oh sorry, my sens was set to 3 so .05 * 3 was where I got the .15.

So yeah with no multiplication by sens it should result in .05. I updated my post.