That is exacly why my solution required a aggressive high ping kicker. I would love to see someone make a more robust solution then mine is.
----- Original Message ----- From: "Michael Kramer" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, May 19, 2005 2:54 AM Subject: Re: [hlcoders] Speed hack detection?
But then whoever writes the hacks would find that exploit and make it so it tricks the server to make him think is ping was 400++ a lag hack....
On 5/18/05, Erling K. S�terdal <[EMAIL PROTECTED]> wrote:
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: <[email protected]> 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: <[email protected]> > 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
_______________________________________________ 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
