Possible Level Streaming Issues I have Found

Development World Creation
, , , , ,
1

I set up the levels, the persistent level and the level I want to stream.

Player or players start in persistent level, and I have a level streaming volume in that level which will trigger the second streaming level.

The second streaming level has a single AI bot in it.

Issue 1: No matter what I set the level streaming type to, when I leave the volume, the streaming level unloads, and the AI bot is reset. So if i kill the bot, step back out of the streaming volume, and back in to it, the second level is fully reloaded and the AI bot is alive again.

I had expected SVB_VisibilityBlockingOnLoad to allow for only changing the visibility of the second level, but it does not. It fully reloads it on the server, rather than just setting loading and visibility on the client.

If I set up my own volume and stream by blueprint, for a Dedicated server…I can get the behavior I want where the server always has the levels loaded, and I can tell the server to make it not visible on the clients. This fixes the issue with the AI and the level in general are reloading. I can kill the bot, back out of volume and watch level hide, go back into volume and see dead bot.

Issue 2: If I want to use level streaming by blueprint on a non-Dedicated server, I always have to keep the level loaded on the host client, or there are some bad artifacts that occur when changing visibility on the client host. So the client host has to have everything loaded AND visible and the other clients can stream appropriately.

It should be that the host client should be able to at least toggle visibility of the levels, but it cannot safely do this. Toggling visibility of the levels on a host does more than change just the visibility, it seems to affect ticking and perhaps replication.

Ideally level streaming should:

  1. Allow for turning off visibility only ( render ) of streamed ( loaded ) levels, and allow for things continue to tick and replicate properly even though they are hidden

  2. Allow for 1) above on a non-dedicated host. Ideally the client host should be able to not render those streamed level elements it doesn’t need to render, even if it needs to have them loaded.

  3. Level Streaming Volume type SVB_VisibilityBlockingOnLoad working such that it only affects visibility on the clients rather than forcing a reload also on the server. Or some additional type option that does this.

If anyone has workarounds for any of the issues I have mentioned, I am all ears.

2

To reproduce the Level Streaming volume issue, I create a persistent level. Then a level to stream. I tie the streaming level to the Level Streaming Volume. I set the stream type to SVB_VisibilityBlockingOnLoad. I place a single AI bot in the streaming level.

Then I run the game in editor, dedicated server, 1 or 2 clients, and walk one of the clients into the streaming volume. The streaming level loads and appears. I shoot and kill the AI bot. I back up a couple steps out of the streaming volume, and the streaming level disappears. I step forward again into streaming volume, and the AI bot is alive again because the streaming level reloaded.

For a dedicated server, the server can have the streaming level loaded, and the clients can have visibility of the streaming level set in blueprint, and this works fine ( as long as the server has the streaming level loaded ).

For a non-dedicated server client host, that client host needs to always have the level loaded ( and visible ) or the other clients connected to it will have issues. It should be that the loading of a streaming level is separate from the ticking and / or rendering ( visibility ) of said level IMHO That doesn’t appear to be the case.

I don’t even care really if sublevels are loaded on clients, what is most important is hiding and not rendering those sublevels…for performance reasons…and that even hidden levels are still ticking all their actors and so forth, so that when they become visible, all the states are correct.

3

Hi KMcPherson,

  • What steps are you taking to reproduce this on your end?
  • Are you streaming the level in or are you hiding/unhiding the level?
  • Are you spawning the AI in the streamed level or is it being handled by the persistent level, but they act in the streamed level?
4

Try adding a boolean variable for your AI’s spawn that is called in your game instance. When you run the game the instance (each time PIE is run), when you kill the actor, set the instance bool value. When you stream the level it should check this bool to see if it has already been killed, if so, do not spawn.

5

This will not work for our game. Our AI can have items in its inventory that need to be looted. Mission objective items. Weapons. Ammunition and so forth. So it is important that the corpses remain to be looted.

6

You can save those values to a save state that can be passed back into the AI upon level load. Unfortunately outside of this the only other way I would think this will work would be to run the AI information in your persistent level as opposed to the streamed level. Streaming a level will run the begin play script every time it is streamed, so you will have the information run each time you need the level to open. Without accounting for this in a save state (to save the information of location, loot, life/death state, etc.), you’ll have to keep your AI spawning information in the persistent level to allow it to act continuously as opposed to spawning each time.

