Hi, so when one actor spawns, it has to send some data to the other actor. But what if the other actor didn’t spawn yet? Once it spawns too, how can it get the data from the “sender”?
What I’m asking is, what is the best way to achieve this (best practices)?
Thanks.
1 Like
I’ve found that you can just decide which goes first. Even if they are identical blueprints, you can give each an ID, and decide the one with ID = 0 always goes first.
On begin play, the one with ID = 0 send the info, all the others ID > 0 just wait.
1 Like
Thanks. The problem is I can’t decide that. These actors will spawn at different times throughout the game. In no particular order.
1 Like
Can you give a likely scenario / example?
1 Like
So I have a fuel tank (one actor), and a gauge (the other actor).
If the tank spawns first, there’s no gauge to tell how much fuel there is.
If the gauge spawns first, there’s no tank to get the fuel amount to show.
Assuming they both run the code on begin play.
1 Like
If this is meant to be one thing, then just making it one blueprint is easiest.
If they are supposed to appear at different times, then you need to write them to take this into account.
So the gauge checks if the tank is around. If not, wait, otherwise start working.
The tank, just spawns, because the gauge will find it.
1 Like
But what’s the code though? How do you “wait”?
1 Like
Literally a delay loop. It tries to find the tank, can’t find it, wait 1 second, go back and try again…
1 Like
Thanks, I was hoping I can avoid looping functions.
1 Like
It’s not a problem if the delay is not tiny, and it will end.
1 Like
I can show you how to avoid the loops, but I need to do an example, a bit later…
1 Like
So, the way I’ve done it is through a mediator. That’s an actor both gauge and tank will always be attached to, so will always be present for both.
I’ve put event dispatchers in the mediator which both actors call when they come online.
What do you think?
1 Like
You could do that. Trouble with dispatchers is you need to know the class you’re binding to.
I was going to show you a global event system, which works without knowing the class of actors. Will be at another machine soon…
1 Like
Wow, that sounds great.
1 Like
Ok, so you use the game instance to keep a list of signals in a map like this
It’s just a map from ‘name’ to ‘actor’.
The gauge now does this
and the tank
You can generalize it, so that a list of actors can wait for one signal, and you can send data also etc.
You can also create a sort of ‘buffer’ in the GI to avoid the ‘get actor’ stuff, but that’s more fiddly…
PS: Corrected it.
1 Like
Thanks a lot. That’s great.
What if I send the actor object instead of string, as the map key? That would avoid “Get Actor Of Class”, right?
1 Like
I prefer Timer based polling.
Could actually put all of this in an Actor Component, then nuke the component when it’s done what it needs to.
1 Like
Thanks. Is there a benefit over the previous method? Isn’t running code every second a bit less efficient?
Method without actor of class coming…
1 Like
Mine is based on the presumption that the “other actor” will be spawned soon.
If the gauge is always spawned and the tank is sporadic then put the polling in the tank actor and have it poll the gauge.
Sounds like you are doing a vehicle modification system. Swapping out parts. If so I’d have a core component (Actor component) that all spawning in parts reference, then the AC would get/set data based on what contacted it. Versus having components like a gauge checking for a fuel tank or vice versa. That’s just me though.
1 Like