How can I make multiple levels in the same Map

I am making a PVZ like game, where there are multiple levels using the same area in the same map, the exact same scenery, the only difference would be the enemy spawns, what is the best way to do this? It would be cool if there was a way to maybe make like child levels or something.

1 Like

Take a look at ‘level instances’

You can load multiple copies of one level, in different orientations ( load level instance node ).

I’ve been fiddling with this for a few days now and it works great, except I can’t load multiple copies of the same level programmatically. I use the node “Load Level Instance” either by name or object, and it works fine the first time but I get a warning the second time (and no level appears). The warning being ‘Streaming Level ‘/Unique/Path_1’ uses same destination for level ‘memory path’ as ‘/Unique/Path_2’. Level cannot be loaded again and this Streaming Level will be flagged as failed to load.’
While trying to fix this I tried using the return value from LoadLevelInstance as input for Create Instance but, while successful, it doesn’t make anything appear regardless of what properties I set it on.

Hoping you or someone else has some ideas for this since the tooltip for Load Level Instance even says “You can create multiple instances of the same level!”

This is Level A

In the first person map, I put this

and I get

Aha, that is interesting. It made me go back and fiddle some more. I found that if I remove the Optional Level Name Override this works exactly as you show there. My nodes have a custom name for every instance of the level, i.e. L_{0} and a format so it always increments but that is what makes this problem appear.

The thing I am fiddling with is intended to be networked and the docs of the node says that this Override is required for networking since server and client need to have the same name (And you get booted if you don’t).

I’m going to dig a bit in the C++ code and see if I can trace why there’s different behavior for this. Cheers for the input!

Edit:

So in

ULevelStreamingDynamic* ULevelStreamingDynamic::LoadLevelInstance_Internal(const FLoadLevelInstanceParams& Params, bool& bOutSuccess)

we have

const bool bNeedsUniqueTest = Params.OptionalLevelNameOverride != nullptr;

which is what triggers the check that results in the warning.

1 Like

This isn’t the actual place where the problem appears and digging more I have a hard time finding it.
The error itself comes from
bool ULevelStreaming::ValidateUniqueWorldAsset(UWorld* PersistentWorld)
which is called during UpdateStreamingState.

What weirds me out a little is that my Streaming Levels array looks like this:


where the first two are “TEST_LV_1” and “TEST_LV_2” but then I also have two memory instances of the same two streaming levels, essentially two copies of each.

World partition is also off for the Persistent Level for this test but I have tried with it on too and get the same result.

And testing this without giving the levels unique override names also generates four streaming levels, but the second two have different memory locations and work as expected. Therefore I can’t for the life of me figure out why when you name two instances unique names they still decide to have the same memory reference.

Seems the memory placements of these extra cells are World Partition Runtime Streaming Cell names. i.e. PackageToLoad here is /Memory/CellName (from UWorldPartitionRuntimeLevelStreamingCell::CreateLevelStreaming on line 190 in that file).

From testing it appears as if you give your levels unique override names they end up in the same cell while as if you don’t they don’t. This feels really broken to me since I need unique override names to do this in a networked environment. It’s also weird to me that this happens in a level with world partition turned off.

Finally this seems to be a bug in 5.4. It works correctly as expected in 5.2 but updating the same functioning project to 5.4 breaks everything and the second instance does not spawn. I’ve posted a bug report to see what happens.

Trying the same thing in 5.3 crashes the engine x).

1 Like

Well researched :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.