I just leave it .
Next steps in derived blueprint (in question is BP_ShipStart) helped to me (UE 4.26.2):
- Reparent to Actor
- Save
- Compile
- Save again
- Reparent to the original parent class (in question is AShipStart)
- Save
- Restart editor
Enjoy!
I just leave it .
Next steps in derived blueprint (in question is BP_ShipStart) helped to me (UE 4.26.2):
Enjoy!
So this is still present in the current UE5 version. I’ve encountered it in two different projects.
Both times it was a child of the ACharacter class in one way or another.
Both times it’s the same problem: The AttachParent of the newly added Component points to the CDO version of the Parent Component.
Now is some news: This seems to be known to Epic. They have a repro project.
There is even an Issue ID, which I can’t view. This was reported a while ago (1+ year?) and nothing has changed.
There are some suggestions, like turning off Deferred CDO Initialization via DefaultEngine.ini, but none of these actually fully fixes the issue. Some people might crash when turning it off, others will get problems with their references.
All of the suggestions in this thread are bandaids that will break eventually again.
Some users can’t afford to redo BPs and others might not even be able to solve it with that.
I’ve been through multiple different solutions, even tried my own, they all either don’t work or break in the future again and required a lot of time to even be executed.
I know Epic reported this to be tricky for them to fix, but this blocks me now on at least one project and I absolutely hate that core issues like these aren’t properly discussed anywhere.
Not everyone has UDN access, yet everyone suffers from BPs corrupting.
Could someone from Epic at least check the issues ID 113689 and let us know what the progress on this is?
I encountered this bug when trying to swap out the Skeletal Mesh Component type in C++ (removing a marketplace plugin) – from USkeletalMeshComponent to USkeletalMeshComponent.
I ended up having to just revert the changes with git and try again with a more step-by-step approach.
Of course that can cause other issues but they’re more standard fare than this one.
Also if you’re reading this and aren’t using version control, Unreal trashes blueprint binaries in an unrecoverable way pretty frequently. It’s worth it to set something up just to take the sting out of those issues.
This bug appear to me when I update to version 5.1. A bug report UE-38697 is describing similar issue but it is currently marked “cannot reproduce”. I use the fix mentioned in the bug report which is overriding “OnRegister()” method and running the “SetupAttachment()” inside “OnRegister()” and it seems the problem is gone for now.
In my case I am trying to attach a USceneComponent to a Actor in c++. The USceneComponent has its own capsule component attached to it using SetupAttachment(this). It works fine in 5.02 but currently the fix mention above is the only way to get it working without warning or bug. Hope Epic can reproduce the issue and figure out what is the cause.
Link to the issue report Unreal Engine Issues and Bug Tracker (UE-38697)
I was banging my head on the wall with this error, and since this is the top result on Google for the error, I thought I’d share my solution. I’m very new to Unreal and am more familiar with C# but still have some C++ experience outside of Unreal, hopefully my explanation makes sense.
For me, I was using delegates for the first time (through a DECLARE_EVENT macro). I was calling GetOwner() to pass my Character to the AttachToComponent call inside of the event handler.
I called AddUObject in the constructor of the subscribing class. I believe this caused the handler method to have a “template” version of my Character when I was in-game. Moving the AddUObject call into a BeginPlay method solved the issue for me, and GetOwner() is now getting the “instanced” version of my Character.
So, the lesson is, don’t (in general) subscribe to events in the constructor of your UObjects as it will be bound to the template version of your object rather than the instanced one.
I’m sure there are a lot of Unreal pros out there saying “duh”, but it took some debugger-fu to figure this out. Luckily I had some working code I was able to compare the instances during this call to figure it all out. I also had no clue what the difference between an instanced and templated version of my component was before this, you learn something new every day I guess.
still happens in 5.2 i had it a few times.
I’ve been struggling with this problem for over a day now, but just managed to solve it.
The underlying problem was a circular hard reference in a couple BP components, which apparently causes a different component initialization path.
I removed those hard references and the problem goes away.
I just leave it .
Next steps in derived blueprint (in question is BP_ShipStart) helped to me (UE 4.26.2):
- Reparent to Actor
- Save
- Compile
- Save again
- Reparent to the original parent class (in question is AShipStart)
- Save
- Restart editor
Enjoy!
Sadly, the only workaround that works… After driving me crazy, I went auto-mode and started reparenting back and forth. The huge downside, is that variables will reset, so if you have TO MUCH stuff in the variables, you will suffer a lot going this way, but I find no other option.
Someone suggested removing duplicates of PlayerStart’s which worked to remove the error on launching the editor but didn’t remove the issue. I have a project in C++ but I had initially set everything up in blueprints and slowly migrated to C++. I copied the project and started deleting everything to try and find the route of the problem. I had left the original blueprints for my GameInstance and GameState in the projects. These had a reference to my C++ character. Even though these are not set up to work on any of the maps they were still causing an issue. I deleted these and was able to remove the issue. I never narrowed it down to specifically why they were causing the issues only that deleting them removes the template/instance problem. Hope this helps anyone!