Technical solution to eliminate desync in single-player sessions

"

It would solve the problem. However, could you please provide some reference, i'm very interested.

http://www.coranac.com/tonc/text/fixed.htm
This is a good explanation of some of the issues and how they can be overcome. I don't disagree that it solves the problem, but there are trade offs. They may or may not be acceptable for GGG.

"

The server has to verify client commands anyway.

The verification used is different for this proposal, since the current model does not actually verify, it calculates and tells the client what it can/can't do. If the client was wrong in its math it is corrected. This is not the same as the proposal, where the client sends its end result to the server and the server compares them and than sends the dispute to the client.

"

For gear swap/exchange, it would suffice to consider these events as client commands, which are sent to the server as the other ones. For loot and craft, it would suffice to return back to the server the command "i received the loot/craft information"

I was basing off the proposal, this may work. But it does effect the calculations and thus, is still a potential point of client/server drift.

"

The framework would work well coupled with GGPO approach. In mutliplayer this leads to desync as the max latency of the whole party.

Possible, but I see things spiraling out of control quickly if one client is always slightly off from the others.

"

Of course, all the model is based on the fact that the same simulation can be run exactly both by the server (non realtime) and the client (realtime). A single bit of difference may invalidate all. But this can be achieved with proper design.

You can't guarantee that the simulation will run exactly the same on two different machines. No matter the design, there is no guarantee. The design can detect differences (which might be what you are thinking of) but that is not the same thing as them running the same.

"

Verification should be done against the final result, not every step of the calculation. Rhys mentioned the verification of individual calculations not in the context of server load, but in the context of calculating leniency.

Yes ,that is exactly what Rhys mentioned, which is why I assert that it is an increase in server load and coding to provide sufficiently robust verification.

"

The additional work on the server is unknown, but considering Rhys's responses, it's not an apparent problem. As I previously stated, unless Rhys comes and says that it's too much of an additional load, we cant assume that it's a reason to discard the idea.

It is a valid concern and needs to be considered.

"

And it actually eliminates desync. No condition other than attempted hack or software bug (and I'd consider difference in rounding fp a bug) would desync the server/client.

It definitively does NOT eliminate it. Again, there is any number of scenarios that can cause two machines to calculate two results differently. Thus, you will be out of sync for something other than cheating. Further, round with FP is not a bug it is differences in architecture. Both machines are perfectly valid in their approach to FP, they are just different approaches.

I've been reading through a lot of this thread, but I'm still wondering about one issue (though maybe it was discussed already, and you can point me to an answer?).

So, a seed value determines the exact outcome of an action. However, what calculation it's going to be used for depends on the actions of the player. I don't see how you can prevent cheating here --- if the client is able to determine the outcome fast enough for fluid gameplay, any cheating program should be able to do the same. It could take the next seed value and determine which player action would lead to the best outcome at this time.

In the first post, qwave says that the random seed would be changing too quickly. But why? The gamestate is only sent back to the server at discrete intervals --- theoretically, a hacked client could stop the simulation for, say, 900ms while it calculates the best course of action for the player, then spend the remaining 100ms to produce a valid gamestate for the last 1000ms to send back to the server.

Even if you "only" handle pathing and combat logic this way, and exclude loot drops/crafting/etc., there is still some significant advantage to be gained this way. Not dying is a significant advantage in races/ladders.

"

Tantabobo wrote:

Yes ,that is exactly what Rhys mentioned, which is why I assert that it is an increase in server load and coding to provide sufficiently robust verification.

Well I guess we will have to disagree here, as I can not come to the conclusion that what Rhys said is in relation to server load.

"

Tantabobo wrote:

It is a valid concern and needs to be considered.

I should be considered, but it should not be assumed a significant flaw.

"

Tantabobo wrote:

It definitively does NOT eliminate it. Again, there is any number of scenarios that can cause two machines to calculate two results differently. Thus, you will be out of sync for something other than cheating. Further, round with FP is not a bug it is differences in architecture. Both machines are perfectly valid in their approach to FP, they are just different approaches.

Could you provide an example, other than a bug or hardware failure?

And regarding the fp rounding, again I have to disagree. It is a flaw to me.

"

Amaroid wrote:

I've been reading through a lot of this thread, but I'm still wondering about one issue (though maybe it was discussed already, and you can point me to an answer?).

So, a seed value determines the exact outcome of an action. However, what calculation it's going to be used for depends on the actions of the player. I don't see how you can prevent cheating here --- if the client is able to determine the outcome fast enough for fluid gameplay, any cheating program should be able to do the same. It could take the next seed value and determine which player action would lead to the best outcome at this time.

In the first post, qwave says that the random seed would be changing too quickly. But why? The gamestate is only sent back to the server at discrete intervals --- theoretically, a hacked client could stop the simulation for, say, 900ms while it calculates the best course of action for the player, then spend the remaining 100ms to produce a valid gamestate for the last 1000ms to send back to the server.

Even if you "only" handle pathing and combat logic this way, and exclude loot drops/crafting/etc., there is still some significant advantage to be gained this way. Not dying is a significant advantage in races/ladders.

]
Security is totally thrown out the window in this proposal. Pages upon pages of possible hacks.

