No. that's not correct. Supposing client A is the one using anti-aimbot, client B is the one using aimbot.Quote:
Originally posted by iliveoncaffiene@Apr 15 2007, 22:26
It's not going to prevent a manually controlled aimbot. All proxies still pickup (at least mine) the walking coordinates. So by the time the packet shoots, it will have the latest coordinates (By getting them from the coordinate hashtable right before shooting, the coordinates are the latest.
Assumption: average ping = 300
1. timestamp a: client A jump (proxy send jump packet to server)
2. timestamp a + (0.01 sec): anti aimbot send a walking packet
3. timestamp a+ 0.3 sec: server receives jump packet and start send this packet to client B.
4. timestamp a+ 0.31 sec: server receives walking packet, coordinate changes on server side
5. timestamp a + 0.6 sec: client B receives jump packet about client A, aimbot it
6. timestamp a + 0.61 sec: client B receive walk packet. aimbot it again
7. timestamp a + 0.9 sec: aimbot packet reach server, fails as cord changed in stemp 4
8. timestamp a + 0.91: second aimbot packet reach server, may hit only if client A does not move
So the only way for a aimbot to hit is when it meets the following 3 requirements:
1. it hits twice (one for jump, one for walk)
2. the aimbot support firing consequentially in less than 0.01 sec
3. the client A (anti-aimbotter) wont move within 3 average ping time cycle (which is very rare).
Hope it is clear to you technically.
<hr>Append on Apr 16 2007, 02:59<hr> For manually controlled aimbot, it may hit accurately when the target stand still. If the target is moving using anti-aimbot (jump or move), it wont hit as I explained in step 1-8.