Desync problem

[von_paulus 0]

Hi,

Can anyone explain me what causes desync?, Is it only a communication problem?

I've got a:

               PIV 2.0Ghz

               512MB RIMM

               Geforce 1

               Windows XP

               ADSL (512K download,128 upload)

It's not bad for a PC, but the fact is, that me and my friends with similar machines and similar connections (cable and ADSL), are getting problems with desync. The pings seems to be allright between 30 and 200 (depending on the server). But we notice that our values of desync are bigger than other players playing in the same server.

Is it a problem with our ISP's?

Is there any way to fix the desync?

Will the next client patch help solving this problem?

Please can anyone help?

Thanks

[ACES_KEVIN 0]

Maybe the geforce 1...........it might not be capable of running OFP to fast causes some slow FPS and the resulting desync!

Kevin

[von_paulus 0]

I don't think so. I said that my friends have similar computers... not equal, one at least gots a gforce4 4600, and another a gforce4 4400, and the desync it's still the same. Besides I run the game with 1024x768 32 bit, but with low detail.

But I forgot to mention one thing... We are using Microsoft Game Voice (which uses Microsoft Messenger) for voice communication. Can this be a cause for desync?

Thanks for answering ACES

[Mister Frag 0]

A slow video card will affect the framerate, but not the network bandwidth or stability, which are the only things that should have any impact on desync.

The GameVoice uses network bandwidth, so that could be behind the problem. Have you tried hosting a private game to see how the desync does? It would also let you keep a close eye on the bandwidth requirements using a tool such as NetStat Live! from AnalogX.

[von_paulus 0]

Thanks Frag,

We have already tryed to host, and the problem with the desync its the same.  

That seems to be a good ideia to monitor our connections with and without Gamevoice. If the problem is in the Gamevoice I'll report it here, maybe then, someone thinks twice before buying it.

I think that one of the problems might be the stability of our connection. Our ISP's here in Portugal, are making a campaign, in order to get new subscriptors for the service, offering free traffic until the end of the year. So maybe the connections aren't really stable as they should be, cause a lot of people are getting advantage of free traffic, and they spent 24 hours a day with their PC's connected to the internet to download all kind of things (you may imagine) from the Kazaa's and newsgroups. That might be one reason.  

Could you or anyone tell me what values should be considered "normal" (or suficient) for the Bandwith and for the desync?

[JRMZ 0]

a normal desync = 0

[Mister Frag 0]

By the way, I play privately hosted games exclusively, and all of the players have the GameVoice hardware. We don't use the GameVoice software however, we use OFP's built-in voice communications using the DirectPlay network code implementation.

[LBGS_Stewart 0]

ok people have asked what causes Desync, but what exatly is Desync??

[Mister Frag 0]

I'd like to hear one of the developers answer this one, but my understanding is that a desync occurs when a client is in an inconsistent state, i.e. the knowledge it has does not match the state that the server and other clients are in.

I further believe that using the Sockets implementation increases the possibility of getting a desync, since it uses UDP packets, which do not ensure delivery of the packet, and depending on the network's reliability, crucial game state information may not reach a client.

[suma 8]

6--></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Mister Frag @ Nov. 24 2002,076)</td></tr><tr><td id="QUOTE">I'd like to hear one of the developers answer this one, but my understanding is that a desync occurs when a client is in an inconsistent state, i.e. the knowledge it has does not match the state that the server and other clients are in.<span id='postcolor'>

Your explanation is correct.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">I further believe that using the Sockets implementation increases the possibility of getting a desync, since it uses UDP packets, ...<span id='postcolor'>

DirectPlay also uses the same UDP packets, and even when using DirectPlay, most information is sent as non-guranteed in OFP. When talking about sockets, we are not using sockets "instead" of DirectPlay. We implemented our own layer with those features of DirectPlay OFP needs (and with some features OFP can use, but DirectPlay does not provide), and this layer is used instead of DirectPlay (including guaranteed message delivery when necessary).

[Balschoiw 0]

Are you located in germany ?

Have you got Telekom ADSL

This would explain your problems, as DSL is not fastpath and

Telekom connections are known to be not the best at all.

[von_paulus 0]

Hi,

Now I'm pretty sure what is the problem... It's bad and lack of reliable communications that causes all the troubles. Not GameVoice.

For example, when we play at afternoon (when most people are at work or in school) the Desync is almost inexistent. But at night, well...

So the problem is with our ISP's (here in Portugal). They just don't have enought bandwith or whatever, to support all the customers. And still they want more people to join the service  

Anyway thanks all for trying to help me with this problem. This is a great  community, and OFP it's the GAME ! 

[Mister Frag 0]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Suma @ Nov. 25 2002,04:00)</td></tr><tr><td id="QUOTE"><Snip>

DirectPlay also uses the same UDP packets, and even when using DirectPlay, most information is sent as non-guranteed in OFP. When talking about sockets, we are not using sockets "instead" of DirectPlay. We implemented our own layer with those features of DirectPlay OFP needs (and with some features OFP can use, but DirectPlay does not provide), and this layer is used instead of DirectPlay (including guaranteed message delivery when necessary).<span id='postcolor'>

Suma, I actually just read your comment, and was surprised to read that your socket implementation is still built on top of DirectPlay -- I assumed it was using straight Winsock calls.

Be that as it may, this brings up an interesting question/possibility: having voice communications while using Sockets.

Given that DirectPlay is still being used, could VON be implemented for Sockets?

[suma 8]

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (Mister Frag @ Nov. 30 2002,02:40)</td></tr><tr><td id="QUOTE">Suma, I actually just read your comment, and was surprised to read that your socket implementation is still built on top of DirectPlay -- I assumed it was using straight Winsock calls.<span id='postcolor'>

I am sorry, but you read my comment wrong. Our socket implementation is not built on top of DirectPlay. Try reading it once more, more carefully this time.

[Mister Frag 0]

Oops -- my bad!