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:
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):
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.
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.
“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
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.
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.
ConstructObject is equivlent of SpawnActor, i find it out by lurking in engine source code so it ok to use it