Welcome back.
Now our electric beam looks pretty good, but you might have been bothered a little bit by the fact
that it just goes through walls.
And if you click up here on the wall and you launch that beam, it doesn't go up to where you're clicking.
It goes to the location of our hit result.
And of course, these walls are not responding to the visibility channel.
That's why we're not getting that hit.
So what we can do is our target data under mouse, which is what is used by our gameplay abilities,
doesn't really need to be ignored by the surroundings.
It can actually be blocked by everything.
And the easiest way to make that happen is to make it have its own trace channel.
And we can make a trace channel.
We've done so before.
In this course we can go to Project Settings and search for object and under Object channels.
Here's our custom projectile channel set to ignore everything by default, we can click New Object Channel
and create a new one.
Now I'd like this to be used by our target data under Mouse Ability task.
So I'm just going to call it target.
And I'm going to leave it to block everything.
So I'm going to click accept.
And now we have a target trace channel.
And what we can do is we can set our target data under mouse to use that channel.
And before we do that I'm going to define a macro symbol for it.
I'm going to say pound define EQ underscore target.
And this will be collision channel EQ game trace channel two.
As we've already created one custom channel that's channel one.
The next becomes channel two.
And then we can go into our ability task under private ability system ability tasks target data under
mouse.
And we can find in send mouse cursor data where we're calling get hit result under cursor.
Here we can change this to trace against EQ target.
Now.
Now that means we have to include the ora h header file.
So I'll go ahead and do that.
And with that we can go ahead and launch the editor.
So back in the editor, I can press play now.
And if I right click and hold now, I see my electric beam is hitting everything because everything
blocks against that target channel that we're using.
In fact, I can launch a fireball as well, and it'll go towards those locations that I'm clicking on.
So that's pretty nice.
Now this fixes a lot of issues, but since everything blocks it, this can create complications.
For example, if I come up to the edge and I right click and hold, well, you expect me to zap down
there on the floor, but I'm zapping up towards the camera because there's a blocking volume here.
And if everything blocks target by default, that includes this blocking volume.
So we have to uncheck or at least check ignore for the target trace channel on our blocking volume.
And that should fix that issue.
But if I right click right in the middle.
Well, remember Ora has a box component right there.
So we also need to make sure the box component ignores the target channel as well.
So we'll open Ora and get that box selected.
And we'll make sure the box ignores the target channel.
Okay, saving all and just performing a quick test.
Now we see that it's working.
Okay, so that looks good.
But there's also an issue.
And you know what?
These goblins are in the way.
So I'm just going to really quickly delete them.
As I'm testing we can very easily bring them back in.
Okay.
With no goblins to distract me, I'm going to go into the tunnel.
And as that fade actor on top fades out.
Watch what happens first of all, before it fades out.
Notice that we can zap up onto the ceiling here, or at least up onto the wall, but when it fades out,
we expect it not to block anything, right?
But if we right click notice that we're zapping up to that ceiling again.
So what we need is when the fade actor fades out.
We need it to ignore the target channel.
And really, the fade actor doesn't even need to block the visibility channel at all anymore.
So if I browse to the Fade Actor folder and open up Fade Actor the parent class to all fade actors,
we can go to the event graph.
And notice that when a timeline finishes, we have this fade finished passing in that fade amount,
and we're checking the fade amount.
We're checking to see if that fade amount is greater than or equal to zero, and then saying if block
visibility is true, block the visibility channel.
And then we check to see if that fade amount is less than or equal to zero.
And if block visibility is true, then ignore the visibility channel.
So what I'd like to do instead now is first of all no longer use that block visibility Boolean.
Instead, I'm just going to set our mesh to ignore and block the target channel instead.
So where here, when the fade amount is less than or equal to zero, we're fading out, which means
we should ignore not the visibility channel anymore, but the target channel.
And then here, when the fade amount is greater than or equal to one, we know that we've just faded
back in and we want to set not the visibility channel but the target channel to block.
Now we can't forget why we had this block visibility boolean in the first place.
This is for things that should block the visibility and unblock visibility or ignore it when faded out.
And that's going to be things that fade out, but also that we want to walk up onto like this right
here.
So we're also going to check block visibility.
And in the case of where we're setting the response to target to block, we're also going to set the
response to visibility to block.
And when we're setting the response to target to ignore, we're going to set the response to visibility
to ignore as well.
So we'll have both.
So ignore down here.
Block up there.
Okay, we can test this out.
And really, it's this piece right here that that pertains to.
Now, one last issue, and you may have noticed this.
If we barely, barely just touch on the edge, you'll see that it fades back in.
So why is it fading out and fading back in so much?
Now, this might have been something that stumped you, but that's because it's not a very obvious reason.
If we browse to this asset and we open it up and we take a look at the mesh being used here, this is
a composite mesh made of several meshes.
And if we browse to it and open up this static mesh, we'll see that because it's made of several meshes,
there's a very important thing we have to know about this.
And that's if we check out our collision let's go to show and simple collision.
Notice there's no green.
We don't have a collision hull.
So how is it colliding.
Well if we type complex we'll see collision complexity use complex collision as simple.
Now if we're using complex as simple and this is made up of several meshes.
Well that's going to trigger multiple overlap and end overlaps.
But if we take this and set it to project default and with collision you could just go to add box simplified
collision.
So we have one single collision hull.
Now this should behave itself.
And if we test out.
The game.
Now we see that it fades in only once.
No more strange behavior.
And of course, target data behaves as it should.
And if we come back out, target data behaves as it should.
Perfect.
Okay, so that was a pretty important detail that I thought we should address.
And yes, if we zap something behind a pillar, it'll go through the pillar.
We'll take care of that with our beam.
Don't worry.
It's going to be robust, but at least now we can zap things and know that our zap will go where it's
intended.
Great job.
I'll see you soon.