We should probably move this to the MP forum since it went beyond "Ask Conitec" a while back.


Quote:

The problem I encountered with ltency was, that the data send by the server was 100ms-300ms old



That's pretty high latency. Note that latency has nothing to do with the speed of you connection. It has everything to do with the number of "hops" you packet takes (ie: network topology) and to a lesser degree the speed of the server computer.

Lag, as I define it in my classes, is the human experience of time synchronization. One factor is the latency and the other is the clients computer (slow client computer = high lag).

I just wanted to say this so that we have a clear understanding that you can have high latency and low lag (by hiding the lag).

Now then...

Allowing the client to handle it's own updates is bad for several reasons. Cheating is one but actually not the most critical one. The worst reason is that your simulation will fall out of sync incredible fast. Consider one client and one server. If the client handles their own updates, no problem... it's no differnet than having the server do it. But now let's up that number by four. With five players, each INDEPENDENTELY handling their updates, you will have five people giving you five versions of where they are. Or in another implementation, you have to wait two hops to find out where someone is: one hop for the client to update the server and then another hop for the server to update other clients. In other words you introduce even MORE latency this way. As well, allowing collisions on the client suffers from he same problem: collision on one client is not guaranteed on every other client and thus your simulation is out of sync again.

Trust me, in a Client/Server architecture, the only way you SHOULD do it it is to have the server be the ONLY one in charge of the simulations and updates. This will actually reduce latency and perserve the uniqueness of your simulation. It makes things easier I assure you.

The reason you are having problems Firo is most likely a bad Dead Reckoning algorythem (either your's or Conitecs). A good one will allow you to effective hide latency and reduce lag. The worst that will happen with a DR algorytem is that you will have occasional "warps" and "snap backs" when the latency gets so high, the simulation is way out of synch and the client has gone beyond the limits of the DR routine. There are several techniques you can us and I recommend you either search programming books (no matter what the languge, the routines are the same) or see what google pulls up.

A7's dead reckoning works great for few players. For large number of players (say 10 or more), the fact that it sends updates to all players all the time eats up bandwidth and that is not a good thing. So dont' give up on server updates; you'll be thankfull you didn't in the long run!


FUTUR-E-SCAPE: The Future Landscape of Education and Entertainment.