Reasons Why Desync Happens (Thoroughly Explained /w Cited Commentary On Fixes & Focuses Info)

I don't believe that it "cannot be fixed" as some people suggest here. Well, at least it can be improved considerably. Why not just auto resync after the usage of skills like whirling blades instead of requiring me to setup some AHK macro .................................

Also, quite sure it was better last time I played, like 5 months ago.

This game has been in beta for years. De-sync has been a part of PoE for years.

Desync will not be fixed. Learn to play with it or move on to another game.

"

darkjoy wrote:

This game has been in beta for years. De-sync has been a part of PoE for years.

Desync will not be fixed. Learn to play with it or move on to another game.

What ?
You seriously trying to justify a wontfix with it being an issue for years ? That is so wrong in so many ways ....

Of course I adapt, that is why i use AHK to re-sync myself after certain abilities. Does not mean that it needs to stay that way. If anything, it shows that it can indeed be done.

As a network engineer, I find it surprising that PoE doesn't use UDP for a portion of its information. I never did a wireshark on the game or anything while playing, that's an interesting choice.

The great part of TCP, is that you acknowledge every packet you receive (and everything you send is acknowledged) which is great for file transfers (lose a packet, corrupted installer for firmware and boom, your device is unhappy) It is also for a lot of useful information in the game world, such as picking up items and placing them places, key presses by the user and other "important" portions.

But streaming data that changes constantly being TCP doesn't make sense, as you have to acknowledge all packets, and unacknowledged ones are transferred again. Look at it this way, if a monster is walking toward you, and you miss a TCP package halfway from point A to C, once the monster is at C, does the packet about point B MATTER once the monster isn't there anymore? Of course not, and yet, we are busy retransmitting and acknowledging point B's packet when monster is at C and working his way to D.

A hybrid approach to packet transfer could alleviate SOME of the specific desync problems IF they don't have another underlying cause as well. I have seen a lot of ideas thrown around. One that I also think could help a lot with one of the major desync causes is, you click to attack monster z at point x,y. When that packet arrives at the server, if monster z isn't at x,y or within some tolerance range of that point, then a resync occurs instead of your character walking to where the monster is on the server. The part that escalates the desync is that your computer still attacks monster z at x,y. So you continue to move farther and farther from your character's position on the server. I check like that COULD potentially help as well. It would force a lot more data transfers as resyncing does increase traffic obviously, but this data transfer is going to happen at some point, better at the point that it is realized instead of later when more and more things are going farther out of sync.

What I don't get is why the server verification needs to happen in realtime. The entire game is a simulation controlled by a relative few inputs (e.g. RNG seeds, timestamped player actions, etc.). Given these inputs, the entire session could be verified at any time. Even with multiplayer, one could just treat the other players actions as inputs into separate sessions that appear to be the same "game". Maybe that's not p2p, but say player B does something, that action is transmitted to server, server transmits to player A client (at this point it's like player (e.g.) clicked with a player B mouse), and that action is re-timestamped and sent back to the server like any other action. Faster if p2p instead. The desync you'd get then would be desync between player A's and player B's separate sessions (i.e. instances), but that's minor compared to the desync we have now.

Over simplifying, obviously, but as long as the server is doing prediction, desync will never be fixed.

Hi

Kamoa:

"

I have always wondered why Diablo 3 has absolutely no desync, especially with the latest patch, the screen is always full of monsters, not a inch of desync, never.

Why not you POE ? You deserve it more.

I agree POE does deserve it more then that hogwash blizzard pretends is a Diablo series successor which they rushed into developement.

I know this will be sorted out/mitigated eventually even though this problem has been with this game since the beginning, it is still beta(but this should not be used as a complete excuse.)

cheers

"

pmenso57 wrote:

Over simplifying, obviously, but as long as the server is doing prediction, desync will never be fixed.

Yeah, prediction, everyone knows this. It can not be 'perfect' as long as not every single person playing PoE has a direct fiber optics connection to the servers.

But you can definitely improve it. UDP was mentioned. Even quick and dirty solutions like auto-resync after whirling blades, cyclone and so on would work. Sometimes their prediction just seems quite unpredictable too. I end up in rooms I could not possibly have reached, even with extrapolated directions ...

"

pmenso57 wrote:

What I don't get is why the server verification needs to happen in realtime. The entire game is a simulation controlled by a relative few inputs (e.g. RNG seeds, timestamped player actions, etc.). Given these inputs, the entire session could be verified at any time.

THIS!!!!!
+999

I also suggested in another post of mine that the rng seed could be send each [say] 5 second with a buffer of maybe three seed (15 second), so that a bot could not 'calculate' the entire session. This wuold descourage cheating. For non time-critical events such loot definition and orb effects on item, an explicit sincronization with server may be enforced.

"

HellGauss wrote:

"

pmenso57 wrote:

What I don't get is why the server verification needs to happen in realtime. The entire game is a simulation controlled by a relative few inputs (e.g. RNG seeds, timestamped player actions, etc.). Given these inputs, the entire session could be verified at any time.

THIS!!!!!
+999

I also suggested in another post of mine that the rng seed could be send each [say] 5 second with a buffer of maybe three seed (15 second), so that a bot could not 'calculate' the entire session. This wuold descourage cheating. For non time-critical events such loot definition and orb effects on item, an explicit sincronization with server may be enforced.

1) It actually makes a lot of sense to give the client inferior predictive abilities relative to the server. Client = freely downloadable = no security = easily reverse engineered; server = proprietary = (potentially) high security = (hopefully) never reverse engineered. We actually do not want the client to predict the gamestate accurately; we want it to rely on the server.

2) A 5-second random seed wouldn't help. A bot who decoded that infromation, even within the span of only 5 seconds, could line up key rolls (blocks, perhaps dodges) with favorable numbers and less important rolls (perhaps crits with no crit multiplier in the build) with less favorable numbers. Just like trusting the client with the map seed is insanely poor security, trusting the client with the RNG seed is also insanely poor security.

The client should not be trusted. With anything. Ever. The solution is better implementation of streaming technology, not moving towards a server-client mutual trust system.

@Scrotie

The actual system not only give inferior (but not zero) predictive abilities to client/player, but it gives also inferior perceptive abilities. Of course, if the games is easier for the player, it will be also easier for the bot. It seems that we already have bots even with the current system: theoretically these bots could analyze when the server is not respoding due to desync, elaborate a strategy to mitigate its negative effects, and have very high advantages over humans EXPLOITING desync (i do not think they do... it is only speculation) . Also consider that botting is mainly about collecting loot, and loot can be determined server-side.

There are many work-around for the points you have highlighted. Of course a faster/smarter net-code is also desirable, but even the fastest code have to deal with the fact that 'c' is a finite constant.