[4.9.2] Multicast: Attach ActorToActor has some ugly side effects

Hello,

I’ll try to be as clear as possible, since trying to solve an issue led me to find 3 more, i’m kind of a bit lost in that pool of problems.

So in this particular scenario, i have a Pawn with a ChildActorComponent (another blueprint), namely a BP_Turret. When I press a button, I spawn an upgrade (BP_Upgrade) that I attach to the turret (so i can move around with it).
The result : when I move, the Upgrade positions are moved somewhere else, some are still attached, some are not.

This is what happens step by step :

Client spawn some Upgrade

Then Server is doing the same (so far so good)

Client is pressing forward to move. Upgrades are moved somewhere else (looks like the pawn location…). This only happens on the client.

Server do the same, and everything is fine on his side. Client has wrong results

Client spawn more Upgrades then move around. One is prorperly attached, others are not…

Here is how I spawn the Upgrade (on server)

http://s20.postimg.org/4vp4ztnp7/Replicated_Child_Actor_Rotation_6_Script.jpg

The Turret Blueprint has default settings, it’s not set to “Replicates” as it would be even worst : A child actor component, when set to replicates, is duplicated on clients.

Is there anything I can do to fix that?

Hi Genova,

We need some more information to see what’s happening here. What do your BP graphs look like for these? Can you reproduce this in a small test project? If so, please upload it somewhere and we can take a look at that. Otherwise, please show us your BP setup, both the Component Hierarchy and each BP’s replication setting and graphs.

Hello Ben,

Yes this is already a gym to try to solve the issue I have.
here, attachedlink text

Hey Genova,

Thanks for the test project! I see the same behavior, and I’ve entered a bug report for the issue (UE-22392). I’ll let you know if I see any update on the report.

For now, you may need to explore different options. The easiest would be to use a separate actor for your turret, rather than a child actor component. In that case, the attached actors should replicate as expected (if you replicate the turret).

Thanks again!

Hey Ben,

Ok great, let me know when there are news on that matter.

I thought about having external actors for my pawn but I didn’t feel confident enough to try that solution. My pawn has a dozen of ChildComponent and that would make a big mess. Though if that is the way to work around that issue i’ll have some questions for you.

Assuming i’m not mistaken, to spawn an actor, you need to make it happen on the server. You fire a custom event “Run on Server”, right?

  1. What would be the best way to get the value returned by the SpawnActorFromClass to the appropriate client?
  2. Does the Ownership need to be manually specify using Set Owner ?
  3. I noticed the Ping has a lot of impact on how long it takes for a Client to see the actor he requested to spawn on the server, the result can be awful. Is there a way to solve this that i’m unaware of ? Like spawn locally so it’s instant, then spawn on server for everybody else?

Thanks Ben.

If you want to have an actor appear and function on all Clients, you would want to have it spawned on the Server and replicated to all Clients. So yes, an RPC set to Run on Server is how you would do that. As long as the actor spawned is set to Replicate, it will then appear on all Clients.

  1. Easiest way is to create a variable for the spawned actor and set it to Replicate. Since you’re calling it on the Server’s instance of the spawning blueprint, that variable will update on the Client’s instance.
  2. Yes. Ownership is usually reserved for the Client’s Player Controller, Character, and Player State. Anything else you would need to set ownership on if necessary. That said, if you do all of your Run on Server RPCs from the Client’s Character or PC, it’s likely this won’t actually be necessary. Have your Actors call Events or Functions on the Character, which can then do an RPC from there.
  3. You’ll want to limit the amount of Reliable RPCs whenever possible. You can use the Network Profiler to identify the largest loads on your networking and try to trim them as much as possible. Definitely do not replicate anything on Tick. Otherwise, spawning locally and then from the Server may be a viable solution, but it could be extremely messy (multiple instances on the Client, more BP communication than was previously necessary, lost information between BPs depending on the situation, etc).

Hey Ben,

Thanks for the answers. This is pretty much the methodology I was using.

Though i’m a bit disappointed with the spawn system. I agree spawning locally then on the server will be a total mess, the real and only way then is to spawn a ‘replicatable’ actor on the server. But as I’ve experienced, if the ping is say 200+, you’ll get quite a delay before seeing an actor spawning. I wonder how a game like UT handles that kind of things, since you need to immediately see your rocket when firing it.

I thought about a solution though, but I think it’s gonna be a bit tricky. It involves pre-spawning actors to have them immediately ready for action when requested. It will requires a lot of logic depending on the complexity of the actor but I believe it will be an efficient method, in the absence of a better way.