[FEATURE REQUEST] Set defaults and visually adjust components in the editor

Currently when creating components and making references in C++, you can either do it manually by entering coordinates and using the ConstructorHelpers. This is very tedious though, and it adds hardcoded references in code.

Another option is to derive the class in Blueprint, then set the references and adjust the components in the derived Blueprint.

However, you then have to make sure you instantiate your BP derived class and not your C++ class.
The approach is also flawed.

For example. Say you have a base class like:

UCLASS()
class AMyActor : public AActor
{
    GENERATED_UCLASS_BODY()
    
    UPROPERTY(EditAnywhere, Category = MyActor)
    class USoundBase* SomeSound1;
    
    UPROPERTY(EditAnywhere, Category = MyActor)
    class USoundBase* SomeSound2;

    UPROPERTY(EditAnywhere, Category = MyActor)
    class USoundBase* SomeSound3;
}

Now you could use the ConstructorHelpers::FObjectFinder struct to hardcode references to each sound in your C++ code. However, if someone decides to make another sound or, whatever, they’d need a programmer to change it.

In any case, I don’t really like to have content references in my code.

So another way you can do it is by creating a new Blueprint that derives from AMyActor, and then set the references in the derived Blueprint. Now you only need a reference to the derived BP in your code.

However, the problem with this is that you cannot derive a C++ class from a BP.

This means that if you sub class your C++ class, like so:

UCLASS()
class AMyActorSub : public AMyActor
{
    GENERATED_UCLASS_BODY()
    
    UPROPERTY(EditAnywhere, Category = MyActor)
    class UParticleSystem* SomeParticleTemplate;
}

And you want to specify that SomeParticleTemplate reference in BP, you have to create a new BP that derives from AMyActorSub, and thus have to specify not only the SomeParticleTemplate but also the SomeSound1, SomeSound2 and SomeSound3 references again.

So for each new sub class, or sub class of sub classes, you have to redefine all the content references. Which also means that if you need to change SomeSound1 for your actors, you have to do so in each and every BP.

If instead you could specify defaults and adjust components of C++ classes in the editor directly (Or something to that effect), derivatives in C++ would automatically inherit those.

Hi ,

Thank you for your feedback, we will take this into consideration. Have a great day!

Hi ,

You are right that adding hardcoded references to assets in native constructors is a generally bad thing which impacts the base memory footprint and affects initial load times. You’re also right that blueprints are currently the best way of achieving your goal. And when go on the Blueprint path you basically should create Blueprint classes derived from your base Blueprint classes. We’re not planning to add support for editing native class defaults in the editor because, well, they’re native and that’s the expected behavior when working with them and essentially we’d be doing some weird kind of a native/blueprint hybrid.

However, we do have plans to tackle the ‘long initial load times caused by native Class Default Objects references’ problem in the near future.

“And when go on the Blueprint path you basically should create Blueprint classes derived from your base Blueprint classes.”

As I explained in the original post, that’s the problem. If you have just one character with one behaviour, and you just need variations, using BP works.

However, if you have characters with different behaviours you can no longer just inherit your BP base class, as BP doesn’t support multiple inheritance, and thus for each C++ sub class of your character, you need a separate “line” of BP inheritance, and you lose polymorphism.

One C++ base character:

Multiple C++ character sub classes:

Yeah, I understand that. What I meant was that if you decide to go with the BP path, you basically have to create your specialized character types also in Blueprints (no C++, unless you work around that through C++ components).

Another approach would be to create a separate class just for content reference purposes and have that referenced in your character classes.