Physic Replication Bug: "Camera Hack" does not work in all circumstances - some data still replicates when using certain instances

[MrChickenRocket]

Physic Replication Bug: “Camera Hack” does not work in all circumstances - it still causes some data to replicate when using BodyPositions, Humanoids, and other physics interacting instance types.

Backstory:
Right now there is a rather useful (but extremely janky!) hack called the “Camera hack”.

With this hack developers can parent fully simulated server instances underneath a camera, and this prevents those instances from producing any replication data to clients, while still allowing the instance to function on the server. Eg: a ball will roll, but it won’t send any visual or physics data.

This is used for a host of reasons, including allowing custom replication.

The bug:
This trick only seems to work for raw, unadorned physics objects. Attaching things like BodyMovers to instances parented under the camera causes replication data to be consumed by the client, even though nothing is being actually sent.

Affected instances:

• Humanoid
• BodyPosition
• BodyAngle
• BodyVelocity (and family)
• AlignPosition (and family)
  (and possibly a bunch more)

Setup: a camera with a bunch of unanchored balls inside

What the client sees:
Notice there are no balls, and also no replicated data cost on the client. However the balls are still happily rolling around on the server

The bug: After adding a BodyPositions to one of the balls, its starts sending out replication data (3kb/s).

Expected behavior

(I mean ideally the camera hack would be replaced with selective replication… but alas!)

What should happen is any instance underneath a camera should never, ever, be able to replicate any data.

[MysteriousVagabond]

I want to piggy-back onto this since I just discovered the issue in my own work today and have some more conditions in which this occurs.

In my setup, the client and server are running parallel simulations, and none of the objects are replicated between the environments. The client’s objects include Attachments and Welds, whereas the server just has the parts. Both environments have connected to the Touched and TouchEnded events for the parts.

What I’m seeing is a huge spike in network traffic; specifically, both environments are attempting to replicate general physics and touch physics packets for their respective objects even though neither environment actually has parts to receive the packets with. If I just launch the parts into the void, server-to-client physics packets are still being sent, but client-to-server seems pretty quiet.

Edit: What I’ve realized I’ve failed to really emphasize is that the issue seems to be even more ubiquitous than the Camera case. Specifically, client-created parts are never replicated regardless of where they end up under the DataModel, and yet the client will attempt to send physics updates to the server regarding them. It isn’t uncommon for the client to use the physics engine to execute visuals using locally-generated parts, and this issue adds an undue cost to that practice.

[asdfiji123]

Hey there - we recently released a fix for this issue. Physics should no longer replicate if the part is not being replicated (e.g. if the part is parented under a Camera). Please let us know if this problem persists!

[MrChickenRocket]

I’ll be sure to test it out! This is an extremely powerful optimisation tool.

[MrChickenRocket]

The problem appears to be resolved!
I tested entire humanoid rigs running around and some bodyPosition parts, and it’s all clean.

Thank you!