Creating BaseParts on the client and locally simulating physics sends physics replication for those BaseParts to the server despite the server having no concept of those particular BaseParts.
This adds tons of unneeded overhead and clogs the network with useless packets and can delay more valuable packets.
This is very easily reproducible 100% of the time, and I have provided a file to do so below.
Iâd have to check but this might be something Iâve experienced as well when using a lot of parts and physics. Posting here to help this gain attention.
I think this is partially due to the fact that the engine has no knowledge that the part was created locally, and such is not replicated, meaning it will send physics data over the network regardless.
I assume a fix would be extremely easy here, just tag the part saying it was created locally.
Its probably just an artefact of Robloxâs RCC client from when before FilteringEnabled was added.
Hey boatbomber, thank you for the report and repro! Youâre right these updates are pointless and use up bandwidth, this looks like a simple fix (we already do this when streaming is enabled). Iâll update when itâs fixed, or if thereâs some problem preventing it from being fixed.
I merged in a fix for this yesterday, will edit this post when itâs enabled (should be next week).
Edit: There was a bit of a delay waiting for all platforms to get the fix, but it should be live everywhere now.
This specific issue was fixed, I just double checked to make sure.
You can take a look at some network stats in Studio by going to View > Network (far right side of the View section). There should be four categories (Data, Physics, Touches, Clusters). In which category are you seeing the 20kb/s?
The client isnât doing any cloning in your example â the server is. The client just reparents the models to be under proxy.Parent, but never actually makes a local copy. If you want a local copy Iâd probably change this line local model = game.ReplicatedStorage.clientmodels:FindFirstChild(modelName)
to: local model = game.ReplicatedStorage.clientmodels:FindFirstChild(modelName):Clone()
See the 61 parts inside of âPartsâ? Those are all inside of ReplicatedStorage! Theyâre the only parts in the scene besides the spawn and baseplate - the game isnât even executing. Not sure this is what was intended for that counter - maybe itâs indicating something is happening that shouldnât be?
Itâs a bit complicated since the model that was reparented isnât actually local so the client doesnât know it shouldnât be sending physics updates. We donât have any immediate plans to change that behavior, so if youâre worried about Client â Server bandwidth then I would suggest creating a local copy (with :Clone()).
Your second screenshot is not a bug, that counter tracks how many parts there are in the DataModel (i.e. everything under game), not just the Workspace.
