I have a USceneComponent subclass with a single UStaticMeshComponent attached to it in the constructor. When I add this component to a Blueprint actor, the subcomponent doesn’t show up in the Components hierarchy, despite appearing fine in both the viewport and properties window of the parent.
When I drag an instance of this Blueprint into the scene, the subcomponent is present in the hierarchy of the instance and I can move it around without an issue.
Thanks for lettings us know about the inconsistency in the hierarchies. This bug has been reported as UE-15271. Since you are able to access the component in other ways I would continue to do so for now.
A bit of extra information on this issue: I’m actually creating the UStaticMeshComponent in the constructor of the USceneComponent as opposed to creating both in the parent AActor and creating the scene hierarchy via attachments.
I’ve since been told that this isn’t really a supported configuration, and that both components should be created from the AActor’s constructor and placed in a hierarchy using AttachTo().
This is probably fine for most cases, but for what I’m doing it presents a bit of an issue, as I want to have pre-defined component types that dictate their hierarchy of child components.
Can you think of some workaround for not being able to create and attach components from within components? Is this planned to be supported at some stage?
Even though the component created as part of another component class doesn’t show up in the hierarchy it is still editable if the base class is used/selected.
For example: If you create a custom SceneComponent class that declares a StaticMeshComponent* and creates the component in the construct, then using that custom SceneComponent in a blueprint you can select the SceneComponent in the hierarchy and make changes to the StaticMeshComponent in the details panel.
So you’re saying it’s OK to create and attach USceneComponent subclasses in the constructors of other USceneComponent subclasses? That is what I’ve been doing up until now, but it has been causing some pretty serious bugs.
Besides this one, the issues I’ve been having are:
Having subcomponents created/owned by other components permanently breaks hot-reload (See related question)
Having subcomponents causes ambiguous “Import failed” messages when restarting the editor (See related question)
The child node in a component hierarchy keeps its default property values (set in the C++ constructor) when play begins, instead of using the ones set in either the derived Blueprint or placed instance. (See related question)
If you could take a look at these issues, I’d be glad to help out in whatever way I can. The objects in my project are inherently hierarchical and need to be configurable, and being able to define subcomponents in this way would vastly simplify the design.
The other errors you reported seem to stem from this (the fact that the components defined in the SceneComponent class aren’t showing in the hierarchy). Since the components are still editable if the SceneComponent is selected you can set the properties of the other components as necessary.
The workaround for editing properties of subcomponents is fine for now, I was more wanting to get an official answer on whether creating subcomponents in the constructors of other components is OK or not recommended. Everyone I’ve spoken to in the IRC chat says to avoid it as it doesn’t work properly, but from what you said above, it sounds like that should be a supported configuration.
As I mentioned in your other post, it would depend on if the components are parents/children of each other or if you are referencing two non-related component. If the components are parented the you only need to add the child to have the functionality of both the parent and child. If they are separate components then declaring a pointer to ComponentB inside ComponentA should work.
The child components are not subclasses of the parent components; they’re completely unrelated classes. Declaring a pointer to ComponentB inside ComponentA “works”, but it causes all of the bugs I linked to in my earlier comment. If you take a look at the sample projects I’ve attached to those questions, you’ll be able to observe these bugs for yourself.
I tested the sample project you posted with your post and saw the issue with the default not changing with the actor already in the project. When I created a new actor and added the TestComponentA to it I did not have the same issue however. Additionally, seeing that your actor was setup in code it would be a better practice to define pointers to TestComponentA as well as TestComponentB in the actor itself. Then in the constructor you can set one of them as the root component and use AttachTo() to make the other a child in the hierarchy.