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 Unreal Engine Issues and Bug Tracker (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.
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
Can you explain exactly what is happening in your case? After creating a Multiplayer Shootout project, what changes were made before you encountered this loading issue? Please provide any information to help me investigate the behavior locally.
I will try to tell you everything I can remember before the load problem. I enabled the experimental plugin for editing code. I also imported some procedural midi assets and made child classes of the midi assets, did some experimenting with variables within the midi assets. I looked for a way of casting variables to and from game mode classes, but I don’t think I acted on it. I don’t think I did any work in BP with that.
These are the changes made hours before the load problem. I created this project a month or so ago and did so much in it that there is no way to tell it all. I did run a defrag which (I think) broke the midi assets I had in the project somehow it ruined their references to the original c++ files, said they failed to load but they were all there. SO re-importing the midi assets worked in fixing it, and I had saved and reloaded a few times since before the load problem.
The main thing I’m sure of is that I made a child actor of one of the midi assets, and it had c++ parent files.
I tried deleting the midi assets and it still locks at 71%.
Also let me correct myself, it was not multiplayer shootout project it was the Shooter game example project from the learning section.
Unfortunately the steps provided are too vague to produce a reliable repro case for me. If you could reproduce the behavior in a new project and provide clear steps on what exactly was added to the project, or provide a sample project that shows the behavior occurring, we can investigate further.
I narrowed it down to the player pawns folder. I’m not sure why it caused the error. Deleting the folder caused the editor to stop locking at 71%. Moving the assets also stopped the error from happening, but in both cases the attached error was thrown on load. SO basically when this error was not thrown, the project locked loading at 71%. When I moved the problem assets the project would throw this error on load, but succeeds in loading up. I’ll check in and let you guys know if saving the pawns back into the level or something like this reproduces the problem. I hope this helps!
So, repeatedly the editor crashed when attempting to playtest until I recompliled the blueprints I had to move and changed their references to eachother. I also moved something in the level and re-saved it and then playtesting stop crashing the editor. Strange issue I’m sure and I hope running a defragment on the drive this was on didn’t have anything to do with the issue. Thanks again guys this Engine is the best in the world keep up the good work.
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.
Unfortunately we have no plans of fixing it right now as it would require pretty much rewrite of some of the basic systems of the engine. The issue there is that the native AMyGameMode class is loading the character blueprint which has the same native AMyGameMode class as its export (dependency) so AMyGameMode’s Class Default Object needs to be constructed on load which leads to a dead-lock caused by internal C++ guard on static local variables when re-entering the same constructor in one callstack.
Could it at least be guarded in some way? Give a compile error when you try to do this in a blueprint? Currently it’s a big potential-data-loss issue, as it works fine until you restart the editor.
