[Feature Request] additional Cursor.LockState

Hi,
Since the feedback site doesn't exist anymore and the forums were announced to be the new source of feedback, i'd like to request this:
Give Cursor.LockState an option that keeps the cursor locked wherever it currently is.
Because that's standard in most third person games that use the mouse for interaction and click-hold to position the camera; and unity only has the option to 'lock' it to the center for now, which is only really useful for FPS type of games (in the other case it's even kind of annoying having to reposition the mouse after every camera-move).

 

Hi,

I know this might sound obvious, but... couldn't you just make the mouse have no effect on the player? Or you could create a virtual mouse, and only allow it to be influenced by real mouse movements when you want to - idk.

Hopefully this helps...

Miggi124

 

Hi, maybe i'm just not understanding your suggestion, but disabling a baseline game feature (mouselook) seems like a weird way to me for working around this trivial issue.
Creating a virtual mouse may be a solution, but in reality is just way too much work to be feasible for such a simple case; for unity it would just be locking the cursor as before and then - just not forcing it to the screen center, but to the current position, nothing more; but implementing a software cursor that works like the regular cursor just for this is somewhat overkill.
Thanks for trying to help though.

 

This implies you are doing this every time you update the camera-move.

Well you're going to have to update the 'lockstate' every camera-move as well. So just encapsulate the mouse repositioning in it.

Create a 'CursorAux' static class, on it have a 'LockState' property with your own custom enum that has the 3 existing LockStates as well as your 1 extra mode. When the LockState property gets changed, set the Cursor.LockState to its corresponding state... if the option is the 4th custom type, emulate the functionality, if it's exiting that custom state update the mouse position.

pseudo-code example:

Code (csharp):

1.  
2. public enum ExtendedCursorLockMode
3. {
4.     None = CursorLockMode.None,
5.     Locked = CursorLockMode.Locked,
6.     Confined = CursorLockMode.Confined,
7.     CustomLocked
8. }
9.  
10. public static class CusrorAux
11. {
12.  
13.     private static ExtendedCursorLockMode _lockState;
14.     private static Vector2 _mousePosCache;
15.  
16.     static CusrorAux()
17.     {
18.         //get the current state first initialized so we start in correct state
19.         SyncLockState();
20.     }
21.  
22.     public static ExtendedCursorLockMode LockState
23.     {
24.         get { return _current; }
25.         set
26.         {
27.             if(_current == value) return;
28.          
29.             if(_current == ExtendedCursorLockMode.CustomLocked)
30.             {
31.                 //TODO - restore mouse position and undo your stuff
32.             }
33.             else if(value == ExtendedCursorLockMode.CustomLocked)
34.             {
35.                 //TODO - cache mouse position, put the Cursor.lockState in closest approximation, and do all other logic to simulate your behaviour
36.                 _mousePosCache = Input.mousePosition;
37.             }
38.             _current = value;
39.         }
40.     }
41.  
42.     //use this if Cursor.lockState is modified independent of this to sync the states
43.     public static void SyncLockState()
44.     {
45.         _lockState = (ExtendedCursorLockMode)((int)Cursor.lockState);
46.     }
47.  
48. }
49.  

 

Hi,

I'm in a bit of a pinch rn, but I can post an example of what I mean later.

 

I see that i wasn't very clear with my wording. What i meant was 'physically' repositioning the mouse. My goal is not needing to implement hackish platform specific cursor overrides. Unity must already be doing it internally when moving the mouse to the center, that's why adding another enum case would be less hastle than reinventing it ontop, plus it's a widely used behaviour.

 

I understand adding another enum on unity's side would be better.

But the likelihood of that getting done any time soon is slim to none.

I was giving a suggestion on a work around in the mean time.