Godot: MOUSE_MODE_CAPTURED returns the speed of repositioning the mouse at center.

[kakoeimon]

Operating system or device - Godot version:
Windows 7 64-bit (Godot 3.0)

Issue description:

Setting the mouse mode to MOUSE_MODE_CAPTURED the input returns AND the values to return to the center when the actual mouse movement is finished.

Steps to reproduce:
func _ready():
Input.set_mouse_mode(2)

func _input(e):
if e.type == InputEvent.MOUSE_MOTION:
var ms = Input.get_last_mouse_speed()
print(ms) #See the output for the values.

Link to minimal example project:

[nunodonato]

@hinsbart this is what I was mentioning on IRC the other day :)

[zvodd]

BUMP

Input.get_last_mouse_speed() behaviour changes with MOUSE_MODE_CAPTURED

Is anyone working on this?

I'll just list some relevant code, for anyone knowledgeable enough to deal with it...

• /main/input_default.cpp#L472
• /main/input_default.cpp#L461

• /platform/windows/os_windows.cpp#L387

• /platform/windows/os_windows.cpp#L405

[bojidar-bg]

Can someone confirm on linux/mac?

[Melix19]

I can confirm on macOS Sierra.

[bojidar-bg]

@Melix19 Thanks, so it is not window-only, hopefully...

[Melix19]

Well, I've tested this on Windows 10 as well and I noticed that the problem is different.
On macOS when you start moving the mouse, the output value of get_last_mouse_speed() approaches to (0, 0) until it reaches it and stays like this even you move the mouse really fast.
IDK if it's designed to work this way.

[kakoeimon]

I just want to inform that mouse relative position remains uncorrupted by the MOUSE_MODE_CAPTURED.

[kubecz3k]

First of all thank you for your report and sorry for the delay.

We released Godot 3.0 in January 2018 after 18 months of work, fixing many old issues either directly, or by obsoleting/replacing the features they were referring to.

We still have hundreds of issues whose relevance/reproducibility needs to be checked against the current stable version, and that's where you can help us.
Could you check if the issue that you described initially is still relevant/reproducible in Godot 3.0 or any newer version, and comment about its current status here?

For bug reports, please also make sure that the issue contains detailed steps to reproduce the bug and, if possible, a zipped project that can be used to reproduce it right away. This greatly speeds up debugging and bugfixing tasks for our contributors.

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

Thanks in advance.

Note: This message is being copy-pasted to many "stale" issues (90+ days without activity). It might happen that it is not meaningful for this specific issue or appears oblivious of the issue's context, if so please comment to notify the Bugsquad about it.

[akien-mga]

Our Bugsquad will review this issue more in-depth in 15 days, and potentially close it if its relevance could not be confirmed.

As there was no update since the previous post, we close this issue.

If it is still relevant in the way it was described and discussed above, please comment to ask for it to be reevaluated. If it is only partly relevant, or if the original issue has changed, it would be better to open a new issue (potentially referring to this one) focused on the current state.

[isnt-alice]

Well, I've tested this on Windows 10 as well and I noticed that the problem is different.
On macOS when you start moving the mouse, the output value of get_last_mouse_speed() approaches to (0, 0) until it reaches it and stays like this even you move the mouse really fast.
IDK if it's designed to work this way.

It still works exactly like this. (Linux)
15cda53, I should say.