I’ve used level streaming a lot before in UE3. It appears that currently in UE4, the “Should Block On Load” var has no effect.
Desired effect: when this node is hit, the level “edin_script” starts to load, and the entire game hitches until the load is finished and the level is visible.
Actual effect: exactly the same as if ShouldBlockOnLoad was false. The game continues to run while the level loads; it takes a few seconds and then appears. There is no hitch. In an example where I’ve teleported the player to the new level’s location in the persistent level, and tried to do a blocking load at the same time (effectively teleporting the player to a new level), the player has long since fallen out of the new level’s space by the time it loads.
-I’ll try repro-ing it in a blank project, but my project is content-only and doesn’t do anything weird with level streaming, so I highly doubt it’s project specific.
-Just try to stream in a level from the level blueprint, with ShouldBlockOnLoad=true. It won’t be a blocking load.
-That’s not possible, no. I can see the level loading in around me over time, as is expected with a non-blocking load. The desired lag/hitch isn’t minimal, it doesn’t happen.
Is it possible that the reason you haven’t been able to repro is that you’re not using a big enough map? On a small map that doesn’t take much time to load, a non-blocking load is pretty much indistinguishable from a blocking one, after all.
Just like to add that I have heard of this in Squad which is currently UE4.12, I believe if the level is of certain size, and perhaps happens more if installed on HDD then SSD, it’s possible for a player to load in before the ground terrain or other objects have thus the player falls. I’d guess the best way to try to repo is have the project on hdd and a use sub level that has a very large terrain and possibly with other sublevels. Now the above is in regards to using level streaming without “ShouldBlockOnLoad” but I believe all Squad maps are set to “always loaded” as has pointed out using seams ‘ShouldBlockOnLoad’ doesn’t work.
I’ve tested this multiple times with several different maps, the only significant difference I can see is the amount of content within the level. Level streaming, in general, happens very quickly, so a level with little content is not going to show the same hitching as a level with many assets. The hitching occurs, but it may be so small as to be insignificant.
Try moving the distance at which you are streaming the level to prevent falling through the content, does this make a difference? The reason it doesn’t work with “Always Loaded” levels is because these levels have already been loaded, so there is no reason to block again. You can also simulate the hitching using “input UI Only” or other nodes to prevent all assets from moving, but this will require much more backend work to function properly and should be taken into account while building each asset that has movement.
We have not heard from you in several days. I am marking this as answered for tracking purposes. If you are still experiencing this error, please comment with the requested information.
On 4.13 I’m still having this, but for whatever reason I was never able to repro it in an empty project. Further, I’ve just realised that the other bool on the node, Make Visible After Load, is also not working. The default is true, but if I set it to false, the level still loads and becomes visible. Seems like both the bools just get ignored.
Can confirm this issue on 4.13. The “block” flag is completely ignored and has no effect. The best way to check that is to set a callback in C++ for the level load event - it will come much later.
@ : Try what said. But also, just try streaming a level in through the Blueprint node, having unchecked MakeVisibleAfterLoad and checked Block On Load. Neither of these parameters are being passed through correctly.
Looking at your answers before, I feel like there was a misunderstanding - it’s not that I’m expecting a hitch and not getting one so I’m assuming it wasn’t a blocking load; a blocking load is not happening. The game thread continues while the map loads, which is not what needs to happen.
If I teleport the player to an empty point in space, and then that same tick, load a streaming level around him (so that that’s now a valid place for him to stand), it should be impossible for him to fall through the new level, as long as the load was a blocking load. If it’s not a blocking load, falling through the level should be expected. But you also won’t fall through the level if the level just loads really quickly on a non-blocking load. In my case, my level is large, and takes a while to load, so I can literally watch it appear mesh-by-mesh as I fall, which should be impossible if blocking loads are working. I feel like I’m kinda rambling here, but just trying to be clear.
I had to prepare a build over the last few days for the company funding the project, took another look, found that it was impossible to get a blocking load on a level stream from Blueprint. Had a hell of a time.
Can you try the following test for me and let me know what your results are?
Create a new project from the third person template
Add a new default level
Set the NewMap as the persistent map and the ThirdPersonExampleMap as a sublevel of NewMap
Place a trigger volume on NewMap
In the NewMap level blueprint, bind an event to the trigger volume BeginOverlap to call LoadSreamLevel node to ThirdPersonExampleMap
In the ThirdPersonExampleMap, add ~1000 Sphere Geometry pieces
Play in standalone multipletimes, changing the checkbox for “Should Block On Load” in the NewMap level bluperint
Using this setup I noticed that when the checkbox was unchecked and the pawn moved into the trigger volume, the pawn would continue to run around until just before the level actually streamed in.
By checking the checkbox as true, the pawn would immediately halt until the second level streamed in and then the pawn could move again. If the behavior you’re seeing is different with these steps, please let me know.
I actually attempted to repro myself before you posted that using almost the same steps, unsuccessfully. Basically, I wasn’t able to create a repro case, but it happens in every large map I have - it seems like just placing an absurd number of the same object isn’t enough to create a map that takes any time to load (or become visible) and cause the problem to manifest obviously. I feel like you’d be better off trying to repro at your end by streaming something that’s actual content, like ElementalDemo, into ThirdPersonExample or similar.
As you suggested, I tried the same setup I mentioned previously with the third person example map and the elemental demo map. The results were the same as my previous test. Could you provide a copy of your project where this is occurring to help give me an idea of the behavior you’re seeing and help determine what may be causing the issue.
If you’re able to upload the project to google drive or another hosting location, you can send me a PM on the forums with a direct download link for the project. This works best if you’re able to the root project folder itself.
I opened the project you sent and opened the S_Persistent_001 map. When I clicked play there were a number of blueprints with compile issues. Attempting to fix the errors/compile the blueprints causes the editor to crash. Can you try the project you sent to see if the behavior is the same? Rather than adding the persistent level to a new project, could you provide the original project for investigation?
Sorry for the delayed response. I was looking at the project you sent again as I still am unable to reproduce the issue outside of the provided project. I actually found that creating a blueprint and adding a static mesh to it, set to the meshes that were falling through the floor, would stream in and not fall through. This led me to discover that by selecting the mesh in the world as well as the content browser, I could right click on the mesh in the world and choose “Replace Selected Actors with…”. This would replace the static mesh that was falling through the floor with a new instance of itself. The only setting that needed to be set after replacing was to simulate physics again, and after doing so the new instance would collide as expected. I can’t say for certain why this is occurring but it seems to be an issue with the meshes that are already present in the world rather than the Should Block on Load checkbox. Let me know if doing this replacement helps on your end.
I could check, but stuff falling through the world is just a symptom of the non-blocking load; it’s not really important. You could delete them all and it still wouldn’t be a blocking load, so this doesn’t help me either way.
