Lag Resolution

[Sarahlv]

The following appears to be what is happening. Given that appearances can be misleading, it may actually work differently.

As it stands now, the server tells the client to display an aoe box for whatever type is incoming, then does a check to see who is in the target area. This poses two problems, resulting in the client showing the aoe missed, while the server registers a hit:

1) The client doesn't display the aoe box until the message is received, effectively starting at server time + ping. The aoe box lasts the duration, ending at server time + ping.
2) The server checks the target areas immediately. This can be expressed as server time - ping on the client.

[Sarahlv]

One solution may be delayed events. The server would send the command to display the aoe target area a second or two early. For example, AoE Hitbox 1 in 2 seconds. The client would then take the average ping, double it, and subtract the time from those 2 seconds. It would then display the aoe field at that time. One ping subtraction would account for current ping: 2 seconds on server side would account for the delay the client has in receiving the calculation. Given a ping of 250ms, a 2 second head's up turns into a 1.750 second warning client-side. The second ping subtraction would account for the hit/miss check. The server's check would happen where the client was 250ms ago - the position that the client saw when the aoe hit. The client would, thus, show the aoe area for the intended duration, enabling all users regardless of ping, the intended time to avoid an attack.

[Sarahlv]

Could this be abused? Perhaps if the user modified the client to display aoe boxes early. This would result in an advantage equal to ping, given the box would be displayed longer. The delay on server hit/miss checks would be unchanged.

In sum, clients showing aoe boxes at delay - 2x ping would sync server and client aoe handling much better than it currently stands.