Thanks for reporting the issue. It has been reported directly to Epic. A public bug tracker will be generated and I’ll post the link here so you can have access and see how the bug is being developed. Once the issue gets fixed, inside the bug tracker, Epic will publish the fix commit so you can add it directly to your engine without the need to wait for an oficial engine release.
So I did some investigation and I’ve found the source of the bug and a workaround for you. When you have sequencer open and it generates it’s connection to the object created. Internally we mark the object as moveable. When you load your sublevel it will push that setting into the object. Then, when the child object instantiates, it has a mismatched movement setting from its parent and will not create the attachment. Normally when you change the mobility setting of a static mesh actor it will also change any child’s mobility setting as well.
You can verify that this is all happening by looking in your log and seeing a warning similar to this.
PIE: Warning: AttachTo: '/Game/Sub.Sub:PersistentLevel.StaticMeshActor_1.StaticMeshComponent0' is not static , cannot attach '/Game/Sub.Sub:PersistentLevel.StaticMeshActor_3.StaticMeshComponent0' which is static to it. Aborting.The workaround is to, when your sequence is closed, change the mobility option of your parent actor to moveable, save your level, and everything will go away. The downside to this is minimal, depending on how many static mesh actors you are moving, because it means that those static meshes will not be instance rendered automatically. Additionally, although this is annoying, my workaround will address the issue with the editing of your level. In a gameplay or play scenario, this is unlikely to happen because the sequencer typically loads long after the level and all its objects have loaded.
Hey Dustin, we appreciate your response. We’ll have our team look into this further with the information provided and get back to you as soon as we can. Thanks