Server Sided hit detection with lag compensation

I’m using a task scheduler that allows me to set a tick rate for my game. There are two ways I can go about doing hit detection:

Client side: The client raycasts and sends the raycast result to the server
Server side: The server uses the client’s camera rotation and the position of the character and does hit detection server side

The issue I’m having is that client side is easily exploited and server side is very inaccurate as there really is no way to have accurate lag compensation. I want to try using the task scheduler to create “snapshots” of the game similar to how Valve does it and use that to rewind to the tick that the client fired at but I have no idea how to go about doing this.
Here is an article about how Valve handles this, there was a better one but I can’t find it anywhere: Lag Compensation - Valve Developer Community

Valve only stores up to one full second of snapshots before erasing them from memory. I am unsure how to go about storing these snapshots in an efficient way. Here are some of my ideas:

  1. Use a Linked or Hybrid List and have a cap on the amount of entries. Once the cap is met, remove the last entry and enter the first entry.
  2. Have an array indexed by the tick. Ex: Snapshots[tickNumber] = snapshot
  3. Just use client sided hit detection

The snapshots only include player positions, however I am unsure how to go about creating these snapshots and what to put in it. Would I need to manually go in and write down the CFrame of each and every limb on the character? I feel like this would exponentially use up a lot of valuable server memory but I’m not sure. If there are 50 players in a server (extreme example), 32 ticks per second, and up to one second of snapshots, that’s 32 snapshots for 50 players for 6 limbs. 32 * 50 * 6 = 9600 separate CFrames stored in a Linked/Hybrid list or an array. I feel like that would hog server memory.

If anyone has any input or ideas send a reply.

1 Like

One of the issues of implementing lag compensation is that Roblox has their own network buffer that you don’t really have control over. Even if someone has 60 ping, the buffer could be 100ms and so rolling back by 60 is not nearly enough. 9600 frames should only be around 200kb of memory give or take a bit. Why do you think you need a linked list?

1 Like

I was just spitballing ideas when I mentioned the Linked and Hybrid lists, an array would probably work

The server doesn’t calculate the lag compensation in ms, it uses ticks. When a client joins the server their task scheduler gets synced up with the server. When the client sends the remote event over, it sends the current tick, the server rewinds to a snapshot on that tick (or the closest snapshot it can find). This means that the buffer should not affect my system all that much aside from the initial synchronization of the client.

The buffer I was speaking about is specifically with replication of humanoids and not all network traffic. If you manually replicate humanoids with remotes you can circumvent this but otherwise it won’t be very accurate.

1 Like

As long as the memory usage for storing snapshots isn’t insane I’m willing to test it out to see how it performs with the Roblox replication, if the lag is too bad I’ll just switch over to a client sided hit detection system. As long as the clients aren’t using Spectrum there shouldn’t be any issue

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.