Is there a definitive way to have a component of a component in c++?

I am working on creating a variety of nested functionality through components and per-wrapped component trees. For example, I want a component that can bring in a box collider and a text render in the same component.
Which would look like something below with variable complexity.
Actor->[MyCppChildComponent->BoxCollider->TextRender->MyOtherCppChildComponent->etc]
Where everything inside of brackets is handled in c++ and the actor only needs add the component to access all of the functionality exposed, as though the components were all attached in the actor c++/blueprint in a tree, and lots of functionality written into the BP/C++. This seems to me like it could be a modular and elegant way of doing things, but.
I cannot find any engine code component examples of doing this, and every attempt i make winds up causing a multitude of problems for the engine.
Is this simply something UE4 has other ways of doing?
Am I once again treading where Epic’s engineers fear to tread?
Is there a way I can get a definitive slap in the face that says: “No! Bad Spiris! This is how you do it…”?

components cant own a tree of components

That is not entirely true. USceneComponents can have children. Though scene components are expected to display some type of mesh in the world, they needn’t. Whether it is good or bad design is an entirely different question. Different choices can be good or bad in different (project-) settings.

You might want to get into scene components. Those can have child components, which have children added, removed, and modified in the level editor. However, scene components are designed to display some type of scenery in the world, though they needn’t. You must just make a design choice which consists of trade-offs that are specific to your project. Remember though that in engineering there is never the best option: it is always about the trade-offs. So good luck to you.

components cant own a tree of components

Why is this not explicit? I understand why you say this (the evidence is almost unanimous in engine) But the basic SceneComponent breaks this logic anyway, having UBillboardComponent* SpriteComponent as a member.

any time you have a long list of components required for your system to
work, it should be an actor, rather than a component. components generally
shouldn’t rely on other components in order to function.

This is extremely limiting. There are many different types of actors that might be made, and to have to add all the components, bind all of the logic, and prime all of the pumps over and over and over again… it is less than ideal.
If there is anyway around this limitation, i would love to hear it.
Thank you so much for your answers, they have all been very helpful. Good to be on the knowledge bus.

Nothing stops you from referencing components in your own components. In fact it is something that several components in the engine do, too, such as in your example.

I wish to point out to you though that your level designer’s need to be able to configure your components. If there are a lot of components, and they are difficult to find as well, then they might have a hard time configuring them. Often in this case, you need to make choices that are not the most efficient code- or design-wise but make it easier for your designers.

Good luck

“SceneComponents have a BillboardComponent member.”

thats an interesting example, ill have to look into how that is done. maybe it involves Actor setting that up, because i don’t usually see components making components.

Hello Spiris,

USceneComponents can have other USceneComponents attached to each other as children; those children can be modfied in the details panel of an object.

The Unreal documentation describes them as:

A SceneComponent has a transform and supports attachment, but has no rendering or collision capabilities. Useful as a ‘dummy’ component in the hierarchy to offset others.

In the link you can find methods for modifying children. The most important you will be using are GetChildrenComponents and AttachTo.

In the approach you mention, it makes sense to define some public interface for all components that you want to be using in a modular way. However note that scene components generally speaking are supposed to show some scenery. As you are trying to add configurable modularity to your project: I once had the same task at hand and I can provide you with a way I solved it - below.

You create one actor component that adminsters the entire system you are currently implementing; let’s call it UMySystemComponent. To it you can add modules. When an actor wants to use your system, you add the component to it and add specific modules. To define a module let’s create a class, I will call it UConfigurableModule for reference, that defines the basic interface required by any module, for instance a UFunction named Callback(); UConfigurableModule should inherit from UObject from a design perspective but due to engine bugs (which I reported here) it must temporarily inherit from UActorComponent until it’s fixed. The class specifiers of UConfigurableModule shall be Blueprintable, BlueprintType and EditInlineNew. In UMySystemComponent, add a TArray as property and make sure it has the specifiers EditAnywhere and Instanced. Now, your level designers can specify classes for components in your UMySystemComponent and configure their propertiers right in the details panel of UMySystemComponent. Da-da

Cheers,
Univise

An elegant and effective solution! I am compiling my notes on the topic now, maybe I will post a google doc about the knowledge I have gained. Thanks Univise.

Isn’t AttachTo deprecated?