Technical solution to eliminate desync in single-player sessions

Oh yeah, and of course, in the event that the outcome exceeds leniency, a re-sync is in order. You could also send a packet to force the client to generate detailed snapshots so that the server can evaluate what's wrong. If there is a problem, then force that client into using the pure-server authenticated system you have now.

Basically, I think PoE's current system can be used as a fallback in events that the client is not 'cooperating':

- High latency user
- Cheater / abnormal heuristics
- Obscure processor/OS (outrageous floating point values)

"

qwave wrote:

It's like a crossword puzzle. If the client sends enough state, the server can easily fill in blanks to evaluate whether the state is authorized.

You would be amazed at how much you can actually optimize this. Suddenly you start to discover that all your calculations can be done by the client and server with very little exchange. The implicit values fill themself in automatically.

Instead of the server responding with values, the server does not need to send anything back. You save a lot of bandwidth on the fact that the server doesn't need to tell the client what happened.

But should you "trust your data to the cloud"?

http://www.citeworld.com/cloud/22553/google-cloud-company-doesnt-trust-other-cloud-vendors

"

qwave wrote:

"

It's a hash. There is no room for leniency. This simply doesn't work. And if it did, it would allow cheating.

You would still hash it with the seed, but the server can provide leniency for the resulting value. In other words, the seed may be 0.7, the 'randomly generated' value may be 2.55558 which the client rounds up. The server will see the 2.5556 and provide leniency to the client. In other words, the server would accept the hash, thereby replacing its own.

WUT?

Seriously, WUT?

How the hell would you provide leniency for a HASH?

In case your stupidity cannot comprehend this, try running the letters "B" and "C" as they are represented in UTF-8 through an MD5 hasher. There's only a one-bit difference, specifically, the least significant bit is flipped.

To save you the effort, here, I'll do it for you.

B = "9d5ed678fe57bcca610140957afab571"
C = "0d61f8370cad1d412f80b84d143e1257"

Now, in what world/mathematical system would you see a "leniency" between two completely different results, as demonstrated above?

It's a fricking HASH. If similar values created similar hashes, then there's no point to hashing because it would be trivially easy to create values that collide.

And this is the understanding of someone who has worked 12 years in the industry? 12 years as a janitor peeking at the monitors of the guys who actually code, probably.

"

HellGauss wrote:

By using FIXED point numbers

Rewriting all the calculations to account for that is the "Ouch" part.

qwave, your example "player said he dealt 1284 damage, but the server arrived at 1283.4" is a bit simplistic. The rounding error of a small difference, over a large amount of calculations might mean a difference of several hundred in damage, so setting the leniency is not possible for the final calculation result, only for each calculation. And that would require the client to send each intermediate result.

"

I don't see how you can check every single operation of every single calculation. This seems entirely unreasonable.

The server only needs to simulate the implicit values to arrive at the explicit values. Can you provide an example on what seems unreasonable? Again, the server's role is to arrive at the same values. The client's role is to produce the minimum state for the server to arrive at these values.

I'm sorry for not reading how your idea has evolved for the last 20 pages, too many of them were people coming in and rehashing the same arguments over and over(sidenote - I wish people would be less antagonistic to simply discussing something)

How has your proposal on point II(syncing inbetween instances) evolved since? If the server and client don't agree with the way an instance has been played out, the server would have to roll the client back a massive amount, which is actually much less manageable for players than the current desync(and in my opinion, will result in more complaints - even now people dislike having to go through a zone because it's reset, imagine what they would be like if they have to REDO the zone, losing all the benefits of doing it in the first place?)

Imagine you are fighting a map boss(now with improved loot!) with a culling strike skill. You know fairly well when the boss will die. Assuming you aren't actually under threat of dying to the boss, how will you stop a client continuously rerolling his drops by simply undoing any kill that results in unfavorable drops(ok, I dont like these drops, so instead of killing the boss I move or do something else irrelevant)? If the server must step in to decide drops, then you aren't just syncing at the end of the instance. This could also be applied to crafting(fuse 6l with just one fusing).

If you need to force the server to validate everything at that point, then how many such situations would there be where the server would have to step in and do its validation checks? It seems like you'd very quickly approach the current system.

Again, I'm sorry if your proposal has actually evolved significantly since the OP, but after the first few pages I only scanned the thread for official GGG responses, because too much of the rest was garbage.

"

qwave, your example "player said he dealt 1284 damage, but the server arrived at 1283.4" is a bit simplistic. The rounding error of a small difference, over a large amount of calculations might mean a difference of several hundred in damage, so setting the leniency is not possible for the final calculation result, only for each calculation. And that would require the client to send each intermediate result.

The client needs to send just enough explicit data to allow the server to gather the implicit values and arrive at the same numbers. Depending on the number of GGG's calculations, the client may or may not need to send additional data.

BGSacho, no problem! And yes, things have evolved quite a bit. I think we are closing in on a small subset of remaining issues that we're trying to work through.

"

If you need to force the server to validate everything at that point, then how many such situations would there be where the server would have to step in and do its validation checks? It seems like you'd very quickly approach the current system.

At our current crossroad, the client is sending the state continually and the server is validating it immediately. Due to numerous issues that Rhys has brought to my attention, it would be completely impossible to do validation at the end of the session. So this should put your concerns to rest. ;-)

Sachiru: Reread the quote of mine that you pasted. You misread some very important words. ;)
The hash itself is not where the lenience is. Re-read!