Question Understanding lag compensation

Hi,

I'm trying to get a better understanding of how Netcode works within a Multiplayer FPS context, naturally DOTS Sample is a great place for getting a better understanding.

Currently I'm looking into lag compensation, in the AbilityAutoRifle.cs, it takes the collision world of a certain tick. This tick is the tick that the shooting client rendered, I assume this is to 'rewind' the collision world and check the client's hit against the world the client 'saw' when it pressed the 'shoot' button.



This seems to work fine (see image above) when I enter a Send/Receive delay of 0ms. When I enter a delay of about 100ms, the positions are very off (see image below) and so the hit reg will be abysmal. In the newest version of netcode we are also able to input an interpolation delay, this can be done via the 'CommandDataInterpolationDelay' I believe, however I'd like that to be confirmed as there is barely any documentation or info about it (mostly the netcode sample uses it).



Now my question is, how would I go about applying proper lag compensation in something like DOTS Sample when I have a higher latency. Should this issue be fixed through lag compensation or are there other paths I am currently missing.

Also, this is how I'm currently drawing the collider positions at the end of the ShootingPhase in AbilityAutoRifle.cs:

Code (CSharp):

1.  
2. isServer = World.GetExistingSystem<>(ServerSimulationSystemGroup) != null;
3.  
4. ...
5.  
6. if (isServer)
7. {
8.     for (int i = 0; i < collWorld.NumBodies; i++)
9.     {
10.         if (hitColliderOwnerFromEntity.HasComponent(collWorld.Bodies[i].Entity))
11.         {
12.             var pos = collWorld.Bodies[i].WorldFromBody.pos;
13.  
14.             DebugDraw.Sphere(pos, 0.1f, UnityEngine.Color.cyan, 5f);
15.         }
16.     }
17. }
18. else
19. {
20.     for (int i = 0; i < collWorld.NumBodies; i++)
21.     {
22.         if (hitColliderOwnerFromEntity.HasComponent(collWorld.Bodies[i].Entity))
23.         {
24.             var pos = collWorld.Bodies[i].WorldFromBody.pos;
25.  
26.             DebugDraw.Sphere(pos, 0.1f, UnityEngine.Color.red, 5f);
27.         }
28.     }
29. }
30. }

 

Hi Tim, thank you very much for responding so rapidly!

Alright, this explains alot already, I thought I was able to back as far as the CollisionHistory allowed (EDIT: I thought it was 32 ticks and not 16). I wanted to make sure I was able to perfectly hit the player with high ping and then cap it myself, but now I know you guys already take care of that.

I am currently using the CommandDataInterpolationDelay purely as a read-only value. However with the setup from DOTS Sample I had to change the ghost owner component from the PlayerState from Interpolated to Owner predicted otherwise it didn't seem to update the delay field within the component (as it wasn't replicated?).

If I am reading it right, the size is currently set to 16. With a simulation rate of 60 this would amount to a maximum ping of around 266ms (16.67ms x 16). Shouldn't that support a send/receive delay of 100ms as it would result in a RTT lower or near 266 (depending on processing time) and thus draw the collisions in their expected positions?

 

Thanks for clarifying the way the delay works, I knew I had to be thinking too simply about it.

I know DOTS Sample isn't fresh in your memory so maybe you won't recall, but I was wondering what the main reason was for the 'player' and 'character' to be separated. Though it offers the ability to destroy the character entity and start off with a clean slate, I was wondering if there were other perks to having those two separated.