BetterReplication | Vastly improve your combat experience by fighting LAG!

:warning: BetterReplication is NOT ready for a production environment. An important update to properly support low network connections is in the works (implementation of an interpolation buffer and disabling default character replication).

Version 3 is now live with an important vertical position update finetune!

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)
  • Very efficient with bandwidth (using ByteNet)!

The results of BetterReplication (its amazing!!):

How BetterReplication works:

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.

:warning: Known limitations and behaviours :warning:

  • BetterReplication does NOT do sanity checks ( and thus also anti-cheat) :warning: !! 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!

Downloads:

Download the model (the tutorial is in the README)!
betterReplication.rbxm (22.9 KB)

Download the test place!
BetterReplicationTest.rbxl (89.7 KB)

Credits:

Any contributions, bug fixes and suggestions are very welcome! :heart:

Log:

24/11/2024 - version 3 release; added easier PlayerPositionsHandler configurations, finetuned and fixed vertical position updates, improved README documentation!
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)

39 Likes

Can this work with Battleground games?

2 Likes

This is designed with battleground games specifically in mind!

3 Likes

I would appreciate if you could maybe make a breakdown post on how this actually works.

Though, it looks really cool!

3 Likes

Good one! I will write an in-depth article tomorrow on how this works!

2 Likes

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.

3 Likes

This will fix it! As my model is new I have not seen this used in a production game yet. Mine will become part of these games soon however!

Thank you for your interest. I am releasing a new version soon which fixes the instability issue when two players collide

1 Like

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?

1 Like

I will look into the bandwith spikes that you experienced (as i have not come across a noteworthy change myselves)

1 Like

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!

2 Likes

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!)

1 Like

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.

Hi Droopy! Thanks for your suggestion. I have this staged as a future feature!

Hey, I was considering implementing this onto my Brickbattle group’s games, as latency has been a big Issue there. However I noticed a problem, when a player constantly jumps, he appears to be flying , as seen in the gif bellow. [Tested In studio with 0.1 incoming replication lag]
replicatedCharacters
This happened to almost every test player, with one exception when a player appeared jumping normally, even after respawning. Not sure what was different. Regardless, this unfortunately means we cant add your replication to the game :expressionless:

Hey vbaumel! I have identified the issue and are working hard on fixing it asap! Thank you for letting me know and making efforts to improve BetterReplication!! It has to do with how BetterReplication lerps for vertical movement! (no need for that frowny face of yours anymore :smile: )

ps; version 3 is now downloadable :slight_smile:

I usually dont like to hate but that replicator is complete mess, my character spazes out every minutes, everyone is freezing and stuttering really hard

Complaining can not advance this project. This is a new issue and I have not seen anyone come across that behaviour. Can you send a place file of in which this issue occurs?