7

Or, rather than the customer / end-user jumping through a series of hoops with workarounds, maybe just fix the issue where SVB_VisibilityBlockingOnLoad on Level Stream volumes actually only affected visibility on the client, and did not reload the level on the server.

And make it so hiding visibility on a host client (non-dedicated server) can be done without breaking connected clients.

8

I do appreciate your workaround suggestions. Although it won’t work well for my particular product. I think what we desire is a straight up fix.

9

Can you show me your blueprint for how you are streaming the level, both on the client and the server? I believe I may be misunderstanding what you are expecting vs. what is occurring. From the sound of it, you are streaming a level on the server based on a client entering a level streaming volume, when they leave the volume the level is unloaded. If this is the case, it will be constantly opening and closing the level, forcing all functionality to reset. If you are simply hiding the level when you leave the volume that may be an entirely different set of circumstances, but if you are loading and unloading the level, it is behaving exactly as I’d expect.

10

Well, in the case of an Unreal Level Streaming volume, that is an Unreal code structure, so there is no Blueprint on my end. And that clearly unloads and reloads the level no matter what type setting is used, even if it is only the visibility setting SVB_VisibilityBlockingOnLoad.

As for my Blueprint, that works fine for a Dedicated server, because I never unload the sublevels on the dedicated server, I only unload them on the clients.

Now this Blueprint would be ideal, except that if I am running a peer to peer connection where one client is the host, that poor client has to have the levels always loaded AND visible ( just like the dedicated server ), so the hosting client has less performance than remote clients which can unstream the sublevels.

In summary:

  • Unreal Level Streaming Volume seems to always unload and reload sublevels on the server regardless of its type flag, for example SVB_VisibilityBlockingOnLoad should only change visibility, but it loads and unloads, destroying any persistence. ( this I believe is a bug or it is a level of implementation that isn’t supported yet, though the type flag exists for it ).

  • For custom code or Blueprint streaming to work with persistent actors and their states, levels must remain loaded on the server, and only on the clients can they be unstreamed and restreamed. It would be preferable that if one was running a client host ( peer to peer ) that the client host could at least hide visibility ( rendering ) of the sublevels if it cannot unload them, and if that hiding would not result in things not being ticked / updated / replicated properly.

11

Hi KMcPherson,

Can you send me a sample project showing what you are experiencing? I’m having difficulty understanding exactly what you mean, seeing it firsthand may help me to see the error you are describing.

12

Hi KMcPherson,

I am an Engine Support Technician at Epic Games. If privacy is a concern, you can send me a copy of the project privately through the forums by sending a private message here:

13

Do you work for Epic Games?

14

Sent you private forum message with links. Thanks.

15

Hi KMcPherson,

After some additional testing I have found that this is the expected behavior with streaming volumes based on the code written. If there are no players inside of the volume using SVB_VisibilityBlockingOnLoad, the level will be hidden and unloaded. After discussing with the developers in charge of level streaming, this is most likely not going to be altered in the near future as it is a fundamental change to the level streaming volumes functionality which could dramatically affect any developers working with level streaming volumes. If you are looking to hide levels without unloading them, you will have to rely on blueprint scripting.

16

That is VERY unfortunate. Perhaps the developers can add a new option to the drop down selection that doesn’t unload the level on the server, and only does so on the client, and fix the peer host so they can at least hide the rendering of a sublevel if not unload it. Level streaming seems to me a KEY technology area for people to be able to keep framerate acceptable, to keep memory costs down, and to allow for large worlds ( like MMO’s, like large multiplayer games ). It seems strange to me that I would have to do this on my own in a blueprint, this is something that should be native to the engine IMHO.

17

Level streaming is still key, however there are alternative solutions that are more efficient than Level Streaming Volumes, which is predominantly going to be used for older systems, such as XBox 360. For MMO’s especially, I would highly recommend looking into the World Composition Browser, which is designed for streaming in larger worlds. Additionally, the blueprint scripting system opens up opportunities for optimization. You can find additional resources on the World Composition Browser here:

18

Hi every one
I got a same problem and found something
You can use trigger box or a actor overllaped to control load a level. But if you wana spawn an ai pawn you should spawn it by your self in persistance level. Because loadstream level make the level restart and … finally. Hope to help