As a roblox developer I would like to ensure that all the data I’m sending a game is relevant/necessary, a lot of my games use local parts and in turn use physics associated with that, however after a little bit of looking, it turns out that despite being created locally the server is still receiving data for parts it has no reference to.
This is fine in small quantities, but I create things like ragdolls on the client, small projectiles, obstacle objects and physics based geometry (lifts, ect). I handle these on the client in some cases as I’m aiming for responsiveness, or to replicate an event from the server.
A locally created humanoid will send information to the server, despite the server not having a reference.
I would like to have the option to be able to disable sending this data over to the server. It has no reason or purpose of doing so. Either by keeping reference of locally created parts and nulling any information that will be sent, or by ignoring sending updates for children of a specific folder.
Yep, comparing with/without local physics of 1000 parts, I get 0.61 KBps out vs almost 300 KBps out with local physics. This is probably awful for mobile connections. At one point, I had ~0.5 Mbps up for my home connection, so the physics data being sent is 5x large than that. This would have killed my connection.
I disagree – a bool toggle is unnecessary. Local parts should never have their changes replicated to the server to begin with. The client should keep track of instances it’s created locally (if it doesn’t do so already), and never send physics updates for those parts because it’s never useful.
Thank you for the repro, I think the issue itself still stems from the lack of Local Parts being an official feature as opposed to a beneficial bug-feature.
I was not aware of local parts replicating physics; this should make for a great performance boost for some of my projects.
I think a good solution would be for the client to internally mark instances via its Instance.new as “NotReplicated” when FE is enabled; from there it could just check that internal tick before sending data from a part to the server. I say when FE is enabled because there could be trouble trying to figure out if something replicated in non-FE as it could always just be parented to workspace.CurrentCamera or some other non-replicating container.
I’ll have a look
Edit:
Had a look, the physics seem to jump to about 500 KB/s out every few seconds as opposed to 300 kbs out (using the repro @EchoReaper reaper provided)
