Need help creating widget with memory at runtime

[anonymous_user_6d4f2fb2]

I have two widget blueprints;
**
Blueprint 0** houses a menu with many buttons.
Blueprint 1 houses a ‘graphics’ submenu that I wish to draw by clicking a particular button in Blueprint 0.

The ‘graphics’ submenu is a menu that needs to **remember ** graphics settings that have been changed and then it needs to be hidden to continue gameplay by exiting Blueprint 0.
TL;DR: Any changes made in Blueprint 1 will persist after closing both widgets.

I have personally tried creating the widget once, and then changing the visibility of the widget using a custom reference variable but I can’t quite seem to figure this simple one out.
Any guidance is appreciated!

[andreschaaf]

Hi,

I think this is not possible. You have to store the settings by yourself and load them on widget creation. In the widget you store then the current values first (for restoring) and on exit you save your settings.

I would use the bind methods to access the settings (value text, slider pos, etc.) in the graph.

The problem is, when you widget is destroyed then your settings are lost. So you have to take care of it to load / store / restore them by yourself. Storage could be the game instance, savegame, in level bp, …

Kind Regards

freakxnet

[Everynone]

To me, it sounds like the most basic case of referencing, if I understood it right, that is.

Create a reference to Blueprint 1 in Blueprint 0. Blueprint 0 is free to command Blueprint 1 as needed. Are you struggling with creating the reference itself?

;634857]
…]I have personally tried creating the widget once, and then changing the visibility of the widget using a custom reference variable…]
[/QUOTE]

This sounds about right.

[anonymous_user_6d4f2fb2]

@Everynone;634893

Are you struggling with creating the reference itself?

It appears so, not sure what I was doing wrong but in the end I ended up migrating Blueprint 1 inside of Blueprint 0 instead of having them separate. That way I was finally able to set the visibility of BP1’s canvas, rather than destroying and re-creating it each time.
This means BP1 is always there, it is just hidden.Not what I was hoping for but it works either way.

Any suggestions on a better solution to save resources? Or am I wrong in thinking a hidden widget still uses resources?

[6ixpool]

Just store the settings in a datatable or (sketchy AF but should work) a variable on main then use that to rebuild the wodget properly wheneverbits called up.

[Everynone]

@6ixpool;635303

Just store the settings in a datatable…]

Unfortunately, you can’t write to DataTable unless you invest in a plugin or C++. (if **you **can, give me a shout!, my knowledge might be outdated here)

When it comes to performance, widgets that are hidden do not tick, the same is true for widgets that are not on the screen (like a healthbar that follows the enemy who is currently not on the screen). The widget will reside in memory, though. Depending on how often you’ll be seeing that widget, you’ll need to decide whether it’s better to create and then destroy it or to just keep it hidden. If it’s the main menu item that will be accessed once per game session, I’d say create, save its state and get rid of it. I’d deem the cost of keeping a simple widget in memory negligible at best, although if it’s not to be used again, it’s still good practice to get rid of it. I would not do it for the inventory full of items. Generally speaking, from my (limited) experience, focus on writing the code, optimise it later once you know how the pieces interconnect.

You have several solutions:

1. The one you went for, where you nest one widget in the other and keep both.
2. Create them separately, set a reference and hide the settings one (not much difference from the 1st one)
3. Create, save state and destroy the settings widget (I believe that’s what you’re really after)

Not going to mention **1. **as you have it figured out already.

As for ****2. You’re going to need direct reference sooner or later anyway for something else so I’ll mention it quickly. Let’s say you have Main and Settings menu. To create a direct reference, create a variable in the Main menu of type Settings menu, the following was done on the Main menu widget:

The variable currently does not reference anything, if you try to access it now, you’ll get a null pointer (accessed none). When creating widgets/objects, reference one by the other:

You can do it the other way round, too or you can reference both ways (which is not always recommended as it may lead to circular dependencies), again this depends which way you’d like the information to flow.

As for 3. The other posters here mentioned saving that data and destroying the widget and that would definitely work. It’s also the cleanest solution but it would require you recreated the widget from scratch based on the saved data.

Since your Main “menu with many buttons” seems to be persistent you can store the state of the settings there. Here’s one way to do it:

1. Create an enumerator for the settings, you may need more than one, depending on complexity:
   

Add that variable to your Main.

2. I’ll assume here that in your Main you have a button that opens the Settings. Have that button create the Settings menu and feed it the enumerator (give us a shout should you have doubts about that) which can set its (remembered) values. When you create the Settings (onButtonClick), set up a direct reference in the Settings that links back to the Main. (what I mentioned in 2. but in the other direction) so the Settings can send the data to be stored in Main.

3. When you apply a graphical setting in the Settings, use the reference to the Main to set the enumerator to the desired state. Destroy Settings onMenuClose() equivalent. Next time it’s created it will fetch the saved data from the Main.

The above can be achieved with EventDispatchers, too which work quite well with all sorts of widgets, whether they’re persistent or not.