Able Ability System Info and Support Thread

[RodentGames]

[MENTION=741122]RodentGames[/MENTION],

With regard to Stamina/Mana, there is a BP method you can override called "CustomCanAbilityExecute" that is always called before an Ability is allowed to start, there you would check they have the available Stamina/Mana/Whatever and then in OnAbilityStart you would actually decrement the resource cost from the player.

I'll double check the Custom Event code and get back to you. I had another report of some weird behavior with dedicated servers so I'll probably just do a dive into that today and see what's going on.

With regard to 4.16 and the crash, my only advice is to wait for 4.17 and upgrade ASAP. I was hoping that bug fix would make it as a hotfix, but it looks like they're going to just toss it in 4.17 instead - so, my hands are tied. Again, this was a core behavior that Able relies on that was changed so it breaks things badly. If you have Engine source I can give you the code to fix the issue until 4.17 is released.

Okay CustomCanAbilityExecute is what I had settled on last night as well as it seems the best place. In my 4.15 version I was running into trouble with consistent behaviour on CustomEvent and a race-condition on the replicated value coming back from the server and it was hard to detect the trouble. With my change to 4.16 and rebuilding my abilities from scratch I seem to get a more consistent response from CustomEvent at the moment and the race-condition showed up. On dedicated servers this shouldn't be a problem because it is in the 1-5ms range that is the issue where the server updates the local controlled player before the player actually fires CustomCanAbilityExecute. If I just put a 10ms lag on the connection I never run into the problem which means I'm very unlikely to run into the scenario with the intended use.

Thanks again!

[RodentGames]

Thanks Teak. Really appreciate the kind words.

[MENTION=741122]RodentGames[/MENTION], so I found a rather big bug with network realm not being respected for most tasks (it respected actors within those Tasks, but things like CustomEvent which don't have Actors to check would get called on all realms despite being set to 1 or the other). This probably is what is causing the issues with branching in multiplayer as well since it has a similar behavior. I'm testing a fix right now and will have it out ASAP (hopefully Monday/Tuesday).

Okay I wasn't crazy! I've got a workaround in place and if I run into the same inconsistencies I saw in 4.15 I'll let you know. There maybe a rare trouble with saving the asset(s) as I've had to delete tasks a couple of times and re-create because the outcomes weren't correct (Collision ignoring a condition or ApplyDamage ignoring the target information as examples). I haven't reported it yet because I can't reproduce the issue and I haven't noticed it in 4.16 at all.

Thanks for your fast responses!

[RodentGames]

I forgot I ran into trouble with abilities having Cooldown = 0 but the client not allowing to switch "due to reason [Cooldown Not Expired]". This for me was an interesting one but I just tweaked ablAbilityComponent.h:

	bool IsComplete() const { return CurrentTime > CooldownTime; }

To:

	bool IsComplete() const { return CooldownTime == 0 || CurrentTime > CooldownTime; }

With a small change to ablAbilityComponent.cpp (though this might be an incorrect approach but it is a hack that works for now):

void UAblAbilityComponent::AddCooldownForAbility(const UAblAbility& Ability, const UAblAbilityContext& Context)
{
	m_ActiveCooldowns.Add(Ability.GetAbilityNameHash(), FAblAbilityCooldown(Ability, Context));
}

To:

void UAblAbilityComponent::AddCooldownForAbility(const UAblAbility& Ability, const UAblAbilityContext& Context)
{
	FAblAbilityCooldown abilityCooldown(Ability, Context);
	if (!abilityCooldown.IsComplete()) {
		m_ActiveCooldowns.Add(Ability.GetAbilityNameHash(), abilityCooldown);
	}
}

This way it makes sure the cooldown doesn't get added in cases where there is no cooldown to add.

[RodentGames]

I'm curious as to this message I'm seeing cropping up at the end of abilities:

LogNet:Warning: UIpNetDriver::ProcesRemoteFunction: No owning connection for actor BattleArenaCharacterBP_C_1. Function ServerCancelAbility will not be processed.

I dove in and found out that what is happening is ServerCancelAbility is getting called for a ROLE_SimulatedProxy which as far as I understand from the docs is not allowed. I'm still learning the structure to Unreal but it seems that the cancel ability call is coming from the simulated proxy on one of the other clients. One way to expand the check is to either watch for SimulatedProxy or follow IpNetDriver's approach and us GetNetConnection() on the owning Actor to find out if there is a valid connection to make the call.

To quiet the warnings I'm going to use the GetNetConnection() approach for now but I'm curious as to which would be the correct approach for this case?

[ExtraLifeMatt]

[MENTION=741122]RodentGames[/MENTION]

Hmm, I think not adding the cooldown if it has no cooldown is probably the right approach, so I'll add that in. Interesting that UE doesn't just skip calls if its a Simulated Proxy. I'll add in the GetNetConnection check before calling RPCs and help clear up that spam. Thanks for the reports and diving into that.

Slight tweak to the AddCooldown method (avoids having to modify the IsComplete call):

void UAblAbilityComponent::AddCooldownForAbility(const UAblAbility& Ability, const UAblAbilityContext& Context)
{
	if (Ability.GetCooldown() > 0.0f)
	{
		m_ActiveCooldowns.Add(Ability.GetAbilityNameHash(), FAblAbilityCooldown(Ability, Context));
	}
}

[RodentGames]

No problem! Thanks for the correct way to fix AddCooldownForAbility =)

