Hello, I have trouble like this. My widget blueprint only updates in screen when I place “add to view port” node in third person character blueprint. If I place “add to view port” node in third person game mode, It doesn’t update. I want to update that widget from game mode because my ammo count data will lose if a player died. Can anyone help me to resolve this problem.
if you hover over the “owning player” input you’ll see that it requires to player controller. by default, it will opt for the player index 0.
If you are setting these things up on begin play, it is likely that the game mode begin play is firing before any actors are spawned. Or you might have failed to set the game mode for the level. You can do that in the World Settings panel.
it might not be a good idea for the game mode to manage widgets, because the game mode is tied to the level, though widgets might not need to be. You’ll also probably run into the problem of an overbloated god class that becomes hard to manage.
It may make more sense to have your widgets or characters report information to the game mode, either via an event dispatch or interface.
A good term to google is “unreal blueprint to blueprint communications.” There is good documentation on it plus epic has made a lengthy demonstration video you can find on youtube as well.
Thank you very much for your advice sir.
I found the documentation, and It solved many problems that I had before.
I’ll try to store ammo data on interface
Thanks again and really appreciate your help.
an interface is only a list of functions/events that can be used to communicate between classes.
So it can pass data, but it does not store data.
An example:
You have a Character blueprint and it has an integer variable called “CurrentAmmo.”
Imagine the Character is killed and becomes a dead body laying on the ground. Lets call this CharacterA. CharacterA is the dead one.
Another character (CharacterX) approaches the dead body and interacts with it.
There is a couple ways the interaction can happen.
One would be that CharacterX cast to the class type of CharacterA. What this does is get access to all of CharacterA’s data. So then you could grab that CurrentAmmo variable directly.
This works, but it does require that CharacterX now knows about CharacterA’s entire class. That means that when you load CharacterX into the level, it will also load CharacterA - which you might not want. Some levels might not involve CharacterA at all.
An interface allows you to communicate with another class without directly knowing what the class is. It just checks if the “other” class is using the interface or not.
So if CharacterX interacts with CharacterA and just sends an interface function that says, “Are you lootable? If so, let me see the goods!”
Then, no matter what class CharacterA is, if they implement that interface, they can respond to the question.
In this case, CharacterA might plug the CurrentAmmo variable as a return result into the interface function.
Then CharacterX (or anybody who calls the interface function) can pick up the ammo for themselves.
There is plenty of help out there to show you the exact steps to use these tools, but I think if you have a plain-language introduction first sometimes that helps me understand better.
1 Like