[Infinite Loop] Workaround for bug causing stuck at loading 70%, 71%, or 72%
We have had a problem where unreal locks up on load (after working in a session where everything worked), and have tracked it down. This is a serious issue because you lose all your work and have to revert back to the last time you made a backup to be able to fix anything. No log is produced in this case.
Our structure is that we have an OurGameModeCPP, with an OurGameModeBlueprint inherited from it for setting custom defaults in editor We have a OurPlayerCharacterCPP, with an OurPlayerCharacterBlueprint inherited from it. OurPlayerCharacterBlueprint is the default pawn.
What we were finding is that if OurPlayerCharacterBlueprint (or any class that it contained a reference to) did a GetGameMode() into a Cast To OurGameModeblueprint, the editor would never load again (even if this cast was never executed). If we changed it to a Cast To OurGameModeCPP, there would be no problem. Note that this happens even if the cast is never executed (just floating free).
We finally tracked down the problem to this code in the constructor of OurGameModeCPP:
If we removed this code there was no longer a problem, even though this is how setting a default pawn class is done in Unreal CPP (I think many of the samples do this).
If I had to guess on the bug (here's where I lose my cred), it's that during the process of loading, the system loads in class definitions on demand. OurGameModeBlueprint has a reference to OurGameModeCPP which then on construction has a reference to OurPlayerCharacterBlueprint class which refers to OurGameModeBlueprint again (because it contains the cast to OurGameModeBlueprint) which isn't identified as being loaded, so it starts the cycle again. In general this reference stuff is robust, but something about child/parent classes mixing with c++/blueprint breaks it.
Anyways, if anyone else has this problem (I see several unanswered questions about this on the forums), our workaround is to put all the blueprint functionality in c++ and then always cast to the CPP class instead of the blueprint class. This has made things robust again.
Thank you for submitting a bug report. I have reproduced this issue and logged a report for it here https://issues.unrealengine.com/issue/UE-37922 . You can track the report's status as the issue is reviewed by our development staff.
As a workaround to avoid the freeze, it would be best to simply define the default pawn in your gamemode blueprint rather than in the class.
answered Oct 27 '16 at 09:43 PM
This bug still exists in 4.15.1 just FYI. I was trying to build my project off the multiplayer shootout example and this answer makes me think I should scrap the project for a pure blueprint project because the code stuff feels over my head. It was working fine a few hours ago and now I'm stuck at 71%. Thanks for the answer though good work guys god bless
answered Apr 11 '17 at 10:17 AM
This issue raised its ugly head again today. Ended up working around the issue by using a SoftClassPointer to the game mode in place of a the game mode class itself.
Worked like a charm.
answered Aug 06 '18 at 06:00 AM
This is still happening exactly as described in the OP.
answered Oct 01 '18 at 01:31 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here