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. "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. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Fearn Sent: Tuesday, June 07, 2005 8:24 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Speed hack detection, was new SDK version is live I don't think it passes velocity, what Botman said was that it passes the impulse keys and that the server calculates your velocity from your existing velocity and the effect those impulse keys have on that velocity. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
