I have created a speedhack detector for amxmodx ( Not released publicy as of yet ), and i encountered alot of problems i dident think of before i started. There is alot of things in a half-life map that can effect the players speed ( Ingame Entities ), that you neeed to check for. I also found that making sure the server FPS was stable above 60 lowered false detections. A aggresive high ping kicker ( ppl with constatly changning ping get easly detected )
----- Original Message ----- From: "Jeffrey "botman" Broome" <[EMAIL PROTECTED]> To: <hlcoders@list.valvesoftware.com> Sent: Thursday, May 19, 2005 12:36 AM Subject: Re: [hlcoders] Speed hack detection?
Jeff Fearn wrote:
Say one put a threshold of 50% or 100% speed up, how would you go about detecting that in a server plugin?
What I would do is keep a list of players currently on the server (store their edict as they connect along with their current location). The player's location can be obtained from the ICollideable::GetCollisionOrigin() function.
If your server plugin GetFrame() function keep checking each player's current location every so often (say every 0.5 seconds).
The "current location" (in the array of players that you keep in your plugin) becomes the "previous location". Subtract the player's current location from the previous location to get a vector. Determine the length of that vector (the distance between now and then), and divide the distance by the time (to get speed, i.e. units/second). Store the new current location in the "current location" field of your array of players.
If the speed calculated is above the server max, increment a "hack" counter. If the speed is below the server max, decrement the hack counter (not letting it fall below 0). When the hack counter reaches some maximum amount (let's say 6, which would be 3 seconds worth of compares), warn the player that the server thinks they are speed hacking and they will be given a 30 second grace period to turn it off or be banned from the server.
Don't check them again for 30 seconds, then if they continue to reach the hack count, ban them.
It's not fool proof and can lead to some false positives, but as long as you allow enough time between comparisons (the 0.5 second window) and as long as you require consecutive check failures (the counting to 6 thing), you should have less people failing due to high latency network connections.
The only problem is how do you handle falling speeds (if you have a long drop that can last for 5 or 6 seconds) and how do you handle teleporters which will look like an intantaneous jump from point A to point B making a speed that approaches the speed of light! :)
Again, averaging things out over several seconds should help avoid even these problems.
-- Jeffrey "botman" Broome
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
