Announcement

Collapse
No announcement yet.

Able Ability System Info and Support Thread

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

  • replied
    Originally posted by KamiSkilletLTD View Post

    Great, if you need more information let me know. Thanks!
    EDIT: Nevermind, I found the bug. It works in the preview window, but in the world/level it was using the wrong transform space. I have a fix and it'll go out with the 4.20 support update. Thanks for your patience and for reporting this bug! - Matt

    Hey Skillet, I got some time to investigate things and it *appears* to be working as I would expect. Here's what I'm seeing.

    So, here is the orientation of the socket I'm using ("head" in this case). You can see the X axis (red) is going up.



    Now, when I set my query to use the socket location and make a box 200x100x100, I get a properly aligned box.
    Click image for larger version  Name:	BoneRotation.jpg Views:	1 Size:	137.3 KB ID:	1502123
    Are you not seeing this occur?

    Click image for larger version  Name:	BoneRotatedQuery.png Views:	1 Size:	567.8 KB ID:	1502122
    Last edited by ExtraLifeMatt; 07-15-2018, 08:32 PM.

    Leave a comment:


  • replied
    Originally posted by ExtraLifeMatt View Post

    So you're seeing it with a manual rotation as well? That sounds like the transform concatenation might be wrong. I'll look at that and report back.
    Great, if you need more information let me know. Thanks!

    Leave a comment:


  • replied
    Originally posted by KamiSkilletLTD View Post

    You're right, if I remove the socket rotation it will stay with my character. I need it to stick with my character but also have the collision hit where I'm aiming/looking. If I try to set a manual rotation on the query it goes off my character again. My headSocket has no relative rotation on it. I do have plane constraint axis setting to X for my character. All this shouldn't really affect it but figured the more information the better. Any ideas?
    So you're seeing it with a manual rotation as well? That sounds like the transform concatenation might be wrong. I'll look at that and report back.

    Leave a comment:


  • replied
    Originally posted by ExtraLifeMatt View Post
    Hmmmm It could be something with the socket rotation. Try removing that and see what it gets. Otherwise I'll try some things out myself.
    You're right, if I remove the socket rotation it will stay with my character. I need it to stick with my character but also have the collision hit where I'm aiming/looking. If I try to set a manual rotation on the query it goes off my character again. My headSocket has no relative rotation on it. I do have plane constraint axis setting to X for my character. All this shouldn't really affect it but figured the more information the better. Any ideas?

    Leave a comment:


  • replied
    Hmmmm It could be something with the socket rotation. Try removing that and see what it gets. Otherwise I'll try some things out myself.

    Leave a comment:


  • replied
    I'm having trouble with my Collision query staying on my character while in game. The collision stays in the exact same spot no matter where my character moves. Any ideas?
    Click image for larger version

Name:	ablecollisionquery.JPG
Views:	44
Size:	77.6 KB
ID:	1493205Click image for larger version

