Just tried upgrading it to 4.11, and the freeze still happens under the same testing procedure. I’m going to try to fix some warnings and errors, then strip down the collisions to see if I can narrow down the cause.
Alright, so I got some time to dig my teeth into this. Took all night, but here’s my results:
I fixed all errors and warnings in 4.11. It still had the freeze.
I removed all wires from collisions, freeze still happened.
I removed the wires from the OnConstraintBroken for the leg+foot joints, it was fixed, I couldn’t get it to freeze.
I dug one function at a time deeper, essentially commenting out everything, then rewiring it one piece at a time until it froze, restarting, and going deeper.
I followed it OnConstraintBroken → Kill Ship Disable → Disable Control → Update Thrust → Update Flame.
It comes down to a single get value from ThrustLevel in Update Flame on my LanderPawn. If I unwire ThrustLevel from the Set Relative Scale 3D calculation, I can’t get it to freeze. Rewire that, and it freezes once again (once per restart on 3rd or 4th crash).
I put a block directly above one of my legs (So my foot hits it) to expedite testing of breaking a leg.
I also noticed that it only freezes when Lander Blueprint is open, that ThrustLevel get value is wired, I break a leg (which was also happening when colliding head-on), AND when my thrust level > 0 (where you can see the flame). Those four things being true, it freezes consistently in the first 4 times breaking my leg on the block after a fresh open.
So there’s something about that thrust level property getting read or it being used to SetScale from, at that very moment, that seems to cause it.
Is there any way for me to provide more info to your development team that could be beneficial?
Also, as a sidenote, after upgrading to 4.11, the freeze is much shorter ~1s, and as a result doesn’t throw the error from original post. It is still a visible issue, and still only happens consistently in the first few leg breaks, and intermittently from then on. Since 4.11 upgrade, the editor spikes to only 1,200,000 instead of the 2,400,000+ seen before. So there were definite improvements, but the issue still exists, and it has something to do with that get value call.
Thank you for performing some thorough testing.
Ideally, I’d like to get a test case that we can reproduce in a clean project to diagnose exactly what is causing the issue. One other thing I’ve noticed were the error messages that were appearing after exiting PIE. I fixed a few of them regarding the Bobblehead pieces being set to Simulate Physics, but not actually having the collision settings to reflect that, and I haven’t seen the freeze yet. I am not sure if that is related, or if the freeze is just being elusive, but go ahead and set the collision of the Bobblehead components in the Lander BP to Query and Physics collisio and see if you’re still getting the freeze to occur.
Those issues were among the things I fixed yesterday. It now launches, plays through multiple resets until freeze occurs, and closes with no errors, no warnings, but the freeze still occurs.
I can try to see if there’s any way for me to reproduce it in a clean project, but I’m thinking its a combination of things all exacerbating a small delay issue at that variable get value, making it visibly noticeable.
I’ll try using the profiler tonight to see what’s different about the time it freezes compared to not freeze. Maybe that will give a hint as to what else is happening to make this frame take longer than the others.
Also, to reduce external concerns, since upgrading to 4.11, I have a bunch of ‘map check external file reference’ errors, is there any way to resolve those to avoid potential red herrings?
I am still experiencing the freeze issue since upgrading to 4.11. It’s less extreme now, but affects gameplay just the same. A 1 second lag when trying to land can ruin an entire playthrough. I’ve been trying to recreate it in a fresh project to help you narrow down the cause, but I’m still not sure exactly how to go about it. I know where it is happening in my code, but there’s so much else going on that I can’t be certain this isn’t a distractor, or that this isn’t just the last straw that causes it to peak over some critical memory usage issue/memory leak… It seems like it’d be easier to approach from your end if you can reproduce it on any of your systems consistently, to have an engine developer put in breakpoints and trace out the issue. I’m basically hitting it blind and following any leads, and it’s taking a long time.
I’m not sure if there’s anything they can do with remoting into my machine (or if you have a studio in MN? or any source code options?), but I’m honestly willing to try almost anything at this point.
Also, I can probably work around the current issue if I need to, since I know where it’s happening and could address the specific way it hits this code differently, but much I’d rather help figure out what the actual cause is, to prevent it from popping up elsewhere, or for someone else in the future.
Hello,
Do you have any further information as far as the results of your profiling? Are you still experiencing the project freezing after you have resolved the errors and upgraded to 4.11?
Could you try packaging the game to see if you can reproduce the freeze in a packaged product?
Good question, I’ll try that tonight.
Thanks.
Tested it and it happens in the packaged product. This is an even bigger concern for me now.
I added my testBed7 level to the
menu, and ran it with nothing else running and got the freeze/stutter on the very first collision. Happens consistently. :\
I did a Windows x64 package, in case that info is useful.
The freeze isn’t improved with 4.11. Crashing fast into the leg while thrusting fully still results in a multiple-second freeze in any platform (PIE, Launch to windows, Built Package x64 Windows) This is what I’m seeing in the profiler on the frame where it hitches. I don’t know what else to do here.
Profiler
I think I’ve found the culprit! I tested in all 3 ways and wasn’t able to reproduce the freeze once I disabled ‘Project Settings>Engine>Physics>Framerate>Substepping’
I will test on my other computers tomorrow to double check, but so far it seems to prevent the freeze!
Since my game is 100% physics-based, I would like to have the accuracy of substepping, so I’ll still pursue a fix. Hopefully this will help narrow down how to reproduce it in a fresh project. I can try this over the next few days.
Thanks again for all of your support in this!
Hello,
I am glad to hear that you have found a workaround for the issue that you are experiencing. Keep in mind that the Substepping feature is currently experimental, which means that it is very possible that there will be complications with using that particular feature.
If the issue reappears, we will need to have a solid repro that we can use to recreate it in a new project in order to enter a bug report.
Have a great day