Unable to Open Unreal: "Assertion failed: Template..."

Working in 4.13, I am getting a crash that leaves me unable to open my project on the next time I go to open it (it works fine until I close it, but will corrupt with next open). This seems to happen anytime I have an actor or component reference one of my enemies and need to select the class from a dropdown menu. So creating a node (even without connecting it) for SpawnAIFromClass, or GetAllActorsOfClass, or having an Actor reference as a property in a bp will all cause the project to crash on next load. However it does not crash if I reference my Base Enemy Class or ACharacter.

So for example if I call SpawnAIFromClass:

  • spawning a Character is fine
  • spawning a Base Enemy (inherits from Character) is fine
  • spawning a NormalEnemy (inherits from BaseEnemy) corrupts.

Finally, I was previously calling this in an enemy spawner, and that has worked fine. It is only now that I’m trying to do a few spawns through scripted events that I’m having trouble, but I don’t know what’s changed. Obviously I can’t repro this in a clean project, but if anyone can help or steer me in the right direction, it would be much appreciated.

Here are the top lines of the crash log:

Assertion failed: Template [File:D:\Build\++UE4+Release-4.13+Compile\Sync\Engine\Source\Runtime\CoreUObject\Private\UObject\LinkerLoad.cpp] [Line: 3880] 

UE4Editor_Core!FDebug::AssertFailed() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\core\private\misc\outputdevice.cpp:421]
UE4Editor_CoreUObject!FLinkerLoad::CreateExport() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\coreuobject\private\uobject\linkerload.cpp:3880]
UE4Editor_CoreUObject!FLinkerLoad::ResolveDeferredExports() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\coreuobject\private\blueprint\blueprintsupport.cpp:1445]
UE4Editor_CoreUObject!FLinkerLoad::FinalizeBlueprint() [d:\build\++ue4+release-4.13+compile\sync\engine\source\runtime\coreuobject\private\blueprint\blueprintsupport.cpp:1302]
UE4Editor_CoreUObject!FLinkerLoad::FinalizeBlueprint()

Got some more info here. Seems like it is breaking in LinkerLoad.cpp on line 3880 while trying to verify/load/something BP_TriggerCheck (a component I made to check the triggers for enemy abilities) on BP_BaseEnemy. So possibly something about this component may be contributing to the corruption somehow? While there have been some changes to it recently, all it’s code works fine and there haven’t been any other problems that I’ve had with it so far.

I have run into this exact problem on my own project.

Ran into the crash a few weeks ago, and after rolling back to a (much earlier) known good state and recreating the files, it came back. After much experimentation with backups, I have narrowed it down to a place where I add a single variable (array of structs) to the file and that immediately takes it from a functional state to the editor instantly crashing if I reopen it and reload that file (or any other file).

I have deleted and rebuilt the struct (a BP instance, a float, and a name), renamed it, and even reordered it, but the problem persists.

Please tell me you have some insight into this. It has cost weeks of work already.

(We are using 4.13.2)

UPDATE: the crash is not directly related to the addition of that variable. It seems now that if I do any further work in that file, the editor gets into the unstable state and crashes on re-entry.

If I remember correctly, this was an issue with circular reference chains. When Unreal opens it tries to load things in the correct order so all blueprint references are valid. Circular reference = infinite loop that was not properly handled and crash. This is also why I was only getting the issue on reload of the editor, as all other objects were already initialized during this session when I created the new reference that completed the circle.

If this is the case for you, it is most likely because of your BP instance references. You should be able to fix it by switching up some of your methods so as to break the chain or reverse the direction of references in one spot. I had to switch from having one actor finding another it needed to instead have the needed actor find the first.

Also, struct arrays have been historically buggy, and although better in 4.13, you may also try avoiding that entirely and just having a separate array for each of the items in the struct. Dumb, for sure, but could help narrow down if the struct is the problem.

Thanks, etecoon3. Any good tips on tracking down where circular reference might be happening? I’ve been combing the code, but without a good starting point, it’s needle in haystack material.

Reference Viewer is your friend. The bp that you were adding the change to that causes the corruption is the one that completes the circle so start there. With the corrupting change implemented, compiling, and saved, follow references forward or back and see if you can end up where you started.

Now I’m not sure that every circular reference chain causes the corruption, but I don’t think so. But in my experience, if the chain is going to corrupt, it will be consistent every time you try to add it. So if you’ve found a chain, break it. Aka, remove a reference to another BP in one of the objects temporarily, and check the Reference Viewer to confirm the reference is gone. Your project doesn’t need to run correctly, but it needs to compile and save. Then compile, save, close, reopen project with your corrupting change still implemented. If it opens and doesn’t corrupt, you’ve found your chain! Now you need to find a permanent solution for breaking that chain. If it does corrupt, this is not the chain you’re looking for, OR you have created multiple chains in one go. You can go back to a backup and try for another chain.

Good luck!

You are a life saver! Wasn’t hard to find the circular references via reference viewer, and the fix was as simple as removing a cast and sending interface messages to the parent instead.

Thanks a ton for taking the time to respond!