4.16 updated project crashes - Skel_ & LinkerPlaceholder.
I have a project in 4.15 that is stable but upgrading it to 4.16 it crashes so much. Play in editor, compile, migrate or deleting all causes crashes.
Errors I am receiving are:
Ensure condition failed: ChildActorTemplate == nullptr [File:D:\Build\++UE4+Release-4.16+Compile\Sync\Engine\Source\Runtime\Engine\Private\Components\ChildActorComponent.cpp] [Line: 95] LogOutputDevice:Error: Found unexpected ChildActorTemplate LinkerPlaceholderExportObject /Game/FirstPersonBP/Blueprints/ElectricitySystem/Parts/Part_Door.PLACEHOLDER-INST_of_PLACEHOLDER-CLASS__Mod_part_Base_Door_C_5 when ChildActorClass is null
Ensure condition failed: !bIsFilteredOut [File:D:\Build\++UE4+Release-4.16+Compile\Sync\Engine\Source\Editor\BlueprintGraph\Private\BlueprintActionFilter.cpp] [Line: 1689] LogOutputDevice:Error: Invalid BlueprintActionDatabase entry (for SKEL_Part_Door_C). Was the database properly updated when this class was compiled?
And I am suspecting child actor components to be part of the issue.
Because of the report size and this website not lending well to formatted text, the report is inside a text file. I don't expect anyone to read or follow it - but it's there if it provides any useful information.
I also include two projects - one which is basically the project version and one that is heavily modified to remove errors as much as I could. Due to the size, and limited dropbox space I had to zip it. I hope that is okay.
There are also 4 log files.
Crash report: (use this) https://www.dropbox.com/s/7yikaztc9u02ya5/Crash%20report.txt?dl=0
I'd be happy to provide anything else that might be of use.
asked May 25 '17 at 06:49 PM in Bug Reports
Ok, after a lost day of work, I managed to make a succesful build.
All I have really done was deleting and adding again all child actor components that were getting errors, trying to force an update on reference on them. I also tried adding a random variable to the classes of the actors themselves, also trying to force an update. I've done that on all the hierarchy of child actors (I had stuff like child actors inside the blueprint being used as CAC, for example)
Long story short... Try to update all components and classes associated, maybe it works.
edit: to fix one of the classes I actually had to restart the editor so the "Child Actor Template" was gone lol
This error used to ruin me, but I just found a super simple way to fix it: Simply create a child class of the class that's causing the problem and replace the child actor component's class with your new childClass.
Example: Your BP_Hero has a child actor component of class type BP_Gun. This gun child actor component is throwing the error.
I run into this error more frequently than I'd like. This hack is easiest way to solve the problem.
answered Dec 19 '17 at 04:06 AM
The solution seems to be this from the comments above (at least for 4.18.3 where the issue still happens):
More precisely, say you have a BP_Character and a BP_Weapon (actor and child actor). In the BP_Character, find and select the child actor component (which has a child actor of BP_Weapon) and in the Details panel, uncheck Editable When Inherited. Then, select its parent component, uncheck Editable When Inherited again, and keep going up the chain to get all ancestor components. After that, it "should" work.
I ask the OP to accept this answer (if it works for OP as well) to make it easier to find. I had to read through all this to get to the solution!
So the Skel_ errors that me and tslimone got was associated with Child actor components but even though I fixed it so I got no more of those errors, my project still crashes.
So I have been trying to narrow down the issue. I have a "Default" project, which is the original project and have been deleting classes, functions and other data to remove things that does not affect these crashes, constantly cloning the project as I go. As I have deleted some things I have noticed that they fix the crash symptoms - but when redoing that action in the Default project, few have fixed the crashing and none to satisfaction since it involves deleting critical parts. I am now down to a project with 12 classes, most are empty of functions and other things. At this point, pretty much anything I do will fix the crashing in this reduced project, but not the default one.
An example of a 'fix' is that the third person character has a node "Spawn actor(Ball)". It's not connected. If it is in the blueprint, the project crashes. If it is deleted, the project stops crashing. But deleting it in the default project does not stop the crashing.
I have no idea what is going on, project was completely stable in 4.15
Again, I will share the Default project and the reduced project.
BP Classes rundown: https://www.dropbox.com/s/1oqoafpkkq6s7ns/Setup.png?dl=0
Please let me know if this is of any use at all.
answered May 30 '17 at 11:41 PM
Interestingly enough, I had to combine two of these solutions. But honestly, the second one could have been what fixed it all.
My scenario: Inventory system. In Character I had 6 slots (child actor comps). One of those slots was a Backpack BP, inside that Backpack, I had two additional Child Actor Components attached.
Fixed by doing this:
I am 99% sure it was really the latter that got this to work. But I am not going to try to repro this.
POST EDIT - This ended up regressing somehow. I ended up just Spawning the Actor BPs and Attaching them to Components already placed on my character.
I'm getting this in 4.18 as well. It happened when I initially set the child actor class and then removed it, so I guess it still has that actor serialized but it shouldn't be there anymore.
answered Nov 01 '17 at 11:02 PM
My current working theory is that this error can occur if there's a cyclic dependency in your project making the compile order unclear or unresolvable. If, for example, Class A casts a child component to Class B and sets a variable on it, while meanwhile Class B does some operation on an instance of Class A, you're going to run into problems because Class A can't be compiled until Class B has been compiled, but Class B can't be compiled until Class A is compiled.
My experience has been that these sorts of circular references can behave in strange ways, since what they do depends entirely on the order in which assets actually get compiled, which is why creating child objects of an offending class could conceivably correct the issue, since then the parent object could simply as a matter of luck be compiled in time to be used.
This is just a theory, but I recently resolved one of these issues by cleaning up my inheritance architecture so two objects no longer needed to know about each other to compile. Or I just got lucky.
Epic's own code concedes that there isn't a clear handle yet on what's causing this.
answered May 19 '18 at 03:58 AM
Follow this question
Once you sign in you will be able to subscribe for any updates here