Desync improvement: density-triggered resync

As far as I understand, currently the game engine tries to strike a balance between two events: desync, and the amount of resyncing that the client requests. Too little resync, and your character dies for apparently no reason. Too much resync, and your character bounces all over the place in an annoying manner. Here's my suggestion on one possible balancing mechanism.

1. When a map is generated, we assign each tile a "density" property, indicating how dense the obstacles around that tile are. This is a value from 0 to 1, 0 being a wide open field, and 1 being a solid impassable wall. Doorways would weigh in at around 0.9, wider corridors at about 0.5, etc.

2. We assign your character a "travel_density" property, which starts out at 0. When your character moves from tile A to tile B, we set his travel_density = travel_density + abs(density(B) - density(A)). If the character uses Lighting Warp, Leap Slam, or some other travel power to teleport to another tile C, we calculate his travel_density as though he walked through each tile between A and C.

3. When the character's travel_density exceeds the "resync_threshold" (as specified in the client's user settings), we trigger resync and set travel_density = travel_density - resync_threshold.

Thus, the character's travel_density value will steadily increase over time as he moves around -- but it will increase much faster if the character travels through any doorways, and much slower if he's walking around a wide-open area like The Old Fields. This means that the client will request resync only when it is most needed.

As an enhancement, we could also increment travel_density when the player attacks a monster, by highlighting the monster (or, rather, a place where he believes the monster to be) with a mouse and using an active skill. In this case, we could set travel_density to something like travel_density + (cumulative density along the straight line path from player to monster) / (length of that path).

This approach has some advantages and disadvantages:

* +Advantage: Triggers resync when it is most likely to be needed
* +Advantage: Relatively cheap to implement, computationally speaking
* -Disadvantage: Does not solve desync completely
* +Advantage: Provides a user-tunable tradeoff between too much vs. too little desync
* -Disadvantage: Will still produce either some rubber-banding or some desync (depending on the threshold) when the character walks through tight spaces
* -Disadvantage: Only helps to correct the position of the character; does nothing to correct the positions of monsters (except as a side-effect), so you could still die from desync even when standing still.

Ok, now please let me know why my idea is stupid :-)

So much work for those who lazy to learn how to play around desync. Its not that hard

As far as I understand, "playing around desync" implies one or more of the following:

1. Avoiding certain skills, such as Whirling Blades
2. Avoiding melee skills altogether and staying ranged
3. Building a character with an extremely high amount of leech, regen, or both
4. Spamming "/oos" via a macro
5. Auto-spamming "/oos" via a script

The reasons I dislike these solutions are as follows:

1. Detracts from the variety inherent in PoE
2. Detracts from the variety inherent in PoE in an even more drastic way
3. Detracts from the variety inherent in PoE, and requires extremely expensive gear
4. Is annoying; I want to play Path of Exile, not Path of OOS
5. Is prohibited by GGG

You should watch Helmans stream, he is the best racer that plays melee char w/o any hp nodes and he almost doesn't cares about desync.

That's some desync thread I like.

Actually constructive and trying to bounce ideas instead of crying around.
Can we get Rhys please to tear the suggestion apart? :P

I just mean that he will be the one able to judge if that suggestion is plausible and efficient enough considering current resources available to GGG. Not the ten million code-monkeys we have floating around here who seem to know exactly how GGG is working.


I really only fear that the suggestion would increase the rubberbanding immensely in places like act 1 church, interrupting the gaming experience for people less susceptible to bad action synchronisation for whatever reasons.

One could adjust the threshold there however that would make the feature maybe useless again. Maybe let users themselves adjust the threshold until a certain point? It's not really elegant and covers another suggestion I read some time ago here around but might be a good addition for those souls being plagued by Desync all the time.

A slider stating "A higher number might increase rubberbanding in favor of precise action synchronisation with our servers" might just do the thing. Of course people will complain about rubberbanding instead of desync then but that choice is on their end then. :P

+1

This solution seems to reasonably understand when and why descync occurs, and thus tries to put up a solution towards the heart of the problem.

You'd probably also want to factor in some variability to latency.


I'd think that on a really high latency, you'd just want to say **** it, and resync far more often, particularly if the player was playing hardcore; where not knowing his true situation could lead him to death. Even letting players to choose to resync at a lower threshold (more often), might not be such a bad idea (still using your formula, or whatever one GGG chooses, but with a threshold slider.)

"

I'd think that on a really high latency, you'd just want to say **** it, and resync far more often

Yeah, you're right, jitter is usually murder on any kind of sync. I'm guessing that GGG has at least some plan for addressing it, but you're right, we could introduce additional bias to the threshold based on jitter.

"

jstq wrote:

You should watch Helmans stream, he is the best racer that plays melee char w/o any hp nodes and he almost doesn't cares about desync.

Yeah, Helmann had a nice death where he was kiting 3 stone giants.
He died far away from them from a melee attack, then used /oos while dead only to find out he was actually in the middle of the mobs.

Just because he doesn't care, doesn't make it okay.

But I think it's awesome that people like a game so much they don't even care about the desynch.