Fixing the infamous "desyncing" problems.

[Robin]

**Desyncing**

It seems a lot of kids have been blindly playing around with their source trying to fix this problem even though they don't understand what it is, or how it occurs.

This isn't going to walk you through the source edit, as it stems from a lot of programming mistakes, which were originally made by Consty with his Mirage ORPG. Now, every engine, source code or game which stems from this ORPG has the same problem.

Desyncing.

Basically, this is where the client has the player's X and Y stored, but has them stored as different numbers to the server. What really matters, overall, is what the server has the X and Y set. If the client has the X and Y set to something different, it's going to get to that terrible scenario.

A player walks to the edge of a map, tries to go into the next area, and gets stuck on 'Receiving map…'

It's terrible.

There are a few different systems which cause this error, but a common programming mistake which allows it to happen.

I'll first list the things which cause desyncing. Warping, kill tiles, shoddy respawns and lag.

Now, it's not general warping which causes desyncs. It's what I call 'Unprepared warping.' This is where an admin uses /warptome on your player. Your server X and Y are set to different values, it sends those values to the client, but processing input and various other systems is still going on in the client. This is because of...

**GettingMap**

Learn to use it. If you're going to warp a player, make sure their client has GettingMap set to **TRUE**. If you don't, they're going to get unsynced every single time they move whilst you warp them.

**Kill Tiles.** If you kill them whilst they're moving, they're going to get desynced. Make sure GettingMap is set to TRUE as the player dies.

**Shoddy Respawns.** Make sure GettingMap is set to TRUE as the player dies. If it isn't, they'll move whilst they're dead, and get desynced.

**Lag.** Perhaps the biggest problem of them all. What you need to do, is instead of just using "SendDataToMapBut…" you need to send **confirmation** to the player who's just moved. If you don't, the client is by itself and desyncing can happen very easily.

[damian666]

hmm… this is actually great stuff to read...

personally i think the biggest cause within your list is lag.

well, atleast for me it is XD

confirmation huh...

well... this gives food for thought.

Damian666

[Sr_Sirius]

And… you try to say, the desyn no is possible fix by code?.. or is hard to done?

[damian666]

whats he saying, and correct me if wrong, is that teh de-sync is caused by several "old"
programming mistakes, things that have been done wrong from the start.

it needs a lot of rewriting if you ask me.

and its proberly to much for the likes of us…

Damian666

[Robin]

@[SB:

> Damian666 link=topic=50503.msg527672#msg527672 date=1250752228]
> whats he saying, and correct me if wrong, is that teh de-sync is caused by several "old"
> programming mistakes, things that have been done wrong from the start.
>
> it needs a lot of rewriting if you ask me.
>
> and its proberly to much for the likes of us…
>
> Damian666

Not a lot of rewriting, really. Prepping a player for warp is easy to work in.

[The New World]

Heres a kid's De-Sync Fix Attempt.

http://www.touchofdeathforums.com/smf/index.php/topic,50571.msg527773.html#msg527773

[Robin]

Eurgh, there was a huge discussion about the problem a while back. That solution was shown to be a bugged out "fix".

You don't want to do something horrible like that, you want to _fix_ the problem, not try and bypass it.

[The New World]

**Solution**

Eclipse Stable Conversion

[Sr_Sirius]

@Rose:

> **Solution**
>
> Eclipse Stable Conversion

Eclipse Stable use a fix post on this forum… and this fix its crap.

[Robin]

@Rose:

> **Solution**
>
> Eclipse Stable Conversion

Eclipse Stable doesn't have a decent fix. You can tell, because Damian just posted in this topic. -_-

[damian666]

Robin is right guys, there is NO fix in Stable that addresses the desync.

maybe, just maybe, its because there is less lag and stuff on stable, that it is not seen as much as it used too…

but no, we didn't have the fix integrated yet.

and Robin, you stated it would not b that much of a rewrite, but that's only for warping right?

because i noticed that the lag was and is the biggest problem on this subject, for me.

also, I'm no kid, but hell yeah, I'm a noob XD

i looked at processmovement, and saw it was updated with playermove if I'm correct out the top of my head.

so, i added a extra one on the end, yeah, noobish XD, but it seems to have gotten less.

not totally fixed, but less.

of course a half arsed fix like that i wont put in Stable, but for my own private game, hell... why not XD

but can you tell me why that seems to help?

because i really want to fix it, but till now i cant even see where the damn client sends the coordinates to server :/

Damian666

[Robin]

@[SB:

> Damian666 link=topic=50503.msg527805#msg527805 date=1250778303]
> Robin is right guys, there is NO fix in Stable that addresses the desync.
>
> maybe, just maybe, its because there is less lag and stuff on stable, that it is not seen as much as it used too…
>
> but no, we didn't have the fix integrated yet.
>
> and Robin, you stated it would not b that much of a rewrite, but that's only for warping right?
>
> because i noticed that the lag was and is the biggest problem on this subject, for me.
>
> also, I'm no kid, but hell yeah, I'm a noob XD
>
> i looked at processmovement, and saw it was updated with playermove if I'm correct out the top of my head.
>
> so, i added a extra one on the end, yeah, noobish XD, but it seems to have gotten less.
>
> not totally fixed, but less.
>
> of course a half arsed fix like that i wont put in Stable, but for my own private game, hell... why not XD
>
> but can you tell me why that seems to help?
>
> because i really want to fix it, but till now i cant even see where the damn client sends the coordinates to server :/
>
> Damian666

The problem is that the client only sends the 'Move' packets to the server, whilst processing blocked tiles and things by itself using the CanMove function. If the client thinks it's in a different position to the server, then it'll go to the edge of the map, set GettingMap = TRUE because it thinks it's going to change to another map, but the server will think it's in a different place, meaning the map is never sent.

Here's an image which shows the problem.


As you can see, the server thinks the player is 1 spot away from the edge of the map, but the client thinks the player is actually on the edge of the map. This means that if the player tries and moves to the right, it'll set GettingMap as TRUE, as it thinks it should be changing to the next map, but on the server, the player isn't yet ready to move to the next map.

When this happens, GettingMap = TRUE causes the client to lock up, not allowing any movement.

This shitty fix which is being posted around doesn't do anything, really, as it's obviously programmed by someone who doesn't know what the problem actually is.

What you need to do, is make sure the client and server have the player set in the same spot at all times. Then, this problem will never happen.

[damian666]

ok… help me out here then, i cant find the friking command to send the coordinates to server.

am i right if i think its "Call SendPlayerMove" ?

if i know what actually moves the player, thus updating the coordinates, i think i could figure it from there XD

Damian666

[Robin]

Just follow the path through the code. It all starts with input, which calls CanMove.

Follow the packet trail from there.

[damian666]

ok, thanx for the starting point, i was really at a loss, and didnt knew where to start looking XD

Damian666

[Pikachu]

The packet trail goes like this:

1) Player tries to move
2) Client checks if player can move
      |
      -> If player can move, send the PlayerMove packet, which contains the direction the player is trying to move to. It does not contain the new coordinates.
          1) Server recieves the packet and moves the player
      |
      -> If the player is trying to out of the map bounds, check if there is a map switchover for that direction. If there is:
          1) Send a RequestNewMap packet to the server. (Does not contain coordinates, just direction)
          2) Set GettingMap to True
          3) Server checks if player is moving out of the map bounds (using the server coordinates). If the player is:
          |
            -> 1) Switch maps
          Otherwise:
          |
            -> 1) *server does nothing here* Server should be sending the players X/Y coordinates to the client, as well as telling the client to set GettingMap to False

