basically, a normal client's firing pattern looks like: (horizontal axis is time, 'x' is a fired bullet)
x-----x-----x-----x-----x-----x
and the server is fine with that. all the bullets are registered.
a hacking client could potentially do this:
x-x-x-x-x-x-x-x-x-x-x-x-x-x
i.e. firing at a much higher rate
the server recognizes this and drops bullets if they are too close together. so the bullets that the server keeps look like
x-----x-----x-----x-----x--
this prevents hackers from gaining an advantage by increasing the rate of fire.
sounds good right? well it is a good idea. however, there is the issue of network instability (i.e. fluctuating ping/latency).
a normal client may do this:
x-----x-----x-----x-----x-----x
and the server could potentially get something like
x----x-------x---x------x------x
now for the 2nd and 4th bullets, the time between them and the previous bullets is lower than usual. this not due to hacking but due to fluctuating latency. unfortunately, the cs2d server can't tell the difference and ends up dropping those bullets.
the bullets that actually do damage look like:
x------------x----------x------x
this is what is going on here (a very extreme example):
http://www.youtube.com/watch?v=iohPyxKoyb8
in cs2d b0.1.1.9 this was added:
Quote
Attack buffer to minimize server sided attack packet drops
however, the behavior of this attack buffer is quite weird actually. the dropped bullets get put in a the "attack buffer" and the bullets in the buffer get fired every second after the client stops shooting.
for the previous example:
a spectator would see this pattern of bullets:
x------------x----------x------x-----(1second)-----x-----(1second)-----x
anyway, this is how it would be like ideally:
the server receives:
x----x-------x---x------x------x
these are the ones usually dropped
-----*-----------*--------------
ideally, it would look like
x-----y------x-----y-----y-----x
DC if you want i'll post some pseudocode later for how to implement this