On 6/7/05, Deadman Standing <[EMAIL PROTECTED]> wrote: > LOl, it is the same thing. The movement command is based on time, that is > why velocity not position is passed. Keep in mind velocity is a measurement > of distance over time. If you advance time it thinks you traveled farther.
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. Are you saying that the server is ticking along and the client is ticking at say twice as fast and the server processes ticks from the client that the servers knows are in future? 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. It's also fairly simple to modify that to handle teleporters and such, which aren't used in most mods anyway. It's a little more difficult, but not hugely so, to include the effects of known environmental effects, like explosions and vehicles etc. > You can look at the old quake code to get a fell how this is done. Also look > on the web, there are some open source hacks out there. They basically speed > time up for the program. This is an easy fix, ignore packets from more than a few seconds in the future. This wouldn't completely remove such hacks, but it would certainly limit them significantly. I suppose what I'm trying to find out is why this is hard to fix, I haven't heard any reason I would consider a blocker to significantly reducing the effectiveness of these hacks. Jeff _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
