Welcome back.
Now our load menu map has a load screen game mode which has its own load screen HUD.
Now we're going to want to do some stuff in that HUD.
We want to create a new widget.
And I'd like that widget to be one of our C plus plus classes.
We just created our load screen widget, which by the way we can make sure that our load screen widget
blueprints are based on it.
So let's go into blueprints UI load menu.
And we're going to make these load screen widgets based on our C plus plus class.
But even more than that, I'd like to make a blueprint based class based on load screen widget that
all of these can inherit from, and that way they can inherit anything we add in blueprint as well.
So I'm going to right click and make a new user interface widget blueprint.
And this is going to be based on our load screen widget.
So I'm going to select that I'm going to call this Wbhp load screen widget underscore base.
So we have a base class, and these other widgets can be based on it.
And they'll inherit anything that we put in that C plus plus class.
And in our new load screen widget base, if we decide to put things here and we will.
So I'm going to close that and make sure that these widgets all inherit from load screen widget base.
So we'll start with our load menu.
We'll go to the graph, go to Class Settings and set our base class to Wbbp load screen widget base.
We'll go ahead and save that, and we can do the same thing for these other widgets.
We have the enter name widget.
This can be now Reparented to load screen widget base.
We can also go to the take in widget Reparent this to load screen widget base and the load slot vacant.
We can reparent this to load screen, widget base and finally load slot widget switcher.
This one too can be a load screen widget base.
They're all based on the same blueprint now, which is a load screen widget.
And just like all of our other widgets are based on or a user widget, these are all based on load screen
widget.
So with that, I'm going to go ahead and close down all these as we don't need them anymore.
And now that we have a load screen widget class, I'd like to construct one of these.
I'd like to add it to the viewport, and I'm going to do that in my load screen HUD.
So I'm going to go ahead and close down the editor and go to my load screen HUD dot h file.
And I'd like to first of all have a public and a protected section.
The protected is for begin play.
We're going to overwrite that Virtualvoid begin play override.
We'll go ahead and get that constructed.
Now, in addition to that, I'm going to want to spawn some things.
I want to spawn a user widget, and I'd like that user widget to be my load screen menu.
So I'm going to make a subclass of for the class for it.
It's going to be a user widget.
We'll call this load Screen widget class, and we'll set this in our HUD blueprint.
We'll give it a U property edit defaults only.
And that is going to be the class that we want to create.
And in addition to that, we'll have a pointer for the user widget itself once we create it so we can
hold on to it, we're going to have a t object pointer of type user widget as well.
And this will be the load screen.
Widget one is the class, the other is the widget.
And the widget itself is going to be blueprint read only.
And with that, we can construct a new load screen widget and add it to the viewport so we can go into
Begin Play.
And we can take our load screen widget.
And we can initialize it by using Create Widget and create widgets is a template.
It's going to need that user widget class to spawn.
Now writers telling me to include user widget.
Now that I have I can spawn with create widget.
The type of widget I want to create.
I can create a u load screen widget if I like, and for the owning object, I'm just going to have the
world own it.
And for the class to spawn it's going to be load screen widget class.
Now we can add this to the viewport add to viewport, and then we can do anything we want on the Load
screen widget.
Tell it to do things whatever we want.
And in fact load screen widget doesn't have to be just a user widget.
It could be a u load screen widget, and then we wouldn't even have to cast it as create widget is going
to return that type.
So this can be a you load screen widget.
We can add a forward declaration for that.
And now we have this in the form of a load screen widget.
Now this is great.
We can go ahead and compile.
We can launch make sure that it works.
We'll do that real quick.
And we can go right into our HUD.
So I can go to my HUD folder to load screen HUD and set that class load screen widget class.
And it's actually called Wbhp load menu.
That's our load screen widget.
So we're going to go ahead and set that.
And we can go over to our load menu map.
Let's go to maps Load menu.
We can press play and we're spawning our load screen widget our load menu okay.
So nothing new right.
We've already done that before.
Now we're just doing it in C plus plus.
But the difference here is now I want to create a view model.
So how can we create a view model.
Well we can do it in C plus.
Plus we can add a class to spawn just like we did our load screen widget class.
We can have a view model class.
So I'm going to have a subclass of.
And this will be of our load screen view model type.
And that starts with a U and its mVVM.
So you mVVM load screen.
We'll add a forward declaration.
And this is going to be the load screen view model class.
And just like our load screen widget class it's going to be edit defaults only.
And we'll also have a t object pointer of this type so that we can store it once we've created it.
So we'll have a t object pointer using our load screen ViewModel type.
And this will be load screen ViewModel.
And this will be blueprint read only as well.
So let's go back to begin play and let's create one of these.
Now this is a new object.
We can create it with new object.
We'll do it before creating the load screen widget.
So we'll say load screen ViewModel and we'll use new object.
Now this is a template.
We specify you mVVM load screen.
That type will be included.
We got the header include there and new object needs an outer will just use this this particular HUD
and the class load screen view model class.
Now we have it.
So now that we're creating this load screen view model and we're doing it before creating the load screen
widget, how do we set our load screen widgets view model.
That's the question.
And there are a few options when it comes to setting the view model.
Let's explore some of these.
Let's go ahead and compile and launch okay.
So I'm going to go ahead and get my load screen HUD back because we have a load screen view model class
to set.
Now we only have the C plus plus class.
But we can make a blueprint based on view models too.
And I'd like to do that.
I'd like to go into blueprints UI and have just like we have Widget controller, we can have a view
model class.
So everything you're seeing here is going to be very similar to the way we've done things already with
widget controllers, but we'll start to see some differences pretty soon.
Here in the view model folder, we're going to create a new class based on our mVVM Load screen class.
And this is going to be called our load screen view model.
We can call this BP Load Screen View model.
That way it's nice and different from our C plus plus version of the class and load screen view model
is a blueprint.
Much like other blueprints, it has its own event graph.
We can add functions, we can add variables to it, and we're going to go back to Load screen HUD and
set our load screen view model class to our new load screen model blueprint.
So now we should be constructing one of those.
If we go back to our maps and load menu map and we save all, we can press play.
And not only are we constructing our new load screen widget, we're constructing that view model too.
We just can't see anything as a result of it.
It's invisible.
Now.
Just because we're constructing one in the HUD doesn't mean that it's associated with our load screen
widget.
It's not.
We have to make sure that that happens by going into our load screen widget in blueprints UI load menu,
and we have it here.
It's called Load menu.
Now I keep calling everything load screen except for this one widget here.
So it seems kind of like it should be called load screen shouldn't it?
Let's go ahead and just rename it to Load screen Wbhp load screen.
And now we won't be so confused.
Let's open load screen.
And the question is how do we set its view model.
Now, we've seen in our system, we created with our widget controllers that we could do this in a number
of ways if we wanted to do it using our ability system library, like get some kind of widget controller.
Attribute menu, overlay spell menu, and provided that those widget controllers have already been constructed
by the time we call this, we'll have a valid one.
The question is, is there a way to do that with Viewmodels?
Well, kinda.
It's a little different.
What we have to do is go up to the window tab and in window in the designer we have to be in designer,
we can't be in the graph tab.
In the designer tab we can click on View Models.
Notice we have this view models option.
But if we go back to graph where we're in the event graph and we go to window there is no view model.
So you might be confused.
If you can't find it.
Just remember you have to go back to designer.
If you're in the designer tab then you can click window and open View models.
Now here's where we can add a view model to this particular widget.
If we click plus then we can select the view model class.
And we have the C plus plus class as an option.
But there's a dropdown where we can select the blueprint version as well.
So if we select that and click select we now have Load Screen View model under the View Models window.
Now you could dock this if you wanted to dock it right here under details for example right there.
You could do that now under view model.
If we select BP load screen view model we have a little menu that pops up.
And here is where we select one of the options for creating the view model.
For this widget there's a creation type.
Now we can hover over them to see what the different creation types do.
Creation type create instance says a new instance of the view model will be created when the widget
is created.
So that's one option.
Now if you want to have tighter control you can select a different one.
You can choose manual and a manual.
One says the view model will be assigned later.
So you have to assign that view model manually to this widget.
That's another way.
There's also global view model collection.
So we could create a global view model and add it to a global view model collection.
And then it will be retrieved that way.
And then another way, which is actually a kind of cool way to do it is by selecting property path.
Property path allows us to create some kind of function on our widget that will find the property.
It will find our view model.
And if we set this to property path and choose that function name, if we expand advanced we have view
model property path.
Here we can enter a function name here and that function will be called to find the view model.
Let's see how this method works because it's perhaps the most confusing sounding, but it's actually
quite simple.
Let's create a function that can find our view model, but I'm not going to put it on load screen.
I'm going to put it on the base class.
Let's go into WP load screen widget base.
Here, we're going to have a function that we can use to find the view model.
I'm going to create this function here.
It's going to be a new function.
And I'm going to call this find load screen view model.
And it's going to return a view model.
Let's add an output to it and select the type for the output.
I'm going to search for BP load screen view model.
And it's going to return an object reference of that.
And then we can determine here how to find that view model.
And we could do it quite simply, we can get the player controller.
Why?
Because the player controller can get the HUD.
Why do we want the HUD?
Because we want to cast it.
To BP.
Load screen HUD.
Why do we want to cast it to BP?
Load screen HUD.
Because we made a blueprint read only property called ViewModel.
It's called load screen ViewModel.
We want to get that.
Why do we want to get that?
Because that's what we want to return.
Now this returns a BP, right?
We can't just hook that in.
We have to cast again to BP.
Load screen.
View model.
And then return that.
So provided that these casts don't fail.
And they shouldn't because we've set these classes.
Then this function gets the player controller, gets the HUD from it from the HUD cast to load screen
HUD from load screen HUD gets the load screen view model from the load screen view model casts to the
blueprint version and returns it.
Now this we just put on load screen widget base.
So all of our load screen widgets inherit this including load screen and load screen.
Because it's creation type is property path.
We have this view model property path we can set to find.
Oh I forget what it's called.
It's called find load screen view model.
So we can use that as the property path find load screen view model.
And with that, as soon as our widget is constructed, it's going to call that function to find and
set its own load screen view model.
We can click on compile and we get compiler errors because there's a very specific requirement for these
property path functions.
And that specific requirement is that it has to be a const function.
So if we go back to load screen widget base and get this new function, if we make this a const function
by going to advanced and checking the checkbox for const, then going back to load screen Wbhp load
screen.
That is, we no longer have compiler errors.
So that is one important detail that you can't forget.
These property path functions have to be const.
But now I'm going to show you something kind of cool back in our Wbhp load screen, because we now have
this load screen view model.
If we go to our graph and we right click and type load screen view model.
Look at this.
We have get BP load screen view model like it's a member variable.
It's not.
We don't see it here but we can access it anyway because we've added this view model.
And what I'd like to do is just see at some point and in event tick.
Because right now I don't have any other place to check.
I'm going to check.
I'm going to use a validated get and in tick I'm going to get that load screen view model, get object
name on it and call print string.
And as soon as it becomes valid, we should start seeing its name, just spamming the screen.
So I'm going to go ahead and save all press play and there's my load screen view model.
So it is being set in our load screen.
So it does have a view model.
That's one of the cooler ways to set that load screen view model.
And we'll get some experience with the others.
But the property path it's a little bit more confusing.
So we'll start with that one.
Now that we see that it's not actually confusing, we've got it under our belt.
We now know that our load screen has its own load screen widget set.
Now this is where the magic can really happen.
This is where we can tie things together.
We now have a ViewModel for our widget, and we can start doing some really exciting things, such as
binding some of our widget variables to our ViewModel variables so that they're closely connected and
can update each other.
So we'll start doing that next.
Excellent job.
I'll see you soon.