I’m experiencing an incredibly frustrating bug, where the creation of a new replicated actor does not replicate to all the connected clients properly. I’ve ran multiple tests, and can only recreate the bug when I have 6 clients connected to 1 listen server. Not 5 clients. not 7 clients, not 8 clients connected to a dedicated server. 6 clients connected to 1 listen server. The bug is that the actor (in this case a bullet) only replicates to a subset of the clients. Given client # 1, 2, 3, 4, 5, and 6, shooting the bullet would only replicate to client #4, 5, and 6. Then on the next bullet creation, it might only show up for client #1, 2, and 3. The subset of clients is always the same. It will either replicate for client #1, 2 and 3, or for client #4, 5 and 6. It seems to be random which subset it replicates to. I suspect that it is telling that the subgroups are in order of client #1,2,3, and client #4,5,6.
The replication of the bullet is setup as follows:
If I change the Net Update Frequency to 100.0 instead of 60.0, the problem seems to be sort of fixed, but instead of randomly trading back and forth which aforementioned subgroup fails to receive replication, one of the subgroups will receive replication at a sizeable delay (33ms or so).
Its worth mentioning that I can recreate this when 5 out of the 6 clients are in spectate mode, with no other network traffic other than the shooting players movement and the creation of the bullet. Also worth mentioning that it doesn’t seem like a bandwidth overflow issue, as if I were to spawn 7 clients instead of 6, the problem does not occur.
Can anyone help me out with this one, its driving me insane, and I can’t figure it out. Thanks in advance for your time and help.
edit oh, this is an important detail. The bullet class that this occurs to has only 1 replicated variable (a starting state struct). There exists a subclass of this bullet that also includes an RPC to let the server tell the clients when the bullet should returns back to the player who shot it (based on input from that player). With this subclass of the bullet, the object will successfully replicate AFTER the moment of calling that return RPC ( a second or 2 after it should have, on creation ). So there is some mechanism somewhere that has replication failing, but then it picks up the slack if an RPC is called.