Version 2 has released with lots of improvements! The existing download link has been updated
Roblox’ replication system is too slowww for combat games!
The issues that arise include:
largely delayed player Character positions on the server and other clients
any constraints applied to the Character will show delayed to other clients! See an example here!
This majorly affects games that have high-paced manouvers and close-combat at their core.
As someone who has been developing such a game, I HAD to come up with a solution to get this fixed.
BetterReplication is:
Easy to install (Plug-and-Play)
Lightweight (Optimized for low resource consumption)
BetterReplication uses ByteNet under the hood to replicate player positions using minimal bandwith. This position data is sent to the server and the server forwards it to the other clients. These clients then overwrite the position of the client in question with the up-to-date position that was forwarded by the server.
Known limitations and behaviours
BetterReplication does NOT do sanity checks ( and thus also anti-cheat) !! This is behaviour that you will have to implement yourselves.
The player registry on the client occassionally shows inconsistent behaviour. We are looking into this! (It seems like this issue has been solved, though I can not say this with certainty yet)
For optimizations; BetterReplication is limited to 256 players per server! (This is due to the player identifier that is of unsigned 8-bit integer size)
Though BetterReplication has been tested a lot and performs stable, it is still considered an ‘in-progress’ project. We actively support any contributions!
Any contributions, bug fixes and suggestions are very welcome!
Log:
18/11/2024 - version 2 release; fixed buggy player collisions, large networking improvements and R6 incorrect position fix! 15/11/2024 - First release of BetterReplication version 1 (V1)
Pretty cool! If this works roblox combats can actually get much better with momentum, an issue I had with making certain types of combat was constraints/bodymover latency but this just might fix it.
Edit: Is there any live games that use it would love to see if it in action?
Hey so I decided to look into this and first of all its honestly kinda cool but second I did notice that your recv will jump quite a bit, this is because roblox is still sending their own replication packets, as well as your modules own packets and that will add up with a lot of players.
There isn’t an easy way around this and trust me I’ve tried, roblox doesn’t provide a way of disabling humanoid replication, so what I did in a test of mine was have the server delete the player character and keep its own “reference” of the player (a root part) in the server camera so it wouldn’t replicate. Each client would then load their own character and replicate its CFrame to the server at a constant rate.
Each client would also render the other clients characters as well and smoothly interpolate them based off the data the server replicates. The cool part about this is that I’ve effectively gotten around humanoid replication and it allowed me to add distanced scaled replication. So the server updates each client at a different rate based on their distance to another client.
Overall cool concept but idk how well it would hold up in production.
Really interesting take. But this will come with many limitations when applying server sided changes to characters. Did you find a smart way to tackle this?
hi yall, version 2 has now released. The shudder has been fixed, the bandwith usage has had a partial overhaul and I found major improvements! The R6 bug has also been patched!
Look interesting! Position desync has always been an issue that I wanted to look into since my game involves fast-paced close combat too. Could you put this up as a wally package? With the current structure, updating it is a bit annoying if you want to adapt it to your current game structure.
That is the one downside to that method, you’re gonna have to manually replicate any change you want to make to a clients character since it only exists client side.
The method I described could theoretically work in production but you’d have to write any character based code around the system itself since its not exactly a drag and drop replacement.
Hi there! I have not worked with Wally before, but I will definitely look into this! I will also add a guide on how to integrate this project with existing ByteNet models. (The reason I ship it is because ByteNet’s current model has a bug in their CFrame buffer transformation. I fixed this in the ByteNet module and therefore placed in the BetterReplication model!)
A nice feature would be a way to disable it on certain characters at certain times, like an attribute or tag to just not send/recieve position data, that way it can be disabled in situations where it would conflict with other things. Current solution is to just disable the entire local script, but then i assume that means you don’t recieve other player’s position data anymore either.
Known limitations and behaviours 