I am new to Enhanced Input and UE itself. I’m trying to understand the philosophy behind this system and imagine how I would use it to do what we did in our system in the previous game. I’m pretty confused so far. Specifically:
I can register function via BindAction for specific InputAction but not per trigger (mean press/release…, not the TriggerEvent). And in a connected function I can’t find info which trigger fired it. This seems very limiting to me and the fact that an action can have an array of triggers seems pretty useless to me.
So I need two different actions, let’s say use_press, use_release. Each bound to a different function, it is ok. But I want to use Player Mappable Key Settings and of corse ensure that both actions are mapped to the same key. However it look to me, that relation between input action and MapPlayerKey is 1-1. At least the Name parameter in UI for PMKS must be unique. So I am not able to use one MapPlayerKey for more than one input action. This also seems unnecessarily limiting to me.
In our previous game we used concept “superactions”: each superactions cotains list of logically related actions that player wanted to have bound to the same key (f.e. primary action - pick item in world, equip in inventory, confirm button in menu), but each action was enabled/disabled in different context and what is important - bound in different section of code.
So there are several options: 1) I totally missed some key information. 2) Enhanced Input does not support it and we need to create our own wrapper. 3) Or (I hope) there is some possibility, how to map one MPK to more InputActions and/or get info about activated trigger in bound function.
All of the template projects, as well as the Lyra sample, also provide a few examples of binding to different input events on the same action. Lyra specifically also has player mappable keys set up.
thanks to the answer. I didn’t realize that filling out Triggers is optional. So it is de facto a trigger restrictions, rather than a trigger enabler. So empty array do not mean that action can not be triggered. It mean default behavior - key down = Started, than Triggered and than key up = Completed. There is key code row, which say that:
[Image Removed]However, the inability to distinguish Triggered events from different triggers can be quite limiting. For example, we would like to have Release and Hold on the same button with such a behavior that Release is triggered only if I release the key before the hold has started (it would have some short delay (. How hard would it be to validly extend the ETriggerEvent enum with a new state?
Regarding Player mappable keys and their use in the LYRA project. I researched it and found no use for multiple actions to be mapped to one setting. Everything is either mapped 1 to 1, n to 1, or missing in the settings at all. No mapped 1 to n. As it is shown on picture:
> For example, we would like to have Release and Hold on the same button with such a behavior that Release is triggered only if I release the key before the hold has started
The solution for this is to make two different input actions. One with a hold trigger and one with a released trigger
I’m a little confused about your screenshot there. You specifically point out that Move forward/left/right/backward are all mapped to a single input action, IA_Move.
If you want two input actions bound to the same key, but always want them to fire, then you can uncheck “Consume lower priority enhanced input mappings”. Otherwise, the higher priority input action will always be used. [Image Removed]
If the mappings are of the same priority though, it will always use the key mapping for the IMC that was added most recently. So, you should be able to achieve what you want by using different IMC priorities and unchecking that box on your input actions that you want to be mapped to the same key.
I guess we still don’t understand each other. I know about the features you’re writing about, but I don’t think they solve my problem. My problem is that I have two actions in two different mappings. The mappings are mutually exclusive. For example, I have a Use action in the Gameplay mapping. Then I have the MinigameUse action in the Minigame mapping. There are two of these actions so that I can bind each one from a different part of the code. But this is an implementation detail that the player may not know about. He should see one binding line Use in the settings (set e.g. to the E key), but it internally sets two actions. That’s the 1 to n relationship. And if I’m not wrong (and I need to confirm this), we’ll have to write such a mapping ourselves. I’m okay with it, but it feels like a wasted opportunity.
Hello! Since this thread has spanned many questions now, I’m closing this.
If you have general questions about using existing enhanced input, please make a new case for them.
With regard to receiving thoughts on your own ideas/extensions, I think it would be best to create a post where you illustrate what functionality or quality-of-life/usability you are missing that motivated you to start implementing your own feature (super action in this case). The service/support we can provide then is to log a feature request, and inform you of any existing solutions we’re aware of from our game projects or other public EPS posts.
When it comes to giving validation to your ideas, we can call out when you’re overlooking something obvious but very often the only way to find out is to do it: if it works in a packaged game it works until it doesn’t.
Have you tried to set the “Player Mappable Key Name” to be the same on both of those actions?
That would make it so that, if you used the key mapping screen from Lyra, both of your input actions would be using the same remapped key value for a single “Use” action in the settings.
maybe we are missing something but we cannot assign the same mapping key setting to the two or more input actions. The name of the mapping must be unique across the whole project:
[Image Removed]This means that we cannot aggregate more than one exclusive actions under one mapping.
If that doesn’t meet your needs, then im afraid you cannot do what you’re trying to do with the vanilla enhanced input and you would have to change your approach or make engine modifications.
We’ve just discovered profiles (UEnhancedPlayerMappableKeyProfile) but we haven’t found any documentation. Do you have something on this topic? It seems that it could be something that is usable for our use case. It seems now that profiles can be defined only from code.
Also, I found that mappable key settings in the input action are something that we might not need.
Do you think that it is a good idea to implement own profile class and implement own logic how to bind keys in GetPlayerMappedKeysForRebuildControlMappings()? In our case, we would like to distribute key mapping from something more abstract that we call superaction. The superaction will define the key mapping not only for one input action but for the whole group of actions that could be related. So, our idea is to implement new data asset for superaction which will contain mapping and list of actions. Afterwards, when enhanced input subsystem is building mappings in RebuildControlMappings(), our version of profile will provide mapping based on the superaction. Does it make sense?
Hello! Thank you for the answer. I am not aware that we spanned more questions now. From the very beginning, we have been discussing the superaction concept for keybinds and how to do it, especially when the documentation is not clear. We also feel that we aren’t on the same page with this topic.
Our conclusion now is that the system doesn’t support such a feature and this may be why you want us to open a new thread and discuss this different approach.