Explicit replication control

As a Roblox developer, replication currently has a few pain points with a few more technical scripts.

My post is mainly around custom physics scripts, but I can imagine that almost anything where the client can be trusted to change a property is a pain point here.

Here’s a few pain points I have with FilteringEnabled as a starter:

A system of blind trust

Right now, the replication system will blindly trust any changes from the server, and the client cant change the server without using a remote. At a base level, this is an alright system, however when we get into custom physics engines or stuff that NetworkOwnership cant do. For example, moving anchored parts with CFrames, it becomes extremely tedious to make the movement system replicate.

This is also a problem for other objects, such as sounds, I’d want a client to be able to play a sound as soon as they trigger it, instead of waiting for the server to process their request.

Custom Replication managers aren’t a solution, they’re a hack

This can already be fixed with RemoteEvents, however, this isn’t a solution. It’s a hack. As mentioned above, any changes on the server will be replicated to all clients, even the one who initially sent the request. This forces the developer to send the data through the remote again, but to everyone except the client who initially requested it.

This results in a situation where the server isn’t in sync with the clients because if we try to synchronise the server, the client trying to update the data (the true data), will get junk data, and since the server, is trusted, the client ends up with possibly old data. With CFrames, this results in rubberbanding

This is a hack

The client is already trusted with a few internal systems

As mentioned above, a few of Roblox’s internal services are given trust. These most notably are, but not limited to

  • NetworkOwnership (on Roblox’s own physics engine)
  • Characters

If anything, characters actually cant be trusted as much as they are (people flinging others, teleporting around, deleting their character [thanks for fixing this], but its a tradeoff most developers have to deal with)


So what am I requesting here?

To keep it short, I want a system where I can trust a client to replicate one or more properties on an Instance. Using the movement example above, I could make it so I can change the CFrame, and the server trusts it.

FilteringEnabled is a good idea, lets keep it and build upon it.


If Roblox is able to address this issue, it would improve my development experience because I could create custom physics systems without relying on hacky replication managers.

20 Likes

The problem this poses is how would this be implemented? A new method that allows the server to define which player can freely change a property? What happens if I want multiple players to control a property, then how should I know which change is done by which player? How would a developer know which properties are changeable in Studio before runtime?

I think what you really want is some way for the client to change the position of an anchored part on the server for some custom physics system without the bottleneck of firing normal remove events, as implied by your last statement. This could be efficiently done with the introduction of UDP networking, with the advantage of leaving the technical problems posed by explicit replication such as knowing which player did what to the developer, not Roblox.

1 Like