Technical solution to eliminate desync in single-player sessions

As is the proposal looks fairly sound with the exception of the handling of some floating point variables.
But what about my concerns from like page 28 or something. Chaos. How would this system handle corrupt data or elapsed time variance. And the issue of possible false positives.

You are arguing semantics. The server still has to run the game simulation with the same data and timing that the client did. That it does this in a bulk of one second (or whatever interval) worth of updates is irrelevant.

You keep obscuring this with "verify" as if it is somehow simpler to execute, but it really isn't. Sure, the server can skip all the visual only stuff, but it already does that. (I would hope)

"

What happens when the server comes back and says the client is wrong?

If the client is wrong, it needs re-synced.

"

But what about my concerns from like page 28 or something. Chaos. How would this system handle corrupt data or elapsed time variance. And the issue of possible false positives.

The delta will not experience drift because it's so short-term, but if the user's computer is 'broke', then the server needs to handle full validation for that client.

"

You keep obscuring this with "verify" as if it is somehow simpler to execute, but it really isn't. Sure, the server can skip all the visual only stuff, but it already does that. (I would hope)

It can ignore portions of the simulation that are not needed to identify cheating. But yes, you are correct.

"

Mysterial wrote:

Sure, the server can skip all the visual only stuff, but it already does that. (I would hope)

That got me thinking, perhaps 'some' of the desynch is the result of of the server not performing the same los calculations as the client.
It may be worth a double check for someone with access.
Perhaps the server code somehow doesnt include increased run speed the same way the client... Just spitballing here.

"

qwave wrote:

"

What happens when the server comes back and says the client is wrong?

If the client is wrong, it needs re-synced.

So, how exactly does your proposal "Eliminate desync in a single-player session" than?
The entire cause of desync is that the client and server differ over something. The server is always correct so the client has to be adjusted. If in your model, the serve is still always correct and will correct the client if he is wrong, there is still a desync when this occurs.

The client is only wrong if it's cheating. I feel like a broken record at this point. This is literally the 150th time ive said this.

Im going to bed. Hopefully those of you that understand the system can answer the questions for the others while im gone. ;-)

"

SkyCore wrote:

As is the proposal looks fairly sound with the exception of the handling of some floating point variables.
But what about my concerns from like page 28 or something. Chaos. How would this system handle corrupt data or elapsed time variance. And the issue of possible false positives.

First of all, what do you mean by corrupt data?

Now, regarding elapsed time, that would probably be due to disconnect/extreme latency, there are two ways to go.

First is to save the results of the last received snapshot as final. This protects people in case of disconnects, however it also allows hacks that would make sure that a hc character can never die, so is a bad option imho.

The other way is for the server to run a simulation for some defined time, as if the player made no action. In this case, even if you hack the game not to send the snapshot in case you died, you would still probably die on the server. Of course you could also die if that was an honest disconnect in a middle of combat. But imho that is acceptable, as many people are accustomed to such a thing (an this would also please all those asking to remove ALT+F4 as a side note :)).

Regarding the case when the client results don't match the server simulation (including false positives), there are also two ways to go.

First is to end current session at the last verified snapshot and flag the account for hacking. The action for flagged accounts depends on GGG.

The other way is for the server to forcefully update the client to the state that the server receives as the result. This would be similar to how currently the resync works. So if the client tries to say that the character took 100 damage from Vaal smash in merciless, the server could say nope, you're dead.

"

Tantabobo wrote:

"

qwave wrote:

"

What happens when the server comes back and says the client is wrong?

If the client is wrong, it needs re-synced.

So, how exactly does your proposal "Eliminate desync in a single-player session" than?
The entire cause of desync is that the client and server differ over something. The server is always correct so the client has to be adjusted. If in your model, the serve is still always correct and will correct the client if he is wrong, there is still a desync when this occurs.

The way i see it: in the games current state there is a lot of back and forth communication between the client and the server, since the server is virtually always out of synch with the client they regularly dont agree, when this happens the server asserts the game state resulting in rubberbanding and such.
With the propsed model this is as a whole eliminated since the server is basing its calculation on what the client has already done, here the client asserts the game state at all times. except when cheating is detected via an impossible action reflected in a snapshot.