Welcome back.
We're now ready to associate the enhanced input assets that we created in the editor with our player
controller.
So I'm going to go into our player controller here and open that up.
I don't think I need my character classes open at the moment, so I'm going to right click on our player
controller and close other tabs.
Visual Studio has a similar option.
Now I'll go ahead and open our player controller CP and I'll have them both open here and here in the
header file.
We're going to need a couple of functions.
Now we created an input mapping context and the place to add that to our player controller is in Begin
play.
Begin Play is a protected function.
I'm also going to want a constructor and that will go in the public section, so I'm going to want a
couple of sections here.
I'm going to make a public section and a protected section and in protected, I'm going to override
begin play.
So it's virtual, it's void.
We're going to declare begin play and that's an override.
And in the public section we'll make a Ora player controller constructor and we can define these functions.
I'm going to let Rider create the definition for me by clicking on the hammer and selecting generate
definition.
And for now, the only thing I'd like to do in Ora player controller in the constructor is make sure
that this player controller replicates.
So the player controller has a B replicates boolean that we can set to true.
And we'll talk more about what replication implies throughout the course.
But replication essentially in multiplayer is when an entity changes on the server.
That change that took place on the server will replicate or be sent down to all clients connected to
the server.
So we have the concept of changes being made on multiple machines.
One of those machines is the server and all other machines are clients, so replication is responding
to data, updating on the server and sending that down to clients.
So we're just going to make sure that our player controller is designated to participate in that to
be a replicated entity.
So there's our constructor.
And now let's make a definition for Begin Play.
Thanks to Rider, I have super begin play automatically.
If you're using Visual Studio or another IDE, don't forget your call to super.
Very important.
So here is where we're going to add the input mapping context and our player controller is going to
need a variable to store that input mapping context.
So we'll go ahead and make that member variable here in our player controller and that can be a private
variable.
So we'll make a private section down at the bottom.
I just happened to like my private section below the protected which is below the public.
And you may wish to organize your structure differently, and that's fine.
Now I need a pointer for a U.
Input mapping context.
That's the C plus plus type for an input mapping context.
So I'm going to make a T object pointer to u input mapping context.
And I'm going to call this aura context.
And of course, this will be a new property.
And I'd like to be able to set this in the player controller blueprint.
So I'll make it edit anywhere and I'll put it in the category of input.
Now if I hit control shift B to compile, we're going to get compiler errors because input mapping context
is an undeclared identifier so we can forward declare this type as to object.
Pointer is a pointer after all, and that way we don't have to include the header file for input mapping
context.
Here we can just forward declare and include that header file where we need it.
So up at the top I'll say class you input mapping context.
So we have that forward declared.
Now here's the thing though.
We are going to include it where we need to use it and we can only successfully include the header for
this if we have access to the module, the enhanced input module that contains these header files for
enhanced input classes.
That means we need to go over to our aura dot buildpacks and make sure to add enhanced input to our
module names.
So I'm going to go ahead and do that now right here in public Dependency module names in Aura dot Buildpacks.
I'm going to add enhanced input just to make sure that we can access that module and I'll save and close
out of the build file.
So now that I have an aura context and we're planning on setting that in the blueprint, let's go into
Begin play and we can add this mapping context.
Now, Aura context may or may not be set.
Remember, we need to set that in the blueprint and if we haven't, then this won't be a valid pointer.
And if it's not valid, well then we'll have all kinds of problems such as input not working.
And that's something that's serious enough, I think, to halt execution altogether for so that we can
set that input mapping context on the player controller.
We shouldn't be allowed to continue trying to play the game if input isn't going to work.
So for that reason, I'm going to use an assert.
We can use check here and we'll check the aura context pointer.
So check is going to halt execution if this condition fails and aura context being a pointer will be
evaluated as false if it hasn't been set yet.
So this is a good way for us to assert that our aura context is set and if we try to run the game without
setting it, we'll get a crash.
Now the way to add an input mapping context is we access the enhanced input local player subsystem.
That's a subsystem whose type is you.
Enhanced input local player subsystem.
We're going to make a pointer to this.
We'll call this subsystem.
And the way that we can get it is through a static function that belongs to the you local player class.
So to access a static function, we use the class name, you local player, double colon and we can
use the function get subsystem.
This is a template requiring a type.
We're going to use this type you enhanced input local player subsystem and the function will require
an argument of type you local player which we can always get with the function get local player.
So now we have this local pointer subsystem of type u enhanced input.
Local player subsystem subsystems are singletons.
There exists only one for the duration of the program and the enhanced input.
Local player subsystem is what we can use to add mapping contexts such as our aura context.
Now we can place this all in an If check.
That way, if this subsystem pointer is null, we won't try to access it.
Or we can do like we did with aura context and simply do a check with check subsystem.
The difference between using an if statement to check the pointer and an assertion is that of course
if subsystem is null, we'll get a crash here.
Now, after checking subsystem, we can take subsystem and we can use the function add mapping context,
which requires an input mapping context.
We have our aura, context and a priority as you can have multiple input mapping contexts at the same
time.
And if they're competing with each other for the same inputs, well then you can use priority to determine
which input wins.
We just have a single input mapping context and we're going to keep that priority value at zero.
So now our input mapping context is set here.
Now while we're in Beginplay, we can set a number of settings that our player controller has control
over, such as things like showing the mouse cursor as the player controller has a be show mouse.
Mouse cursor boolean.
We can set that to true in this top down.
We're going to want to see our cursor.
We can even set the default mouse cursor.
And this is an enum of type E mouse cursor.
So we have a number of different cursors.
I'm going to use the default mouse cursor and we can also set the input mode.
Now the struct f input mode game and UI is an input mode struct and if we use this input mode then we'll
be able to use input from our keyboard and mouse and we'll also be able to use input to affect UI such
as widgets and we'll have lots of that in this project.
So I'm going to create one of these called input mode data and take input mode data and configure it
a little bit.
I'm going to use set lock mouse to viewport behavior.
This takes an E mouse lock mode.
I'm going to choose do not lock.
And that way we will not lock our mouse to the viewport.
I'm also going to take input mode data and use set hide cursor during capture to false.
So as soon as our cursor is captured into the viewport, we will not hide the cursor.
And in order to use this input mode data we use the player controllers function set input mode passing
in the input mode data.
So now our cursor settings are configured and now we have our subsystem set up and we're using some
class types.
Now let's go ahead and quickly compile so we can call out any compiler errors that we might have.
And since we don't have any compiler errors, then we're good.
We don't have to include any header files anywhere.
So now that we have our input mapping context bound to our player controller, we're going to want a
callback function that will handle actually moving the pawn, in our case, the Aura character in response
to input.
In other words, we want input actions to trigger some kind of movement.
So in the next video we'll set up a variable for our input action and we'll create a callback function
that we can use to move the character.
So great job.
I'll see you in the next video.