[ExtraLifeMatt]

Alright, finished up Able v1.7, all packaged up and ready for Epic on Monday

Notes:
- Fixed an issue where Actorless tasks (Custom Event being the big offender) would execute regardless of the Realm (Client/Server/Both) specified. (h/t [MENTION=741122]RodentGames[/MENTION])
- Fixed an issue where Abilities with no Cooldown could get added to the cooldown list (causing issues due to network latency). (h/t [MENTION=741122]RodentGames[/MENTION])
- Fixed an issue that could cause Log spam due to RPCs being invoked on Simulated Proxies. (h/t [MENTION=741122]RodentGames[/MENTION])
- Cleaned up Ability Animation Node code after verifying various execution details. In some cases it was failing to move to the next queued animation (particularly if you branched to an Ability with an Animation), branches should feel more responsive now.
- Ability Animation Node no longer errors if you attempt to queue more than 2 animations. Instead, the oldest animation is removed to prevent throwing away more recent animation requests.
- Rewrote "Has Ability Animation" logic to no longer use a reference counter, but instead directly query the Animation Node itself. This fixes calls to CancelAbility appearing to always interrupt the animation (rather than only when the Ability result is marked as an Interrupt and the PlayAnimationTask requests that the animation be interrupted). (h/t [MENTION=33476]Aumaan Anubis[/MENTION] )
- Fixed a small tooltip issue with the Task result choices when choosing from the dropdown in Blueprints (UHT doesn't like same line comments). (h/t [MENTION=33476]Aumaan Anubis[/MENTION])
- Removed an extraneous RPC call when cancelling the Active Ability.
- Couple of non-unity build fixes.

[Aumaan Anubis]

[MENTION=172958]ExtraLifeMatt[/MENTION]

This looks like it's going to be a really clean release! Thank you for investigating.
And also thank you [MENTION=741122]RodentGames[/MENTION] for digging deep into what you found as well.

I can hardly wait for release

[order66]

Is the source included?

[ExtraLifeMatt]

Is the source included?

Yes. All C++ Plugins on the marketplace must include source (and I didn't want to hide things behind libraries anyway, its better everything be out in the open for people to modify/read/learn).

[ExtraLifeMatt]

Hey All,

4.17 support for Able has been submitted to Epic and should be available soon™

Enjoy!

[EniGmaa]

How would able cope with a dash kind of ability in a multiplayer setting specifically the replicating and rubber banding problem . From what I have experienced unfortunately when you do a dash kind of ability unreals replication system tries to correct the movement and you end up with rubber banding or teleportation so the character dashes then moves back to another location . Seems like the only proper way to combat this is to override the character movement component. So just curious wether able has anything built in to tackle this kind of problem with abilities that move a player another example could be a sword attack animation where a player lunges forward etc and also how does the system perform over the network when users experience higher pings , packet loss etc

From what I have seen the videos you have made is only the system tested in the editor I would be curious how it actually performs in a real multiplayer setting as in package the game and server and play it over the Internet from two different computers

Thanks looks really impressive system though

[Vaei]

How would able cope with a dash kind of ability in a multiplayer setting specifically the replicating and rubber banding problem . From what I have experienced unfortunately when you do a dash kind of ability unreals replication system tries to correct the movement and you end up with rubber banding or teleportation so the character dashes then moves back to another location . Seems like the only proper way to combat this is to override the character movement component. So just curious wether able has anything built in to tackle this kind of problem with abilities that move a player another example could be a sword attack animation where a player lunges forward etc and also how does the system perform over the network when users experience higher pings , packet loss etc

From what I have seen the videos you have made is only the system tested in the editor I would be curious how it actually performs in a real multiplayer setting as in package the game and server and play it over the Internet from two different computers

Thanks looks really impressive system though

Character displacement is something you do with client-side prediction, not regular replication. I think you'd have to build that part yourself. I'd like to hear from [MENTION=172958]ExtraLifeMatt[/MENTION] if they have a solution as well.

[ExtraLifeMatt]

Character displacement is something you do with client-side prediction, not regular replication. I think you'd have to build that part yourself. I'd like to hear from [MENTION=172958]ExtraLifeMatt[/MENTION] if they have a solution as well.

Ah, I think this was posted on YouTube so I answered it there. But I'm happy to talk about it here as well.

As [MENTION=2285]Vaei[/MENTION] mentions, quick movement (dashes, teleports, etc) is a prediction/replication problem and is one of the bigger pains in multiplayer titles. A buddy I worked with in AAA likes to say, "Multiplayer doubles the cost and complexity of any game" and this is a great example of that. In a singleplayer game, you apply an impulse/use an animation with root motion and you're done. In multiplayer, you have to play the root motion animation/apply the impulse on both client and server (and hope the lag isn't too bad so you don't get rubberbanding), otherwise you need to craft special movement/interpolation logic for both the local player and remote players so it doesn't look hitchy (and in the end you'll still get feet sliding around).

Honestly, the best way to solve it that I've personally done in the past, is for all movement to be client authoritative - meaning the client drives movement entirely and the server just broadcasts it to other clients and adjusts it when it has to (e.g. don't allow the character to go into walls, check for extremely large changes in an update that occur over multiple frames which might indicate hacking, whatever other sanity checks you can think of). This keeps the local player's experience looking great, at the cost of a bit of security (but again, hopefully you are catching that in other ways by looking for suspicious behaviors). This isn't something Able contains by default, so it would be up to you to write that custom movement logic.

As far as Able and Internet connections, it works fine in my testing - even with high ping/packet loss. Able doesn't take much bandwidth at all and there's only an initial packet that describes the Ability to play, the context, etc - once that is successfully sent, the rest of the Ability is just played locally. The server is still authoritative for damage/etc in Able, so in high ping you may have some damage being dealt but then the client side ability looks like it doesn't "connect" due to the lag/packet loss, but that's about it.

[Celino Peiris]

Hi there, I was thinking that if you could make a tutorial to go along with the new release, that showed how to set up the blueprints of one of the popular templates and made them, let's say.. "Able-Ready" (Ability nodes ofc ), it could turn out as a massive step towards beginners. It would make the already amazingly useful plugin even more accessible and transparent for new potential customers.

I bet you are a busy man, but perhaps you might consider this, I think it worthwhile, so I give it my best shot What do you think?

p.s.: now that I read the fixes for the new version, my confusion is lifted, everything worked like a charm, just the abilities not queuing up drove me slight mad