InputObject.Delta not populated for MouseMove

Bug Reports Engine Bugs
1 
function OnMouseMoved(input, processed)
	
	if (TryDrag(input.Position.X, input.Position.Y)) then return end
	
	-- try pan
	if (MouseButton1Down) then
		print("PAN", input.Delta)
	end
	
	
end

InputChangedConn = UIS.InputChanged:connect(function(input, processed)
	if input.UserInputType == Enum.UserInputType.Touch then
		OnTouchChanged(input, processed)
	elseif input.UserInputType == Enum.UserInputType.MouseMovement then
		OnMouseMoved(input, processed)
	elseif input.UserInputType == Enum.UserInputType.MouseWheel then
		OnMouseWheel(input, processed)
	end
end)

This code prints (0,0,0) when Mouse Button 1 is held down and you move the mouse around.

2 Likes
2

It is intentionally only non-zero when the mouse is locked in place.

3
  1. This is not documented any where obvious (like on the InputObject.Delta docs)
  2. This is stupid.
  3. This is not consistent with Delta being populated for TouchChanged regardless of context.

blob.png

5 Likes
4

I’ll look into fixing this, thanks!

1 Like
5

How do you expect this to work in the boundary case? For example, if the mouse is outside of the window or against the edge of the screen. At the edge of the screen, the cursor is limited but the mouse can still report movement.

Either the deltas are modified so the sum of deltas matches the cursor position, or the deltas are reported accurately*.

There may also be other issues with app-bridge. Not sure though. The difference in the mouse position doesn’t need to match the deltas reported by the raw input device. The OS can modify it.

This clearly isn’t an issue for touch, as the input device no longer registers deltas once you finger is moved off screen.

  • ok, this is a false dilemma. There are other options, just none that I could see a use for.
6

Delta should update both when against the edge of the screen and outside the window. For cleanliness though, it’d be nice to have the following enum values added to MouseBehavior:

  • LockWindow - Mouse can freely move around within window, but is clamped to reside within the window
  • LockWindowCircular - Same as LockWindow, but instead of just running into a wall at the edges of the window, it moves to the other side. i.e. if I moved my mouse past the top of the screen, the cursor would appear at the bottom.
7

With this would people still be able to take their mouse out of the bounds of the window without tabbing out of it?

8

No – not if the developer manually enables this. If it’s a security concern, they can use the menu to exit. Locking them out of exiting can also be accomplished with LockCenter and LockCurrentPosition, both of which prevent you from using the menu to exit, so LockWindow is safer by far than the existing behaviors – should be no security concerns.

9

I for sure will dislike a game if it causes me to not be able to take my mouse out of it easily. Just doesn’t seem like a good user experience. Having your mouse locked in the middle is a non issue because you can see that it’s locked in the middle and the feature is so common place in all games.

10

If a game has LockWindow enabled the entire time, then feel free to downvote their game for dumb usage of it. Its use lies in temporary states i.e. how studio enters this state while you’re dragging parts / box selecting, or in the case of LockWindowCircular, 3DS Max enters this state temporarily while you’re dragging to scale something. That being said, I don’t see how “I dislike certain types of mouse locking because other games don’t use them!” is relevant to the feature and/or sensible.

11

I would copy whatever the windows API does.

My assumption is that it doesn’t fire mouse events that fall outside the client window.

Do people play ROBLOX in windowed mode often? I assume this is the edge case you mean?

Or do you mean full screen mode? In that case I still want the deltas. If I am listing to this event it’s because I’m implementing something like screenscroll where I don’t care about the x,y location of the mouse at all.

12

Dredging up this old bug report here because I think that the Delta property not being populated when MouseButton1 is held down is an arbitrary, blocking decision that I don’t find to be sensical.

In the video below, you see me moving the mouse while MouseButton1 is held down over some UI elements:

The intent is that, using the MouseDelta, the gun in the viewport will rotate according to the mouse movement while MouseButton1 is held down. The current work-around for this is to manually keep track of the mouse’s Delta myself using position, but I can’t be the only person who feels like I shouldn’t have to. Why is Delta not populated in this clear case where the mouse isn’t locked?