Able Ability System Info and Support Thread

[ExtraLifeMatt]

@JSwigart

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.