Client-server Action Synchronisation

"

SinPhil wrote:

Well at least you have conceded is a lot more factors that cause desynch than before. Though saying servers are fine is hard to believe considering how many mass disconnects Aussie server has and can see just how many people dropped in global chat afterwards. Yes lag spikes and desynch are different but the fact both seem to increase together does cause people to mistakenly think they same issue. Hopefully the Aussie server was getting some attention as noticed over weekend I was getting diverted to Singapore for all incidents and haven't had my usual disconnects today since back to Aussie server. Now if my ISP would only listen half as much as GGG I can play some HC lol because they are 90% of my problems causing huge lag spikes that add to mess (latency sitting on 30 with spikes up to 3000).
Thanks for your continuing efforts.

Nope the disconnect was just a few hours late

A point I see brought up often is the networking being done through TCP/IP.

This leads to packets that are outdated being sent between the client and server that are absolutely useless, as the game is too fast moving and reliant on instantaneous and reliable communication. The alternative of UDP is the common practice for games with similar mechanics.

When I asked chris why TCP was used, I was told it was done out of convenience, because the devs knew TCP better. I can only see that this choice was made early on and has had far reaching consequences.

Even if it would require a lot of money, time and effort, I can't help but think that if something were done to switch the game towards UDP networking that synchronisation would be better. I'd rather see a big change like that being worked on than various bandaid fixes to the current system which is flawed from the get-go.

I've yet to see a dev comment on the possibility of this change ever being considered, or for there to be any admittance that the current system may be flawed or at the very least, unnecessarily imperfect. Any comment would be appreciated, thank you.

"

ScrotieMcB wrote:

"

thescyphozoa wrote:

"

Drusek wrote:

Just give us a slider to decide how fast the game syncs our character: max(default) will be the current value, min will sync always (each packet). People with good connection (good ping) could put that to minimum while others could experiment with other values.

That would kill GGG's servers.

During times of ultra-peak use, perhaps. However, in general, no, it wouldn't. As Chris said, when the servers are overloaded, what they cut back on first is new instance generation (creating longer instance load times), not less resyncs.

And by extension, such a dramatic increase in load will drastically reduce the number of instances a server can handle before it stops producing/handling more instances. So they'd need to drastically scale up the number of servers they have, or improve the hardware of existing servers.

"

symban wrote:

So we got the same post from what 4 years ago?..

"

Chris wrote:

It's worth stressing that in 99% of combat events, everything feels fine.

Seems like I got stuck in that *%1 of combat events*.

You misunderstood. He was saying that 1% of the actions/mechanics the game makes use of (Like Cyclone) are most prone to causing desync, not that 1% of the player base is afflicted by more desync then everyone else.

"

Nicholas_Steel wrote:

"

ScrotieMcB wrote:

"

thescyphozoa wrote:

[Rapid resyncs] would kill GGG's servers.

During times of ultra-peak use, perhaps. However, in general, no, it wouldn't. As Chris said, when the servers are overloaded, what they cut back on first is new instance generation (creating longer instance load times), not less resyncs.

And by extension, such a dramatic increase in load will drastically reduce the number of instances a server can handle before it stops producing/handling more instances. So they'd need to drastically scale up the number of servers they have, or improve the hardware of existing servers.

Dramatic? How so?

You need to put everything in perspective. Resyncing twice as often would be more server load, but not as much server load as doubling the number of players online. A lot of the time, the number of players online is less than a third of historic peak values, so tripling resync rates wouldn't kill the servers.

Like I said in my earlier post (the one you quoted, but you left the good part out), the problem with resyncing too often is primarily that it makes the game look like shit.

frequent resyncs do not cost much, its really negligible, its a matter of choice. GGG tries to tell you this but some guys, including those "with 10 year experience as software architect" are spewing nonsense about cost-cutting

a /oos does not cost any more than any other packet youre sending, stop with crazy bandwidth talk, its laughable.

dont believe me, fire up wireshark, play poe windowed and send an /oos
see a huge difference ? yeah, me neither.

there is no cost from client side, connection is made on startup and a simple request is sent with /oos, not any different than /trade

there is no cost on server side. you were told multiple times that server load falls on instances, which are dynamic chunks of memory. no resources= cant allocate instances on heap.

in case of a resync, or /oos, server (most likely an instance method) will take a snapshot, likely of DELTA of last resync, only focused on the player within a screen or two. there is no phantom cost to this.
and then send the packet to player(s), probably piggybacked on other usual data. there are no collisions to deal with, unless you have a full party.

again, its a design decision. you might not like it, but you have to deal with it. you can say other games have a hard synch and are fine, thats all good and dandy- but stop saying asinine things about excuses or cost-cutting.

GGG could do more frequent forced resyncs, but their ideology it will introduce more jarring. and if you do them as frequent as .3 seconds, might as well use hard sync model anyway.

GGG chose to go with predictive model and it will not rewrite a product in its release, pretty much from scratch. no software company in the world will, ever. thats just common sense.

So.. if the un-fun hit mechanics were taken out completely, this would help the desync?

Win-win!

"

Chris wrote:

All online games have this situation. The server has to dictate whether things happen or not, but there's a 50-250ms delay before data gets to the server and back. There are three ways that games can solve this:

• Trust the client. This means people can cheat, but the results are instant. We will not do this.
• 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.
• Start predicting the result of the action as though the server said yes, immediately. When the server later gets back to you with a result, factor it in. This is what Action RPGs including Path of Exile do. It means that when you click to move, or click to attack, it occurs instantly and feels great. The problem is what happens when the server decides that the action can't have occurred - that's when the game gets badly out of sync.

Honestly Id like the opportunity to elect to either use the 2nd OR 3rd system.

I have decent latency, only rarely exceeding 60ms, and feel like roughly 6/100ths of a second is perfectly reasonable time to wait for the server to acknowledge my commands.
While I get that this isnt optimal for all players, I would enjoy being able to use the system myself.

I have an suggestion.
One of the worst misfortunes of these flaws is teleporting in room full of monsters. Mostly it is in room you haven't visited yet, therefore - monsters. Why don't you include server side mapping of already visited parts of an instance, so character can't be teleportated in those unmapped areas.

On the subject of constant re-syncing being jarring, I feel there is one spot where this would be fair. I believe that any time you are stunned (or block stunned), you should automatically /oos. It's already a jarring situation where your survival is instantly much more threatened and you need to understand what's really going on.