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 turret (so i can move around with it).
result : when I move, Upgrade positions are moved somewhere else, some are still attached, some are not.
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.
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 Component Hierarchy and each BP’s replication setting and graphs.
Thanks for test project! I see same behavior, and I’ve entered a bug report for issue (UE-22392). I’ll let you know if I see any update on report.
For now, you may need to explore different options. easiest would be to use a separate actor for your turret, rather than a child actor component. In that case, attached actors should replicate as expected (if you replicate turret).
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 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 server. You fire a custom event “Run on Server”, right?
What would be best way to get value returned by SpawnActorFromClass to appropriate client?
Does Ownership need to be manually specify using Set Owner ?
I noticed Ping has a lot of impact on how long it takes for a Client to see actor he requested to spawn on server, 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?
If you want to have an actor appear and function on all Clients, you would want to have it spawned on Server and replicated to all Clients. So yes, an RPC set to Run on Server is how you would do that. As long as actor spawned is set to Replicate, it will then appear on all Clients.
Easiest way is to create a variable for spawned actor and set it to Replicate. Since you’re calling it on Server’s instance of spawning blueprint, that variable will update on Client’s instance.
Yes. Ownership is usually reserved for 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 Client’s Character or PC, it’s likely this won’t actually be necessary. Have your Actors call Events or Functions on Character, which can then do an RPC from there.
You’ll want to limit amount of Reliable RPCs whenever possible. You can use Network Profiler to identify 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 Server may be a viable solution, but it could be extremely messy (multiple instances on Client, more BP communication than was previously necessary, lost information between BPs depending on situation, etc).
Thanks for answers. This is pretty much methodology I was using.
Though i’m a bit disappointed with spawn system. I agree spawning locally then on server will be a total mess, real and only way then is to spawn a ‘replicatable’ actor on server. But as I’ve experienced, if 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 complexity of actor but I believe it will be an efficient method, in absence of a better way.
