GetMouseLocation and GetMouse returning inaccurate positions

Bug Reports Engine Bugs
,
#1

When moving the mouse quickly and then suddenly holding right-click, both GetMouseLocation() and Player:GetMouse() begin returning incorrect positions that no longer match the visible location of the mouse cursor. The values remain desynced until left-click is pressed, which temporarily corrects the issue. However, moving the mouse again while still holding right-click causes the desync to return immediately.

Repro:
mouseDesyncRepro.rbxm (3.6 KB)

Expected behavior

These methods should consistently return the actual, visible position of the mouse cursor. Alternatively, there should be a reliable method provided to accurately track the real-time mouse position, allowing for precise custom crosshair implementations.

2 Likes
#2

Thanks for your report.
Does this occur on UWP Windows for you?

#3

Many users have reported this issue, I was able to replicate it on Windows 10 using the regular Roblox app.

#4

I reproduced this behavior in MousePosTest - Roblox.
From what I can tell, you are observing 3 things:
a) the mouse cursor is drawn by windows, not the game, so it’s framerate independent
b) the grey box renders per frame, meaning it lags behind the mouse cursor
c) the “GetMouseLocation” stops updating when you right click, because we technically freeze the mouse position and update the camera instead

So what you are observing is not “the wrong mouse location”, but that the “real mouse location at game time” is lagging behind the hardware cursor.
This is technically not a bug, but it sounds what you are looking for is that the mouse location updates one more time after you right-clicked to move the camera?

#5

Hold on, I think I’m misinterpreting this.

#6

To explain this from a different angle: if Roblox would draw the mouse cursor, it would be where the grey box is. The problem is there is a mismatch between the internal mouse location and the HW mouse location at the time you “freeze” the location with right click.

1 Like
#7

This explanation has helped, thank you.

Seems like there is something causing a desync between what the engine sees and what the OS sees.

The engine is able to, when the bug isn’t occurring, switch back to where the OS cursor is, so all I can infer/strongly guess is that the engine has different values or methods that it pulls the cursor info from based on its state and it’s only being updating in generic cases ie. cursor location updates.

#8

Yeah, I assumed that would be the case. I’ve also noticed that changing the Mouse Icon property resolves the lag, likely due to its native support.

Can you suggest any workarounds to align the crosshair with the hardware cursor position, while supporting our multi-element design? This issue is affecting our PvP gameplay, especially for players who hold right-click to aim and shoot.

#9

Hey @rip_indra quick update: we are investigating whether there are any viable workarounds for you and/or whether any engine-side changes would be warranted to help. Oddly enough, the HW cursor was employed to help responsiveness in situations where frame rate impacts input processing, such as cursor position updates.

#10

Hi there, can you explain your use case more for us to suggest a workaround? If you have a crosshair icon, you can use the Mouse Icon property to change the hardware cursor’s icon to the crosshair. Or if you want to use the engine’s mouse location, you can manually update the cursor’s location like in your repro file and turn off the hardware mouse icon with MouseIconEnabled. This sacrifices a bit of mouse responsiveness, but will use the engine’s mouse location which will be more accurate for hover and other mouse position effects.