Spawned actor doesnt equal the parent class

[Kibbles26]

Hey all,

I have created interaction with my character to pickup items.
But when I get the hit actor and check if it equals the parent class of those items, the spawned items do not, whereas the items placed manually do.

Any ideas why?

[Leomerya12]

Hey, Kibbles,

Could you please post photos or a video of your issue to disambiguate it?

[SupportiveEntity]

Hey there @Kibbles26! What class does the instantiated actors take on? How does that compare to the expected parent class?

[Kibbles26]

So the spawner spawns an actor from an array

The spawned actors are children of this parent

Inside the character when I interact to pick up the items, I want to play the montage if the item is from that parent class.

This does not work if the collectable child is spawned from the spawner, but if placed by hand it works.

[Kibbles26]

Hey,
The spawned class usually gets spawned as BP_Collectable_PC0, instead of BP_Collectable_PC.

Could this be the problem?

[Leomerya12]

The reason I asked you to expose your work is because when an object is a child of something, it gets renamed, even if it has its own class.

So, if, for example you have the object: SM_Cookies.
If SM_Cookies is added to a blueprint, then it becomes BP_SM_Cookies, even though it’s still, technically SM_Cookies.

You’re going to have to reference it another way. I haven’t looked closely at your BP functions yet to suggest a route. But I will, if no one else beats me to it.

EDIT: I see you’re not comparing classes. You’re comparing actors. You can try getting the CLASSES of those actors (should be purple) and comparing those.

[SupportiveEntity]

Leo is correct again, you are comparing the display name and not the class. You’d use the Get Class node to compare the classes. For example this compares one object’s class with another and then if it’s the same class, outputs true:

[Leomerya12]

Thank you for visually posting the solution!

I’m getting dead-head (or whatever it’s called when a programmer is burning out) lately.

[SupportiveEntity]

No worries, we all have that feeling sometimes! You had the correct solution anyway. I’ve just been increasingly following up description based fixes with visual aids because a user recently thanked me for it and highlighted how much it helps even if the description is extremely accurate for less experienced users.

[Kibbles26]

Sorry for the late reply! Time zones are very different.

Thank you for the visual! I will try comparing the classes instead of the actors.

Appreciate both of your help!

I will reply after my testing soon

[Kibbles26]

So added the get class and compared them, but still doesn’t work. Not sure why though. They all have the same parent class.

[SupportiveEntity]

Oh I see, apologies I realized blueprints function a bit differently than C++ in this regard. It looks like there’s no blueprint native way to quickly compare to a parent without some consideration such as casting.

1. ParentClass
   a. ChildClass1
   b. ChildClass2

In this hierarchy, if you search for all classes using a get all actors of class ParentClass you’d get all 3 returned, however if you get all actors of ChildClass1 it will only return the ChildClass1.

However, the difference that I was unaware of in Blueprint is that while GetAllActorsOfClass does compare to parents correctly, direct comparison does not because there’s no implicit factor here. The least roundabout method to compare to the parent class is to cast to it, or if you don’t want the BP locked in memory, you could just run a function on it that’s from the parent. Below are some quick tests I did to verify.

---

My test:
First testing if direct comparison to classes already deemed in engine to be of ParentClassTest

It finds all classes that have this as a parent and classes that are the parent, however when compared they are not equal. Purple is true, orange is false.

Then testing if the cast worked appropriately, and it does:

[Kibbles26]

Thanks for the insight. That is really insightful!

So I actually was able to get the desired result a different way.
At first I was just using 1 interface for all interactable actors, but was able to get the parent class to equal properly.
So instead I created another interface. So one for pickup items and another for the doors. This way I can choose what happens with each interface more easily instead of trying to compare the actors. Perhaps this is a more efficient approach as well?

[SupportiveEntity]

Oh good call! That’s correct, a function or interface unique to the class of items should be more performant as it doesn’t force the loading of the BP. The other option with as much setup would be tagging, but I think an interface is cleaner here for sure.