On 6/8/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > Based on the quake code here is what the move command passes: > > BYTE 3 (means move) > FLOAT time (Used to calculate lag, ping, and movement) > ANGLE viewangle X > ANGLE viewangle Y > ANGLE viewangle Z > > // The next three are the velocity of the player > SHORT forward_movement > SHORT sideway_movement > SHORT up_movement > > BYTE bits (for attack and jump) > BYTE impluse > > "I don't have the SDK at work, so I can't check anything atm, but I am still > working on HL1 so I'm wondering if there has been any major changes to the > networking code for HL2. I think it's at least as spoofable as people seem > to have similar issues." > > As martino wrote about HL2 lag compensation: > > " The extra lantency caused by lower update rates is part of the general > client latency. The actual code uses timestamps send with the user commands > to set the execution time. These timestamps are checked against the average > latency and if they are within a valid range, these timestamps are used > since they are more precise then the calculation as stated in the doc. We > can't fully rely on these timestamps since "speedhackers" could alter them." > > It appears HL2 has some level of detection for this, just do not know to > what extent.
Where did you get that from? Not saying you're wrong, just want to read the whole thing :) > "It would seem that if the client sends it's game time with it's packets > then it really is trivial to stop speed hacks. It becomes very simple to > calculate velocity/time and compare that to sv_maxspeed. It also becomes > trival to simply ignore any packet from the future." > > sv_maxspeed is irrelevant. Calcs for maxspeed are already part of the > velocity calculation and are correct. The key is the differences in the time > stamps between packets compared to differences in real world time of when > the packets arrived. If you compare the delta's of the message embedded > times to the delta's of the real world times of when the packets arrived it > should work (in theory). So if embedded delta's of the last two messages are > 100 yet the real world delta's of when the packets arrived is 5 you would > know something was up. > > The danger is a laggy player could appear as a speed hacker if you make the > detection too sensitive (since network lag and UDP packet loss really do > happen). So that leaves a window where some speed hacking will always be > possible. Two things, first wouldn't lagged players be sending you older packets/times not future ones? Second, I think it should be up to the server admin to choose to support HPB's if it's the main reason speed hacks exist. Jeff _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
