At this place I have a script that puts a part at the Hit property of the mouse every heartbeat. When in first person, watch what that part does when you use either of the mouse buttons, both up and down:
You’ll notice that when you depress MB1 or MB2, the part jumps downwards, and when you release MB1 or MB2, the part jumps downwards again, until the mouse moves. That’s causing a fair few problems for me because the game I’m developing is all about manipulating things with the mouse in first person.
Observed behavior: depressing or releasing MB1 or MB2 makes the mouse’s target jump downwards, before any lua code can run.
Expected behavior: depressing or releasing MB1 or MB2 has no effect on the mouse’s target: that’s the cursor’s job.
I would describe it as a loss of floating point precision when you click, and this loss is exponentially more potent on surfaces that have normals near 90* from the camera’s lookVector.
Why I would describe it as a loss of precision, is that the direction of movement I was not noticing happening in any specific direction, but rather at random, and it did not lose any precision at all on the surface on which the ray was intersecting. Instead, it seemed almost like the mouse’s ray was losing precision, the intersection tests were running, then the point was dotted to the surface normal, which is why the result had no loss of precision on the surface it hit.
This all being said, Mouse is deprecated, and UIS is the norm now, would you like me to write you some UIS code, and you can replace your scripts with that?
No it’s not – check the wiki page. Only KeyDown/Up are deprecated.
UserInputService is the appropriate service for input related uses: checking when the mouse moves, has a button pressed, etc. The mouse’s Target, TargetFilter, and Hit are not input related, and Mouse is the appropriate thing to use. Yes, using UIS in this case could circumvent the bug, but bugs aside, it’s fine to use Mouse for something like this.
The wiki is actually down for me right now, for some unknown reason, I tried to double check, but couldn’t. Mouse position in the world I would count as input, and that’s why they added in the Camera casting functions, but it’s good to know that Mouse is still valid.
The Camera casting functions are examples of why mouse world position doesn’t belong in UIS. If you stretch the definition of input to include things that result from direct input (e.g. mouse world position), then Camera + it’s casting functions, whose behaviors are a result from direct input, would also be input and should be in UserInputService. Just like Mouse though, Camera is its own class that breaks off from UIS and serves a purpose more specific than input in general.