Desync and why it's fixable

There's a difference between trusting the client and babying it.

Trusting the client is having it do calculations without the server doing the same work itself. It means the client says what values are, or the in case of disagreement the client wins somehow. The result is rampant hacking.

Babying the client is having the server do all calculations without the client doing the same work. Until the server tells the client what's going on, the client is totally clueless. The result is rampant desync. (Actually trusting the client also causesmassive desync but that's server-side so it's usually less visible to players.)

I think that PoE should baby the client a little, because exposing all calculation client-side would be a blueprint for hackers to exploit flaws in calculation code on the server side. But there's a limit on how much babying a client can take without desync performance turning to shit.
When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
Last edited by ScrotieMcB on Dec 3, 2013, 1:24:00 PM
How about if, when the player clicks on the ground to move, the client sends not only this action to the server, but also the TIME at which the player clicked,
the server then immediately corrects the position of the character ON THE SERVER accordingly.

Ex: The server receives this: "player clicked this coordinates 0.1 seconds ago"
=> player is therefore already "here" (a few steps foward) and mooving towards said coordinates.

Spoiler
As I said before, instead of thinking of why it can't work, try to figure out how it could work.
Start with an imperfect/unfinished idea and... improve upon it.
Last edited by Dreamer000 on Dec 3, 2013, 1:35:58 PM
To keep divergence in check, you need to know about discontinuity and deal with it.

For the love of... the client, in a multiplayer environment, cannot be allowed to predict seconds into the future for highly discontinuous state.

If you don't even acknowledge walking into obstacles and reacting properly (say, by informing the client ASAP), including pretty much any other state variation for seconds you simply cannot expect it to function well. You are dreaming.

There are some desynch/resynch artifacts that I don't quite understand. Superposition after a resynch being my favourite.

"
Dreamer000 wrote:
How about if, when the player clicks on the ground to move, the client sends not only this action to the server, but also the TIME at which the player clicked,
the server then immediately corrects the position of the character ON THE SERVER accordingly.

Ex: The server receives this: "player clicked this coordinates 0.1 seconds ago"
=> player is therefore already "here" (a few steps foward) and mooving towards said coordinates.

Spoiler
As I said before, instead of thinking of why it can't work, try to figure out how it could work.
Start with an imperfect/unfinished idea and... improve upon it.


I want to avoid a negativity bomb here, but the timestamp could be modified by the client. It causes potential problems.
IGN: SplitEpimorphism
This thread moves too fast.
Last edited by BGSacho on Dec 3, 2013, 2:07:41 PM
"
syrioforel wrote:
"
Dreamer000 wrote:
How about if, when the player clicks on the ground to move, the client sends not only this action to the server, but also the TIME at which the player clicked,
the server then immediately corrects the position of the character ON THE SERVER accordingly.

Ex: The server receives this: "player clicked this coordinates 0.1 seconds ago"
=> player is therefore already "here" (a few steps foward) and mooving towards said coordinates.

Spoiler
As I said before, instead of thinking of why it can't work, try to figure out how it could work.
Start with an imperfect/unfinished idea and... improve upon it.


I want to avoid a negativity bomb here, but the timestamp could be modified by the client. It causes potential problems.


Yes, I'm aware of that, hence my spoiler tag.
Last edited by Dreamer000 on Dec 3, 2013, 2:30:46 PM
"
Qiox wrote:

And why do I never see this behavior myself when I play? Simple, I only ever shift attack. The shift key is the hold position command and by always, 100% only ever left click attacking while holding shift, I never ever, ever, ever find myself getting resync'd into a room I never entered.


So the client is only sending the 'Left Click' and letting the server figure out if it's an attack click or a move click. Why not let the client send a bit of additional information, say, 'this is a Left Click AND its an IN RANGE attack'. Then the sever gets this message and says, 'nope, no IN RANGE attack possible, you must be out of sync, /oos'

This seems like the perfect place to insert an automatic /oos command.
Probably a dumb thing to ask, but isn't there a way to have a separate "back-up" server running along side the server seed you are currently playing off of and have this"back-up" server detect when you and the primary server are out of sync and about to rubber-band back giving you a grace period or 1s invulnerability to at least help prevent an auto-death allowing the player to at least spam pots when they see a slingshot?

Granted many will argue something along these lines could be exploited by using a lag switch or something but I disagree. If you were to Lag switch or try to exploit this to move through a map unharmed, you technically wouldn't be moving through the map at all. Since the server is the host of your seed and not the client you would just rubber band back to the same spot not having moved.

The only downside to something like this I could forsee is someone trying to use it to avoid a mortal blow like a vaal smash. But even that wouldn't work because you wouldn't get the grace period right when you lag switch but rather when you rubber-band back. so during that time you tried to lag switch right as vaal was smashing, you actually didn't avoid it, and took it to the face instead. The timing would have to be impeccably perfect in order to exploit it that way.

Sorry if that was poorly explained but I am at work and couldn't really take my time and go into detail.
"
Qiox wrote:
And why do I never see this behavior myself when I play? Simple, I only ever shift attack. The shift key is the hold position command and by always, 100% only ever left click attacking while holding shift, I never ever, ever, ever find myself getting resync'd into a room I never entered.


And a lot of people are aware of shift, and don't use it for a reason.

Did it ever occur, if it was this simple, the mechanics that shift+attack prevent, would just not be in the game to begin with?

You make the choice to remove the function of auto-move and auto-LoS.

This isn't a fix/cure/remedy, it is giving up one major, designed function of the game in order to minimise a not-so-designed bi product of game design.

Casually casual.

Last edited by TheAnuhart on Dec 3, 2013, 4:02:15 PM
Also, I just wanted to say that even though many people complain about de-sync and the many problems that it causes, there are good things about it too.

Yes de-sync has gotten me killed before, but after playing this game for a very long time now, I have learned to sometimes use desync to my advantage.

If you learn what can cause de-sync, you can use it to enter rooms and scope out what is in them before ever actually entering the room. for instance, leap slam back and forth very quickly in a room, then quickly change direction of your leapslam and make your guys slam against a wall or as close to it as you can get and right before you hit spam leap slam through the door and into the room of which you want to scope out. 9 times out of 10 you can de-sync yourself and check if its the right path or for CB or what not.

Granted this could be seen as cheating but if I am running the risk of dieing for no fault but the servers for de-syncing me, then I may as well get the advantages out of it too, no?

Report Forum Post

Report Account:

Report Type

Additional Info