Closed AlexHolly closed 3 years ago
How would you solve that? Go though Input action list and ignore other actions if there is 'direct match'?
If such a check is possible, that would probably solve it.
Someone one irc suggested to add a flag for these cases. If that behavior I described is intended you would have to activate the flag for the specific actions.
Someone one irc suggested to add a flag for these cases. If that behavior I described is intended you would have to activate the flag for the specific actions.
That's probably the best way. Many times you don't want a modifier key to shadow an action without modifier, e.g. pressing Space to jump should work even if you are holding Shift to run.
Yeah thats true. I have no idea how the actions work internally in the example the shadow should only happen when an actual action exists for mod+space otherwise they are simply 2 separate actions mod=run and space=jump but when mod+space=superjump only run will activate and superjump will happen once space is also pressed.
If that is only possible with a flag thats fine too.
That's assuming Shift+Space replaces jump. If the action is used for something on UI, for instance, then this automatic detection will be a bad thing.
I believe there are use cases for both, so it should be a flag per-action.
If an InputMap is going to abstract the keys for me, then it should do the work of filtering and fire exclusively based on most specific matching.
My code should not know or care whether ui_focus_next or ui_focus_prev has more or less specific keys, whether they use modifiers or duplicate keys, or what order they should be in, as that defeats the whole purpose of the InputMap and abstracting the keys for me.
ex.
ex2.
I just ran into this, and was about to file a bug. In my case it's an App with a complicated UI, not a game, and there will be tons of such conflicts, i.e:
Z: Play C4 Note on piano Ctrl+Z: Undo
But Ctrl+Z Plays the note AND performs undo. Since there are two piano octaves available via keyboard... yeah, there will be a ton of conflicts. 😅
Filtering it myself would be a lot of work prone to bugs, since there's no central "UI Control" script and each part of the UI is a sub-scene and manages itself, not aware about where the conflicts may happen in other scenes. Allowing the Input system to perform this filtering as it's being suggested would be much, much welcome.
Maybe an "Exclusive" checkbox column in the Input Map editor would cover most of the cases, and stay simple enough? Checking it would only fire the action if that key, and only that key, is pressed.
Thanks!
More Information about this bug is in #44180.
I found where the problem code is. I will have to fix this very soon as it is required for #43663 to be merged
Reproducible in Godot 4.1 It can be worked around with an elif setup in the correct order but figured might as well report this
Sample project: https://drive.google.com/file/d/176GERr0Lba_PfpjPdpepBfQg24ZYtmJK/view?usp=sharing
Pressing ctrl+A in the project triggers the action for a standalone A press
I've also just run into this. Not having a way to require that a modifier key not be pressed means that I will apparently need to write my own input controller code and cannot use the one integrated with the engine if I will allow players to configure these controls. This seems like a pretty serious piece of missing functionality, or a serious regression if this was working before.
When using the new optional argument for e.g. Input.is_action_pressed
, this does actually work as expected. (#44355)
Godot Master https://godotengine.org/qa/28199/how-to-use-shortcuts-with-modifier
I am looking for something like this I thought godot checks this internally. Try to press CONTROL+S.
Expected result CONTROL_S
This works but I can't use it in my case