Client-server Action Synchronisation

"

Measure overall entropy around the player and force a resync if it exceeds some threshold. The problem is that by the time the resynced information gets to the client, more actions could have occured.

This seems to be good, couldn't you predict the actions of the monsters since they are actions on your server and then resynch? just a question.

"

oBLACKIECHANo wrote:

"

sidtherat wrote:

So nothing will change.

World of tanks would like to have a word with you guys on how to make synchronous system smooth as butter.

You went for cost saving model and it is clearly visible. But with a lot less players than even few months ago you can try sending full state periodicaly. Some of my desync deaths are so bad that playing poe is simply revolting after experiencing smooth as butter gameplay of d3

And while d3 obviously does not have few perks neither does poe. D3 by design and poe by avoidance. In poe any movement based build is so desync prone that it is a noob trap. Same with stun. Any stun/chill/freeze build = desync. Ive never desynced as much as with glacial hammer plus ele prolif. It is simply revolting experience. So - keeping to your explanation- desync resons are the very mechanics players avoid like a plague: movement, stun, body blocking..

If you're dying to desync after you've been playing the game a while and you know what it is, it's because you're shit at the game. It's easy to avoid and a macro can solve desync whenever it does happen.

And that is why it's bullshit. "DESYNC IS A GAMEPLAY FEATURE!!!!! SOOOO HARDCOOOOORE!!!!!!"

I've played with Reave the most. On my current character, I have .13 APS and what happens? I spend a few moments slashing a mob that doesn't get hit, even if I have Resolute Technique. I usually play between 250 to 400 ms. At midnight, it falls down to 140 or so (SG gateway, the 250 one was from US but it had problems for the past month) and you know what changed? Only the length of time before the monster gets free hits.

Heck, sometimes I attack an immobile totem for a good three seconds and it doesn't die. Either I oos or move away and attack again.

I have lost count of the times I thought I was in the clear , only to be whisked away right back in the center of a lethal mob.

I just find it idiotic (pardon the term) to have the mechanics you want in this game to make it SOOOO HARDCOOOOORE!!!!!! are the same ones that causes desync, based on your chosen architecture. Have no one actually tested this? I've lost count how many times I've been Vaal Smashed or Touched by God from halfway across the Oversoul/Dominus that's looking in the other direction.

"

Nicholas_Steel wrote:

One of the reason D3 desyncs less is because all non-sustained attacks will connect. Although you can Dodge attacks in D3, D3 treats dodging as a simple % chance to dodge the attack as the calculation is still performed even if you physically moved out of the way of the attack (There are a handful of exceptions though, certain specific skills in the game will allow the player to move out of the way without risk of being hurt by the attack).

With POE something like 99% of attacks can be dodged by moving out of the way of the attack, completely avoiding damage in the process! This approach is much harder for a prediction model to handle well.

There are also critical hits that the client might not know has occurred, which stunned you/an enemy momentarily causing you/an enemy to go out of sync with the server!

And the trusty ability to have your/an enemy attack outright fail/miss.

Remove these mechanics and it will be as stable and perfect as D3's infrastructure but the gameplay will suffer.

Well said, and all those blaming all their failures on 'desynch' .. Man up or pack up !!! :P

