Mirage Source

Wouldnt a solution be to actually check if the time it took them to get from square a to b is the time set? Checking the tickcount or whatever each step?

Might be a problem if they are lagging though...

There are 2 tutorials here to prevent speed hacking.

http://www.key2heaven.net/ms/forums/viewtopic.php?t=67
http://www.key2heaven.net/ms/forums/viewtopic.php?t=772

_________________

I know, but neither of them do this (i think o.0); and i think one of them uses a timer..

Edit:

Nvm lol

Okay, but you say the 'Time Set'. How is that set? So you mean that there should be a certain time for a player to move 1 square. Of course with some uncertainty then.

_________________

Well the thing i have been working on for this was just blown to pieces after reading verrigans tutorial the speed hack would just make it faster ~.~

Sounds stupid and obviouse but i wasnt aware they could do what they can

But the tutorials he made will make it so speed hack wont work, so I dont see a reason to find another way.

_________________

Yup i didnt know he had made a second one, the first one was a bit crude~

Yes it was.

It was just something I stumbled across in my own endeavors to beat speed hacks.. Then I found that it didn't work as anticipated in all environments (Thanks Misunderstood), so I continued my struggle, and went to the 64-bit time method..

This can still be hacked by changing your system time constantly, to make it seem like you are further in the future than you really are... But... with a little effort, and an encrypted packet (using a key that could be difficult to guess.. ) you could send the system time at login, and the server could randomly request the system time from each client to confirm that they are still using the correct time..

A problem with that is.. People could catch on that the only packet that is encrypted is one that requests the current system time, and then change their system time to normal time... but then, if they have moved too far into the future, the client will hang because it's waiting for a specific 'tick count'. So they'd end up having to close their client and reload it, which would be too much of a pain to bother with.

But.. if they fail to notice that the encrypted packet is actually the time request, they would end up being too far into the future, and you could calculate that based on the first time entry received by the server... (Calculate how much time has passed on the server, and how much time has passed according to the client, and if they differ by more than... say... 5 seconds.. They're obviously 'speed hacking'.)