Improve support for plug-in mouse blocking

[not-tomo]

Is this issue related to documentation?

• This issue is related to documentation

Issue or Feature Request

I am currently writing a plug-in to support passively blocking mouse/keyboard inputs while users are actively interacting with debug overlays (corresponding generally to the built-in Game Maker detection for is_keyboard_used_debug_overlay() and is_mouse_over_debug_overlay() respectively).

The keyboard component for this can be handled by plug-ins reliably via consuming verbs while the keyboard is in use.

However, in implementing mouse blocking, I have run into a limitation of the current plug-in API.

At present, the only available mechanism for blocking mouse inputs is via the InputMouseSetBlocked() function. Since functions like InputMouseCheck() or InputMousePressed() bypass input collection/the verb system, consuming verbs is not a viable approach to fully block user mouse input.

In a vacuum where only one party is attempting to manipulate the blocking status, InputMouseSetBlocked() can achieve the intended functionality via a snippet like:

InputMouseSetBlocked(is_mouse_over_debug_overlay());

However, the singular blocking lever in the form of InputMouseSetBlocked() is problematic because plug-ins and/or users may interfere with each other in attempting to modify the block status.

If multiple plug-ins are attempting to block input, for example, each individual plug-in has no means of knowing when it is safe to unblock without coordination between each other. Similarly, a user that attempts to leverage InputMouseSetBlocked() for their own purposes may run into unexpected behavior.

Proposed Solution

A possible solution may be including an InputPlugInMouseSetBlocked() function that could manipulate the blocking status for the particular plugin that calls it via an internal Map of currently blocking plugins.

Underneath the hood, this function could also trigger detections for whether a block was initiated on that frame. If any block exists in the internal map, all mouse inputs would be blocked.

[JujuAdams]

Thinking bigger, there's an argument that we should provide an API to allow setting mouse state much like we provide an API to allow setting verb state. Replay plug-ins (cough cough @tabularelf) would no doubt appreciate this.

[offalynne]

Likely need an interface for setting touch state as well, in that case

[offalynne]

Do we have a necessary real-life need for this in an existing or theoretical plug-in @not-tomo @JujuAdams ?

[not-tomo]

I have created and actively use the described DebugOverlay plug-in within the context of my projects. However, I have withheld publishing the plug-in for public use due to the unreliability of its mouse blocking implementation per the limitations described above.

Regarding immediate need, I have accepted that any additional mouse input blocking should currently be done at the game level rather than leveraging Input given the constraints of the API. Additionally, I have not added or currently need to add another plug-in that manipulates mouse blocking (I am not aware of any such public plugins that currently exist).