Name:	ableInGamecollisionquery.JPG
Views:	43
Size:	60.4 KB
ID:	1493206

    Attached Files

    Leave a comment:


  • replied
    Originally posted by Tetsumori View Post
    Is there a way I can send a reference to character class in Ability Context to minimize casting?
    Not currently. To allow Able to be as flexible as possible, it only stores Actors. On the bright side, UE4's casting system isn't the normal C++ RTTI so the casts are very quick.

    Leave a comment:


  • replied
    Is there a way I can send a reference to character class in Ability Context to minimize casting?

    Leave a comment:


  • replied
    Originally posted by acxsasx View Post

    Yep, did that. When I look for all the references for the CharacterTag variable, it only shows Gets and no sets in the blueprint. Only reason I am bringing it up is to see where I am missing something where it gets set. I see the IncommingTag off the DamageByAbility class variable and I see where the comparison is done in the CheckBurning method.

    One thing to note is I opened up the example in 4.19.2 and I am seeing some weirdness in BurnPassive where all the custom events end in "_1". So maybe something is getting lost in the conversion.
    Ahh, right. The underlying methods changed names in 2.20 so that's why you see the _1. Yea, I'll need to remake those to get rid of that (Fun....). The get is either in the Ability Blueprint or the Character blueprint. Has to be set somewhere.

    The principle flow is still the same: When Damage is about to occur, pass in the tags for the incoming Ability. When damage does occur, check the Ability tags against the player tags, and do whatever combinations you want.

    Leave a comment:


  • replied
    You can also download the example and see how things work in more details.
    Yep, did that. When I look for all the references for the CharacterTag variable, it only shows Gets and no sets in the blueprint. Only reason I am bringing it up is to see where I am missing something where it gets set. I see the IncommingTag off the DamageByAbility class variable and I see where the comparison is done in the CheckBurning method.

    One thing to note is I opened up the example in 4.19.2 and I am seeing some weirdness in BurnPassive where all the custom events end in "_1". So maybe something is getting lost in the conversion.

    Leave a comment:


  • replied
    Originally posted by acxsasx View Post
    Regarding your burning man example, the BurnPassive ability sets gameplay tag "Status.Burning" which is done to the gameplaytag container on the ability component(?).

    On the targetmannequiun, off the "Event AnyDamage" event, in the Check Burning method, the CharacterTags variable is checked for the above gameplay tag.

    I don't see where CharacterTags gets the "Status.Burning" tag.

    I am assuming the abilitycomponent's gameplay tag variable should be used to look for the Status.Burning? (GetGameplayTagContainer)
    Correct, you want to keep all your tags in one place - so Ability Component makes sense since it already has support for them. The CharacterTags variable is just a temporary to copy the incoming damage's tags to before evaluating damage. It's then checked against the Character's tags (e.g. the Ability Component) and if anything special needs to happen - it does it there.

    You can also download the example and see how things work in more details.

    Leave a comment:


  • replied
    Regarding your burning man example, the BurnPassive ability sets gameplay tag "Status.Burning" which is done to the gameplaytag container on the ability component(?).

    On the targetmannequiun, off the "Event AnyDamage" event, in the Check Burning method, the CharacterTags variable is checked for the above gameplay tag.

    I don't see where CharacterTags gets the "Status.Burning" tag.

    I am assuming the abilitycomponent's gameplay tag variable should be used to look for the Status.Burning? (GetGameplayTagContainer)

    Leave a comment:


  • replied
    Originally posted by acxsasx View Post
    Thanks. I watched the video again and picked up a bit more. I think that was the last video I watched when I was deciding on buying the plugin and was a bit glass eyed at that point.

    I shied away from changing state in the calc dmg for actor method due to your warning about making it thread safe.

    In your example you are setting Damage by Ability on the actor and I think I heard something to the effect if that is the only ability(?) that sets that variable then it should be safe? So if I have another ability, I would need to have a second (and so on) variable on the actor for the second ability to be setting in order to maybe(?) take advantage of async?

    I am not really interested in trying async at the stage I am at, however I may want to not have abilities reuse the same ability variable on the actor for sanity sake. If having separate variables on that actor lends itself to using async in the future it would be good to start it now.
    Yea, if you're doing async you'd have to worry about two abilities possible running at the same time trying to set the same variable, in which case one would likely just stomp the other - not ideal, but it wouldn't crash. Or you just use a queue, which is thread safe, and simply queue / dequeue the entries rather than directly setting a single variable.

    It looks like Queue isn't exposed to blueprints by default, but there's a good step-by-step tutorial on adding that here: https://www.parallelcube.com/2017/10...to-blueprints/

    Leave a comment:


  • replied
    Thanks. I watched the video again and picked up a bit more. I think that was the last video I watched when I was deciding on buying the plugin and was a bit glass eyed at that point.

    I shied away from changing state in the calc dmg for actor method due to your warning about making it thread safe.

    In your example you are setting Damage by Ability on the actor and I think I heard something to the effect if that is the only ability(?) that sets that variable then it should be safe? So if I have another ability, I would need to have a second (and so on) variable on the actor for the second ability to be setting in order to maybe(?) take advantage of async?

    I am not really interested in trying async at the stage I am at, however I may want to not have abilities reuse the same ability variable on the actor for sanity sake. If having separate variables on that actor lends itself to using async in the future it would be good to start it now.

    Leave a comment:


  • replied
    Originally posted by acxsasx View Post
    Goal: Whenever an actor takes damage, evaluate the type of damage and react accordingly for that actor.

    First thought is to use UE4's TakeDamage's event "OnTakeAnyDamage" as a launching point for logic to respond to damage types for differing responses and logging. I would like to pass in a custom DamageType to have the different actors make decisions as this is a parameter of the TakeDamage actor method I am overriding and is included in the event being raised. Sadly, I see DamageTypes have to be a class and cannot be an instance.

    Alternatives:

    1 - add my own events in the blueprintlibrary call where damage is being calculated and pass the gameplay tag.

    2 - I see you set gameplay tag task could work, but it does not fire off any event that I could respond to.

    3 - Hmmm...maybe use the custom event task and have to remember to set it after every set gameplay tag is set?

    I think I am going to try for the (1) alternative. Make a delegate off my class that inherits from actor and have the bluprintlibrary broadcast it.
    Yea, I'm really not a fan of how the Damage type is setup by default in the engine (they're classes as you point out which is pretty heavy weight just for what amounts to a simple flag / integer).

    I basically handle this in the Burning Man example ( https://www.youtube.com/watch?v=-cAP5eqTb2Y ) by explicitly passing the Gameplay Tags during CalculateDamageForActor, so when the Actor actually receives the OnTakeAnyDamage callback - they can then look at the incoming tags for that damage.

    While not 100% ideal, since those calls happen back to back, you don't have to worry about some other damage call coming along and stomping your incoming tags (and if you are that worried, you could always store them as a queue).

    Leave a comment:

Working...
X