Able Ability System Info and Support Thread

[RodentGames]

I'm back! =)

I decided to test this a couple different ways to make sure I'm not missing anything else before I dive too far. I just attempted the same build (with the IsBlocking set to Replicated) to test networked responses. If the client is set up as the Authority everything works as planned with the little tweak. If I run two clients the Authority works properly and the animation replicates on the !Authority client. Switching to the !Authority client and run the ability and it gets stuck in the middle of channeling with no firing of Ability End.

It looks like the problem is in the UAblChannelingInputConditional.CheckConditional() as it always returns true if the AbilityComponent->IsNetworked() && !AbilityCompontent->IsOwnerLocallyControlled(). With logging this on the second client I was able to see that it was running that code on the client not just on the server and never able to let go of the channeling ability. I'm wondering if I'm missing a piece of code that submits the Input check from the client to the server for letting go of channeling or if I need to add something to the released input event?

A quick note this behaviour happens if running one client with a dedicated server for testing.

Thanks!

[ExtraLifeMatt]

I'm back! =)

I decided to test this a couple different ways to make sure I'm not missing anything else before I dive too far. I just attempted the same build (with the IsBlocking set to Replicated) to test networked responses. If the client is set up as the Authority everything works as planned with the little tweak. If I run two clients the Authority works properly and the animation replicates on the !Authority client. Switching to the !Authority client and run the ability and it gets stuck in the middle of channeling with no firing of Ability End.

It looks like the problem is in the UAblChannelingInputConditional.CheckConditional() as it always returns true if the AbilityComponent->IsNetworked() && !AbilityCompontent->IsOwnerLocallyControlled(). With logging this on the second client I was able to see that it was running that code on the client not just on the server and never able to let go of the channeling ability. I'm wondering if I'm missing a piece of code that submits the Input check from the client to the server for letting go of channeling or if I need to add something to the released input event?

A quick note this behaviour happens if running one client with a dedicated server for testing.

Thanks!