I can't speak for Hardcore but in Standard if desynch happens and you die everytime or a good
number of time then there something wrong with your build.. I desynch loads due to my faster attack character but even if I do I rarely die ( probably have but I've always picked myself back up pretty soon because its a rare occurrence )

i'm sorry, but personally I think the opinion that synchronous movement a la MOBAs is a bad idea is just plain stupid. When you play MOBAs you *are* the unit you control, which is contrary to what you just mentioned, and trying to imply that MOBAs aren't as time critical/sensitive to lag as PoE is laughable at best.

"

conall88 wrote:

i'm sorry, but personally I think the opinion that synchronous movement a la MOBAs is a bad idea is just plain stupid. When you play MOBAs you *are* the unit you control, which is contrary to what you just mentioned, and trying to imply that MOBAs aren't as time critical/sensitive to lag as PoE is laughable at best.

Give this man a damn medal please.

Repeating same excuses about desync since 2012 but noting improved nor fixed.
Just getting worse and worse.

It's been almost 2 years but still same or worse.
What is GGG actually doing?

One thing I don't understand is OP said that more servers aren't the solution to the problem, however in the first few paragraphs you wrote:

"

Wait until data arrives back from the server before doing anything. This is a very common strategy in RTS and MOBA games. If you click to move, the unit will only start moving once the server says so, which is 50-250ms later. If you are close to the server, you'll quickly get used to the lag and everything feels pretty good. If you're far away (New Zealand, for example), it feels like you're playing drunk. Every time you issue an order, nothing happens for quarter of a second. This does not work well for Action RPGs - the immediacy and pace of combat requires that actions start to execute instantly.

Doesn't this paragraph mean that if the servers were closer to people's locations then you could use method 2 above? Obviously you'd need many more but what is the optimal server distance to use method 2 above?

Something I didn't see in your list of improvements, but which is probably worth considering is to have the server share its pathfinding routes with the client, and have the client adjust pathing appropriately as that information is received. Doing this right is a bit tricky, as the client will want to then compute a path from the character's current location to the nearest vertex on the path it received from the server, so as not to do silly backtracking. You might just have the client rubber-band if there isn't a straight line path to one of the vertices on the received path. The hope would be that in many cases at least the first vertex of the client and server path will roughly agree, and the client might be able to receive the correct server path before anything too fancy (and potentially incorrect) has taken place client-side.

A little bit of client-side velocity warping would also be worth considering. For things which aren't so far off their correct position so as to warrant rubber-banding yet, it might help sync to give a small directional adjustment to the allowed movement speed of their displayed locations on the client (while they are moving), based on the difference between their position and the reported server-side location at a given point in time. That is to say, add a small adjustment to their movement speed based on the dot product of their direction of travel and the vector between their client and server locations, so they're just slightly slower on the client if moving away from their server position, and slightly faster if moving toward it.

I'm not sure whether this is appropriate for the players, it might feel wobbly, but for monsters it might help control small amounts of desync before they have a chance to pile up into larger distances. Also, the viability of that tactic would vary based on how often the client receives updates on the correct positions of things on the server. You might limit the amount of time that the speed adjustment applies for or taper it off somehow in order to limit the total displacement it can be responsible for to exactly the displacement that was observed.

"

ignarsoll wrote:

"

Chris wrote:

• Other than skill-specific improvements, our experimental changes so far attack the problem by causing more intelligent resyncs. There's a very tough trade-off between small frequent resyncs (which make the game feel jittery but it's kept in sync) vs less-frequent but larger teleports. Users have come to associate a resync with being out of sync, so updating them more frequently makes them feel like the sync is worse rather than better.

To elaborate on the last point and clarify the problem in a nutshell: in order to keep hardcore game mechanics like body-blocking, stunning and missing while also preventing players from manipulating combat results, small amounts of desync will occur naturally. There is no way around this, due to the speed of light. An ideal solution from Grinding Gear Games would be to very rapidly detect and correct those sync problems, putting things back where they should be. We have not yet delivered this solution to our satisfaction. Once we have, though, you may notice periodic resyncs, which may initially feel like you're out of sync all the time. That's because the system will be acknowledging it and correcting it, rather than assuming that it's all going to be fine and letting you end up two rooms away, pinned against a wall.

I learned to live with desync, understand why it exist and appreciate it.

Less deaths caused by desync would happen if GGG just "stops the simulation", wehn client/server mismatch. So if you lag/desync, the server will also stop as long as it takes. At the moment, you usualy die because the Server continue with the game "off screen".
In Diablo 3 I survived and 10 second lag/desync right into an Elite Mob group because the server waited too.
This may not so valid in group play (no clue how this works in Diablo 3) but at least in solo play I prefer a short stop in gameplay over a heavy desync.