Spodi, about Double Tick Count

[William]

You where talking about resolution, but I didn't full understand what you ment. I know that you dissliked the idea of doing it, could you tell me why? Cause I need to protect my game from speedhacks.

[Rezeyu]

Couldn't you just control movement server side?

[Spodi]

Couldn't you just control movement server side?

Optimally, you'd control it both. General rule of thumb is the physics / math of the server and client are as identical as possible, so they can both simulate together. When the user moves, the client first checks if it is okay, then when the server gets it, it verifies it is okay. Skipping the server check allows hacking but reduces server load, and skipping the client check results in the server receiving an excessive amount of movement requests.

Resolution, in this context, is just how accurate the timer is. For example, a millisecond resolution would look like:

1, 2, 3, 4, 5, 6...

While a 30-millisecond resolution would look like:

1, 1, 1, 4, 4, 4, 7, 7, 7, 10...

The reason I suggest again a lower-resolution timer is like I said above - the server and client should be replicating the physics as closely as possible. Lets say, for example, we have a platformer game with a nice physics engine. In the game, the user kicks a box, which falls off the cliff. If we had a lower resolution timer, we could end up skipping a few milliseconds worth of calculations since the timing would be rounded, and because the server and client are different computers, they will be rounded differently. The box could end up in two different positions or have two slightly different paths of flight. The server may end up seeing it smashing an ant, while the client sees it landing in front of the ant. But since the server saw it smash the ant, the client is told the ant is smashed, and the user is sitting there thinking, "wtf m8?".

I know Mirage has nothing as extensive as that, but its just to give an example of how badly it can mess things up. Another is movement. Client rounds up, sees its okay to move, sever sees it not being okay, rejects the packet, client moves anyways, the client is now offset by one tile. Of course, that can and should be fixed with a server-side check, but then the server still has to waste time and bandwidth on that extra packet that is just dropped.

[William]

Okay, I see what you mean. But still, the client and server is not dependent on each others tickcount. The client basicly sends it when his ready, and the server is always open to receive it. So even if it doesn't correlates together doesn't mean it will affect it. Are you sure it could mess things up?

Cause it might be worth adding it since it helps against speed hacks. Although I'am considering adding a check serverside, that will check if more than for example 10 movement packets has been sent the last second or so. If so, kick or ban.

[Spodi]

Well if the timings aren't critical, which I guess they aren't, then theres no harm.

[William]

Do you think that doing this to the tickcount will prevent speed hacks from having a affect?

[Spodi]

Not sure, I haven't dealt much with speed-hacking.

[supermatthew]

to counter speed hacks, i would do something like this.

Although i work with .net, which has threading support, and would make it easier.

in some form of server loop(a seprate thread in vb.net, maby part of the server loop/another timer):
10 second delay, or even longer
send request to all clients for time

Client responce:
it includes seconds and minutes, and hours maby?
Do a check from last request to get difference, allowing for rollover, like 55 seconds, 2 min was last, and now its 25 sec, 3 min, a 30 second difference, now you take this difference, and something like

TimeDifference = (CurrentReponceDiff / DelayTime) * 100
which would be 300%
and lets say you want there to be a 150% maximum, for lag and such, anything higher and client would be banned.

lot less work with server, cause your not checking everytime they move.

[Matt]

to counter speed hacks, i would do something like this.

Although i work with .net, which has threading support, and would make it easier.

in some form of server loop(a seprate thread in vb.net, maby part of the server loop/another timer):
10 second delay, or even longer
send request to all clients for time

Client responce:
it includes seconds and minutes, and hours maby?
Do a check from last request to get difference, allowing for rollover, like 55 seconds, 2 min was last, and now its 25 sec, 3 min, a 30 second difference, now you take this difference, and something like

TimeDifference = (CurrentReponceDiff / DelayTime) * 100
which would be 300%
and lets say you want there to be a 150% maximum, for lag and such, anything higher and client would be banned.

lot less work with server, cause your not checking everytime they move.

No, but at a fixed time, you're sending a shit load of packets back and forth. Not very bright, imo.

[Spodi]

You could easily just do it once every minute or two. It doesn't have to be often.

I have no idea how threading would help at all, unless you are using the thread in a completely stupid manner like spawning a new thread just to send the packet after an elapsed amount of time.

[William]

Send packet from server to client
Both server and client start timer

