Touched Events Are Always Networked

[MysteriousVagabond]

Bug

Physics touches for owned assemblies are always sent over the network, even in cases where the objects they pertain to are non-replicated. This cannot be prevented by destroying the underlying TouchTransmitter object.

Reproduction

Attached is a small place file to demonstrate the issue with some controls to affect the environment and observe the results.

TouchInterest_BugReproFile.rbxl (52.5 KB)

1. Open the place file and click “Play.” Initially, there should be no abnormal network traffic.

2. Step on either the green “Spheres .Touched” or red “Pad .Touched” buttons to cause the .Touched events for the respective objects to be connected to. These connections are made, and the created TouchTransmitter is immediately destroyed.

3. Observe heightened network traffic. If the client is the creator, this traffic will be outgoing. If the server is the creator, this traffic will be incoming.

Expected Behavior

Because the parts are local to the environment that created them and they have destroyed the TouchTransmitter object responsible for networking physics touches, there should be no networking traffic related to the physics interactions of the parts.

Actual Behavior

Physics interactions for the affected parts is communicated to other environments. This creates a great deal of network traffic–so much so that stepping on the buttons in the example place had to be handled via RemoteEvent because the client’s outgoing touch data was not reliably being processed by the server when the client was the creator and .Touched events were connected to.

Here are some screenshots of network traffic under different configurations:

Client creating, no .Touched connections (normal traffic):

Client creating, spheres’ .Touched events connected to (high outgoing touches):

Server creating, no .Touched connections (high incoming physics):

Server creating, spheres’ .Touched events connected to (high incoming physics and touches):

Workaround

There is no direct workaround for this problem. Utilizing the distributed physics engine and managing network ownership will ensure that network traffic is not “wasted,” but it will still be generated, and it requires all parts to be replicated.

Other Information

One thing to note is that the server always seems to replicate physics data in this setup. I had originally made a reply to this bug report regarding my problem, but I came to realize this issue is distinct from that problem.

I recognize that the server-to-client communication is likely necessary and that the environment I have set up (which is similar to the environment described in the other bug report) is very much a corner-case unlikely to be worth handling; however, it would seem like the client could be reasonably certain enough of what parts are or are not replicated to the point that it could avoid sending the unnecessary data.

Issue Area: Engine
Issue Type: Physics
Impact: Moderate
Frequency: Constant
Date First Experienced: 2023-06-06 12:00:00 (-04:00)

[Focia19]

We’ve filed a ticket to our internal database, and will follow up when we have updates!

Thanks for the report!

[APandaPoet (熊熊熊)]

Thanks for reporting the issue! Can you please try again to see if the issue is fixed? Thank you!

[MysteriousVagabond]

The issue has been resolved, thank you!