It might be intended behaviour, but it is not something I expected when first using it. So:
-
I have DefaultAbility blueprint class.
-
Now in MyCharacter blueprint I create object out of DefaultAbility.
-
Now I use my new object with EquipAbility function defined in C++:
void ARPGCharacter::EquipAbility(ARPGAbility* ability)
{
if(ability)
{
SetCurrentAbility(ability);
}
}
It looks like this.
When debugging the ability pointer is null. Which I assume means that the object I create is just empty and doesn’t spawn the defaultability by default after creation.
The blueprint works fine when I use Spawn Actor node. Either alone by directly plugging it into EquipAbility node, or with combination with my DefaultAbility object variable (by using set, and then get to plug it into EquipAbility).
If that is intended behaviour, did you guys considered spawning an object by default, or there are reasons for not doing so ?
Automatically created ‘default sub-objects’ are supporting in native classes, but not in Blueprints. It is very tricky to get right and has several caveats that we did not want to expose Blueprint authors to. We are working to support ‘custom structs’ to Blueprint authors though, which will let you define a new struct and then ‘embed’ that in your Blueprint as a variable, and pass around as a single entity (like a vector, color etc)
“2. Now in MyCharacter blueprint I create object out of DefaultAbility.”
Cany ou clarify this step?
I can provide C++ code to do what you are asking very easily,
but if you need to use blueprint please show your setup and what yuo mean by “create object”
Rama
Red is what I mean.
Blue is how to make the setup work.
I could also do it in C++, but that is besides the point. I want to do it in Blueprint, and use C++ only for creating bricks for later use (;.
You’re not creating anything with that setup
ARPGAbility* is the type of that variable.
That’s just a pointer!
You need to spawn the actor and then assign your blueprint variable to your spawned actor so that the pointer reference becomes valid
The Blueprint +V doesnt create objects, it just creates variables.
If your data type extends a UObject or a AActor, you are getting a pointer when you create a new variable with +V, not a hard data type like if you create an FVector.
#To Answer Question
“If that is intended behaviour, did you guys considered spawning an object by default, or there are reasons for not doing so ?”
I cannot answer for Epic but I can tell you, if I were spawning automatic Actors or Objects every time I made a variable to a UObject or an AActor, I would have no way to just create references to UObjects and AActors and that would be very disorganizing
Hope this helps
Rama
Well yes. But the new Blueprint update was supposed to resolve the issue about creating objects directly out of blueprint classes.
I might have understand something wrong, but I thought that mean we can create an real object directly, without using Spawn Actor node. Just like in C++ when you can do something like this:
MyObject object = new MyObject();
or
MyObject* objeect = Get(FromSomwhere);
or
Any other possible combination for creating object.
I hope you got my point (;.
Now aside that I can create object of type of my Blueprint class not much changed, because I still have to call Spawn Actor node to actually assign object to it (hah how it sounds :D).
But it seams we just create empty pointer to blueprint class.
I cannot answer for Epic but I can tell you, if I were spawning automatic Actors or Objects every time I made a variable to a UObject or an AActor, I would have no way to just create references to UObjects and AActors and that would be very disorganizing
You actually might be right, but it still desirable behaviour for me. Maybe small checkbox, to whether spawn object by default or just leave it as empty variable ?
“You actually might be right, but it still desirable behaviour for me. Maybe small checkbox, to whether spawn object by default or just leave it as empty variable ?”
That’s an interesting Idea!
I will leave it to Epic at this point,
nice to hear from you Lukasz!
Rama
