Yea, I found the issue with the checkbox for Camera/ Collision. I have a fix coming.
As long as you save the Ability (which happens automatically when you try to play an Ability), it should change the Animation during the preview. I’ll check that locally as well, but I’d look at your log for any weird errors.
That is up to you. Able doesn’t support that out of the box.
I would do it where I figure out the general direction of the damage (so, just create a vector from the damage source to my actor). And then do a handful of half space tests to find the general location.
I recently started working on my project again and saw that there was an Update for Able.
Right now it seems that the “OnGetDynamicProperty_Cooldown” function isn’t even called.
All I did was copy pasting my code from “GetCooldown”(which was marked as deprecated) to this new function.
I read that there were bugs with dynamic fields not working. Wasn’t this fixed in 3.0.3?
Move To / Jump To are entirely experimental. I’m planning to circle around to them this weekend. They may get removed as movement is such a per-game specific thing, but I’m going to see if I can’t give them one more shot.
Dynamic fields were fixed in 3.0.3, but I may have missed a spot with Cooldown. I’ll verify.
You’re going to have to get comfortable with making your own Tasks (either through Custom Task or through C++ and inheriting from UAblAbilityTask). You’re going to want to just apply some Z velocity to a character and then put them in some “Air Juggle” movement state (which you’ll have to create).
Again, Movement is so game specific that it’s near impossible for me to make “out of the box” solutions for people.
Doing jam using Able. Anyone had problems when restarting level? (only in build or DebugGame / DevGame without Editor) When destroying AblComponent it tries to call OnAbilityEndBP for “None” Ability. It isn’t null but just None object… cause to crash.
It appears when I’m extending abilities from other ones not from base c++ class.
I went ahead and checked on this. Cooldown IS being calculated through the field, but it’s not calculated within the Ability Editor (unless you’re using a Branch Ability which calls an Ability). This was done on purpose to avoid not being able to iterate quickly on an Ability that has a long cooldown. I could add an option whether or not to respect cooldown while authoring Abilities, or even add an option that just clears all cooldowns - but I’m still thinking on that. I’d appreciate any feedback from people on which they prefer (or if they even want the current behavior changed).
I’m still trying to decide how I want to handle Move To / Jump To. I’m leaning towards making them work only with the Character Movement Component which would greatly simplify things. Maybe split out Navigation Path Finding in to it’s own Task.
Thanks for your support and keep the feedback / bug reports coming.
Sorry…I’m not completely able to follow you.
What does “OnGetDynamicProperty_Cooldown” if not asking for cooldown at runtime?
And what would be the best method to dynamically change the cooldown depending on variables from a context actor?
Aswell thank you for your support and your willingness to help.
I still cannot get a target asset to spawn in the editor. The output log says “LogAbleEditor: Warning: Could not load asset [name of asset]” no matter what asset I pick. I tested with multiple actors and even the same actor as the preview asset, but I still get this message.
It does ask for the Cooldown, but only when not in the Ability Editor. The Ability Editor purposely doesn’t calculate cooldown since it doesn’t use it. Like I said, I may make that an option so if you want to test your cooldown logic in the Ability Editor - you can.
If you try your Ability when in a level or in game, you should hit your breakpoint (at least, I did).
Interesting. Any special repro steps? Or just try and spawn the Target Actor?
Yea, It’s on my list for this weekend. I’m already preparing a patch for the dynamic fields on the Ability itself not binding during runtime, so I’m going to try and squeeze in a fix for the Target Actor as well before I submit the patch this weekend.