One way of testing the functionality of these options is to go into the Project Settings and go to the “Engine - Streaming” page. There you can set the “Actor Initialization Update Time Limit” to a very low value like 0.1. This will cause the streaming to only add one or two objects from the streaming sublevel per second - at least on my machine.
If you only enable “Make Visible After Load” you will see each object from the sublevel appear as they are streamed in. So I guess it’s not making the objects visible after load, but rather during load. If I disable the setting it won’t show any objects from the level, even when it is done streaming.
If you enable “Should Block On Load” it seems like the node doesn’t really block anything but the execution path it’s connected to. So if you connect it to the Event BeginPlay node and you have a Print String node after it, the Print String will not execute until the level is loaded. But from what I can see, everything else (like the Event Tick or other blueprints) keeps running as usual.
So if you want everything to just stop while you’re loading I guess you could set it up so that you first use “Set Tickable When Paused” in the blueprint that you’re using for loading. Then you pause the game (“Set Game Paused”). Then you run Load Stream Level and set up an event in the Event Tick that keeps checking every frame to see if the level is loaded (Get Streaming Level → Is Level Loaded). When the level is loaded you have a branch set up that unpauses the game.
Or you could just sprinkle a few “Is Level Loaded” in select places that you don’t want to fire while loading.
By the way, make sure you’ve set up your levels correctly in the Levels menu (Windows/Levels) and in the level streaming volume settings. If you click on a sublevel in the Levels menu and click the “Summons level details” button you will see some options. One of the options is “Initially visible” which may conflict with your settings in the Load Stream Level node and cause confusion. If you’re using streaming volumes there’s an additional setting in the actual volumes that may cause conflicts as well. So yeah, there are three places where you can set visibility for streaming levels. There’s also a “SVB Blocking On Load” setting in the streaming volume, but I’m not sure how it works (i.e. what it’s actually blocking).
The thing that is supposed to be “blocked” by “should block on load” (or the SVB Blocking On Load function of Level Streaming Volumes) is the main thread. This is how it worked on UE3, and has been confirmed as being supposed to work on UE4.
So, basically - when you hit the Stream Level node, if block on load = true, what should happen is the entire game stops completely until the level is fully loaded and visible (if MakeVisibleAfterLoad) was checked. The reason these guys haven’t been able to repro it yet can only be that they aren’t streaming in a level large enough for the machine they’re testing on to take much time to load it.
Thanks for providing the Actor Initialization Time Limit tip - that should provide a better way for the Answerhub staff to repro it!
It’s worth noting that MakeVisibleAfterLoad also doesn’t work at the moment. The level is always made visible, which isn’t always what you want - sometimes you want to, e.g., start async loading a level in the background before you need it, so that by the time you want to make it visible it’s ready (and if it hasn’t already loaded, you do a blocking load). UE3 games, including Gears, did this all the time.
It’s been years since I reported this and it’s still like this, hopefully someone from Epic is still reading this thread and attempts to repro with a low ActorInitTimeLimit set.
I can confirm that in UE4.19 “Should Block on Load” is completely ignored. However, “Make Visible After Load” is not.
Unlike op, my level is rather small such that the anticipated “hitch” is negligible to begin with. But similar to op, I have various player starts in my sublevels (it’s a linear setup where one sublevel leads to the other), so the sublevel must be loaded before the game begins playing in order to restore progress.
Simply calling Load Stream Level with “Should Block on Load” ticked behaves the exact same as if unticked. The player start is not found and the player is spawned at the fallback player start in the very first level.
However, adding a Sequence node before the Load Stream Level node and connecting Then 1 to a Flush Level Streaming node does what I’m looking for. The level is loaded before BeginPlay and the player start found.
Note that it does not suffice to call Flush Level Streaming after the Load Stream Level node as the Completed execution pin, of course, executes after the level has finished loading asynchronously. This semi-nasty workaround is a necessary evil.
Also note that I extended AGameMode with a custom C++ class to add more Blueprint hooks to run at various points during initialization, because BeginPlay propagates up the ownership chain, starting with the objects that own no other actors. This means the Game Mode is one of the last actors in the game to receive the BeginPlay event, which is the exact opposite of what I desired. (Although overriding OnPostLogin might have done the trick too, idk.)
Still a problem in 4.23 - in my case I do this with LoadStreamLevel from code and just needed to get the first object of a specific type via an Actor Iterator. I used a short busy-wait for the specific thing I needed (appropriate for the specific use-case) as a band aid fix, but that will not work for everyone so it would be nice if this was properly addressed somehow.