How to replicate custom changes from clients without replicating back?

Is there a way to replicate specific properties of objects from a client to the server without those changes replicating back to the same client? For instance, change the Value property of a NumberValue named Air on the server to be the same as what the appropriate client changed it to.

Is there an API somewhere that lets me control replication behavior? I’ve tried digging around the wiki for information on doing this to no avail.

This clean behavior already happens with specific properties of Parts and Humanoids controlled by a client via their appropriate systems, and it was seen on a much larger scale back when Experimental Mode was still around. If you’re not familiar with replication, read the pages on FilteringEnabled and the Client-Server Model.

I’ve tried using a combination of RemoteEvents, Changed events, and scripts to accomplish the task, hoping the replicator was smart enough to not replicate back. Instead, I got a feedback loop where the value changes on the client, the object’s Changed event fires which then fires the RemoteEvent, the server writes the change, the server replicator replicates it back, and the client’s later changes are overwritten, possibly triggering Changed and restarting the process.

How it should behave with replicating (video made without replication scripts):

A video of what’s going on with artificial replicating (artificial lag added to make problem visible):

Here is the place file used in the videos.

ReplicationAttemptCase.rbxl (33.8 KB)

3 Likes

I do this sometimes for lag compensation with guns.

let’s say we are trying to color a part. We can keep the client from seeing its own changes by having duplicate parts that exist on the client and server. We can destroy one of the duplicates on the client (the server will use this duplicate). The client fires a RemoteEvent with a request to change the color of the part. The server applies the color to the duplicate that the client had already destroyed, while doing nothing to the copy that exists on the client.

The only problem with this system is that one of the duplicates has to exist on the client, which can be really inconsistent with lag and such. Generally I only use this system for purely visual effects.

2 Likes

So I’m guessing do what I’m doing already, except that on the client make a copy of the artificially-replicated object in the same location and move the original somewhere else (possibly nil or by destroying it) so that the LocalScripts see the clone?

It’s not the cleanest solution, because another LocalScript passing that object (the clone) to RemoteEvents will result in the server not properly seeing what the client meant.

Even if I kept both duplicates on the server and just destroyed the one on the client, there would still need to be special code in every other system handling that object and the clients interacting with it to compensate by figuring out that when the client says client duplicate, the client means the server duplicate.

Despite that, I guess it’s the closest I can get to true client-to-server replication at the moment. Thanks.

If the functionality I need doesn’t exist, I might put in a feature request.