A few UMG Widget questions I'd like clarification for

Hey, we are using 4.8.2 and I wondered…

  1. How to use menu anchors?

I tried adding a Widget I wanted to spawn in the “MenuClass” variable of the Menu Anchor, and called “Open” on that Anchor but there’s no way to “Get” the spawned widget as a “MyGameWidget” so I could access it’s variables and use functionality of it.

  1. How to use named slots?

I added a variable name to it and ticked IsVariable checkbox, then tried adding a child to it using AddChild, but the child couldn’t be clicked or interacted with. The other possiblity I thought this widget was used for was when you extend off a widget blueprint, so chlidren can put different functionality in the same place, which leads to number 3…

  1. I cannot extend off a widget and use it as expected.

Issue 1 - No visible widgets appear on the designer view of the child widget blueprint (I expected, like actor blueprints, that you could ammend parent components or at least use them, leading to the second point…)

Issue 2 - Although I appear to have variables from the parent widget, none of them are initialised and seem to be invalid and unusable, throwing errors and simply doing nothing when I try to access them.

  1. Off that topic now, I wanted to check what the standard was you expect UMG to be implemented.

I am still using A_MyGameHUD, which on BeginPlay create a MyGameUMGHUD Widget, adds it to the viewport.

The MyGameHUD extends off MyGameHUD.cpp and all the functionality is done there or in A_MyGameHUD. I then, in the Widget HUD blueprint, have a Custom Event for every single event the A_MyGameHUD gets.

For example my character loses a bit of health, this is passed from MyGameCharacter.cpp to MyGameHUD.cpp, which calls a BlueprintImplementableEvent in the A_MyGameHUD blueprint, which calls a Custom Event in the MyGameUMGHUD Widget blueprint, which then sends a Custom Event or function call to the Healthbar.

This feels a bit long winded to add for every bit of new functionality I make. I wondered if it was expected the main hud would be set to a widget blueprint, skipping the AHUD altogether, or any other step I may be missing.

Thanks for any help.

  1. The MenuClass option should be used if you need to spawn something that doesn’t need configuration, it’s just stock. If you need to customize, use the GenerateMenu (I think that’s what I called it) event, at the bottom. That’s called in response to the menu opening, you can customize the creation of the menu from there, or store it off for later access…etc.

  2. The 4.8 version of named slots has some bugs. The idea is to just create them, give them a variable name, and then you can drag and drop new items into them from the palette when that UserWidget is used in other UserWidgets, and slot something into one of the named buckets.

  3. The extension of UserWidgets was not the intention. At least not from the blueprint point of view. Slate is primarily a composition style framework, not inheritance, and UMG reflects that to a large degree. We support extensions but only for functionality reasons, from C++, not the hierarchy, currently. It’s something I’ve considered for the future, and the mechanism would indeed be named slots function as the only editable areas you can injects widgets into. You’d sort of see the hierarchy in terms of multiple roots, where each named slot is a root widget in the tree, and the rests of the tree from your inherited widget is non-existent. I’ve unfortunately not found the time to dig into that one, but I definitely want that for the future.

  4. AHUD serves no current place in the land of UMG, except maybe to spawn the HUD. It was never the intention for it to continue to exist along side UMG. As for design, I would have had an event on Character called HealthChanged, and when the UI was created for health, it would have accessed the Character, or player data or UIModel object that it was passed or had access through through some LocalPlayer context, and then it would have hooked an event on that object called HealthChanged. The Model the UI uses might be the character directly, or more likely it’s some custom UObject designed to marshal dirty data to the UI only, and in a format useful for the UI. This Model might internally hook the event of the Character’s health changing, it may poll it, or maybe the Character knowns about the model object directly and interacts with it in that fashion. Personally, I’d probably go with the polling approach (for health). You poll in native code, in the model, you determine dirty-ness, and you emit change events when it is dirtied. Polling is handy in unreal given how many things can change a variable, health might change because someone updates it directly, or perhaps network replication changed it…etc. The Model design is common in patterns such as MVVM, MVC…etc. If the change isn’t simply a variable, and is more of an event, always try to maintain that, for performance reasons.

I know it’s a pain, but please try to make separate tickets rather than a laundry list in the future. Makes it easier to parcel the tickets out to multiple people if need be :slight_smile:

1 Like

OnGetMenuContent is the event name i was trying to remember.

Thank you very much for the help. I’ll mull over each of these points for the project. And sorry I had no idea that was best practice for you guys, will do in future :slight_smile: