On 6/9/05, LDuke <[EMAIL PROTECTED]> wrote: > Imagine that the client lags out for 5 seconds, then an update gets > through. From the tick before the update to the tick after the update, > the client moves 5 seconds * maxspeed. At a max speed of 320, that's > 1600 units in less than a tenth of a second. How does the server know > if this is a speedhack or a lagging client?
You need to construct the entire scenario, else you miss the parts that make no sense ... to me ;) 1: Client joins server at tick 100 2: Client starts playing 3: Client gets lagged at tick 200 4: Server gest tick 200 at tick 205 5: Server back tracks, player moves faster as ticks 200-205 are corrected See how when you are lagged the server recieves your tick from the past, the server should never process ticks from the future. I'm pretty sure that the speed hacks make your client tick faster and thus send ticks from the future, i.e. at server tick 200 client tick 205 is being processed. > Somehow it would have to average the speed over a period of time. How > far back would you have to check? How much processing time would it > take to check that far back? The server defaults to 1 second of lag compensation, so you should only be able to speed a little by fooling lag. Also it should only work in short spurts as you have to catch up for time you missed, which you actually have to miss at some point. I'm still interested in knowing if turning off lag compensation, sv_unlag 0, breaks speed hacks. It probably breaks HPB's ;) Jeff _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