Send packet from server to client
Both client and server stop timer
Client sends server the deltaT

compare with server's deltaT

If it's significantly different, mark the client

Yeah, that's a very easy method indeed.

[supermatthew]

You could easily just do it once every minute or two. It doesn't have to be often.

I have no idea how threading would help at all, unless you are using the thread in a completely stupid manner like spawning a new thread just to send the packet after an elapsed amount of time.

threads are not bad. in vb.net, you would do something like

Code:

dim T as Threading.Thread
sub form1_Load(byval sender as object, byval e as system.eventArgs) handles form1.load
T = new threading.thread(addressof CheckClientsSpeed)
T.Priority = Priority.low
t.Start
end sub

Code:

sub CheckClientsSpeed()

while true
threading.thread.currentThread.sleep(40000) ' 40 seconds
'um using my engine as an example

Dim myEnumerator As IDictionaryEnumerator = _USERS.GetEnumerator()
  While myEnumerator.MoveNext()
   If UserOnline(DirectCast(myEnumerator.Value, clsPlayer)) Then
    SendTo(DirectCast(myEnumerator.Value, clsPlayer), PTD.TimeRequest)
   End If
End While

end while
end sub

or if you were more oop

Code:

sub CheckClientsSpeed()

while true
threading.thread.currentThread.sleep(40000) ' 40 seconds
'um using my engine as an example

SendToAll(PTD.TimeRequest)

end while
end sub

threads reduce the strain on a program and can speed things up alot, but you run into lots of problems accessing forms with other threads and stuff.

[Matt]

You could easily just do it once every minute or two. It doesn't have to be often.

I have no idea how threading would help at all, unless you are using the thread in a completely stupid manner like spawning a new thread just to send the packet after an elapsed amount of time.

threads are not bad. in vb.net, you would do something like

Code:

dim T as Threading.Thread
sub form1_Load(byval sender as object, byval e as system.eventArgs) handles form1.load
T = new threading.thread(addressof CheckClientsSpeed)
T.Priority = Priority.low
t.Start
end sub

Code:

sub CheckClientsSpeed()

while true
threading.thread.currentThread.sleep(40000) ' 40 seconds
'um using my engine as an example

Dim myEnumerator As IDictionaryEnumerator = _USERS.GetEnumerator()
  While myEnumerator.MoveNext()
   If UserOnline(DirectCast(myEnumerator.Value, clsPlayer)) Then
    SendTo(DirectCast(myEnumerator.Value, clsPlayer), PTD.TimeRequest)
   End If
End While

end while
end sub

or if you were more oop

Code:

sub CheckClientsSpeed()

while true
threading.thread.currentThread.sleep(40000) ' 40 seconds
'um using my engine as an example

SendToAll(PTD.TimeRequest)

end while
end sub

threads reduce the strain on a program and can speed things up alot, but you run into lots of problems accessing forms with other threads and stuff.

This is NOT VB.Net. So nobody cares what you can do or how you would do it in .Net.

[Matt]

It's not vb .net, however the concept is the same. Shut up Matt.

Ban me. Mr. I don't give a fuck anymore cause Willam don't give a fuck and I can't figure out how to enforce rules because the owner of the site doesn't do it.

[William]

It's not vb .net, however the concept is the same. Shut up Matt.

Ban me. Mr. I don't give a [edit] anymore cause Willam don't give a [edit] and I can't figure out how to enforce rules because the owner of the site doesn't do it.

What are you talking about?

[Matt]

Ask Dave.

[Robin]

Don't start going off-topic.

If you've got something to say, keep it to Pms and Ims.

[Matt]

Don't start going off-topic.

If you've got something to say, keep it to Pms and Ims.

I assume that's directed to William as well, since he was the first to really go off topic. My post before his, which was to Dave, was about something said in the topic, which was on topic.

[Spodi]

I didn't say threads are bad, I just was stating that spawning a thread for something that doesn't need a thread is bad. In this scenario, there is:
- A global game loop
- One event being raised from the thread before its destroyed
- No heavy importance of time (you can afford waiting a frame)

All of these point to single-threading. Just because you can use multithreading, doesn't mean you should. Multithreading is only faster if theres blocking operations being called (file I/O or socket I/O namely). Besides that, it is always slower than the single-threaded alternative, it just appears faster because they are in sync. The CPU has to take extra time to sort the threads and find which one needs to be updated.