Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

"

Several times now he's posted what the alternatives are: Cheating, Guaranteed Hits, Removal of Accuracy, Hits from a greater distance, and more.

Number one alone, cheating, I can guarantee would have the community in 10 times the uproar. The others would just make the game feel cheaper.

If 0.0001% players were able to get more frequent critical strikes, would you trade that to be able to eliminate lag/desync?

This is all about trade-offs. I am proposing a system that is extremely difficult to cheat, and it would not effect item drops/crafting/etc. And in effect, we could eliminate desync and lag. Extremely skilled hackers may be able to improve their critical strikes/chance to hit. A worthwhile trade imo.

Come on man, nothing you've said so far permits ONLY critical hits to be tampered with. The fact that you would use that as a comparison to make it look like your 'solution' only had the smallest of drawbacks is disingenuous. As is making up random stats.

When reading OP I wanted this to work so bad...but sadly I have to agree with the criticism posted.

Desync in this game feels very very frustrating and...basically demoralizing.
It feels like another Halting Problem. You want it to be solved so so badly, but it's just not theoretically possible to do so :/


However, it would be great if there were some advanced computer scientists investigating this subject in GGG, but we know GGG is not a multinational multimillionaire super company so they can't have that kind of stuff :/

"

Consider 1.49999 vs. 1.50001, and 1.99999 vs. 2.00001. You can't correctly round both these pairs of numbers. Any rounding mode that handles the first pair fails on the other, and vice versa.

You don't need this much precision for the combat calculations, that's what im saying. Reduce your precision and you shouldn't have this problem.

"

But they will disagree on whether it's equipped, or disagree on the quality, which affects the stats. This can easily cause desync.

No they won't disagree. Equipping/unequipping would be part of the input snapshot (as it currently is). The crafting/upgrading would be strictly server validated, and would require a re-sync.

"

Even with virtually no latency, switching gear in combat will cause desync (see above).

This is only true if you upgrade/craft an equipped item. I think players would be okay with desync happening during equip/unequip either way.

"

Even with virtually no latency, the server and client fundamentally disagree on the issue of death vs. near-death.

No, the client's snapshot would include death. If it doesn't send a snapshot, then the server simulation takes precedence.

"

Rhys wrote:

It's very hard to find experienced game programmers in NZ. And importing people from overseas is hard because we can't match the salaries of most US/EU companies. We kinda have to rely on finding people who wanted to move to NZ anyway... and even then, we aren't the only company here super-keen to hire these people.

Of all the GGG responses to desync on this thread the above pathetic statement is the ONLY one concerning what they are trying to do NOW.

"

Come on man, nothing you've said so far permits ONLY critical hits to be tampered with. The fact that you would use that as a comparison to make it look like your 'solution' only had the smallest of drawbacks is disingenuous. As is making up random stats.

What else could be tampered with? I think you must be misunderstanding something. If you were to write a hack that tried to optimize more than a single calculation, the odds would be so stacked against you that it would be virtually impossible to calculate. I used critical strike because any other value that I can think of would not provide noteworthy gains.

Now that I think of it, the PoE client itself could even build this in as part of their critical strike calculations. I believe the 'gain' can be eliminated completely using some clever tactics, but id have to crunch the numbers. Basically, PoE could run heuristics on the number of critical strikes the player is rolling and curve it accordingly. So if some random player is rolling crits 3x more frequently than he should be, heuristics would start to kick in to make an adjustment.

"

The simulations run by the PoE client and server are inherently non-deterministic and cannot be reproduced. There is thus no reliable way for the server to validate the results produced by the client.

The core of my proposal is a deterministic seed. Please read my post before making replies like this.

"

qwave wrote:

"

RogueMage wrote:

The simulations run by the PoE client and server are inherently non-deterministic and cannot be reproduced. There is thus no reliable way for the server to validate the results produced by the client.

The core of my proposal is a deterministic seed. Please read my post before making replies like this.

Yes, and that's why it's a pipedream that would fail in practice. Even if all state variables are regenerated deterministically, asynchronous open-loop simulations will eventually drift out of sync with each other. The inevitable discrepancies must be resolved and GGG chose to do so by revising the client's state with the server's. In that situation, the server could not instead "validate" the client's results - for the same reasons the client was unable to reproduce the server's results.

GGG obviously doesn't know how this game works and should just stop wasting their time... let qwave re-code the game already.

"

Even if all state variables are regenerated deterministically, asynchronous open-loop simulations will eventually drift out of sync with each other.

The snapshots are being streamed to the server in realtime. Please explain how a deterministic simulation can drift out of sync? By calling it deterministic, it cannot drift out of sync. I would love for you to tell me how something deterministic can also be non-deterministic at the same time. Maybe you have discovered some new laws in physics that im not aware of.

"

qwave wrote:

"

Even if all state variables are regenerated deterministically, asynchronous open-loop simulations will eventually drift out of sync with each other.

The snapshots are being streamed to the server in realtime. Please explain how a deterministic simulation can drift out of sync? By calling it deterministic, it cannot drift out of sync. I would love for you to tell me how something deterministic can also be non-deterministic at the same time. Maybe you have discovered some new laws in physics that im not aware of.

No movement in physics is deterministic. All movements are inheretily non-deterministic, but the probabilities can in many cases be so high that we can for all practical purposes treat those cases as if they were deterministic.