Hi
as the title says.
i can get player variables etc from the HUD widget by using ‘get player controller’
how do i do it the other way round?
how do i find a widget from the player blueprint?
thanks
1 Like
Depends on a dozen of factors. What is this widget for, how many are there, which blueprint created this widget…
i can get player variables etc from the HUD widget by using ‘get player controller’
A side question - why keep player variables in the controller?
the widget is ‘created’ in the hud blueprint.
when a certain thing happens in the character blueprint i want to call a function in the widget.
side answer - i meant ‘get player character’ and cast to my character blueprint
What is the HUD blueprint then. An actor, I presume? How does this actor get added to the world?
Asking questions as I’d like to offer a solution rather than leave you hanging with: use an Event Dispatcher.
world settings - hud class
1 Like
HUD is a singleton so you can:
And Cast. You custom HUD should keep the reference to the widget after having created it. You can also bind the whole with a dispatcher. Or even use an Interface.
There might be some confusion here because you said:
the HUD widget
And HUD class is not a widget. But HUD class can create widgets, keep their references and manage them. It’s actually a pretty good place to keep global widgets - easy to access and it meshes well with the extra functionality the HUD class offers.
1 Like
AHA!
thank you
yes its a widget in the hud class and yes it does keep a reference to the widget i can access
1 Like
Make “hud message bus”:
how to do it all:
-
create dispatcher in game mode or game instance (depends on multiplayer configuration of your game). Why there: (on game mode example): it is easiest to every imaginable blueprint get reference to it (including widgets that are buried deep in component tree, or those that spawn dynamically). It is easiest and penalty/drawback for it is in next point.
-
make player controller (or anything that needs to send data to hud) trigger that dispatcher in game mode (add custom event that can be called from anywhere) . So drawback is adding one more step, that is all.
-
dispatcher and custom event should pass just 2 arguments: enumerator indicating what type of information you send (like HP, mana, ammo etc). and actual value as STRING. why string? Because you can change any variable to string and then read it back from string, so you can send Float, int, some text text with numbers, anything)
-
and last: HUD should be used only to display data, so communication from HUD to player is not necessary (unles those are buttons or some interactive widgets)
For other way around you make same “event bus” just other way around. Ie. widgets find game mode reference, call custom event there (new one that trigger dispatcher for player), and you hook that dispatcher in player controller.
Why dispatchers: because alternative to that is pooling (ie. checking every time in player controller if value of variable was changed). With dispatcher it is widget button or whatever that triggers whole chain of sending data back.
Hope it all makes sense.
1 Like
thanks. that looks interesting
the hud is only displaying data depending on variables in the player.
Then its simple:
player calls event in game mode,
event triggers dispatcher
widget hooks to dispatcher
But i recommend you make that |event bus| to transfer any data over, or you end with mess of many dispatchers instead of single one.
Why involve Game Mode in all this? The widgets are in the HUD… But yes to Dispatcher, of course.
i get the game mode event bus thing and will likely use it as the game develops.
for this instance ‘get hud’ cast etc is good enough. its only to switch panels full of buttons on and off
@Nawrot now there is an OG name i remember
Because you have central hub (plug there debug code, add one enum that is “debug only” and you know everything) for that, and you may have actors in level that also want talk to HUD.
Yes for multiplayer games it is not that simple and kind loses this reason.
Edit (example):
you have lights system, they all are implemented as separate actors. With that event bus in game mode lights caa hook to dispatcher there and listen for event that changes lights. Or it may be bunch of actors for quest system, or if you have different pawns, you will have most code in one place not in all of them.
you have lights system, they all are implemented as separate actors. With that event bus in game mode lights caa hook to dispatcher there and listen for event that changes lights. Or it may be bunch of actors for quest system, or if you have different pawns, you will have most code in one place not in all of them.
OP wanted to send data to the HUD framework (almost) all blueprints have already access to. HUD is their central hub for widgets. Level actors can talk to the HUD in the same way. I see 0 reasons to involve yet another blueprint in this. Meh.
This hud:
In case there was doubt.
1 Like
What I do is, create the widget inside a child HUD class, which implements an interface for whatever you need to communicate to the widget. The player controller can call this interface without needing to cast to your child HUD, which eliminates a hard reference. Only the HUD holds a reference to the widget, which is fine as it will only exist once on each client, as opposed to the player controller that can exist multiple times (i.e. networked scenario if that matters to you).
If for whatever reason you need the widget to communicate back to the player controller, then implement another interface on the player controller and use that from the widget. Eliminate as many hard references between classes as you can., which is where interfaces shine.
2 Likes
Yes I just discovered that HUD now is not THE old simple render to texture hud from 4.10 anymore.
So now instead of game mode HUD is the way to go.
Btw. There is new great widget, “named slot”. See some tutorials about it before you start complicating your widgets. Makes so many things much less redundant in umg. However complicates communication. So learn it and implement from beginning, this will save reworking all widgets later.
1 Like
HUD can do some unique things - mouse hitboxes, line painting, drawing textures, act as a hub. It still has its uses. Also, it’s fast.
And yeah, Named Slots + Interface is the way for a modular approach. Owning widgets can talk to the Named Slot’s content. Since widget inheritance is so weird in BPs, slots fill that gap, patch it up.