I’m just wondering what if any drawbacks there are to using child actor components? I just started playing around with them and they seem really awesome, which makes me suspicious about why I can hardly find anyone talking about them. They seem to be just the sort of nested blueprint feature that I’ve seen several threads saying you can’t do. It seems you can use them for any blueprint, place them however, get their variables, call functions back and forth no problem, and even change the child blueprint on the fly. I read about some bug with setting their visibility, but I tested that and it seems to be fixed now.
So with all this too-good news I’m wondering if there’s any serious issues with them, before I start building significant chunks of my game with them.
Thanks for any inputs!
I used them once for a gun that my player wielded, and they worked fine for me, though that was in the 4.7/8 days. The reason a lot of people probably haven’t used them is that there rarely is a need. I personally have never seen a need to use a child actor after I made my initial gun, as I just spawn & attach things in order for them to be completely dynamic.
Ahh, that’s true. Hmm. I guess then the only real benefit to them is that you can place them as you like in the editor. The on-the-fly actor switching could be useful too, rather than having to destroy one actor and create another, but no big deal.
After a bit of fiddling, I found you can get a reference to the parent actor from the child, by doing Get Attach Parent on the root component, Get Owner on that, and then casting. So it’s pretty easy to communicate between the actors in either direction.
Anyway, cool! Thanks for the input, my suspicions are soothed . . .
There’s also the fact that you can’t click them in the main BP’s viewport and move them. You have to actually click to component in the tab before you can move them. Strange.
Well, the by far biggest problem is that you can’t configure them because their class default are not shown inside the editor. You have to expose their variables to the parent by hand and then change them from the construction script.
You also have to create a variable for every child actor by yourself and then pass the result of childActor.getChildActor() by hand and also cast it first.
This + binary assets (hell!) are IHMO the biggest issues with Blueprint right now.
@ - Ah! I can’t believe I didn’t notice that myself, I just thought I was really bad at clicking. That is quite annoying. I think I get why it happens though. They behave like scene components, since there’s no way to select those or make them visible, right? I’ll submit a bug report/feature request for it though.
@ - Ahh, yeah. So you’re saying that you wish they worked that way? I guess I never expected to be able to do that. Though I agree, they’re not components, but I wish they were. It’s unfortunate that you can’t make custom blueprintable components with their own meshes, etc. Does anyone know how difficult this is to do with C++?
They seem to be just the sort of nested blueprint feature that I’ve seen several threads saying you can’t do. It seems you can use them for any blueprint, place them however, get their variables, call functions back and forth no problem, and even change the child blueprint on the fly. I read about some bug with setting their visibility, but I tested that and it seems to be fixed now.
That is quite annoying. I think I get why it happens though. They behave like scene components, since there’s no way to select those or make them visible, right? I’ll submit a bug report/feature request for it though.