Properly using NewObject

Hi guys,

I have a UObject-inheriting class here:

11497-ghsdgdghh.jpg

As you can see, I have an implementable event there. My idea is that I inherit several classes from this one using blueprints, and implement this event differently in each of them. So, I created a function that accepts a subclass of this UTalent class, creates object of this subclass and calls its ReceiveInit function:

11499-sdcfasdfl.jpg

However, when I create a Blueprint which inherits from UTalent, and call this AddTalent func from blueprint, passing the created blueprint’s class as argument, the ReceiveInit is not being called.

When I dug deeper, I found out that my way of using NewObject, apparently, creates simply a UTalent object, instead of instance of my blueprint’s class. I found it out simply by changing some properties in inherited class. While debugging AddTalent func, I saw that talent object has same property that were set in UTalent class, and not the ones in my blueprint class. So, am I using the NewObject wrong, and how to properly create an UObject using a TSubClassOf thing?

To clearify things a little bit, here is a blueprint class that I inherited and my call to AddTalent func with that class as argument (which apparently still creates an UTalent object):

Try ConstructObject insted of NewObject

This anwser is outdated use NewObject(SomeParent_CanBeSimplyThis,UClass*)

WORKS! Thanks, man. Always thought that ConstructObject is just a slower and more specific way of creating uobjects.

Ok converting to anwser then :slight_smile: ConstructObject is equivlent of SpawnActor, i find it out by lurking in engine source code so it ok to use it

I see now that ConstructObject is being deprecated in v4.9. What is the correct method then, when ConstructObject is not available anymore?

NewObject ;] now it works ok

Is NewObject still fine? In 4.10.1 i found that ConstructObject is ok, but NewObject is still always creates objects with basic type ignoring TSubclassOf<> argument.

What do you mean by “basic type”?

I mean that (according to Lordink code) basic type is UTalent and we are trying to create some object of derived class (BP_Talent for example). So variable TalentClass is TSubclassOf and it’s value is BP_Talent. After calling NewObject(TalentClass) instance of UTalent will be created, not BP_Talent.

Yep, i’m calling it like this. Thanks, understand UClass* limitations

You calling it like this?

NewObject<UTalent>(SomeBlueprintClassVarableYouUse);

Also one note TSubclassOf is UClass* template type, it only limits selection of classes in editor to specific relation

Ah i forgot, first argument of NewObject is InParent so you need to call it like this

NewObject<UTalent>(this,SomeBlueprintClassVarableYouUse);

“this” will become owner of object, it should not have much effect on it i think so you can place whatever you like on it, you might try placing “nullptr” here if you want. I can’t find NewObject in API refrence to show you that, but it should work

Brilliant, thank you, problem was fixed :slight_smile:

Since this question was initially posted, ConstructObject has been deprecated and you should now always use NewObject. You need to be careful with the arguments though. The first argument is the object to use as the outer (think of it as the owning object) for the newly created object. If you want to specify a particular class to use, pass that as the second argument.

The overloads are not ideal - UClass is actually a descendant of UObject, so if you pass a UClass* as the first argument, this is an acceptable outer, and since the rest of the parameters have defaults, it will compile, but it won’t be doing what you intend.

Note that this question is old (1.5y actully) back when everyone was using ConstructObject

True, though it’s worth having it updated if people still find it when searching. Updated my answer to reflect that there was nothing wrong with your original answer.

Do we have to use RegisterComponent afterwards if we create a component object? And UnregisterComponent?

1 Like