I have multiple “Enemy” blueprints that inherit from a “CombatAI“ parent class, which in turn is a child of the default “Character” class. After reparenting “CombatAI“ to a new “CustomCharacter” class, I’m getting the error message below.
Old class hierarchy: Character > CombatAI > Enemy New class hierarchy: Character > CustomCharacter > CombatAI > Enemy
LogOutputDevice: Error: === Handled ensure: ===
LogOutputDevice: Error: Ensure condition failed: !FBlueprintCompileReinstancer::IsReinstClass(OwnerClass) [File:D:/Build/++UE4/Sync/Engine/Source/Editor/UnrealEd/Private/Kismet2/KismetReinstanceUtilities.cpp] [Line: 1763]
LogOutputDevice: Error: OwnerClass should not be 'REINST_'! This means that a REINST class was parented to another REINST class, causing unwanted recursion!
LogOutputDevice: Error: Stack:
LogOutputDevice: Error: [Callstack] 0x00007ffd6e1c1769 UE4Editor-UnrealEd.dll!DispatchCheckVerify<bool,<lambda_787fa22efeea56ac530ee0812261dd56> >() [D:\Build\++UE4\Sync\Engine\Source\Runtime\Core\Public\Misc\AssertionMacros.h:164]
LogOutputDevice: Error: [Callstack] 0x00007ffd6d9d98e8 UE4Editor-UnrealEd.dll!FBlueprintCompileReinstancer::MoveCDOToNewClass() [D:\Build\++UE4\Sync\Engine\Source\Editor\UnrealEd\Private\Kismet2\KismetReinstanceUtilities.cpp:1763]
The error pops up seemingly at random when I edit any of the blueprints. I couldn’t find any way of deliberately reproducing the error, nor isolating which blueprint exactly is causing the issue.
I made a lot of deep-reaching changes before noticing the error, which makes it difficult to undo everything. Does anyone know what this error even means and how I can fix it? Web searches are giving me nothing related to my particular issue.
But this will appear only when I will compile all blueprints in commandline and it causing no problems in my game it seems:
Engine\Binaries\Win64\UE4Editor-Cmd.exe YourProject.uproject -run=CompileAllBlueprints
Also it is temporaly fixable by “refresh all nodes” in the blueprint and resave, but then it will show this error on a other blueprint. And if I will fix the other, error is back on the previous blueprint.
But I see there “UnknownFunction” error. I had even other “UnknownFunction” error while packaging game, crashing at some group or random files. And I fixed it by moving all these files to another fresh folder and fixed redirectors. Maybe you can try it too.
I had even other “UnknownFunction” error while packaging game, crashing at some group or random files. And I fixed it by moving all these files to another fresh folder and fixed redirectors. Maybe you can try it too.
Thank you for the reply! I didn’t have any UnknownFunction errors so far, but I’ll try moving the files to a new folder. I’ll report back when I know if it worked.
In your BluePrint you can try Right clic → Asset Actions → Reload
After Reload do a simple modification for save the BluePrint and restart the engine
If it doesn’t work you can set the parent class to “actor” then again on the origin class.
This will reset a lot of property so you will have to note and reset the settings in Class Defaults.
For a Blueprint compilation I think I found a workaround. You can enable alternative blueprint loading mechanism with BP.bEnableSkelReinstUpdate variable.
I’m adding a line to Engine\Config\ConsoleVariables.ini before running UE4Editor-Cmd.exe
Thanks for your response, but I’m not sure we should be editing the console variables just to fix a weird unknown error.
I can seem to replicate this error by asking certain child classes to recompile, even without making any changes. PIE and packaged project work fine.
I think this needs posting to Epic under a bug report or can we get an Epic response on this? I’ve recently encountered this upgrading to 4.27. Is this something to do with the Skeleton? ‘MoveSkelCDOAside()’ and ‘MoveCDOTToNewClass’ is the function at the top of the call stack on my side.
Ran into this error as well. Seems to have cropped up only in 4.27. Using the console variable fix described above works for my team, and is a fine way to go about solving the issue IMO after looking into it for a few hours. It enables a newer codepath to be used during BP compilation that was not enabled by default in 4.27, but is enabled in use in 5.0