I dont know what LPBs firstly.
If someone has a constant ping of 400 im sure that fine, but the problem with when a users ping spikes, when this happens your speedhack detectors gets a false detection. This can easly be seen if a user is running a p2p program in the background, his ping can easly go from 50 ish to 400+++ for a minor second. Its posible someone with a better understand of the HL engine can make a better solution then what i made. You could proberbly add a ping check that made sure his ping at least was stable, as a midle ground.
----- Original Message ----- From: "Andrew Foss" <[EMAIL PROTECTED]> To: <hlcoders@list.valvesoftware.com> Sent: Thursday, May 19, 2005 1:32 AM Subject: Re: [hlcoders] Speed hack detection?
high ping kicking is mean and spiteful. I don't want to rant about it, but lag comp nullifies any complaints LPBs have. (which should be none, because HPBs don't lag the game. if anything LPBs with aggressive settings do.)
On 5/18/05, Erling K. Sæterdal <[EMAIL PROTECTED]> wrote:
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
_______________________________________________ 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
