Welcome to your next quest.
For this quest, you're going to handle the death impulse.
Now, there are a number of steps to this, and I feel like you can handle it without me telling you
all the steps.
So this is going to be up to you.
Once you get that death impulse vector, I'd like you to make that enemy as soon as it has died fly
in that direction.
Now, if you'd like a hint, you can call add impulse on the mesh.
So by the time you know that damage is fatal, then at some point you can do that.
But I'd like you to keep the code structure well maintained.
Don't go in and make unnecessary dependencies where they shouldn't be.
I don't want the attribute set dependent on or a base character or anything like that.
We have solid principles in place, so pause the video and conquer this quest.
Now.
Welcome back.
So I'm here in my attribute sets.
And I know that if be fatal I want to use my death impulse.
And I know that I can call add impulse on the mesh of the thing getting hit right.
But I don't want my attribute set dependent on, say, or a base character or something like that.
I'd rather be more flexible than that.
So what I'm going to do is go through my combat interface.
I'd like to go into my interaction folder, into combat interface, and before I go through all that,
I'm going to close all tabs except for aura attribute set.
And here in Combat Interface, we can figure out a way to send that death impulse to the character upon
death.
And I think we could just send that through in the die function.
If we add a const f vector reference called death impulse to the die function, then it'll be really
easy to use that death impulse vector.
So as soon as we add an input parameter to die here we've just broken a bunch of things.
So we need to go in and make sure that everything's compatible.
So we'll start by going into base character or a character base.
And we can see right here the die function has red squiggles on override.
Because there is no base class that has this function.
It now needs a const vector death impulse.
And we need to fix it in the cpp file as well.
Or a character base die needs to take that death impulse.
So what are we going to do with the death impulse once it's finally passed in here?
Well, I'd like to pass it down into multicast handle death, and in multicast handle death, we could
take that death impulse and we can apply it to the mesh.
We could even apply it to the weapon too.
So I'm going to add death impulse to multicast handle death as an input parameter.
And we'll put it right there in the function.
And we'll pass death impulse through into multicast handle death.
And then by the time we get here we can add an impulse.
We can do it to the weapon.
We can call add impulse passing in death impulse.
And we can do it to the mesh.
We can call it mesh and call add impulse passing in that death impulse.
So all we need to do is make sure that die gets the death impulse passed through.
Now, are we overriding die in other classes?
Well, we can check.
We can go to Aura enemy and it looks like we're overriding die here.
So this needs to take a const f vector reference called death impulse.
And we'll have to fix it in the cpp file.
Di needs to take that death impulse.
And really it's calling super di.
So we need to pass death impulse there and or a character H.
I don't believe overrides it.
We see that it doesn't.
So these comments are really useful because I didn't have to go search through the entire file.
I could just search right here.
So we've fixed or a character or an enemy and or a character base.
Those are done.
We can go back to the attributes set and make sure we pass a death impulse into die.
Well, we know that we have an aura ability system library function called get death impulse right?
All it needs is the effect context handle.
But we're nice and crafty and we collected all of our relevant properties in F effect properties.
So we can take props and we have the effect context handle there.
So by the time we hit die we can use that effect context.
We can get the death impulse using our easy to use function.
Aren't these easy to use functions nice and easy to use?
And now that that's happening, by the time a character dies, we should be adding that death impulse.
And we don't need this to do here anymore.
We're all done.
So the last thing to do is to compile, launch and start launching some fireballs and seeing if we can
fling some enemies around.
Okay.
So we're going to go ahead and press play.
We're going to launch some fireballs.
Okay.
I didn't see any death impulse there.
Didn't see any flinging around there.
So let's see what the death impulse is.
By the time we hit this line here where we're calling die.
I'm just going to make an f vector called impulse and use get death impulse on our function library,
and then place a breakpoint here so we can see what that's equal to.
So I'll go ahead and close down and launch again.
I'd like to see if we're actually getting that death impulse and make sure perhaps we haven't forgotten
a step somewhere.
So I'm just going to launch.
One more should do it.
I believe that the enemy has died from the fire damage, actually.
And I think the fire damage isn't going to have a death impulse and its effect context.
So what I'm going to do is.
To make things simple, I'm going to open my.
Game play.
Firebolt.
And I'm going to set its debuff chance to zero so we don't get that debuff.
And now we can test this.
Okay, now we're getting our impulse and it looks like it does have a magnitude.
So I'm going to continue.
And it's already dissolved.
So I'm going to have to do this again.
Okay, so it has a death impulse, but it might be too small.
I'm going to set it to 6000 for the magnitude.
Okay, so I saw the weapon go the mesh did not.
The weapon flung out to the side.
Or flung back.
So here's what I'm going to try to do.
I'm going to take my call to add impulse and hit comma and see that the pop up shows that there's a
couple other parameters.
One of them is B change.
That's for velocity.
Now if we set that to true then add impulse will no longer take the mass into account.
So if I pass something in for bone name we can just pass in name none.
And then for B change it says.
If true, the strength is taken as a change in velocity instead of an impulse, i.e. mass will have
no effect.
So if we do that for the mesh, then we won't have to use such astronomical numbers.
So I'm going to pass in true for that.
So with that little change, we should be able to start seeing those bodies fly around.
Okay, we can open our Firebolt and let's see how it looks at 6000 with that change.
Okay.
It did move a little bit.
Not quite as much as the weapon, so we might have to scale the weapon impulse differently.
But we have 6000.
I'm going to change it to three times that.
Let's go to 18,000 for that magnitude.
So one more should do it here.
There we go.
That's what I wanted to see.
One more.
There we go.
Now, the spear kind of flew a little too violently.
Yeah, way too violently.
So the spear doesn't quite need as much added to it.
We could scale that by perhaps a quarter of the force.
But I'd like to do the same thing that we're doing here, namely call add impulse.
Passing in.
True for velocity change, but we may need to scale that impulse by zero point.
Let's try 0.1 F.
We'll see if that's not enough.
But in general, those weapons are going to be a lot lighter than the mesh of the character itself.
So we might be able to get away with that.
It may actually be a parameter that you would set on your character if it becomes a problem, right?
If your weapons vary too much, you might just have a death impulse weapon scale factor of sorts.
But let's see how this works.
Okay.
That seems okay for the slingshot.
But let's see how it looks on the spear.
That actually looks pretty nice.
One more should do it.
Yeah, that looks like a pretty good impulse.
I'm liking it.
Okay, we have a death impulse, and it's looking good.
Now, we know that if an enemy dies due to fire damage from the burn debuff, it's not going to receive
any death impulse.
And I'm okay with that.
So, realistically, I think my debuff chance can be about 20%.
That could change per level.
Maybe not, but as you can see, that Firebolt missed because it already died due to fire damage.
And of course five fire damage per second could be a little op.
Oh, it looks like my fire debuff particle system survived.
I'm going to need to make sure to handle that, but I'm going to set my debuff damage, I think, to
one at least at this level.
And this of course could scale by level.
But I think that kind of a debuff is a little too overpowered at five damage per second.
And we're getting our really cool looking damage death impulse.
And it's looking great.
I love it.
So we do need to make sure that we kill those Niagara particles.
We need to find out why they're not dying.
And I just have this sneaking suspicion that they're being activated when they shouldn't be.
So let's go into that component.
Let's go into ability system debuff Niagara component.
And right here in debuff tag changed.
We're only activating here.
And I'd only like to activate if the owner isn't dead.
So I'm going to check that I'm going to say if get owner.
And I'm going to call implements the interface you combat interface.
And while I'm at it I could check is valid.
Get owner.
Make sure it hasn't been set to pending kill yet, and we can also check if it implements the interface
if it's dead, so we can take a combat interface.
Execute is dead, and of course we'd have to pass in get owner and to execute is dead.
So actually we have several reasons that we wouldn't want to activate this component, right?
In fact, if is valid, return false for the owner.
We wouldn't want to activate.
So to make this really easy to understand and avoid confusion, I'll make a const bool be owner valid
and I'll call is valid.
Get owner here and I'll say const bool.
Be owner alive and that will be if the owner implements the interface and is not dead.
So I'll copy these two and say not is dead.
And then we will only activate if the owner is alive and valid.
Alive and well, so be owner alive checks if we implement the interface.
If we don't, this would be set to false.
And if we're not dead.
If is dead, returns false.
Owner alive is true.
So we only want to activate if new count is greater than zero and be owner valid.
And be owner alive.
If any of these fail, then we'll deactivate.
So this should fix any unwanted activations.
Let's test that out.
And I think what caused the issue was if we hit the enemy with a fireball that does two things simultaneously,
one adds the debuff and two kills the enemy.
That's when we're running into problems.
So we can test that theory by setting debuff chance to 100.
So we always apply the debuff and then we can set that damage to a higher value.
It's ten, but if I set this value in the text box to say 100 then we'll be causing a thousand damage.
So now a single fireball is going to not only kill the enemy, but also apply the fire debuff.
And we don't see that fire.
Which is exactly what we wanted.
So that's an easy way to check.
Now, if we want to go back to our normal amount of damage, we can test what happens when we kill an
enemy that's got the debuff.
After we've applied the debuff.
And make sure that the debuff goes away.
At least the particle effect goes away.
And it does.
Awesome.
Now another thing regarding the fire debuff before we just completely wrap up is the enemy hit reacts
and while the enemy is hit reacting it cannot run.
And that hit react is happening every second.
Which basically means that if the enemy is on fire, it cannot chase us anymore.
Now that may be what you want.
It may not.
If you're okay with it, then great.
We can leave these mechanics as they are.
But if you want the enemy to be able to run around while it's on fire, well, that's going to be something
that you need to fix, right?
Your hit react.
Is going to need to either.
Not happen.
Or you should be able to run while hit reacting, which that would require some more animation blending.
So I'm not going to get into that.
But what you can do is you can avoid hit reacting if the damage is debuff damage.
Specifically burn damage.
So where do we make the hit react happen?
We make it happen in our attribute set.
If we search for hit react, we try activate abilities by tag with this tag container, and the hit
react ability could very easily be blocked by a specific tag.
The debuff burn tag.
This is just a really nice built in feature of gas.
These activation blocked tags.
If the hit react is blocked by that tag, then we can't hit react if we're already burning.
So let's go to blueprints ability system enemy abilities and hit react.
If we go to our activation blocked tags right here, we can add debuff burn because we know that our
enemy will have this tag.
If it's debuff burning.
If it's burning, if its head is on fire, then we should block the hit react activation.
So let's try that.
Let's go and burn a couple of these things and see if they stay hit.
Reacting.
Nope, they're still attacking.
They're running around.
Right.
Because the hit react is blocked if they have that tag, if the specifically if the activating actor
or component has any of these tags and what's the activating actor slash component?
Well, that if we look in the attribute set for hit, react is the target as the thing getting hit is
activating it, and we know that our debuff is applying that tag again because we added that tag to
inheritable own tags container.
This is the granted tags that we see in the blueprint for gameplay effects.
If you don't believe me, go to Gameplay Effect and find that inheritable own tags, inheritable own
tags container and look at its display name.
Granted tags right?
These tags are applied to the actor I am applied to, says the comment.
So this is the granted tags.
I should have come in here and showed you that back when we added to this, because that could have
been a source of confusion.
This is the granted tags.
Okay, excellent.
So now our enemies can run around while they're on fire, but they're still taking damage.
They're just not hit reacting perfect.
Excellent job.
And I'll see you in the next video.