Child Actor Component Data Loss/Corruption

Hi! I have a sad!

I use Child Actor Components fairly frequently for my player avatar customization system, and ever since 4.14, there have been some serious instances of data loss in their use. Right now, it tends to be a result of a child actor component just losing data at the top-level (like an actor with a Child Actor Component as a child will lose bits and pieces of data from the intended-assigned child actor).

This is mega hard to explain with any clarity, but here’s a screen shot (I had to delete and re-assign the top attachment, the bottom attachment is how I found it). In this image, you’ll notice that mech_attachment_one_null has all of its data in place (Part and StaticMeshActor). But, for whatever reason, mech_attachment_two_null (which is the exact same setup with a different name) has lost its static mesh actor at some point. The core blueprint itself still is fine, but the child actor component reference is all wonk.

I’m using a custom fork which is mostly 4.14.1 with some cherrypicked (and unrelated) master bits and custom bits.

I have moved this into the Bug Reports section for further investigation. We’ll follow up soon.

Hello mittense,

Where are you setting the Static Mesh Component values for these actors? Is it in their defaults, in their constructors, or otherwise? Does this occur with any class that has a static mesh component in it that is set as a child actor, or does it only happen with this particular class? Are you able to reproduce this in a fresh project?

So, basically, my setup is this (I can’t easily setup a small project with this, but I have had be reproducible):

  • Base C++ implementation of an actor type that are added as UChildActorComponent members in a base class.

  • This base class has a list of UChildActorComponent members that are all filled with the aforementioned actor type. I set them up in the constructor like this:

     // Create a dummy root component we can attach things to.
     RootComponent = CreateDefaultSubobject< USceneComponent >( TEXT( "RootComponent" ) );
     RootComponent->SetAutoActivate( true );
     
     // Create the legs (AMechLocomotionPart).
     Locomotion = CreateDefaultSubobject< UChildActorComponent >( TEXT( "locomotion" ) );
     Locomotion->SetRelativeLocation( FVector::ZeroVector );
     Locomotion->SetupAttachment( RootComponent );
    

(and so on)

  • Then, in-editor, I create a base blueprint class for the primary actor type (that holds all the child actor components).
  • I create a whole bunch of “dummy” instances of the UChildActorComponent actor class which all have their static mesh instances set to a simple cube.
  • Then, after that, I have a blueprint that is derived from those “dummy” instances that further fleshes out specific functionality with actual static meshes and game data.
  • Similarly, I have a blueprint class derived from that primary actor type which has references to the actual actor data intended to fill out the UChildActorComponent fields.

I hope that kind of explains it?

And, and one quick addendum: this is not the only setup related to child actor components that has been affected by this issue. This is just the one I’ve spent the most time with and tried to work around the most. I had some pretty significant data loss in any blueprint that relied on child actor components.

Thank you for the information. I’ve placed a bug report in which you can find here: UE-40027. It’s quite a confusing issue and may of been happening prior to 4.14 but the specifics of a child actor component weren’t visible in blueprints prior to 4.14. You should be able to track the bug’s progress there.

Thanks a lot! <3

can confirm, just stumbled upon this. It works fine if child actor is an empty c++ actor, as soon as you add meshComponent pointer to it - stuff breaks.

The bug claims to be fixed, but I’m still experiencing exactly this in our project on 4.19

It was stable for most of the project, but now I can’t get it to remember all the template settings from one session to the next. Someone else has observed that it seems to be caused by casting: