Weird issue with Open Level (by Name) and Open Level (by Object Reference)

I made a game which is currently running on a Steam Deck in an art gallery. For some reason loading levels with Open Level (by Name) and Open Level (by Object Reference) does not work all the time.

The game is not resource intensive - very low poly meshes, lighting and materials are handled through this Retro Graphics pack, so very low costs in general. I started off loading levels with everything in at the same time, which I probably shouldn’t, but it seemed to work, most of the time. Levels are included and named correctly in the list of maps to include in the packaged build.

Every so often I run into an issue in the packaged build (never in editor) where after completing a mission, the screen fades to black and when the next level should load, nothing happens. The larger levels with more blueprints, more lights, way more actors, and way more meshes always load fine, but two of the smaller levels with not much in them seem to hang. This has been happening every so often, but not always, with two of the smaller levels. Large levels always load after small levels, and this is done through the level blueprint. While the problem levels are smaller, they are loading out of the larger levels from a widget.

The two problem smaller levels do have about 3-4 higher poly meshes (one is 500,000 tris), so I converted those levels to World Partition, and added the bigger meshes to a data layer that loads in after the level has opened. This seems to have partially solved the problem, but now the 3rd small level, with no big meshes, which wasn’t a problem before, is sometimes not loading. I’m going to convert the third small level to world partition, and hopefully this will solve the problem, but it’s hard to determine if what I’m doing is actually helping.

Why do you think this is happening? Is it likely that it’s being caused by loading in too many meshes at the same time, as the level is opening? I would have thought that a packaged UE5 game should be able to load in three 100,000 tri meshes as a level is loading, but maybe I’m wrong? Should I always use world partition? Is a mix of world partition and non world partition levels bad? Could it be the difference between opening a new level from a widget vs. from level blueprints? Is there something I’m missing about level opening in general? I really want to resolve this issue before moving onto the next project, because I think this is most likely going to come up again!

1 Like

Can you show some of code around the parts that change levels?

1 Like

This is in a widget that counts the number of mission objectives completed, and displays some information. This section labeled “All Mainframes Destroyed Load Next Level” is triggered after an int has reached a specific number. The ‘Load Next Level’ custom event is definitely triggered, and so is the screen fade. Could removing the widget be an issue? This one is Object Reference and the next is by Name - I’ve been testing to see if it makes any difference, but it doesn’t seem to.

This one is in level blueprint, which always works:

1 Like

The problem may well be here

This is a widget, right. You just issued a command to remove it, then wait 6 seconds ( plenty of time for it to be destroyed ) before trying to call open level. It never gets to the call, I’m thinking…

It might be better to separate these operations. For now maybe, just make it so you can close the widget using a keypress ( or remove all widgets from the destination level BP ).

1 Like

Does removing widgets in this way remove functionality happening in them? I can actually just keep the widget, I’m only removing it for aesthetic reasons.

1 Like

You can just hide it instead.

A quick test I did killed the widget code. I think it might depend on what the widget is doing, but better not to chance it :slight_smile:

1 Like

Thanks for testing! Maybe that was it all along :upside_down_face: Well, at least I’ve started learning world partition :slight_smile:

1 Like