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: <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 > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
