I’ve been following the Udemy course about UE4 C++, but in the course (UE 4.11), the instructor isn’t facing this weird problem. If I play the map directly, physics work fine, but if I start the game from a menu and load the map with “Open level” blueprint node, I experience really weird physics.
In the video I show first the physics working fine loading the level directly and then showing the weird problem I am facing loading the level from a widget menu.
I don’t think that is the cause, I am not streaming level, I am fully opening another. I found that if I open the level that contains the meshes, load the menu level with the console and I use the menu to load the map, it works fine, so:
Open Tank level directly: OK.
Open Menu → Load Tank Level: Wrong.
Open Tank level → (with console command) Load Menu → Load Tank level: OK.
Getting the same behavior. I have two space levels. PIE on each works fine. The moment I try to use OpenLevel in a blueprint or ServerTravel in console, all physics goes haywire.
Did you figure anything out?
EDIT: I just tried the standalone game and at least ServerTravel works there. Might be related to PIE.
I am probably doing the same course you are doing right now.
The problem was opening the level through Blueprint. Apparently, when you do that, physics isn’t loaded correctly. Probably something correlated with the runtime, but I’m not very sure on that. Anyhow, this I what I’ve done to solve it:
if you want to make that your main level, you can right click the level you just added and click on Make Current
When you load your level from your blueprint, the level physics should load correctly.
I hope it helps, at least, maybe this can help as a start on solving the problem definitely.
One thing I still didn’t test is with multiple levels, so be careful about that.
Following your instructions fixed this issue for me. I’m currently going through the udemy unreal course and was getting the same bug as described with the physics going crazy when loading the battleground level from the mainmenu level.
I’m just going to add an answer here in case it helps anyone. I had a similar problem. Crazy physics when the level was loaded in as a sub-level. In my case it was because I had simple (so bounding box) collision set on another sub-level that contained a big landscape geo. So all the physics went crazy because everything was spawned inside the collision of the landscape because it was just the bounding box. Changing the landscape collision settings fixed this (either no collision, overlap all or setting complex collision) This was why it worked fine when I opened the physics sub-level by itself because the landscape sub-level was not present.
I think this is the best answer, Alessio answer uses a solution for streaming levels, so you will get references of Test_Ground on main menu, which makes everything weird.
In my case, collision/overlaps were not working on actors added at runtime.
The objects placed in editor beforehand (before PIE) were working fine, but when I tried to place actors dynamically at runtime in the level that I loaded from the main menu level, they did not register overlaps or GetHitResultUnderCursor() or any other collision related stuff. Adding the levels to the Levels list fixed this problem.
late to the party but looks like it similar issues still occur in the current day and age. I was using 4.25 and after Open Level node, physics was completely disabled. Solution posted by SarperSoher did not work for me at all, entire physics was disabled (despite my enabling simulation post level load).
Turned out the issue was that the path I was using to load the level was causing problems (not sure why). Despite it loading the level correctly, it was messing up the physics system.
I was loading: /Game/Maps/FolderName/MapName.MapName as this was the string I obtained from Soft Object Path structure. When I changed it to load the MapName only instead it worked just fine and now physics works just fine with Get Base Filename node.
I was having the exact same issue and using the base filename instead of the full path fixed it for me as well. You used to need the full path but I guess now just the map name is needed. I’ve seen this issue with a few other function calls related to levels.
