I can think of a few tedious ways to do it like with a switch with the enum on every different button click but I’m thinkng more of a binding on the Widget Switcher change similar to the Visibility Change bind so I can have the logic on one event. The reason I want this is as I cycle through any of the different options menu, if I don’t apply the changes then they should reset the values
Widgets are to inform other actors like player character that user clicked something. Do not put logic for gameplay in them (yes you can but soon or later you will get multiple places that calculate same stuff).
So TL/DR:
widgets are ONLY to send messages/events that something happened, and to display things like HP, mana, ammo etc. They should not have game logic inside
pick your poison where main hub for all info from widgets and for widgets is. Like GameMode or HUD , or just main widget that you add to display and is parent for everything. I suggest either game mode (or similar that is local in multiplayer) or HUD.
when you have main hub for processing widget, make there custom EVENTS. Trigger them and send data when button is pressed. Main Hub should keep all data and track of widgets events
when you want to update any widget on screens, create event dispatchers in main hub, hook to that dispatcher in widget. This way widgets that use dispatchers are independent to where they are placed in widgets tree. You can use widget switchers, or create your own widget class that displays something, and not worry how you hook it to information.
Yeah I’m already utilizing those aspects, I’ve got a main HUD that creates this menu which is also held within the pause menu, but in this scenario I just want a slighlty more dynamic method to what I already proposed. I guess what I’m looking for is some built in function that I can use to determine when a change to the widget switcher has been made, but doesn’t look like ther is? As I’m not changing the visibility I can’t use any is visible nodes. The Generate Options list purely visual it is adding the widgets as children.
Oh you are bit more advanced, so what i do with widgets:
i do blueprint interface with single event: “EVENT_SetMyOwner”, it gives widget reference to whoever keeps it, and sets construction values. For eg having custom button widget and SetMyOwner sets pointer to whoever knows/spawns those button widgets, and sets text for button name.
i use GamePlayTag with all widgets. For eg, for widget state changes, like Button.Pressed, Button.Released etc. Also for telling buttons what they are, like button.ExitGame, button.Applysettings etc.
then having all those GamePlayTags, i create function library, and then some helping functions: like GetButtongName from ButtonTag. etc.
then for updating anything in hud/widget i create dispatcher in main place, that triggers update or something changed. It has GamePlayTag like Changes.HP Changes.Mana etc. When thet dispatcher fires every widget checks if tag matches what it should track, then pulls info.
Seems like a decent idea. Not really a fan of gameplay tags, I use data assets for alot of things. I spawn the widgets per menu based on a collection of data assets, setting the contents of each widget works nicely like this I think
Gameplay tags are like better enumerators. With enums there is one big problem: C++ during runtime knows them only as byte or int32. Blueprints are fine, but then C++ side does not know enums from blueprints.
GamePlayTags are like enums that have nice support, functions, and can have that hierarchy built in.
