Desync and why it's fixable

"

Meistervinny wrote:

"

ScrotieMcB wrote:

None of them. When I say "the client gamestate ahead of the server," I mean chronologically ahead, not of a higher importance; the server gamestate would still always be the official one.

So how will the server decide which clients state to adopt?

None of them. You aren't understanding what I'm proposing. This is about more accurate client prediction of the gamestate, and not about letting the client arbitrate the gamestate. The client's prediction is only of relevance to that particular client; however, better prediction means the client and server agree more on monster position, hence less desync.

"

Meistervinny wrote:

"

ScrotieMcB wrote:

The client already has have the same answer as the server, using deterministic prediction methods, otherwise it predicts monster movement in a way which disagrees with the server, which would cause more desync; however, this is preventable. Assuming that system worked properly, the problem you mention would solve itself almost automatically.

You are forgetting about player behaviour, until you receive synched player information your client has "no clue" of where the other players are.
Their behaviour affects the mobs behaviour resulting them to be in a different state as well, when you have 4 players in a game you will essentially be running 4 different gamestates!

This is actually a valid point; this suggestion would not wipe out desync in multiplayer. However, that doesn't necessarily mean that it would make desync worse in multiplayer.

Essentially, you'd be going from this:
- yourself: immediate
- monsters: delayed
- other players: delayed
to this:
- yourself: immediate
- monsters: immediate
- other players: delayed

In any case where you have immediate objects interacting with delayed objects, you introduce significant desync risk. So in the current situation, you interacting with anything is likely to cause desync, but other players' interactions with monsters is less likely to cause it (which is why sometimes you can see other players desyncing in group play, when that player isn't aware of it). Under my suggestion, other players interacting with anything is likely to cause desync, but your interactions with monsters are less likely to cause it.

Although predicting the exact results of such a change is difficult, I believe that overall this would be for the best, even in multiplayer, because the monsters you are fighting wouldn't be desyncing on you as much, while the monsters your teammates are fighting may be desyncing on you more. I think that's a trade many of us would be willing to make.

"

ScrotieMcB wrote:

This is actually a valid point; this suggestion would not wipe out desync in multiplayer. However, that doesn't necessarily mean that it would make desync worse in multiplayer.

Essentially, you'd be going from this:
- yourself: immediate
- monsters: delayed
- other players: delayed
to this:
- yourself: immediate
- monsters: immediate
- other players: delayed

In any case where you have immediate objects interacting with delayed objects, you introduce significant desync risk. So in the current situation, you interacting with anything is likely to cause desync, but other players' interactions with monsters is less likely to cause it (which is why sometimes you can see other players desyncing in group play, when that player isn't aware of it). Under my suggestion, other players interacting with anything is likely to cause desync, but your interactions with monsters are less likely to cause it.

Although predicting the exact results of such a change is difficult, I believe that overall this would be for the best, even in multiplayer, because the monsters you are fighting wouldn't be desyncing on you as much, while the monsters your teammates are fighting may be desyncing on you more. I think that's a trade many of us would be willing to make.

I am sorry but previously you mentioned that the servers gamestate is the authority gamestate so in a multiplayer game with your proposal you would still have the monsters delayed because you are not certain if your gamestate will be the same a few seconds later. This is because every client will run it's own state send it to the server and then the server provides the updated gamestate (server is the authority gamestate), so essentially you will have exactly the same desync issue as you do now but potentially worse.

"

Meistervinny wrote:

I am sorry but previously you mentioned that the servers gamestate is the authority gamestate so in a multiplayer game with your proposal you would still have the monsters delayed because you are not certain if your gamestate will be the same a few seconds later. This is because every client will run it's own state send it to the server

No. Every client would calculate monster behavior on its own; none of the clients would send this information to the server, because the server can calculate monster behavior on its own as well. The only delayed information would be the actions of the various non-you players.

I kinda agree with partial parts of this suggestion.

Seeding the RNG engine which determines what a mob will do ("Will Voidbearer incinerate or melee charge") would be a good way of ensuring immediate client response, and thus allow for animations that remain in sync.

However, I believe a limit should be established. These things aren't the things which should be seeded, IMHO:

Monster Movement
Monsters need to be reactive towards players. Determining the movement of monsters beforehand via RNG seed would be tedious and counterintuitive, because it reduces mob movement's "unpredictability" and makes it trivially easy to kite/evade.

Combat Effects and Player Status
Seeding the damage results, ignite/other status effects, loot drops, etc. would be bad. Map layout prediction is already out, drop prediction would be something dangerous as well. Re-instancing Docks until I get a seed that drops uniques would be the least of your problems here.

"

ScrotieMcB wrote:

No. Every client would calculate monster behavior on its own; none of the clients would send this information to the server, because the server can calculate monster behavior on its own as well. The only delayed information would be the actions of the various non-you players.

I am sorry, but you want everyone to have their own environment? So you would be receiving data of someone cleaving in the air because in the other persons state the mobs are there but in your state they are not? So his damage is calculated in his state but not in yours?
Do you not see the massive flaws in this plan? This would result in some really weird gaming situations and not in a good way!

"

ScrotieMcB wrote:

"

westgate wrote:

I don't see how this solution could work in a multiplayer environment.
If the client was responsible for the AI's behaviour and you're playing in a party, you would have different gamestates, none of which can be true at the same time.
And that would most probably cause even worse desync.

The client already has have the same answer as the server, using deterministic prediction methods, otherwise it predicts monster movement in a way which disagrees with the server, which would cause more desync; however, this is preventable. Assuming that system worked properly, the problem you mention would solve itself almost automatically.

"

Wilde79 wrote:

This and every other issue related to this has already been covered in this thread:
http://www.pathofexile.com/forum/view-thread/626664

I felt this was a slightly superior option to bumping that thread, which I would have done otherwise.

Yes, much superior, so we can once again go through all the same things (already happening) as stated and discussed in the previous thread. I just feel you want GGG to reply on _your_ thread so much, you decided to start the same conversion all again.

Just go bump that thread if this issue bothers you and let this thread die.

Desync this desync that. if all desync would be fixed what would ppl blame on their deaths then. save some desync for those occasions.

"

Sachiru wrote:

However, I believe a limit should be established. These things aren't the things which should be seeded, IMHO:
Monster Movement
Combat Effects and Player Status

I agree with combat effects and player status; I thought it was clear in the OP that I wasn't pushing for these being done on-client, and instead doing combat math on the server as it is now.

In terms of monster movement, however, I strongly disagree. Just because the client has access to a seed doesn't mean that every decision needs to be random in order to be deterministic and therefore predictable. Movement (and skill use too!) shouldn't be purely random, but reacting to player input... which is fine, because the client has access to player input in real time. There is still no need to wait on the server.

"

Meistervinny wrote:

"

ScrotieMcB wrote:

No. Every client would calculate monster behavior on its own; none of the clients would send this information to the server, because the server can calculate monster behavior on its own as well. The only delayed information would be the actions of the various non-you players.

I am sorry, but you want everyone to have their own environment?

Everyone currently has their own environment.

Well, as with qwaves suggestion, there's still a problem of FP deterministic calculations. While simulating only mob movement will reduce the amount of possible points of error, it's still a factor.

And regarding multiplayer, it might actually increase the desync.
Lets say there are two player characters and a mob in a room (let's say the mobs is Brutus for nicer effect :)), and both players move into the Brutus's agro range at the same time.
Previously the server would say that Brutus attacks player A, and both players can see that on their clients.
After your suggested change, each player would see that Brutus attacks them, because the actions of the other player would come in delayed and the client would not wait for the server to say which player is attacked.
Now, it's not that bad that you think Brutus is attacking you, while he isnt. But it's possible that your client will show that Brutus is attacking the other player, while he is attacking you, and that's not fun :)

"

ScrotieMcB wrote:

Everyone currently has their own environment.

Way to quote 1 sentence, of course everyone has their own environment but you want the state of that environment to be unique to the player as well. Even when they are in the same instance.
Your plan is flawed, but if you think this is the solution, feel free to e-mail GGG so they too can tell you how your plan will not work.