keep it as a variable in a component or the class that the ability is trigering. so that the class object (pawn? character?) gets pushed as instigator and owner of the ability component in the syntax, and then you can cast or call interface to get target as reference, or target as a worldspace location.
Hi, I hope you can add āDuplicate Taskā feature, itās very useful, thanks!
Sure. Should be do-able.
Hi, does anyone know if Able is compiled on VS2017 or 2019?
What I really want to know, is which VS version is the most stable for Able to compile on at the moment?
Or is the latest VS always recommended to use by default?
Thanks in advance for any advice given
@ Hey, Iām stuck with UE4.23 due to how my other dependencies. When do you think you can get to pushing a patch?
VS2017, although 2019 should be fine.
I tend to wait for the official release before I build the patch, just to avoid working on a moving target. But generally I try to submit an update within 24hrs of the release.
@ That is understandable. Some other plugins have 4.23 beta branches in their repos already. Iām not sure when 4.23 will be fully released, but Iām excited for it.
In theory, you may be able to just open up the Able.uplugin file and change the engine version to 4.23. As long as there werenāt any crazy signature changes by the engine guys, youāll be fine. But yea, Iād wait if you can.
It think it was asked a couple times in the ue4 marketplace so Iāll bring the question here because Iād really like to know.
Able was written while GAS was still in development / being used by Paragon. I was frustrated with the lack of documentation and a decent editor, so I just created my own system from scratch. The main advantage Able has over GAS is it makes no assumptions about what type of game you are building and the editor is super easy to use. GAS was very much driven by Paragon at the time and the Editor was fairly non-existent. I havenāt gone back to GAS over the last year and seen the current state, but I honestly havenāt needed to. I use Able for all my own stuff.
Tell me on the versions of ABLE on marketplace direct download? You had a major update you said that require redo of all abilitiesā¦ what version up is the update? is it live? do you plan more changes like this in the future?
No update requires a redo of all abilities. Able 3.0 changed some things GOING FORWARD, but the old stuff still works just fine. And no, I donāt plan to make any more large changes. v3.11 is the latest I believe.
Is it possible to pass data from one ability to another other? Iām trying to prototype some abilities that donāt seem to map into the way Able works, so Iām looking for recommendations. I like the system but it feels like it has a narrow band of utility when it comes to setting up abilities, particularly abilities that involve more than 1 phase of state.
For example, I have a āground poundā ability that is split into 2 abilities. Iāll call them Pound_Air, and Pound_Land for reference
Pound_Air - The first ability is activated when the character is in the falling state and they press the attack button. This ability loops and starts an animation with the characters fist raised in preparation. It also has a branch which checks for whether the character has landed. When the character lands, this ability branches to Pound_Land
Pound_Land - This action immediately starts an animation, effects, and sounds for pounding the ground, as well as some radius queries and damage tasks.
The problem is that the Pound_Air needs to perform some logic that results in some information that Pound_Land needs, such as evaluating whether the landing (based on velocity, etc) should be a heavy or a light Pound_Land, and there doesnāt appear to be a mechanism to pass data between abilities. Requiring different
It looks like the closest thing available would require modifications, and that would be the key value set on the ability context, and extend the branch task to copy the key/value set like it does the targets, but it doesnāt feel ideal. It also doesnāt feel ideal to make a bunch of individual ability elements just to account for the different phases of a broader ability concepts. Itād be great if these abilities were authorable similar to how montages are authorable, with several discrete āsectionsā that represent different phases of an ability. In that case the in air and land could be part of a single ability, which is far nicer to work with and also limits the scope for issues like this where data sharing is necessary.
Have you set up some non trivial abilities like this? And if so, how did you resolve these issues?
Also, why does the code of UAblBranchTask ultimately pass the current context ability to the CanBranchTo function? I thought for sure it would pass the desired destination ability. Otherwise having multiple branch tasks within the same ability wouldnāt be distinguishable from each other in the CanBranchTo code. Am I missing something here?
Hi
Does able ability system allows additive animation playback? So we can layer one animation over another, and possible by body parts?
Sorry for the delay on this, I swear Epic only sends every other notification.
No, currently there is no way to pass information from one ability to another. The way I got around that in the Chain Lightning example is just to store that info on the target (or the player itself) and the other ability just asks the player for the info. You could pass in the old context into the new ability to let it grab whatever, but I currently donāt have that setup.
It should pass the current context and the Ability it wants to transition to. If itās not, thatās a bug (although I swear that was fixed recently). Iāll verify again.
Layering your animations is driven entirely through the Animation Blueprint system. Able does have a special animation node that will blend between animations you call in Able (if youāre using that mode) so you can dynamically blend between sword swings or what ever, but if you want to actually break it up so the top of the skeleton does one animation while the lower half does another - youāll have to set that up yourself.
You may have fixed the branch argument already. Iām not on the latest currently given the number of modifications weāve made. I would like to work our modifications back into Able(or come up with good alternatives) so we can keep Able more upgraded. I like the library, but I wanted to give some feedback on some issues that really get in the way of productivity and end up making certain abilities needlessly complex and/or require modifications to Able.
Hopefully I am just missing something here, but ability contexts being the only thing that is instantiated per instance, and the abilities being basically a shared object, really seems to work against the grain of how UE4 is set up, blueprint wise.
For example,
Canāt use ability local variables for anything other than shared data. Iād love to be able to define ability specific blueprint local variables for information pertinent to the ability(whose values will differ for each instance of the ability). For now, weāve added a general purpose TMap<FString, float> key/value store to the ability context, and to support branch passing of data, I added an option to the branch task to copy the k/v map to the new ability. Itās crude but it works, but itās only necessary because the only shared resource(ability context) is the object that is blueprint extendable
Actor delegates are useless in ability blueprints. For one of our abilities, I had some ability logic that needed information only known when a delegate is called(such as ACharacter::LandedDelegate). If the ability were instantiated, I could just bind an event to my delegate and do what I need to do in there, because when the event is called, it would still have enough self context to do something useful with. Instead, if you Bind Event to the delegate in the blueprint of the ability, such as OnAbilityStart, where I would expect to be able to, it gets called on the ability, and you donāt have the ability context to know who/where you are running on, so you canāt do any logic to evaluate an ability instance with delegates.
There are workarounds to these issues of course. I could have some scratch data fields to store the information from the delegates and poll them in the ability. Or I could extend the ability context with a simplistic data storage(as weāve done), but these still feel like hacks to a flawed library design that are only necessary because Able was deliberately set up in a way that runs contrary to how UE4 blueprinting works.
Yea thatās intentional. Able uses the CDO to speed up a number of things (mainly around replication and memory costs). The only thing that is instantiated per Ability call is the Context and the ScratchPad for the Task (which is a much smaller structure and far cheaper memory/construction-wise). My background is in MMOs and Consoles so I tend to be very conservative around memory/CPU/bandwidth when I can. Ideally I could do what GAS does and allow the option to instantiate vs not, but I havenāt felt the need to do that yet (and donāt receive much customer feedback about it either) so Iām wary about adding more complexity to the fundamental behavior of Able.
If you wanted to store state, you could modify the ScratchPads or the Context itself (as you have). So in your example, You could add a delegate to the ScratchPad for your task. Bind the Actor when the Task starts, and then release it afterwards.
Why does creating a blueprint ability task show up in the āAdd Ability Taskā menu like this?
UE creates multiple blueprints under the hood for a given blueprint class. The default and skeleton BP options are supposed to be hidden. Thatās a quick fix, Iāll get it in for the 4.23 update.