Although I have no computer science knowledge, I have good enough reading skills to point out the following:
OP, as much as I would love your idea to work, and I respect your effort, there's (at least) one extremely noticeable contradiction on your part.
At various points in the first 20-30 pages, you stated that cheating would only be possible either with a million dollar set-up, or with a tremendous and unlikely reverse engineering effort (I'm paraphrasing, I know this weren't your exact words but it was something similar).
But, only a couple of pages later, a user or two mentioned a couple of ideas to hack your method, to wich you responded something like "yes but to avoid that we could do the following...", so you basically started tackling issues as they came along. So, you went from "it's virtually imposible to hack" to something like "I think I/we can tackle problems as they appear". You are not being realistic IMO, in fact you said at one point that the risk was that 0,0001% (don't remember the actual percentage you used but that's not important as it was just illustrative) of the users hack, but you are not taking into account that hackers actually spread the word (and that you would be dealing potentially with thousands of them), and the second you are still trying to tackle the first 3 o 4 hack ideas or potential hacks, 10 other can go under your radar and under GGG's radar. You are underestimating hacking BIG TIME, IMHO.

"

Tantabobo wrote:

"

And it actually eliminates desync. No condition other than attempted hack or software bug (and I'd consider difference in rounding fp a bug) would desync the server/client.

It definitively does NOT eliminate it. Again, there is any number of scenarios that can cause two machines to calculate two results differently. Thus, you will be out of sync for something other than cheating. Further, round with FP is not a bug it is differences in architecture. Both machines are perfectly valid in their approach to FP, they are just different approaches.

For as far as the server is concerned, every deviance is a 'hack detected'. There exists no plausible way to differentiate between a hack and a bug( chaos).

I think there is a lot of negative stuff going on in this thread, which I think is not really helpful since PoE really needs threads like these every once in a while.

This negative stuff comes from both qwave and critics. Qwave, maybe you should make your points clearer. Try laying off this forum for a while, reformulate your thoughts, make them cleaner. Maybe write something about it and make it structured. This continuous back and forth where the same arguments are rehashed over and over doesn't really help others understanding your "solution", nor you understanding their valid criticism.
For critics and the like...yeah there is too much negativity surrounding this. I've seen some people calling qwave names and shit which doesn't help. It's obvious he has good intentions (who doesn't want to solve desync?), but misunderstandings and the problem I mentioned above is what's causing all this shit, not qwave being "stupid" or whatever.

I think it would be better if EVERBODY except qwave and GGG's staff refrain from the discussion. qwave should be given space and time to reformulate this more clearly, but he also needs feedback from GGG since he wouldn't really know PoE's architecture and the like. Maybe they should discuss this somewhere else, and not in this thread or this forum. That would make it much more easier for both parties.

My 2 cents

Amaroid, yes, there is a theoretical possibility that a hacked client can arrange the player actions of one snapshot in such an order, that the outcome is better for the player. However it is a difficult task to calculate multiple possible outcomes with each possible user input and compare them in real time, hopefully enough so, that it can not be done fast and reliable enough.

Double post.