I remember a while that I would see people adding variables to their PlayerController or other classes that references the widgets they were creating - like this official guide.
For example, BeginPlay would run Create Widget to make a Pause Menu, then create a variable to store that widget in. Then when they needed to Add to Viewport they’d just reference the variable.
Is there a particular reason to do this? Or is it just for convenience sake so that you can perform actions with the widget (such as destroying it) in the same blueprint? Couldn’t you do that inside the widget itself?
Just wondering if this referencing process is strictly necessary, or if there’s some major benefit to doing it that I’m unaware of. I’m having some issues with sharing input mappings between menus when following the above procedure and figured I’d see if I could just get rid of it.
Hey there @Vigilant! Welcome back to the community! So any UI that you need to do anything with is good to have references to it. It’s the easiest way to manage the UI elements. It’s not strictly necessary for all games, but if you need to reference them for basically any reason it’s just useful. Many games can instead have the logic directly on the player actor as well if you have your mapping set up for it.
Unreferenced widgets that are not in a Container or Viewport will be destroyed and removed from memory - and this can be a good or a bad thing.
Imagine you’re doing floating damage numbers and showing it through widgets:
There’s no reason to reference those widgets, they can remove themselves once their jobs are complete and, eventually, get garbage collected.
But if the player has a complex inventory, you probably want to reference that particular widget to keep it alive and use the reference to interact with it.
I’m typically using the HUD class because it is already created and attached to the player controller.
This means that it is easy to find.
I’ll use some components to attach to the HUD class to house various different elements of my total UI. This is mostly for organizational purposes, just so the HUD class doesnt get too much stuff going on in it and become confusing.
Each one of those components will have references to whatever individual widgets it needs to talk with.
So it’s like this:
Player Controller > HUD class > InventoryUI_Component / RadialMenuUI_Component / HUD_DisplayUI_Component, etc
Usually in those components, I’ll have some event like “Show the Alert Message” or “Refresh the inventory display”
And I’ll have a call to those events from a Blueprint Function Library. That way, anybody anywhere can call for some UI related thing to happen, but they don’t need any direct references to widgets.
Just wanted to say thank you to everyone for the suggestions and info, I definitely appreciate it. I decided to keep the references since I intend for several of these UIs to be fairly complex and data-rich and didn’t want to re-initialize them if it wasn’t necessary. I just duplicated the input mapping to separate them even though they use the same keys and are intended for the same purpose - it’s annoying, but I’ll deal with it. I also moved my UI code and references into their own HUD class.