BetterReplication | Vastly improve your combat experience by fighting LAG!

Resources Community Resources
,
1

:warning: IMPORTANT: BetterReplication is now considered superseded by Chrono, an advanced replication library that builds on the foundation that BetterReplication provided!:star:

Temporary explanation of how to support ragdolls with BetterReplication here!

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 (A simple interface with informative method description)
  • Lightweight (Optimized for low resource consumption)
  • Very efficient in bandwidth consumption (Using a custom buffer writer and reader implementation) (Adds only +/- 0.6 KB/s of RECV overhead per player in proximity)!

The results of BetterReplication (its amazing!!):

How BetterReplication works:

BetterReplication uses Roblox buffers under the hood to replicate player cframes 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 anti-cheat checks :warning: !! This is behaviour that you will have to implement yourselves.
  • 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 Interface module contains a readme and all public methods)!
BetterReplication.rbxm (35.4 KB)

Download the test place!
BetterReplicationEnvironment.rbxl (116.5 KB)

Marketplace model:

Github:

Credits:

  • @Tazm0ndo for taking hours of your time to help me out prior to BetterReplication!
  • @Parihsz for assisting with the snapshots implementation (and memory leak ;D) and the suggestion of proximity based replication!
  • @XK4nekiX for the incredible contributions towards the replication buffer implementation!
  • @puddest for the initial contributions and advice!
  • @ffrostfall for ByteNet (In versions prior to V6)!
  • @Ax1sAng1e and their replication system that was used as inspiration!
  • @BreezeOnTheDoor for fixing the R6 issue
  • And the rest of the OSS community who has made efforts for BetterReplication!

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

Log:

28/05/2025:

  • Reworked player identifier system
  • Examples folder contents have been fixed
  • Incorrect packetloss configuration fixed
  • Sanity check callback expansion
  • New method: ‘getLastClientTick’ (used for sanity checks)

18/04/2025: Finally a new update! V7 has now released with a refactor! BetterReplication is no longer a plug-and-play based model but a proper framework instead!

15/02/2025: V6.1: reduced replication packet size by 40%! CFrames now consist of i24 and i16 for position and rotation data (f32 * 6 before)

15/02/2025: V6 BetterReplication has moved away from ByteNet and now has its own buffer reader and writer!

  • new config option; makeRagdollFriendly. Replicates the player’s entire CFrame orientation instead of solely its yaw.
    Results in higher bandwidth consumption however. It is recommended to not enable this setting when its not directly necessary.
    More elaboration on this config option soon.

30/01/2025: V5 contains back-end changes and fixes that should make replication much more reliable and accurate!

  • For the advanced users under us; clients now forward their own ticks instead of the server doing this for them. In V4; BetterReplication assumed the same tick for every client (as it forwarded the position cache in bulk at 20hz). This
    is not the proper way to do it as receiving the tick information from the original client is the most accurate. This does mean an
    increase of 4 bytes (f32) per packet (but also less overhead at the same time as we dont use a ByteNet map anymore).
  • The position forwarder on the client has been reduced from 30hz to 20hz, reduced send and recv for the same result!

23/01/2025 Late happy new year! V4 contains huge improvements and a big refactor!!

  • :star:BetterReplication now has a replication buffer implemented. This makes BetterReplication much more compatible with production-ready scenarios where inconsistent internet connections are present!
  • :star: Proximity based replication has also been added! You can easily configure this. Proximity Based replication is an implementation that you can use to have MUCH less network traffic by disabling BetterReplication for clients at larger distances from others.
    (Notice that swapping in-and-outside of the replication zone causes jitters as the Roblox replication buffer will take over.)
    (Make sure therefore that it is not intrusive to the gameplay when people enter and leave this proximity.)
  • :star: Sending and receiving position data has been optimized by 25%!
  • Easier configurations

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)

178 Likes
2

Can this work with Battleground games?

2 Likes
3

This is designed with battleground games specifically in mind!

3 Likes
4

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

Though, it looks really cool!

4 Likes
5

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

3 Likes
6

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?

7

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.

7 Likes
9

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

2 Likes
10

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?

2 Likes
11

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

1 Like
12

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
13

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.

14

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.

15

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
16

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.

17

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

18

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:

1 Like
19

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:
psps; version 4 is now downloadable and solves all issues you had earlier

2 Likes
20

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

22

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?

ps; version 4 solves your issues with the new interpolation buffer

2 Likes