I saw a lot posts about this well known issue and wasted a lot of valuable time trying to fix them when they come up.
Sometime child blueprint and level actors will ignore component attachment rule so everyone will go where they wants when they want. Sometimes your dynamic delegate functions are still called by a delegate you delete long time ago. Sometime after you moved a sub-object component to the parent class, you can see it on some of the child classes but not others… all CDO related misery. Best of all, what if you have to recreate the blueprints and the child actors that placed all over your levels in order to fix the problem, will you do it or just quit.
There is this technical post about how to understand and debug this kind of issues, but hey, if you somehow figured out the solution by reading the post, please post your solution for us none engine engineers.
There is a hack I found to fix a similar issue I had. The goal is to fix the problem without recreate blueprint classes or replace effected actors in level so we can keep the custom data and setup in the level actors intact, because if we have to redo everything every time we encounter this and other CDO related issues, the war has already lost.
-
First comment out all the UPROPERTY micro/specifiers of the problematic sub-objects, including “URPOPERTY” keyword itself.
-
Then create a dummy c++ class that is the child class of the c++ class that the blueprint base class derivatives from. It can just be a empty class. It should look like this:
C++ class → dummy c++ class → blueprint base class (potentially problematic) → many child class and level actors (potentially problematic).
-
Create a new sub-objects in the dummy class, could be a new UStaticMeshComponent or a scene component. Initialized it in the dummy class’s constructor using “CreateDefaultSubobject” and give it proper UPROPERY just like a proper component you will normally use. Then make this sub-objects the root component in the dummy class.
-
Start the editor, now the problematic actors and blueprints can at least be opened and edited because we comment out the UPROPERTY specifiers. When we select the component we wish to update or fix, the details panel may appear to be empty which is normal.
-
Re-parent the base blueprint that is the direct child of the c++ class to the dummy class we just created. If your original setup is like this: C++ class-> Blueprint Base → many Blueprint Children, you only need to re-parent the “Blueprint Base” to the dummy class. Recompile and save. If you see the whole sub-object structure changed and both blueprints and in level actors update to the new structure then so far so good.
-
Close the editor, go back to your IDE software. Un-comment the UPROPERTY specifiers. Rebuild the project and restart the editor.
-
After the editor starts, without touching anything else , go to the base blueprint class we re-parented, revert the parent back to the proper c++ class we want to use. This should cause a recompile and re-propagate the changes to the children blueprints and level actors automatically, save the file and hope the problems goes away.
Why it may work?
I have tried many methods just like the original author and many others, like changing the names of the components, recreate the blueprints then update references, clean-rebuild and many other weird things like a mad man. The best result I could get was even though the base blueprint and newly created actor instances seems acting correctly, the old one always revert to the problematic state after restart the editor.
The theory behind the above method is because the dummy class is a child class of the original base native class. We only add a new sub-object in the constructor but everything else stay the same. The re-parenting force the children blueprints to go through restructure that is big enough to clean-up old serialized data, but not destructive enough to damage the custom data those actors had. I am not an engine engineer so what I said may not make any sense, but doing some of the things individually without other steps will not produce the same result. Un-comment UPROPERY micro is important not only because it stops the editor trying to access the problematic components at start up or at begin play, it may also give the re-parenting action a chance to clean-up left over connects. Again all just my best guess.
Why it may not work?
Sometime we can have other issues that stop us from getting the correct result. I have had a problem that was caused by a leftover unreal property re-director pointing to two different name, one new and one old. That thing confused the editor big time so no matter what I did the actors and blueprints always return to their broken state after few restart. Of course your code may have few surprise of their own, so in the end your own wit and judgment are your best friend.
Best practice going forward:
If Epic at least post few videos or some kind of best practice articles to acknowledge the issue in some shape or form, a lot of time will be saved. You won’t believe how many tutorials and examples, new or old still telling people to bind the component’s dynamic delegates in the constructor, which will causing problems later when the component or delegate function has to be changed.
I don’t know if anything we do can realistically stop similar problem from happening. Epic has this commit for 5.4 may just be the hope we are desperately searching, but I really doesn’t know.
What I will always do from now on is every time I edit a sub-object, like renaming, moving, or removing, I will check if the derivative classes are still function normally. I will never bind dynamic delegates in the constructor and always put sub-object components in the private field with “VisibleAnywhere” and Meta = (AllowPrivateAccess = “true”) and only use getter function to access the component if other class wants to edit the component.
In the end, sorry to revive the old post. Of the many similar posts this one seems to have the most easy to understand title and the issue is clearly described so it is easier to get the discussion going. If this rant can help people encountered similar problems to get a better understanding so they may come up with a fix or if this fix works for you, that is good enough for me.