Is there a way to force something to not replicate? Network optimisation

I’ve got a bit of a network optimisation problem. In my game, I’m using server-side custom humanoid type things as enemies, and I’m using BodyMovers to move them. I have three bodymovers in each enemy, and I’d like the game to be able to handle quite a lot of these, at least 30, with a decent amount of players. Most importantly, it needs to run smoothly. Right now, it isn’t.

It’s working well (the physics-based custom humanoid) with just players. This is, I think, because I’m not replicating all of the values the BodyMovers have when they update. Instead, it just replicates the fact that there is a bodymover and that it is moving etc. and it works out fine.

On the server however, there is no option to make these bodymovers not replicate to the client, as far as I’m aware. Deleting them when they load on the client doesn’t help, since the data is replicated regardless. Not sure what to do here - if you have any ideas or suggestions please tell me!

4 Likes

Stick whatever u want to still physically simulate serverside in the server camera. That’s all that comes to mind.

1 Like

Just tried this and… it’s weird. Something still replicates, but the client receive stats went down a lot. I’d have to do a pretty big workaround to get this to work nicely though, and it feels like a bit of a hack. Not sure if I will do this, but it’s pretty interesting at least.

EDIT: Although, this does give me an idea. Maybe I could put my bodymovers in a different NonReplicated object? I’m just guessing at this point, but I’ll have a look around.

Also, I do preferably want to replicate the actual object which is moving. It’d be nice if this sort of thing was supported by Roblox, but I don’t think it is. :frowning:

Try deleting the objects on the client. It may or may not improve your network performance, and it may or may not just create the objects again, but it’s worth a try.

game:GetService("ReplicationService"):SetCanReplicate(Object, false) pls! I think it’d make a nice feature request.

7 Likes

The reason I picked the Camera is that afaik it’s the only physically simulated object I know. If you don’t care about physics interactions in the workspace, ServerStorage would work obv.

Already mentioned that I’ve tried this, and it doesn’t help :frowning:

And yeah @Kiansjet I don’t know if I want to do that. It’s pretty undocumented and probably unintentional.

1 Like

Still can’t find a good solution to this. I guess I’ll make a feature request, but that doesn’t solve my problem unless it gets thought about and released sometime soon - and that’s not going to happen.

If anyone has any other ideas on how to not replicate specific objects or properties, I’d love to hear it. I’d hate to think there isn’t some solution to this which doesn’t rely on something like putting the objects in the server camera.

The camera intentionally doesn’t replicate. This behavior is documented in the devhub too…

I know it intentionally doesn’t replicate, but if they intended for it to be used for simulating physics and stuff, surely they would have a better name for it or some documentation?

I’m not sure what documentation you’re talking about - you don’t mean this, do you?
image
That’s just saying it has a certain property - doesn’t mean you should rely on it. In fact, I’m not even sure why there is a server-side camera in the first place.

3 Likes

Made a feature request anyway. Hope I figure this out sometime soon… don’t really want to have to just put up with the performance this brings.

glad you posted this, needed something like this for a while. controlling what the server replicates right now is pretty much impossible without a custom replication system.

3 Likes

Had to do this as an anti-exploit feature in my game, to prevent exploiters on enemy factions to get intelligence on the other teams. No solution. It would also help with performance!

I feel like this is a much needed feature. I also can’t rely on the client to delete the parts because the localscript is on the client and could be bypassed or disabled entirely.

Edit: Didn’t see this was from two years ago. Still a problem now.

3 Likes

Ideally we should get instance level control over replication. So that players can write code like:

local function PlayerEnteredZone(Player, ZoneId)
    local OldZoneContainer = GetZoneContainer(Player.ZoneId.Value)
    -- Disable replication of this instance + descendants to this player.
    -- On the client this instance would effectively be :Destroy()'ed and non-existent.
    OldZoneContainer:Replicate(Player, false)

    local ZoneContainer = GetZoneContainer(ZoneId)
    -- Replicate this instance + descendants to this player.
    -- Client would see this as a new instance being added to the datamodel.
    ZoneContainer:Replicate(Player, true)
    Player.ZoneId.Value = ZoneId
end

Isn’t that a nice dream?

7 Likes

I tried the server side camera work around, and although it works well while in Roblox Studio once the game is published and I join it from roblox.com it chucks an error. I assume this is because the server side camera doesn’t exist or can’t have children on the non-studio version. In my case ServerStorage will work, just wanted to put this out there so no one gets their hopes up. I can’t believe this is still a problem almost 5 years later.

As you mentioned that replicating BodyMovers values to the client can cause performance issues, you may consider reducing the number of BodyMovers you use, or optimizing their movements. You can try using physics simulation sparingly and making use of inbuilt Roblox character animations where possible, as animations are less expensive to replicate over the network than physics simulation.

You can also consider using prediction techniques to reduce the effects of network latency on gameplay. This can involve predicting the movements of enemies and making corrections to their positions as necessary. Additionally, disabling unnecessary features on clients can help reduce network traffic and improve performance. Finally, you may try implementing a load balancer to divide the server load between multiple servers, which can improve game performance and avoid server overloads.