Welcome back.
Now we have a highlight interface which allows us to highlight any actor that we wish.
And that actor provides its own implementation of the highlight and Unhighlight actor functions.
This means that any given actor can have its own custom depth stencil value, which results in it highlighting
a different color, and so on.
Now that's great, but I'd also like our highlight interface to have an option where if we click on
it, we can retrieve a move to location, a specific location that we can auto run to.
This will be useful for things like checkpoints, and soon when we create dungeon entrances or map entrances
that we wish to click on and move into to transition to new levels.
Now for that reason, I'm going to add a new function to our highlight interface that can reset our
destination.
So wherever we're clicking, our player controller is setting a cached destination.
We can see that in our player controller if we search for cached destination.
We'll see that we're setting it in.
Ability input tag held.
As long as we're holding our mouse down, we're setting it to the impact point on our cursor hit.
Now when we release the mouse button, we're using that cash destination.
If we go over to auto run, for example, we're checking the distance to it there.
If we go to ability Input tag released, we're using it here.
If our follow time is less than short press threshold, then we're auto running to the cast destination.
Now, what I'd like to be able to do is reset that cached destination based on our actor that we're
highlighting.
If this actor implements the highlight interface, which it should, I'd like to check to see if this
actor would like to overwrite that destination.
So what I'm going to do is add a function.
To do this in the highlight interface I'm going to make a function.
It can be void.
If you really wanted to, you could return a boolean here.
Returning true to let the player controller know that we're overwriting the cached destination, but
it could be void.
I don't really have a use for that boolean, so I'm going to call this set move to location, and I'm
going to pass in an F vector by reference non-const and call this out destination.
I'm going to make this blueprint native event.
Giving it that versatility.
And we're going to overwrite this in any class that we wish to overwrite this out destination.
And any classes that don't wish to change it at all don't have to implement it.
So our checkpoint, for example, can implement this function.
Let's give it a comment that says highlight interface and another one that says end highlight interface.
And we'll override virtual void set move to location implementation.
Now here's the thing.
I'm not getting the autocomplete for this, and it's not an override because I chose to implement this
interface in C plus plus.
So what I'm going to do, I still have the editor open is I'm going to take my checkpoint.
I'm going to go ahead and just remove my implementation of these in blueprint, and just remove my interface
here from my implemented interfaces.
It's going to ask if I want to transfer the interface functions to be part of this blueprint.
I don't want that.
I'm going to click on no.
So now the checkpoint no longer highlights the interface.
We can see that by pressing play we don't get highlight behavior.
I'm going to implement this in C plus plus now.
So I'm going to close the editor.
And here in the checkpoint I'm going to implement.
Publicly public.
I highlight interface.
We'll get that highlight interface header included.
And now we should be able to override this function.
I must have a typo set move to location.
Yes, it needs an F vector.
A vector reference out destination.
So now that checkpoints implement this function, a checkpoint can return any destination we wish for
our character to move to.
I'm going to go ahead and generate the definition, but we'll keep it blank for now as checkpoints are
going to need to return something.
So we'll figure out what that should be soon.
But now that checkpoint implements I highlight interface, I'd like to provide the implementation for
highlight and Unhighlight actor here in C plus plus.
That way we don't have to go in and implement it for all blueprints that we wish to have derived from
the checkpoint class.
So I'm going to override virtual void, highlight actor implementation and virtual Void and highlight
actor implementation.
And we'll go ahead and implement these functions.
Now highlight actor.
I'm going to want to set render custom depth to true.
And we're doing that in the enemy.
If we go to our enemy highlight actor implementation, we're getting the mesh and calling set render
custom depth.
We're even setting the custom depth stencil value to red, something we could just do in the constructor
for both the mesh and the weapon.
Why don't we go ahead and just do that?
We don't need it here.
I just copied those three lines.
And in the constructor I'm going to go ahead and paste them removing that middle unnecessary line.
So we're setting the custom depth stencil value to red here.
Now if we set this in the constructor we can force that update right away by taking the mesh and call
Mark render state dirty.
And we can do that on the weapon as well.
Weapon mark render state dirty.
So now we're not setting this every time we highlight and unhighlight the enemies.
But the point is that we're setting render custom depth to true or false.
When we want to highlight or unhighlight.
We can do this in the checkpoint as well with our checkpoint mesh.
So we're going to say checkpoint mesh for highlight actor implementation set render custom depth.
Passing in.
True.
And for Unhighlight actor.
We'll call set render custom depth passing in false and we can set that custom depth stencil value in
the constructor.
Right here we can say checkpoint mesh.
Set custom depth stencil value and we have values in aura dot h.
I'd like to use custom depth ten.
So we'll pass that in.
And include ora H.
So that's defined.
And we can take checkpoint mesh and mark render state dirty.
Now our highlight functionality has been moved into C plus plus.
But if we want to be able to change that custom depth stencil value for any actor derived from checkpoint,
this could be a variable.
So let's go ahead and make a variable.
Here in checkpoint this will be an int 32.
And we'll call this custom Depth stencil.
Override.
And I'll go ahead and set it to Custom Depth ten, which means that Ora H should be included here in
the header file, and we don't need it included here.
We'll just make sure it's here in the header file, and we'll make this something we can set in the
blueprint with edit defaults only.
So now we can use custom depth stencil override right here in the constructor instead of custom depth
tan.
Okay, so that's all great.
We're still doing the same thing.
We're just setting render custom depth from C plus plus rather than in blueprint.
What about this set move to location implementation?
Well, for a checkpoint, I'd like some kind of object that we can place in our checkpoint blueprint.
Relative to the root.
We could use an F vector, or we could use a scene component.
I like scene components because we can attach a billboard to them and make them easy to see.
So I'm going to make a U scene component.
And this can be a t object pointer.
Of type using component.
And I'm going to call this move to.
Component.
And this will be a new property with visible anywhere.
And we're going to construct this in the checkpoint constructor.
Move to component equals.
We'll use Createdefaultsubobject with you scene component.
We'll call this move to component and we'll attach it to the root component.
So we'll call setup attachment get root component.
And we'll move this to a specific location in the blueprint.
And our override of set move to location is just going to take this out destination out destination
and set it equal to move to component get component location.
And now we can overwrite any vector we pass into this, such as in the player controller where we're
about to auto run to cached destination.
If we like, we can check this actor.
We can say if is valid, this actor and this actor.
Implements you highlight interface.
Then we can call.
I highlight interface.
Execute set.
Move to location.
We have to pass this actor in first and then we can pass in cached destination.
Now the enemies do implement this interface.
So it would be good if we explicitly define exactly what should happen in that case.
Just so it's clear.
So we can come into the enemy and override virtual void set.
Move to location implementation override.
And for this definition we should do nothing.
Do not change out.
Destination.
So that way it's clear what our intentions are.
Our aura enemy doesn't want to do anything in this case now, because our checkpoint is overwriting
this location.
If we click on a checkpoint, then we should now get auto run behavior to a specific destination.
And before we compile and launch one last little detail, this is a little thing that I'd like to do,
is if we are overwriting this destination, I don't want to show my Click Niagara system.
If I'm clicking on a checkpoint or a map entrance, once we make those, I don't want to show this Niagara
system.
So what I'll do is have this in an else case right here.
If we're not overwriting the destination, then we'll have this line here.
So I'm going to cut that and put it here.
And we could make this compact a little bit by taking the if and moving it right after the else to make
it an else if.
And then we don't have so much nesting here so we can do that.
So that way if we click on a checkpoint and we're auto running to it, I don't want to show those Niagara
system particles because they may be showing us where we clicked, which could be different than where
we end up due to overwriting cache destination.
So it's a small detail, but I felt it was important enough.
Okay, so now we can move that scene component on the checkpoint to a specific location that we'd like
to run to.
So let's test this out.
Okay.
So I'm going to get my checkpoint blueprint back open.
And I'm going to go into the viewport because now I have a move two component.
Now by default it's set to the root components location as it's attached to that.
But I'm going to go into perspective right.
So I can see this from the right.
And I'm going to choose where I'd like to move to.
When we click on one of these I'm just going to take the move two component and move it to about right
here.
So that way we'll move to this location specifically.
Let's test this out.
I'm going to save all first.
I'm going to press play and we're testing a couple things.
First, do we get highlight behavior as we're doing this now in C plus plus and yes, we do.
Now if I click anywhere on this thing.
Well, we actually need to be somewhere where there's a nav mesh bounds volume, don't we?
So now if I click anywhere on this one.
We went exactly to this location on it and we didn't show our particles.
Now, if I click elsewhere, I get the particles right.
But if I click anywhere on here we go specifically to that scene component location.
And to prove that we can go to Perspective view and we can put it anywhere, say on the opposite side
of it back here.
That's going to be the back of it.
Let's try that.
I'm going to click right here.
And I went to the back of it.
So this is what's going to allow us to create anything that we wish.
A set of stairs, a tunnel, anything that we like.
And we'll have this move to component that can help us to determine where we should auto run to when
we click on that thing.
And that's going to be pivotal in creating any map, entrances or exits that we can use to transition
to another map.
So this is a great milestone.
So excellent job.
We're going to continue with this in the next video, where we start to create a new class based on
our checkpoint that will allow us to transition to other levels.
Excellent job, and I'll see you soon.