Able Ability System Info and Support Thread

Thanks for explaining : )
I’m guessing it could be a very common use case that maybe you can consider to teach users how to do. But I’m just one user, so I’m not sure I can say that.

I have a few questions.
Is there a way to get the ability length for branching abilities? I get the first ability length to stop moving until done, but I don’t know how to get the length of branching abilities if they are played. With the way I have it set up right now, it sometimes works depending on when I press my attack button to go the next branch, but I want it to work all the time.

Could you also elaborate on the possession task? I am able to possess fine, but unpossessing does not return to my original character. Do I need to add more logic for this to happen?

I think a better way of doing what you’re trying to do is to simply set some tags on the Ability itself (e.g. “Status.NoMovement”), and then in your character’s tick method, simply grab the currently active ability (if there is one), and check for that tag. If you’re playing an Ability with that tag - don’t allow movement or what not.

The possession someone recently reported as broken. I’m not sure what’s going on there yet since I merely call “Unpossess” which is supposed to magically handle things - but I’ll dig into it.

I have a question.
Can I handle input inside an ability? Preferably on Even graph?
My thing is that I have an ability that uses an animation with root motion but I want to rotate the character towards the input from analog stick while performing this animation.
There would be different kind of abilities that need to interpret input differently - so I assumed the best option is to just implement input interpretation in abilities since doing it inside the character and remembering all different input interpretations for abilities there just sounds horrible.
Is it possible?

Also there is a horrible bug. IF you create custom task using blueprints, any time you recompile that blueprint it will mess up the instance of that task on any ability timeline that uses it.
The most nasty part however is launching the editor once you add custom bp task, as in ablAbility.cpp : 232 when Able tries to build dependancy list, your blueprint task isn’t initialized yet or something in this line:

if (Task->HasDependencies())

Task is still null so you won’t be able to launch editor.

I would use tags for this. Tag the abilities you want to allow input during and then in your character simply check if your active ability has that tag and do whatever input logic you need to do.

Yup. That’s fixed in 3.0 (which is slowly plugging along). In the mean time you can fix that error by modifying two lines:

ablAbility.cpp Line 232:

if (**Task && **Task->HasDependencies)

ablAbilityInstance Line 54:

if (**Task && **Task->IsValidForNetMode(NetMode))

I’d release the bug fix early if I could, but 3.0 changes so much that it’s difficult to pull out just that fix.

EDIT: To be clear, this fix will let you get back into the editor and such, but will NOT properly copy over the newly compiled BP Task. That is the change in 3.0.

I’m sorry but this sounds like a horrible idea from a programming standpoint. Abilities are one thing and in this use-case, since how the input is interpreted is decided by the ability itself and it might be exactly 1-to-1, because there might be as many input interpretations as there are active abilities, the input handling should be inside an ability.
A character should know nothing about it’s abilities other than “It’s active now”.
Implementing some unknown N input types inside a character and then the need to add more in case you add new ability inside your character is a terrible programming practice and I would like to avoid it :confused:

Generally input handling is so specific (for player’s and classes) and tends to be iterated on a lot, that keeping all that code in a single place in the Player is normally the cleanest way to go (or you set up a state machine that has various states each with different input rules).

I don’t mean to dissuade you from trying your approach and keeping input checking contained within the Ability - there’s just no current support for that so you’d have to create your own Task by inheriting from IAblAbilityTask. The editor and such will automatically find it once you create it. You can use a simple task like “Play Sound Effect” as an example.

I’ve managed so far by adding my own task in c++.
I have a different problem now.
Basically I have a climbing system that provides me with information about nearest edges that are climbable in my world. It provdes me with an array of points as a path over which I want to move my actor playing the active climb ability. Can I make an ability duration “variable” so that it depends on the task length which is basically runtime generated from number of points and distances between them?

Yes. You have two options:

1.) There’s is an Ability Play Rate that you can define at Runtime (via GetPlayRate), so if you create just a default Ability that is 1.0s you can simply scale it accordingly up and down based on the whatever length you need.


2.) If you are using a custom task, you can look at the Play Animation Task which pulls the length from animation asset or the Query Tasks which actually simply ask the Task if it’s done (IsDone) yet as the task itself is an indeterminate length.

Thank you. I will try the IsDone() approach as it seems more clean to me

Another crash.

UAblAbilityTaskScratchPad* UAblAbilityContext::GetScratchPadForTask(const class UAblAbilityTask* Task) const
    UAblAbilityTaskScratchPad* const * ScratchPad = m_TaskScratchPadMap.Find(Task->GetUniqueID());

Seems it might be the m_TaskScratchPadMap that is being null at this point. Happens randomly whenever I exit from play mode.
Can’t tell what is null here as m_TaskScratchPadMap isn’t symbolized properly and Task seems to be ok. Unless its “this” that is null at that point.

Likely “this” is null. Can you give me repro steps so I can try and re-create this crash? Looks like you’re hitting exit while an Ability is running?

Here is the first thing before the crash from Call stack which is my custom task

class MYGAME_API UMoveUnitTask : public UAblAbilityTask

EDIT: I just checked, yes, when I exit the play mode while my task is playing, it crashes

EDIT2: Apparently I need to check if Context is valid before doing anything. My bad.
I was looking at how OnTaskStart is implemented. Altough it would be nice if a layer above, in whatever is calling “OnTaskEnd” would first check if context is valid, so that I don’t have to add the same check in every single OnTaskEnd myself.
Unless there is a reason for someone to call OnTaskEnd without the context?

Apparently I need to check if Context is valid before doing anything. My bad.
I was looking at how OnTaskStart is implemented. Altough it would be nice if a layer above, in whatever is calling “OnTaskEnd” would first check if context is valid, so that I don’t have to add the same check in every single OnTaskEnd myself.

I could put it higher. Ideally your context is always valid when you’re at that level. I remember adding that logic in the Blueprint call (basically if you pass bad parameters, we just error out and don’t attempt the Ability). Are you activating this via the C++ call? Or BP?

Task is activated with ActivateAbility Blueprint node.
Ideally the context is valid, yet for some reason when you hit ESC while an ability is playing you will get a crash because context is messed up. The same would happen with your built-in abilities, but I can see your code clearly adds a Context.IsValid() check inside OnTaskEnd() :slight_smile:

Ah, right. So your Context was valid, you closed the session which cleaned up all the objects, and then the context became invalid. Right, I remember having to add that check to fix that particular case.

Ok, here is a question. Why in the hell is BranchAbility marked as PURE ^^?
It’s an execution node, exposed to blueprint yet it has no exec input and output? Is this a mistake?

I mean this makes literally no sense :smiley:

That’s likely a bug.

Even if you take PURE as a const for Blueprint, it would fail that test as branching inherently changes the state of the Ability Component.

EDIT: Did an entire pass on the Ability component and moved most things from BlueprintPure to BlueprintCallable.