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

Input actions conflict when using similar key bindings #50863

Closed
Skaruts opened this issue Jul 25, 2021 · 5 comments
Closed

Input actions conflict when using similar key bindings #50863

Skaruts opened this issue Jul 25, 2021 · 5 comments

Comments

@Skaruts
Copy link

Skaruts commented Jul 25, 2021

Godot version

3.3.2

System information

Windows 7, GLES2

Issue description

If you create two (or more) input actions that use similar key combos, they will conflict when using is_action_pressed or is_action_released. For example, if you create:

action "foo" -> ctrl shift alt S
action "bar" -> ctrl alt S

and you have this input code:

func _input(event: InputEvent) -> void:
    if event.is_action_pressed("foo"):    print("foo pressed")
    elif event.is_action_released("foo"): print("foo released")

    if event.is_action_pressed("bar"):    print("bar pressed")
    elif event.is_action_released("bar"): print("bar released")

The results will be:

  • if you press ctrl shift alt S, both actions will trigger is_action_pressed and is_action_released.
  • if you press ctrl alt S, only "bar" will trigger is_action_pressed, but both actions will trigger is_action_released

I haven't tested this further, but there's probably other combinations that have similar conflicts.

Steps to reproduce

This should be easily reproduced in any project; just create those two actions with those same keys, and put the code above in a script, and then run it and try the keys out.

Minimal reproduction project

No response

@raulsntos
Copy link
Member

Duplicate of #44180 and #18793 that was fixed in master with #44355 but I don't think it's in the 3.x branch and OP is using 3.3.2

@Calinou
Copy link
Member

Calinou commented Jul 25, 2021

Closing per @raulsntos' comment. Feel free to remake #44355 for the 3.x branch, it should be backwards-compatible as the exact parameter defaults to false 🙂

@Skaruts
Copy link
Author

Skaruts commented Jul 26, 2021

@Calinou not sure I understand. Is it going to be backported?

@Calinou
Copy link
Member

Calinou commented Jul 26, 2021

@Calinou not sure I understand. Is it going to be backported?

It's not backported yet to 3.x, but backporting it is welcome.

@raulsntos
Copy link
Member

I opened PR #50874 to backport it

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

3 participants