[Diskmaster]

mabey you should take out number 3 up there? but, I really believed that eclipse stable fixed the desync bug… I started using it from the day it came out and I have only once been stuck receiving map (and that was my fault)...

[emblem]

Thanks for the food for thought Robin.
I knew what the issue was, I just never really thought about it.

And +1 internets for not posting code ;)

[tiggilyboo]

The best way to fix this is to use something a bit faster than winsock controls in VB6\. Using VB in the first place was a horrible mistake.

In other words, Either use winsocks API's or, use a different coding language.

[Spencer]

I get this a lot now, since I'm dealing with some caves and such I use Warp. The warps work fine, when i exit the cave and decide to go North to a map switchover it pauses. So then I am forced to warp to a different map.

[Robin]

@Tiggilyboo:

> The best way to fix this is to use something a bit faster than winsock controls in VB6\. Using VB in the first place was a horrible mistake.
>
> In other words, Either use winsocks API's or, use a different coding language.

Feel free to open your mind in the future.

This isn't anything to do with the language or the socket system. It's to do with the way they're programmed.

Using other programming languages doesn't inherently make your program better. If you're doing unprepped warps, with the same client-side checking system, it would fuck up no matter what language you were using.

[Godlord]

@Tiggilyboo:

> The best way to fix this is to use something a bit faster than winsock controls in VB6\. Using VB in the first place was a horrible mistake.
>
> In other words, Either use winsocks API's or, use a different coding language.

Port it, you'll still have the same issue because you inherited the same issues in the port, which obviously means it has nothing to do with any libraries and programming languages at all.

Regards,
  Godlord.

[Robin]

@Godlord:

> Port it, you'll still have the same issue because you inherited the same issues in the port, which obviously means it has nothing to do with any libraries and programming languages at all.
>
> Regards,
>   Godlord.

gives Stephan 5 internet points.

[Scorpious2k]

@Robin:

> The problem is that the client only sends the 'Move' packets to the server, whilst processing blocked tiles and things by itself using the CanMove function.

And…

> What you need to do, is make sure the client and server have the player set in the same spot at all times. Then, this problem will never happen.

Most of my experience has been with a 3D game (I am a developer on eqemulator.net) but as I look at the code here, I wonder *why* it only sends the move. Why not send the client X/Y for the player, let the server validate and if it rejects the move, send back the old coordinates or makes this the new position if it accepts the move.

This would keep both in sync and remove a little of work off the server…

[Mellowz]

@Scorpious2k:

> And…
>
> Most of my experience has been with a 3D game (I am a developer on eqemulator.net) but as I look at the code here, I wonder *why* it only sends the move. Why not send the client X/Y for the player, let the server validate and if it rejects the move, send back the old coordinates or makes this the new position if it accepts the move.
>
> This would keep both in sync and remove a little of work off the server...

Well, it's fixed anyways.