Delay before adding widgets after level change

Hello,

I have a main menu widget, that must be activated after a map change to the ‘Menu map’ like so:

102353-capture+image.png

The ‘State Transition’ Macro essentially collapses all unused widgets. After this Macro, it will then check for all required main menu widgets, if they are invalid, create a new one and add to the view port.

I am baffled about two things,

  1. Why is it that when I remove this .05 delay, it does not display any widgets? (It took me hours to figure out that it only works when there’s a delay)

  2. Why is it that every time the map is loaded, the widgets are considered invalid and must be created again? Is this due to when the level changes, all widgets are destroyed?

1 Like

You have in fact answered your own question. Loading a new map in the standard sense destroys every single thing with the exception of the GameInstance and other UObjects that do not rely on the Level as their ‘World’. So basically any time you want to change maps, be ready to remake everything you want available to you when that map has loaded itself into memory. Without a map, no Actor or Actor child (widgets) can exist.

So that means I have to always have a delay somewhere when changing a map to be safe? Or is there a special way to detect if the map has loaded or whatnot?

Ah alright, I’ll see what I can figure out. Thanks!

There are quite a few different ways to detect if a level is loaded in C++, but one simple yet effective way in blueprints is to use your Level Blueprint’s Begin Play event. Assuming you have other state based activities you would like to do in GameInstance and you are storing state variables there, there is value to both methods shown:

Hmm is this a changed behaviour? I seem to recall having to clear widgets very often since they would persist over level loads, which most of times was very annoying. I recently started rewamping core game instance functions and noticed that I now had to solve the main menu being drawn before the level had loaded, even tho the load level call comes before the hud instructions, which instead caused these issues the op was having.

Spiris answer is correct and pretty much how I solved it as well, relying on a delay can be flimsy when using it to offset execution of something critical, so I wouldn’t really recommend that.

No changes that I have heard of so far. Still is the same where it takes some time before widgets can be created in a level.

Yes it’s a much better method to use BeginPlay instead of a delay, because who knows, maybe slower machines require a longer delay.

To solve this problem I create a Dispatcher (event delegate) in my GameState class.
I think the GameState exists by the time the level and the viewport exists.

Then any class that needs to put a UMG widget on screen just binds an event or function to that delegate (dispatcher) on the GameState and when its function or event runs, it creates the widget no problem.