Dear McSic // Dave - 0 DMG hits are still around.

I could write a long post explaining how internet protocols work, but let me try to make it short: Information is transferred via the internet using packets. That is not only limited to data like player position and movement (packet loss: a user appears to be 'spiking' because packets fail to transfer) but that also applies to Anti-Lead. What was the big issue of 0 dmg shots? Packet loss. It's all just packet loss.

GunZ works as a peer2peer game. Player A and Player B are constantly exchanging data via packets. As I said above, if position/movement data fails to deliver from player A to player B, player A will appear as 'spiking' to player B, because player B is not receiving updated packets from player A. Sometimes player A will even appear to be floating across the room because player B didn't receive any updated position/movement data so player B's client thinks that player A is still moving that way / in that direction (until B receives the next packet that tells him the correct position/information).

So how is it with Anti-Lead? The Anti-Lead information is, just like every other peer2peer information on GunZ, transferred from player A to player B directly using packets. It is fast and it works for most of the cases.
There are basically 2 packet types which every online game uses. TCP and UDP. TCP = slow and reliable. UDP = fast and unreliable. Big difference here is, TCP packets are usually bigger, they include more information and wait for confirmation - if a TCP packet is sent from player A to player B and doesn't get a confirmation back from player B, it will keep re-sending the packet from player A to player B until B finally confirms that he received the packet. This can be up to a minute, two minutes, 10 minutes, 1 hour. Whatever you define as 'time-out' (the point where you give up and stop trying to re-send the packet). TCP comes like that.
UDP packets, on the other hand, are much faster and smaller but unreliable. Why unreliable? Because UDP is basically 'send and forget'. Player A sends the packet (which is smaller and transferred faster) to player B and forgets about it. He doesn't care whether player B receives it or not, it doesn't matter. All that matters is that he sent it and that it's fast.

If you play a fast-paced game like GunZ, or other fast-paced games (usually FPS), you cannot use the slow TCP protocol to transfer information from A to B, because it would add delay. Delay is bad and noone wants delay. You want updated movement data from the enemies as fast as possible, you want to know what he does and you want it now. So you have to use UDP.

But as UDP is unreliable own its own, you will have to code/create/integrate your own way of 'packet confirmation' to make sure that B actually receives the packets that A sends him. This isn't so important for movement/position data, because new position/movement data is sent so fast that it doesn't matter if a packet goes poof every now and then, but for shots this is important - because every hit matters. So if that hit-packet fails to deliver and A doesn't re-send it, player B will never know that A hit him. He won't take damage. So A must re-send that hit-packet. And if it keeps failing to deliver A must keep re-sending it until he gets confirmation from B.

Basically:

Best case: This is the case ~ 90% of the time. Player A hits player B, player A sends a packet to player B telling B how much damage he dealt to B. B confirms the packet. All good, all done.

Average case: Happens every now and then. I would say like ~ 10% of the time. Player A hits player B. A sends a packet to B telling him how much damage he dealt. B doesn't receive the packet, because the packet was lost on the way. (How do packets get lost? Bad/unstable connections, people dropping packets on purpose, people using proxy/vpn which add to the route and make packet loss more likely). Anyhow. Our way of dealing with this: A waits a certain amount of time for confirmation from B. He doesn't receive a confirmation, so he re-sends the packet to B. B receives the packet this time and sends a confirmation-packet back to A. All good, all done.

Worst case: Extremely unlikely, but as you can see it's not impossible to happen. I would imagine like ~ 0.1% of the time. Short: all attempts of transferring the packet have failed. Either because people have extremely horrible connections (which they shouldn't play with and get d/ced / warned for), or because they are dropping packets on purpose (using third party tools, which we ban them for), or because they are using a proxy/VPN service which could be dropping/filtering packets (sometimes on purpose, sometimes not) (obviously one of the reasons why VPN/Proxies/third-party-programs are forbidden on FGunZ too). So what happens here is A hits B. A sends the damage-packet to B. B doesn't receive the packet, because the packet was lost on the way. A waits a certain amount of time for confirmation, doesn't receive any confirmation, so he re-sends the packet. B doesn't receive the packet, because the packet was lost on the way again. A waits a certain amount of time for confirmation, doesn't receive any confirmation, so he re-sends the packet. B doesn't receive..... and it goes on and on. For how long does it go on? That depends on what the developer decides in the code. How's that decision made? Well, first question: How likely is it that a user doesn't receive a packet 3 times in a row? Unlikely, but it happens. 5 times? Very unlikely, but it can still happen. But 10 times in a row? 20 times? 50? 100 times? Extremely unlikely (pretty much impossible for people that aren't doing it on purpose). Second question: how long do you want to wait until your shot registers? Say if A waits 0.2 seconds until he re-sends the packet, and he re-sends it again and again because he's not getting confirmation, after say 10 retries A would be at 2 seconds. After 20 times A would be at 4 seconds, would you like your shot to register 4 seconds later? Like, is that shot even still useful by then? Doubt that. So the developer sets a limit - a cap - which works for 99.9% of the cases. With that 0.1% pretty much being people that do it on purpose.

That brings us to the question: How did it happen to GAESAEKKI?

Checking the logs...
Which reveil that GAESAEKKI is obviously using a VPN/Proxy, as he's using one computer to play FGunZ from NL (Netherlands) and U.S. at the same day.

Explains how it happened.

Which brings me to my warning:
GAESAEKKI, stop using a VPN/Proxy now if you don't wanna get banned.
It is forbidden unless explicitly allowed.

Turns out that was quite a long post.

We will further work on the amount of retries and time between retries to further eliminate 0 dmg shots (for those 0.01%).