Welcome back.
We now have our own custom gameplay effect context class.
Aura Gameplay Effect Context.
Now the only difference between this and gameplay effect context is that it has two additional variables
booleans for whether we have a blocked hit and whether we have a critical hit.
Now we went through a lot of trouble just to do this right.
We had to create our own struct.
We had to override a couple of functions that existed on the gameplay effect context class, including
net serialize in which we had to learn about what was going on in net serialize in the parent version
so that we could serialize our struct and make sure that our new booleans are serialized along with
the other member variables of this struct.
So that was a really good learning exercise for us.
And in addition to that, we also learned about the struct ops type traits that we needed to define
for our custom effect context.
So a lot of work just to get two additional booleans, but the implications of this are a lot larger
than that.
Yes, we only added two booleans, but now we can add anything we want to our effect context class.
But that doesn't really matter if we can't use it.
We have to be able to actually use this context, and to do that we have to set our project to use this
particular effect context class.
So how do we manage doing that?
Well, one way to do it is to define our own globals class and ability system globals class.
You see, there already exists a class called Ability System Globals and it defines the globals global
variables and such used by the ability system that will always be accessible all throughout our code
base.
But we can subclass that into our own ability system globals class in which we can specify by our own
custom classes and structs to use.
We can specify the gameplay effect context that gas should be using.
We can specify gameplay cues, we can change what's initialized into gameplay cue parameters which we'll
learn about later.
We can change what classes our ability actor info uses.
We have lots of things we can do if we have our own ability system globals class.
So we need to create our own.
So let's go into our C plus plus classes aura public and I'll go into ability system.
We can go ahead and place that new class here.
I'm going to right click and select new C plus plus class.
Choose all classes and search for ability System Globals.
We're going to make a class based on this, and I'm going to call this aura ability system globals,
and we'll put it in ability system.
That's a perfectly fine folder for it.
So let's click Create Class and close down the editor.
So here in ability system, here's my ability system globals CP and my H file.
Now what we're going to do here in Ability System Globals for now is pretty simple.
We're just going to override a single virtual function that exists on the parent class.
So it's virtual and it returns a pointer to a gameplay effect context.
So it returns F gameplay effect context pointer and it's called alloc for allocation gameplay effect
context.
It's const and this is an override.
Now this function should look a little familiar to you.
You have seen it.
Now if you don't remember where you've seen it.
Before we move on, I'm going to show you.
So let's go back to, oh, let's say aura projectile spell dot CP here we're calling make effect context.
Now, recall a few videos ago we right clicked on that and went to the definition of it.
Here it is.
Notice that here in make effect context.
The context that is created as a result of this function call is created right here with the gameplay
effect context handle constructor passing in you ability system globals alloc gameplay effect context.
That's where this function is called.
This is what actually creates a brand new effect context.
Now if we're calling this function to create a new effect context, then this function determines what
class is used to instantiate that object.
And this function is on your ability.
System globals, which were now subclassing.
We now have our ability system globals.
So because we're overriding this, we can choose what is returned from this function.
So let's go ahead and generate the definition.
And what exactly do we want to return?
Well, we want to return a new aura gameplay effect context.
So even though this function returns a pointer to gameplay effect context, we can return an aura gameplay
effect context because it's derived from that type.
So we can return new F aura gameplay effect context.
So now we're determining that Alec gameplay effect context will create a new gameplay effect context
object of our custom type.
Now if we could only manage to tell our project to use this ability system globals instead of the you
ability system globals, then every time an effect context is created in our project that will result
in this function being called on our ability system globals which will return our effect context class.
So the question is how do we configure our project to use our class?
Well, first I'm going to go ahead and compile and make sure everything compiles correctly.
And it does.
And from here, I'm going to close down the editor and go into my config file and open up default game
dot ini.
And here in default game ini we can specify our ability system globals class.
We do that by introducing some new square brackets.
We have a forward slash script forward slash and we're going to have gameplay abilities.
Dot.
Ability System Global's.
So under this category, we're going to have a plus.
And we're going to say ability system globals.
Class name equals.
And in quotes we say forward slash script.
Forward slash followed by the module which contains our project.
That's.
So in my case, my project is called Aura, and then the class name for the ability system global.
So now we don't prefix it with the U.
Instead we just say aura, ability, system globals and that's it.
We save this and now our ability system Globals class is the one that we've chosen.
I'm going to close that down.
Your editor should be closed for this, by the way.
And after doing that, I'm going to right click open my project with writer.
And now my project should be using my custom gameplay effect context class.
So how can we prove that?
Well, going back to Aura Projectile spell, we're creating the effect context here.
We can place a breakpoint after we've created the context and just inspect that context, see what that
object actually is.
So I'm going to go ahead and run in debug mode so that we can hit this breakpoint.
So back in the editor, all I need to do is press play and launch a fireball.
Now, as soon as that happens, we've created our effect context and or projectile spell.
Now all I need to do is see what that effect context is.
So hovering over my effect context handle, I can take a look at data and right away I see is blocked,
hit and is critical hit.
So my effect context has these two booleans and the only way that that is possible is if this effect
context were an object of my custom aura gameplay effect context.
Because the regular gameplay effect context struct does not have is blocked hit or is critical hit.
So this right here tells me that I'm successfully using my gameplay effect context class.
And then of course we have access to all the stuff in the parent class.
So this is a success.
And now that we have these, we can access these in basically anywhere along the pipeline for our gameplay
effect applications.
For example, we can go to aura attribute set and right here in post gameplay effect execute.
I can place a breakpoint here, I'm going to hit resume and we see that we've hit this breakpoint and
because we've hit the breakpoint we have access to things like our effect properties.
This props here.
If I take a look at that, I can see that I have the effect context handle.
Here's data and here's the B is blocked, hit B is critical hit.
We can access that there.
So this is huge because if we set those booleans somewhere along the line, then later on down the line,
say in our attribute set, we can access them here.
In the attribute set, for example, we're showing the damage number with our floating text.
We're calling show floating text here.
What if we could pass along those booleans to show floating text and show the text in a different color?
For example, maybe for a blocked hit, we can show the text as blue and for a critical hit, we can
show it as red.
We can do anything we want here.
So the next step is actually using those booleans.
We need to figure out how we can access and how we can set that data.
So that will be our next step.
For now, this is a great milestone.
Excellent job.
And we have our ability System Globals class.
You can do lots of things here.
You can even create variables for global gameplay tags.
Of course, we've already done that with our gameplay tag singleton.
But here's another place that you could do it.
A Globals class is a nice handy place to put things you want globally accessible.
So great job and I'll see you in the next video.