BetterReplication | Vastly improve your combat experience by fighting LAG!

To set the record straight, I would not consider Ax1s’ implementation a ‘good’ implementation. And definitely not something to be used in production environments.
Besides a mediocre code implementation; it suffers from no optimisations for both networking and code performance. Regardless of that his concept serves as a base for projects like BetterReplication that have these necessary optimisations implemented.

The tick rate should not be altered either as 20hz is the rate at which the character replication step regularly occurs. Increasing tick rate will only increase your bandwidth and not lead to any better results.

2 Likes

I mean, it’s used in Typical Colors 2 according to him, and it feels smoother than normal, so regardless of performance implications it does a hella good job at what it’s made for :person_shrugging:

It’s not like I have packet loss anyway so the downsides don’t affect me that much. Not saying this isn’t better for production, but it just feels noticeably less responsive due to the interpolation.

2 Likes

In my earlier reply, I meant that they are both more responsive than the default roblox replication - didn’t mean to say ax1s’s one was necessarily better for production environments, mb.

And no wonder, okay I shall not mess around with the tick rate then haha :sweat_smile:

2 Likes

Hey! Still hoping for that article to release sometime soon, in the meantime is there no simple fix for the ragdoll issue?
Given the fact you haven’t really said anything about it, I’d imagine it’s quite involved with no simple answer, although it has been a month now so I’m guessing more stuff got in the way.
Power to you, hope you’ll find time soon.

Using Ax1s’s module to explain this.


Pink Cube - Replicated Position
Player - Normal Roblox Replicated Position

If a player were to lag-switch, move a bit, and stand completely still afterward, their position on the server wouldn’t change (from where they first lag switched) until they move again. This unfortunately seems to have the same behavior using BetterReplication, but I don’t know how I’d go about patching this one honestly.

I know the module isn’t supposed to do any anti-cheat checks, but what’s a good way to patch this using BetterReplication?

This looks awesome! For more ease of use, would it be possible to convert the system to using a ModuleScript? I use a single-script framework for client and server-side, so being able to simply have this as a module would be great in terms of staying organized.

1 Like

Hey! I was asked this a variety of times. While this does eliminate the literal idea of ‘plug-and-play’; I realize that it is more natural to have the interface wrapped in a module! Besides that, this is a model that more experienced developers will be making use of. Hence why a simple ‘plug-and-play’ is probably not ideal! For this interface I’ll also be adding the option to toggle replication off for specific players!

2 Likes

Hey! BetterReplication does not overwrite Roblox’ default character replication on the server. The server is solely there for sanity checks and forwarding the positional data. If you see this behaviour happening on the server; that is NOT due to BetterReplication!

1 Like

Thanks for your interest once again draakjes! It is still a work-in-progress, work and study has just hinderred me a lot from being able to write this article in the quality I wish it to be. Thank you for your support as well <3

Yes, I’m aware of this, but I’m expecting to see the updated position on the client. Using BetterReplication, for some reason, the player shows up where the player is in the image, rather than where the cube is in the image. Using fastp2p, the client position updates as expected.

This is due to optimisations in BetterReplication where a player CFrame no longer gets sent to the server if the player stands still. I could shift this task to the server however and that way this issue would be solved!
(This will lead to more serverload and bandwidth for sending these position packets. I may make it an optional setting to enable/disable this!

2 Likes

I’m fine with it being optional. This is a very niche lag switcher bug that most people don’t know about anyway, but can still majorly affect certain games.

1 Like

Awesome! Will definitely look forward to implementing this in my game once the modularized code comes out.

2 Likes

Circling back on this. Is there any update coming out soon?

Again, computer science has taken a TON of my time and I HAVE to make my courses to be able to stay in the uni. I just have not found the time to maintain any of it.

I will have time from mid-april and afterwards after this quarter is over.
I hope you can empathize for my situation :smiley: thank you

2 Likes

No worries! School comes first, take your time

1 Like

Seems like its broken with R15 Ragdoll ( R15 / Rthro Ragdolls )
What ragdoll module have you used in your video?

1 Like

Found this section of your code and updated it

Old:

-- i find the implementation below a bit ugly to read, if you have a more elegant solution please let me know!
if outOfProximityIndex then
	if isInProximity then
		table.remove(
			currentlyOutOfProximity[receiver], 
			outOfProximityIndex
		)
	else
			continue
	end
elseif not outOfProximityIndex and not isInProximity then
	table.insert(
		currentlyOutOfProximity[receiver], 
		subject
	)
	table.insert(
		newOutOfProximity,
		identifiers[subject]
	)
	
	proximityUpdate = true
end

New:

if outOfProximityIndex then
	if isInProximity then
		table.remove(currentlyOutOfProximity[receiver], outOfProximityIndex)
	end
elseif not isInProximity then
	table.insert(currentlyOutOfProximity[receiver], subject)
	table.insert(newOutOfProximity, identifiers[subject])
	
	proximityUpdate = true
end

Just saw the new update! Can’t wait to implement this

Thank you for the feedback Robot! I appreciate the patience :slight_smile: