Announcement

Collapse
No announcement yet.

Able Ability System Info and Support Thread

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    So I just picked Able back up after a long break. Got a fire ball going and I have an issue.
    Engine Version: 4.21 fresh download of Able

    Skill:
    PlayAnimation
    SpawnActor

    if an enemy/wall etc that is collidable with the project that spawns is too close, UE4 crashes and I get an error shown here:
    Assertion failed: SpawnedActor [File:\Build\++Portal+Dev-Marketplace+Full\Sync\LocalBuilds\PluginTemp\HostProject\Plugins\Able\Source\AbleCore\Private\Tasks\ablSpawnActorTask.cpp] [Line: 116]

    i am 99% positive it's got something to do with potentially trying to destroy the projectile before the spawn actor task can finish firing?
    I'm off work tomorrow so I was going to take a look at it tomorrow because it's 1:20 in the morning and I need some sleep

    Leave a comment:


  • replied
    Yes that was the situation I was in, though I didn't realize until after I had refactored away from the custom task to try and see if it worked without the extra child class.

    Leave a comment:


  • replied
    Originally posted by JSwigart View Post
    Does it still work if the blueprint task is inherited from another blueprint class?
    Are you saying you have it setup "UAblCustomTask -> MyCustomTask -> MyCustomTaskChild"?

    I could see that potentially failing? I'm not sure what UE does under the hood for childs of BlueprintImplementable functions. It may be as simple as marking the BlueprintImplementable methods in UAblCustomTask as virtual (and hope that flag persists in child classes).

    Leave a comment:


  • replied
    Does it still work if the blueprint task is inherited from another blueprint class?

    Leave a comment:


  • replied
    Alright Able v3.15 submitted. Notes below:

    • Added support for UE 4.23
    • Added Bindable Dynamic Play Rate to Play Animation Task (let me know if you run into problems with this). This lets you dynamically change your Play Animation play rate at runtime.
    • Filtered out SKEL and REINST blueprint objects when using the Add Task picker. Blueprint objects use their display name rather than their raw name (no more Default__ if you don't override the GetTaskName method).
    As always, your feedback is super important and please let me know if you run into any issues.
    Originally posted by JSwigart View Post
    I have a blueprint class that extends AblCustomTask that implements the OnTaskStart override, I add the task to the timeline of an ability, the blueprint task OnTaskStart doesn't trigger. When I debug the code, I can see the UAblCustomTask::OnTaskStartBP gets called, FindFunctionChecked finds a function, but the Script field of the function is empty, so it doesn't execute anything, just early outs. I can't seem to get any of my blueprint tasks to work.
    I just verified it by making a simply custom task, overriding OnTaskStart and telling it print a string. I can give you the project if you want to see what I did and where you may be going wrong. You can grab it here.

    Leave a comment:


  • replied
    I have a blueprint class that extends AblCustomTask that implements the OnTaskStart override, I add the task to the timeline of an ability, the blueprint task OnTaskStart doesn't trigger. When I debug the code, I can see the UAblCustomTask::OnTaskStartBP gets called, FindFunctionChecked finds a function, but the Script field of the function is empty, so it doesn't execute anything, just early outs. I can't seem to get any of my blueprint tasks to work.

    Leave a comment:


  • replied
    Originally posted by KhxiSaki View Post
    is able build from the ground up or is it similiar or using UE4 Gameplay Ability System
    Built from the ground up. It has some similarities to GAS but that's mainly coincidence. GAS was pretty opaque when I started Able.
    Originally posted by JSwigart View Post
    Seems like UAblCustomTask aren't working in the latest code.

    The UAblCustomTask::OnTaskStartBP finds a function, but there is no script associated with the function, even though my blueprint has the OnTaskStartBP implemented. Any ideas?
    Define "no script associated with the function". If you have "OnTaskStart" overridden in the blueprint - then it should be fine. If you're trying to do it through code then you need to inherit from OnTaskStart as OnTaskStartBP isn't virtual (on the C++ level).

    Leave a comment:


  • replied
    Seems like UAblCustomTask aren't working in the latest code.

    The UAblCustomTask::OnTaskStartBP finds a function, but there is no script associated with the function, even though my blueprint has the OnTaskStartBP implemented. Any ideas?

    Leave a comment:


  • replied
    is able build from the ground up or is it similiar or using UE4 Gameplay Ability System

    Leave a comment:


  • replied
    Originally posted by JSwigart View Post
    What if the only options I see have the default tag?
    Because you're asking specifically for the default object. Admittedly, Able doesn't care because it uses the default under the hood, so anything besides SKEL should be fine.

    Leave a comment:


  • replied
    What if the only options I see have the default tag?

    Leave a comment:


  • replied
    Originally posted by JSwigart View Post
    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.

    Leave a comment:


  • replied
    Why does creating a blueprint ability task show up in the "Add Ability Task" menu like this?

    Leave a comment:


  • replied
    Originally posted by JSwigart View Post
    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.

    Leave a comment:


  • replied
    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.

    Leave a comment:

Working...
X