Enable InputEvent-filtering in SubViewportContainer

[Sauermann]

Introduce an user overridable function _propagate_input_event, that allows filtering, if an InputEvent should be sent to SubViewport children.

implements #78759 (comment)
alternative to #78759
implements a more generic approach than the one in godotengine/godot-proposals#1249
related to #62421

MRP to showcase the new functionality: SvcInputEventFilter78762.zip

Updated 2023-08-03: rename _send_input_event to _propagate_input_event in order to adhere to the usual nomenclature. improve docstring. Rebase for CI-changes.

[Sauermann]

I have a small nitpick with this PR, namely, that the wording _block_input_event is negated.
I have updated the PR to use positive wording _send_input_event instead.

[djpeach]

I wonder if _propogate_input would be more aligned with the current _input, _unhandled_input methods. The _event on this one makes me think it is more specific than those, but it is not

[Sauermann]

I'm not entirely convinced, that these need to be aligned, because _Input, _unhandled_input and the other functions have a different intention (handle the event for this node) than _propagate_input_event (return a flag that indicates, if the event should be sent to a different node) does.
But I am happy to find the best possible name for that function.

[KoBeWi]

While this PR does close the mentioned proposal, there are multiple problems that the proposal's author did not cover.
This PR allows to discern between 2 joypad devices and between joypad and keyboard. It has a some caveats:

• to use it effectively like suggested in the proposal, all players need to share the same actions
• you can code your input only inside _unhandled_input()

This means that:

• you can't rebind controls per controller
• you can't have 2 players using keyboards (e.g. WSAD and Arrows)
• you can't use Input methods like get_vector() (unless there is a way to use them in _unhandled_input()?)
• you can only use it with split-screen inside viewport containers. Single screen or split screen with e.g. sprites doesn't support this feature

That seems quite limited to me.

[Sauermann]

Thank you for your thorough review.

While this PR does close the mentioned proposal, there are multiple problems that the proposal's author did not cover. This PR allows to discern between 2 joypad devices and between joypad and keyboard. It has a some caveats:

* to use it effectively like suggested in the proposal, all players need to share the same actions

The original idea for this PR comes from #78759 (comment)
Even when multiple players sharing the same action, it is possible to distinguish the events within _propagate_input_event. I provide an implementation for handling the WASD vs Arrow case.

* you can code your input only inside `_unhandled_input()`

The event is propagated as usual to SubViewports, so it is possible to use any input-handling function on nodes within SubViewports and not just _unhandled_input.

This means that:

* you can't rebind controls per controller

The user has the option to include any code into the overwritten _propagate_input_event function. So I don't see any problem with including functionality for rebinding controls there. Though I'm not entirely sure we are looking at the same problem.

* you can't have 2 players using keyboards (e.g. WSAD and Arrows)

This use-case is covered by the PR. The following overwritten function would handle that case:

func _propagate_input_event(event: InputEvent):
	if not event is InputEventKey:
		return true
	var e: InputEventKey = event
	if self == $"/root/FocusTest/SubViewportContainerWASD":
		return e.keycode < 255 # letters
	else:
		return e.keycode >= 255 # arrows

It sends events, that are based on letters to one SubViewport, and events that are based on arrow keys to the other SubViewport.

* you can't use Input methods like `get_vector()` (unless there is a way to use them in `_unhandled_input()`?)

Thank you for pointing me to get_vector.
get_vector accesses a global state, so if different Controllers are mapped to the same Action, then they will interfere with each other. I am not sure, if I should expand the scope of this PR to make get_vector multi-controller aware, or if this should be rather done in a separate PR.
Also please see my previous argument regarding _unhandled_input.

* you can only use it with split-screen inside viewport containers. Single screen or split screen with e.g. sprites doesn't support this feature

I agree with this statement. This implementation is based on the concept of using SubViewports for handling events for different Players. It ties nicely with #79480 which allows each player to have a focused Control in their SubViewport.

That seems quite limited to me.

I hope, that I have addressed most of your concerns.

[KoBeWi]

The event is propagated as usual to SubViewports, so it is possible to use any input-handling function on nodes within SubViewports and not just _unhandled_input.

Right, what I meant is that you can't use _process() and the global state input method. All _input_*() functions are pretty equivalent.

The user has the option to include any code into the overwritten _propagate_input_event function. So I don't see any problem with including functionality for rebinding controls there.

The whole idea behind the proposal was to use a single action set for every player. If you have multiple action sets, _propagate_input_event() is not needed for anything and it doesn't really make things easier.

But that's more problem with the proposal itself than the implementation. Not every game will have control rebinding, but as soon as you want to add one, you will run into godotengine/godot-proposals#3555 and the solution proposed here, while it's for a similar problem, it doesn't solve all issues. (also in that proposal I commented with a convenient way to solve pretty much every problem raised here).

This use-case is covered by the PR. The following overwritten function would handle that case:

It doesn't handle other control schemes like IKJL. Though nowadays they aren't used I think, as most people will just play with controllers.

I hope, that I have addressed most of your concerns.

As a person who always writes input code inside _process(), I wouldn't use the new functionality, as the _input() limitation makes it inconvenient. idk how most people write their code though, but Input methods exist for a reason.

[KoBeWi]

Not sure about the feature itself, but the implementation looks fine.

[YeldhamDev]

@KoBeWi If it adds any weight, my game needs this feature as well (which was possible in a different way in 3.*). It's a mini-game collection, and this would be used to dictated when said mini-games would start/stop listening to inputs.

[akien-mga]

Thanks!

Edit: lol, bad copy paste ;)

[TisFoolish]

you can't rebind controls per controller

Wait, that seems pretty bad, especially for those of us that are more disability focused as rebinding controllers is one of the most basic of forms of accessibility. It'd suck for a disabled user to be penalized in a split screen game or the non-disabled user having to deal with the whatever esoteric setup the disabled user.

[Sauermann]

Right, what I meant is that you can't use _process() and the global state input method.

As a person who always writes input code inside _process(), I wouldn't use the new functionality, as the _input() limitation makes it inconvenient. idk how most people write their code though, but Input methods exist for a reason.

Using Input in _process() is something, that is not addressed by this PR. It focuses solely on input event propagation.
I haven't yet found a solution, that is better that your solution in the other proposal.

you can't rebind controls per controller

Wait, that seems pretty bad

I don't see any restrictions for rebinding controls per controller while using the functionality of this PR. But as stated above, _process() is not covered by this PR.