I got a Player Blueprint with 2 Child Actors. Often those two has to talk with each other, their variable values and all that. What I do is this.
In Child Actor - 1 -. I get owner, cast to owner, get it’s child actor -2- value, cast to that child actor, get its variable.
I can’t help but feel it’s abit wrong. I get no delay when the Pawn BP wants to talk with those child actors. But if one child actor wants to speak another, I get a milimilimili second delay which is kinda noticable as I use Paper2D and it’s related to flipbook changes.
I got my way arounds to not let player see the delay, but if there is any better way I would like to know.
So what do you do when you want to speak from Child Actor -1- to Child Actor -2-?
instead of casting every time they talk, why not cast only when your reference goes null?
you can cast and set the reference on begin play, then every time they talk, you check if the reference IsValid, and if its not, you cast and set the reference again.
as long as the reference variable is the same type as the thing you are talking to, you wont need to cast.
Yeah that’s what I do at the very beginning. I forgot to tell. I already cast once and use the reference for the entire game.
Though even if I cast once, I still see a milimilisecond delay. You could say “Why bother?” and I would say “I got a way around already but meh”, as this would be hardly noticable if it was 3d.
But I guess there is no other way than casting right?
There is a child actor for Flipbook of Character and it’s faked shadow. Shadow is another flipbook that mimics everything that Flipbook Child Actor does which holds the main character. Basically he does whatever Character C-Actor does so it looks like a simple shadow.
Though there is a milimilisecond delay where the shadow system responses late to the change of character itself. As it gets the character flipbook animation every tick to act like a shadow. It is not exactly noticable but always there.
I already combined them together so the problem is gone. Though this is just as given example, asking if I could do it better even when they were seperated or not. =)
when things are related closely, it makes sense to find a way to combine them, or control them through a common manager that they share, which updates them at the same time.
so instead of your controller’s InputState controlling your pawn, which controls his shadow, you can have the InputState control both the pawn and the shadow in the same update function.
