Mouse hover enhancement: ability to re-trigger mouse movement processing

[jon-heard]

Background

The "_mouse_enter" and "_mouse_exit" signals of the CollisionObject3D class are an easy way to react to the mouse hovering over scene objects. However, relying on these signals is dangerous if the scene changes frequently (camera movement, object movement, new scene, etc). For example, if a mouse is not being moved, but an object it hovers over moves away from it then the "_mouse_exit" signal is not called until the next mouse move, so hover information is invalid until the next mouse move, and whatever reactions the project has to mouse hovering is invalid until that time as well.

Of course, one solution would be for the user to implement their own custom hovering system. This would require some complexities, such as ray-casting, but could be manageable with some study. However, the existing hovering system mostly works fine and my proposed solution is quite simple, at least in concept. Here it is...

Proposal

Add a global function, perhaps called "reevaluate_mouse_position()", that would re-evaluate where the mouse is and emit "_mouse_enter" and "_mouse_exit" signals as appropriate. The user could then call "reevaluate_mouse_position()" whenever the game-logic causes the scene to change. Perhaps the "reevaluate_mouse_position()" function could be as simple as triggering an InputEventMouseMotion event for wherever the mouse currently is positioned.

Reasons for this suggestion:

1. The circumstances discussed above are common:
   • mouse hovering is used in many games for tooltips, hover highlighting, or deeper interactivity.
   • scene changes are quite common in games, even in more static, puzzle-oriented ones.
2. While implementing one's own mouse-hovering system isn't terribly hard, it IS a barrier for new users, and extra code-work for any user. It's also likely implementing something that is quite similar to the existing system. The existing system is good for common purposes... except for this danger of hover invalidation from scene changes explained above, which can be resolved by implementing the above solution.
3. While 3d projects would benefit the most from this proposal (due to complexities of calculating mouse hover in 3d) even 2d projects could benefit from not having to write a custom mouse hover system.
4. It's possible that there is some back-end chicanery that a user could write to manually trigger an InputEventMouseMotion event on demand. Even so, having a function call is superior in that it is simple, documented and clear in purpose.
5. I am NOT familiar with Godot architecture, but I am a competent, formerly professional C++ programmer and would be willing to look into implementing this myself.

[Sauermann]

The functionality that you describe as reevaluate_mouse_position got already introduced in godotengine/godot#58995, however currently it is not exposed to GDScript.
Since godotengine/godot#66625 touches this function, I have updated this PR to solve this proposal.

[jon-heard]

I see it. So viewports will have a "update_mouse_cursor_state()" function that can be called to re-evaluate the mouse for that viewport? Nice!

[Sauermann]

This can be closed, since godotengine/godot#66625 got merged, which exposed Viewport.update_mouse_cursor_state to GDScript.