The ServerCancelAbility call should be the one who takes care of that (server obviously can't check input, so when the condition fails, the client notifies the server who then replicates out the result). Change that previous code to this and see what you get:

		if (!ActiveChanged && m_ActiveAbilityInstance->IsChanneled())
		{
			if (!m_ActiveAbilityInstance->CheckChannelConditions())
			{
				// Condition(s) failed
				CancelAbility(&m_ActiveAbilityInstance->GetAbility(), m_ActiveAbilityInstance->GetChannelFailureResult());
			
				m_ActiveAbilityInstance.Reset();

				ActiveChanged = true;
			}
		}

The CancelAbility code will make sure to forward cancellation request if the the game is networked and then process internal cancel as well if the owner is locally controlled (otherwise it'll cancel the ability after the server sends out the updates).

[RodentGames]

The ServerCancelAbility call should be the one who takes care of that (server obviously can't check input, so when the condition fails, the client notifies the server who then replicates out the result). Change that previous code to this and see what you get:

		if (!ActiveChanged && m_ActiveAbilityInstance->IsChanneled())
		{
			if (!m_ActiveAbilityInstance->CheckChannelConditions())
			{
				// Condition(s) failed
				CancelAbility(&m_ActiveAbilityInstance->GetAbility(), m_ActiveAbilityInstance->GetChannelFailureResult());
			
				m_ActiveAbilityInstance.Reset();

				ActiveChanged = true;
			}
		}

The CancelAbility code will make sure to forward cancellation request if the the game is networked and then process internal cancel as well if the owner is locally controlled (otherwise it'll cancel the ability after the server sends out the updates).

Just tried that as a test however the problem is on the remote client AbilityComponent->IsOwnerLocallyControlled() is always returning false? This is especially where my less than 40 hours in Unreal starts to show!

Thanks

[ExtraLifeMatt]

FYI: Able is now $99. The plan was always to drop the price a bit after the system had solidified (early adopters have been amazing with feedback and bug reporting), and after the sale I was happy with how the system held up under a bunch of new users - so, I'm comfortable with moving the price down a bit so more people can have access to Able.

Enjoy.

[ExtraLifeMatt]

Just tried that as a test however the problem is on the remote client AbilityComponent->IsOwnerLocallyControlled() is always returning false? This is especially where my less than 40 hours in Unreal starts to show!

Thanks

That's expected. That client should stop the Ability using the OnServerActiveAbilityChanged callback (which is set once the server resets the Active ability on its' end).

[RodentGames]

That's expected. That client should stop the Ability using the OnServerActiveAbilityChanged callback (which is set once the server resets the Active ability on its' end).

Okay with that in mind CheckConditional will always return true which means the Tick on the component will fail to send any cancel as m_ActiveAbilityInstance->CheckChannelConditions() will always return true. Am I missing something? I'm not sure where else from the remote side it will check the condition and cancel on the input?

[ExtraLifeMatt]

Okay with that in mind CheckConditional will always return true which means the Tick on the component will fail to send any cancel as m_ActiveAbilityInstance->CheckChannelConditions() will always return true. Am I missing something? I'm not sure where else from the remote side it will check the condition and cancel on the input?

Correct. The Remote side always assumes it passes. It's up to the server to cancel it.

The flow for a Cancelled Channel looks like this:

Authoritative (Local) Client:

Check Channel Conditions -> Input Condition Failed -> Send Failure to the Server -> Server clears the Active Ability -> All clients receive this change and cancel the Ability as well.

UnAuthoritative (Remote) Client:

Update Active Ability -> If it's channeled -> Check Channel Conditions -> Always Pass

OnServerActiveAbilityChanged:
Update Active Ability (or Reset it if the Server cancelled things).

I'll be able to play with this tonight and verify if there is some bug in that logic.

[Aumaan Anubis]

Hi [MENTION=172958]ExtraLifeMatt[/MENTION], so a couple things:

So I'm not to sure what the functional distinction is between the two nodes "Activate Ability" and the other node "Activate Ability" they're named the same thing, but one doesn't support a "target" field, what's the intended use case or benefit for having both of these?

Also I'm still having issue with cool down (my own user error more than likely).
When the ability reaches cool down, I want it to no longer be able to execute the following logic until the cool down is over.
The problem is that after the first "cool down" the next time ability is able to execute again, it fails to trigger the next cool down (allowing it to execute multiple times without being blocked by a cool down). I have the cool down hooked up to print screen so I can monitor when it's true or false, and I see that it cool down doesn't become "true" again until several executions later.

It's almost like the "cool down" feature has it's own cool down preventing it from triggering "cool down" because it's still cooling down from it's own cool down.........did that make sense?

Unrelated, but in task properties under "Branch", I want to use "custom" in the "conditions" section, however there is nothing to define after selecting "custom". What custom event is it assuming, I thought this could be user defined before?

[RodentGames]

Correct. The Remote side always assumes it passes. It's up to the server to cancel it.

The flow for a Cancelled Channel looks like this:

Authoritative (Local) Client:

Check Channel Conditions -> Input Condition Failed -> Send Failure to the Server -> Server clears the Active Ability -> All clients receive this change and cancel the Ability as well.

UnAuthoritative (Remote) Client:

Update Active Ability -> If it's channeled -> Check Channel Conditions -> Always Pass

OnServerActiveAbilityChanged:
Update Active Ability (or Reset it if the Server cancelled things).

I'll be able to play with this tonight and verify if there is some bug in that logic.

Thanks that would be helpful, if you need anything let me know!

For the price change I'm surprised by a drop, I paid the full price before the sale thinking I still got a good deal!

[ExtraLifeMatt]

Hi [MENTION=172958]ExtraLifeMatt[/MENTION], so a couple things:

So I'm not to sure what the functional distinction is between the two nodes "Activate Ability" and the other node "Activate Ability" they're named the same thing, but one doesn't support a "target" field, what's the intended use case or benefit for having both of these?

Also I'm still having issue with cool down (my own user error more than likely).
When the ability reaches cool down, I want it to no longer be able to execute the following logic until the cool down is over.
The problem is that after the first "cool down" the next time ability is able to execute again, it fails to trigger the next cool down (allowing it to execute multiple times without being blocked by a cool down). I have the cool down hooked up to print screen so I can monitor when it's true or false, and I see that it cool down doesn't become "true" again until several executions later.

It's almost like the "cool down" feature has it's own cool down preventing it from triggering "cool down" because it's still cooling down from it's own cool down.........did that make sense?

Unrelated, but in task properties under "Branch", I want to use "custom" in the "conditions" section, however there is nothing to define after selecting "custom". What custom event is it assuming, I thought this could be user defined before?

Hey Aumaan,

Can you get me a screenshot where you are checking this cooldown and of the Ability itself (or if you want to package up the project, I can take a look that way as well)? I'm still not totally following what you are trying to achieve vs what you are seeing.

This is the behavior you should be seeing.
- Cast Ability A (which lets say has a 1 second cooldown).
- Immediately try to cast Ability A again - Fail due to cooldown.
- After 1 second, Cast Ability A again - Success. Rinse, repeat.

Now, the cooldown is per Actor, so if you are trying to do a "universal" cooldown or something like that, it wouldn't work. But you're saying you're seeing the Ability fail initially (due to cooldown), but then other attempts succeed even before the cooldown is completed?

Also, is this a networked game or just local?

[MENTION=741122]RodentGames[/MENTION], Yea it's been planned for a while. I had promised myself I would drop the price after a few months once I was sure Able could handle more users, so I just decided to finally go through with that.

[Aumaan Anubis]

[MENTION=172958]ExtraLifeMatt[/MENTION]

So while I was cleaning up the BP getting it all pretty for the screenshots, I actually figured how it's supposed to be done while cleaning it up xD. It's fixed now!

Here is the BP if anyone wants to check out to do it:
BP



Able

Edit: Should disable the "loop" I left it on by accident in the screenshot because I was experimenting with something lol.

Anyway:
While doing this I did find a legit bug with the cancel ability node (more like a mismatch label):
The tool tips in the drop down list don't match their items:

[ExtraLifeMatt]

[MENTION=33476]Aumaan Anubis[/MENTION]

Glad you got things figured out! I'll take a look at that mismatched comment. Thanks for reporting back!

[Aumaan Anubis]

[MENTION=172958]ExtraLifeMatt[/MENTION]

Thanks, np. One more thing, I can't seem to get "blend-in" to work when transitioning into an ability animation:
In Able and in the StateMachine I've set the "blend-in" "duration" to 1.0 then I tried 2.0, but there is no "blend-in" to the ability animation.

Meanwhile "blend-out" works just fine as expected.

[ExtraLifeMatt]

[MENTION=172958]ExtraLifeMatt[/MENTION]

Thanks, np. One more thing, I can't seem to get "blend-in" to work when transitioning into an ability animation:
In Able and in the StateMachine I've set the "blend-in" "duration" to 1.0 then I tried 2.0, but there is no "blend-in" to the ability animation.

Meanwhile "blend-out" works just fine as expected.

Ah, good find. Definitely a bug there. Right now it won't blend for the 1st animation that used with that node, but the subsequent ones are fine. I'll work on a fix for that and it'll be in the next update.

[Aumaan Anubis]

[MENTION=172958]ExtraLifeMatt[/MENTION]
Cool, thanks

Oh, and what about the task properties under "Branch", I want to use "custom" in the "conditions" section, however there is nothing to define after selecting "custom". Is that intended?
If so, what "custom event" logic is it assuming, I thought this could be user defined before?