Is there some way to have the input action event inside a gameplay ability? I want to give the player the ability to do something when pressing a certain key. Having the input inside the gameplay ability itself makes more sense. Is there a way to do that in blueprints?
Thanks.
You can simply give input id and send input events inside ability
GiveAbility->AssignID
and you can get ability component PressInputID()
An example done here by another community member.
In ability you can catch presses like this Press/Release
Ability must be activated in order to receive inputs, inactive abilities cannot receive input directly.
Also you can send AbilityTask with specific input to ability and do the same.
It’s also possible to forward enhanced input bindings from AbilityBase class derivations from C++ however in the end still uses abilities wait input presses in the end.
Thanks. What about something more complex, like mouse look? Can that be done in a gameplay ability?
Well any input can be done same way to activate an ability.
However keypresses and high frequency inputs are different and depends how you handle them and how you trigger an ability.
If you are talking about like Zoom, ADS type of functions thats totally fine, however if you are looking into gestures and swipe type motions, its better to handle those arguments in another class (pawn, controller) and redirect whatever should happen into the ability.
If you are looking for something specific, you need to give a bit example or description of what you mean, like use case.
Well, let’s say I want the player to open a menu through a gameplay ability, and that ability blocks another gameplay ability that allows the player to mouse look. If mouse look could be handled by a gameplay ability?
Since GAS can block/cancel abilities by tags, it would be great to manage interactions between all sorts of player actions through GAS.
Generally speaking, there is many ways to do one thing.
On the use case you say :
UserWidget->AddedToViewport-> InputModeChanges
Usage of GAS & General mindset : The use case can be done that way too however GAS is generally speaking on off impulse activated classes. GAS better at gameplay actions however not so very good at long lived states and dependency graphs .
Still you can do this however you should think about if your game allows all sorts of menus that are interdependent to each other. If not this not something that you should lean on to. So rather than thinking about what menus do as input, we should be thinking about who authors the menus.
Also one step forward if menus going to have gameplay actions, this can be something like a card game, you draw a card and something happens (destroys all on board as example) if you have these type of interactions in gameplay yes GAS is something you want to utilize.
This can possibly done with gas or simply you can make a UIManager that makes simply tag detection and open closes menu’s as you wish.
Input handling though can be a simple function in some class, even player, something like EnableMouseLook() with a bStatus bool. You can simply call that in widget or UIManager to
OnConstruct- >EnableMouseLook(false)
OnBeginDestroy >EnableMouseLook(true)
In short for input vs menu a simple manager would be way to go however if you planning something as described with gameplay actions (It doesn’t matters you draw a card or swing a sword) GAS is way to go.
As example:
We have some cards on our hand. Each of them has ability assigned, have their own things, costs, effects, cues, tags etc. On the game board we will put one of these.
GA_FireballGA_DrawTwoCardsGA_DestroyAllMinionsGA_SummonCreatureGA_ApplyPoisonAuraUI->DragDrop->Card->TryActivateAbility(GA_DestroyAllMinions)->Commit(Costs/Tags etc) → BoardState(TurnEnd)
UI-DragDrop is just the intent not the gameplay result, player tries do something. End of its effects can be many things aswell as your input mode change for a duration. You can make a gameplay effect even changes input mode (GE_Stunnned : does input block, some post process maybe on camara manager, maybe some cue)
Since only you know your game you are the one who has to make decisions on “who authors what”