Hello. For that moment I have too much widgets. So I have a question, how should I organize them? For example, I have one widget in level blueprint, one - in character blueprint, and one in component. When I press Pause button, I want to hide all of them and show Menu Widget. I find one trick with creation Master Widget and interface impementation with using GetAllWidgetsWithInterface function, but can’t understand how to do this. (link to that trick: Trick)
Maybe there is better way? Or somebody can explain how to do this?
But that’s like 3 widgets only, no? Why not access them and hide them as needed? You may want to move the one widget from the LB elsewhere → Game Mode, perhaps? It can be made to work with a LB widget but it’s awkward.
GetAllWidgetsWithInterface
This is actually a somewhat clever hack-ish way to go about it. I guess it’d work like this:
- create a new Blueprint Interface in the Content Browser, add a function with an inputs:
- implement the BPI in all widgets that need their visibility altered:
- you should be then able to call like so from anywhere:
Any widget that has this interface will fire the corresponding function that BPI provided. Untested but should / could work.
I tend to manage all my widgets in the GameInstance Blueprint. It has several methods to show and hide and takes care that no widgets are shiwn at the same moment which don’t work together.
With this approach I habe all references there and from the other blueprints only the public methods are called.
But all of them in different places, so in future I there will be more of them. I can’t keep in mind all of them. So it’s for future purposes.
I’ve tried this but my event just don’t work.
*created BPI
*implemented it to my widget
*trying to call it in another widget, but without result
You’re not doing it right. Consider following what I posted a bit more closely. The interface function is not even implemented…
And you’re calling a widget function, not the interface’s implementation:
Although that would work too, I guess; it’s just a waste of the interface. So the question here is - do all widgets you wish to hide implement the pertinent interface? We see it in Custom HUD, others have it too?
Yep, you’re absolutely right! I missed interface’s implementation, now it works. Thank you! But where should I keep all widgets? In GameMode? Or in structure that own it?
You’d normally keep a reference to a widget in the actor that needs it. If the player owns a Health Bar, their BP should create and hold onto it. If we have a World Map Overview widget with POIs, it could live in the Game Mode so other blueprints can access it, too.
You could look into Event Dispatchers. The events / functions in the actors ↔ widgets can be bound together when the widget is instantiated. Once this is done, we no longer need a target. Firing a dispatcher broadcasts data on one end, and whoever registered to listen receives the message. And if the target no longer exists, nothing happens, which is neat.
Another way to handle it, in case things need to be scaled up, and actually organised before it all gets out of control:
- have a framework class (game mode / player controller) create a Master Widget with a canvas panel
- instead of actors creating their own widgets and adding them to the Viewport, actors now ask the Master Widget to add widgets to its own Canvas
- this would allow you to create and manipulate layers of interface from a single location
- this also allow you to easily control the Z order - who draws last, on top of whom
- and if those widgets need to talk to one another, well, they’re referenced by the very same Master Widget / canvas panel
Think of it as of a widget manager. You can still communicate with an interface but now any actor can simply:
Get Game Mode → Interface Call
The game mode deals with the request and informs Master Widget Canvas regarding what needs doing.
It may not make much sense in all genres, though. A point & click adventure would need a different structure than an RTS or a grand 4x strategy, the above may shine in the latter.
Thanks a lot for your help.
1 Like