Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InputMap does not take conflicts into account #2464

Closed
tavurth opened this issue Mar 15, 2021 · 4 comments
Closed

InputMap does not take conflicts into account #2464

tavurth opened this issue Mar 15, 2021 · 4 comments
Milestone

Comments

@tavurth
Copy link

tavurth commented Mar 15, 2021

Describe the project you are working on

A project which requires two actions to be mapped to the same key, one with a modifier, and one without.
These actions are separated into different nodes, which independently listen for _input events.

Describe the problem or limitation you are having in your project

I have two events:

ui_a which maps to i (letter i)
ui_b which maps to Alt+i (Alt + the letter i)

When attempting to listen for ui_b with event.is_action_pressed("ui_b") the node listening for ui_a takes precedence, and still matches, even though there's a modifier pressed.

Normally after ui_a action, I'll do get_tree().set_input_as_handled() to prevent further propagation of the event.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I would like to have the modifier key take part in understanding if that action is really pressed, because here it feels like a bug in some ways.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Perhaps just limit the actions with modifier keys, so that pressing the key with a modifier (Alt+i) will not call the (i) key event.
Perhaps default to calling the (i) event if there are no keys with modifier associated.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Unfortunately not so easily, I'd like to be able to configure these keys at runtime.

Is there a reason why this should be core and not an add-on in the asset library?

It's a problem of InputMap as far as I can see.

@Calinou
Copy link
Member

Calinou commented Mar 15, 2021

See godotengine/godot#44355.

@tavurth
Copy link
Author

tavurth commented Mar 16, 2021

@Calinou thanks for the relevant link!

I see that it's already been merged into master, is it planned for this be backported to 3.x?

@Calinou
Copy link
Member

Calinou commented Mar 16, 2021

I see that it's already been merged into master, is it planned for this be backported to 3.x?

Since the new input action system contains many breaking changes, I'm afraid it may not be possible. The pull request I linked is backwards-compatible, but it may rely on other changes that aren't.

@akien-mga
Copy link
Member

Fixed by godotengine/godot#44355 (4.0) and godotengine/godot#50874 (3.4).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants