Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

Prediction always occurs on the server because the client has nothing to predict.

Did you even read my post? Go back and read it again. (To be fair, I edit my posts frequently, often drastically, within the first few minutes of their lives.)

What are you suggesting that the client would be 'predicting'? There is nothing for it to predict. I've read your post.

Actually regarding this question, since the server state is considered "real", it's the client that predicts. In the example that Scrotie posted, the client predicts that the character arrives at the monster that player clicked on, while on the server he might be interrupted half way there.

I suppose I can see why you are calling that a prediction, but it's not a prediction because the client is simulating a well-known state. It cannot predict how the server will respond. It would only be a prediction if it was performing an action based entirely on an expected response from the server. Instead, it is simply performing the user's input while executing the well-defined simulation.

The server is using prediction based on the expected input from the client. It's using prediction to interpolate the player's position over time. That's why you sometimes desync and warp to a location that you never moved to in the first place.

"

qwave wrote:

What are you suggesting that the client would be 'predicting'? There is nothing for it to predict. I've read your post.

The client is predicting where it will be according to the master gamestate, which is stored on the server and predicts nothing. It doesn't "uses interpolation to guesstimate" a goddamn thing; it starts moving you only once it receives the command, starts attacking once it receives the command, et cetera. What the client is predicting is essentially that nothing is coming from the server to contradict its version of events; for example, read the 2000ms entry again, in that entry the client is predicting that it successfully reached the monster and wasn't interrupted by a stun en route.

"

in that entry the client is predicting that it successfully reached the monster and wasn't interrupted by a stun en route.

That's not a prediction, that's a simulation in a well-known environment. A prediction would indicate that it is performing an action BECAUSE it ->expects<- the server to change it's state.

Predictions are based on expectations. The client is not changing it's behavior based on an expectation.

Then I might see what prediction means differently. Prediction means that you try to say what will happen. The server says what actually happens, because the server state is saved and influences your character. So it seems that whatever the client shows you is actually a prediction of what will happen once the server saves the state.

"

qwave wrote:

That's why you sometimes desync and warp to a location that you never moved to in the first place.

No, the reason you do that is because you sent a command to attack a monster (which wasn't in the same location on the server as it is on the client) rather than a command to attack a location. The server, receiving your command, executed it based entirely on the monster and not at all based on the location, moving you to within range (melee) or within line-of-sight (projectile/spell) of that monster, which means: the server had your character moving through a door to achieve the appropriate range or line-of-sight. If you pay careful attention to what is going on, you will notice that every time your character desync-teleports into a room, a monster (or corpse) teleports with you. This is also why holding down the shift key (forcing your character to perform actions without moving) is a flawless preventative measure against desync-teleporting yourself, if used consistently (it does not guarantee monsters will not desync-teleport).

"

If you pay careful attention to what is going on, you will notice that every time your character desync-teleports into a room, a monster (or corpse) teleports with you.

Fair enough. That's not how it's handled traditionally in online games, but that makes sense.

Also, you are right about client prediction. I see that the industry does use the term 'prediction' in this situation. =)

I am extremely uncomfortable that the server handles correction that way. No wonder things desync so bad.

So yes, the client is predicting the server's response. This technique was cutting-edge for awhile, but it has really become antique for action games like PoE.

qwave has posted contradictory examples of how his proposal would work. At one point he dismissed flaws because he claims the server and the client were not synched, then later suddenly there is synch again. Hes expressed that his system is completely deterministic( so as to gain certain benefits), yet allows for margins of error in several scenarios. 'margins of error' in a deterministic system?!
It like saying a shape is a square to begin with, then when someone points out the angels of its vertex cannot possibly be so, he changes the shape to something which is like a square. But still maintains the idea he can make calculations based on it being a square.
Any injection of chaos into a deterministic system completely invalidates all future predictions. There may be some propagation speed of the chaos within the system but this is moot as it quickly becomes far too complex to keep track of said chaos.
He has said that a difference between server and client snapshots would result in disconnect. Later he said it would result in the server resynching the client. And still later he says it will result in a rollback.
It should be clearly obvious to anyone who reads through the entire thread that qwave is merely attempting to appease individuals who disagree or point out flaws ad hoc. There is no grand plan. And what plan he has laid out is contradictory with ITSELF as well as well as be shown to be inherently flawed in several technical and fundamental ways.

request thread lock