Hello,
I am trying to implement a feature where to trigger a UI action user is required to input two keys together (ex. for KBM Ctrl+LMB). Seeing CommonUI supports Enchanced Input Actions, and EIA supports chorded actions this seemed like a natural choice. However it seems that the support for EIA is minimal as they use the usual ActionBinding structure and HoldBindings are disregarded for EIA, to the point where only key assigned to the Input Action is relevant while Triggers are ignored when registerering via UCommonUserWidget::RegisterUIActionBinding. I am aware that EIAs work when Input mode is set to All, but this does not seem like a solution for menu inputs as they will bleed out to the player unless all player IMCs are unregistered.
UIActionRouterTypes.cpp (794)
if (CommonUI::IsEnhancedInputSupportEnabled() && Binding->InputAction.IsValid())
{
if (const UInputAction* InputAction = Binding->InputAction.Get())
{
TArray<FKey> InputActionKeys;
CommonUI::GetEnhancedInputActionKeys(BindingHandle.GetBoundLocalPlayer(), InputAction, InputActionKeys);
for (const FKey& InputActionKey : InputActionKeys)
{
if (TryConsumeInput(InputActionKey, InputAction))
{
return true;
}
}
}
}
UIActionRouterTypes.cpp (165)
else if (CommonUI::IsEnhancedInputSupportEnabled() && BindArgs.InputAction.IsValid())
{
if (ActionDisplayName.IsEmpty())
{
ActionDisplayName = BindArgs.InputAction->ActionDescription;
}
// Nothing else to do if we have an enhanced input action,
// the input action itself will be queried against for keys later
}
So with that in mind my questions are as follows:
- What would be the proper way to handle “chorded actions” in CommonUI then? They only way of implementing this via InputActionDataBase definitions I found is a hacky solution through hold actions with excessively long hold times as UI bindings do not have a state like EIA Triggers. And I don’t want to work on raw FKeys as this defeats the purpose of the whole UI Input framework.
- Are there any plans in the near future to expand support for EIA to emulate Triggers functionality on the UI side?
[Attachment Removed]
Hi there,
I did some testing and I can confirm that when using generic Input Actions common UI does not respect the Input action’s triggers. However when implemented as a specific input action (as outlined in this article). The input actions triggers will be used as specified in either the IMC or the IA. I’m not sure if this is applicable to your situation but using this method would be my recommendation.
- Louis
[Attachment Removed]
Hey,
thanks for the reply. However the solution you’ve suggested only works when the input is routed to the PlayerController EnhancedInputComponent (either because of mouse capture or by setting the Input mode to ‘All’/‘Game’), which in turn requires me to remove all player related IMCs when opening the menu to prevent the player from reacting to the keystrokes (ex. crouch), which I would like to avoid doing.
This is the essence of my question. Because I know that those EIA triggers will be properly handled when the input is passed to the PlayerController, but in menus I don’t want to do that and that’s why I’m searching for different solution. I might be missing something but from my limited time testing different setups it seems that what I want to achieve is impossible via EIA in its current CommonUI implementation. If you have any other suggestions I would be exited to hear them as I don’t believe this case is not already covered by one of the ways to handle the input in CommonUI.
[Attachment Removed]
Hi,
This limitation is a pretty big (known) pain point in the current integration of CommonUI and EnhancedInput. As you noted, we don’t currently have a way to defer the processing of UI input to detect chords, so while we do support EI bindings in CommonUI, it only really works for simpler inputs. We have plans to address this at some point, but no news to share at the moment.
For now, the only real options are to either make your own chord-handling logic at the UI layer, or let everything fall through to the PlayerController so it can be processed at the Enhanced Input level. I have some high-level ideas for how you might take either approach, though the best option is probably going to depend quite a bit on your project and what kinds of chords you need to detect.
If you want to do your own UI-layer implementation, Slate Preprocessors might help. Preprocessors can be registered/unregistered and will hijack input before anybody else handles it, so it might be pretty straightforward to do something along the lines of “While Ctrl is held, block all additional keys until I check them against a chord list”. You lose some of the flexibility of Enhanced Input, and your preprocessor will need a way to access any necessary context on the game state, or you could push/pop the preprocessor as needed (i.e. register it when the menu opens, unregister when it closes).
For the second approach, rather than remove and readd those gameplay action IMCs, you could try setting up input mode filtering in your enhanced input settings. The idea there would be that you would apply a specific tag to your gameplay IMCs, then add/remove tags via the Enhanced Input Subsystem to filter out those IMCs without needing to explicitly remove/readd/track them. You’ll still need to deal with the hassle of making sure all the relevant keys fall through the UI and hit the player controller, but that might be easier than building something custom.
Best,
Cody
[Attachment Removed]
Hi again,
Thanks for getting back to me with this additional info, I can understand the circumstances a bit more now. However, I am going to escalate this case to the epic team so you can get some more support on this issue.
Cheers,
Louis
[Attachment Removed]