Technical solution to eliminate desync in single-player sessions

This is a very nice idea which should work in theory. My only concern is with imprecision with different hardware. Floating point precision problem could be solved with fixed point arithmetic but what about timing? Hardware clocks are not very precise. If you send the timestamp of all actions, it will probably differ a tiny bit from the server' simulation. The server's simulation might be running a tiny bit faster or slower. It could lead to very rare but possible reject of legit gameplay.
"
patlefort3 wrote:
This is a very nice idea which should work in theory. My only concern is with imprecision with different hardware. Floating point precision problem could be solved with fixed point arithmetic but what about timing? Hardware clocks are not very precise. If you send the timestamp of all actions, it will probably differ a tiny bit from the server' simulation. The server's simulation might be running a tiny bit faster or slower. It could lead to very rare but possible reject of legit gameplay.
Regarding floating-point, it would be vitally important to have the client and the server agree on the exact same random number (since "Rhoa charges" and "Rhoa does not charge" entail completely different animations, as does "Dominus Touch of God" and "Dominus Soul Stream"), so ironing out such issues is important. It requires work, but it is possible.

In terms of hardware clocks, that level of precision is not required. Remember, this is what the current model looks like this...
Client simulation
Client input is interpreted immediately (no delay)
Monster skill selection waits on server (delay = round-trip ping)
Server gamestate
Client input is interpreted upon receipt (delay = one-way ping)
Monster skill selection occurs based on client input and decision tree (delay = same as client input = one-way ping)

... therefore the client simulation is attempting to predict a gamestate which is a one-way ping in the future (and a round-trip ping before it can be confirmed by the server). That is not a fixed amount of time, and will vary somewhat as user ping fluctuates. So synchronizing clocks with any kind of precision is really just a waste of time. Plus, we wouldn't want to trust the client's timestamp anyway.

The point of my suggestion isn't precision synchronization between client and server; there will still be some desync, and correction mechanisms will still need to be in place. I'm not promising you utter elimination of desync because you'd have to be a complete fool to believe anything could remove it completely while remaining secure. The point is getting rid of the large round-trip-ping delay in monster skill selection. Bringing things within 10 milliseconds of each other should be sufficient.
When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
Last edited by ScrotieMcB#2697 on Nov 20, 2013, 8:49:12 PM
I know a lot of people are frustrated, I'm not here to steal away your solutions. One person said, sadly, that we should not be 'criticizing' OP's idea. It's sad that comments like that are made; an idea should stand on its own, or not stand at all. If people can find holes in a theory, THAT IS A GOOD THING.

Ok, with that out of the way, lets start.

1a) PLAYER MOVEMENT
The players movement cannot be derived from, nor encoded to a seed value.

Some people may need this explained, so let me give you an example: You decide its time for you to leave the house. Your first goal (click) is to get to the front door. You take a single step, reach into you pajama pockets, and pull out a coin. Flipping the coin, you get heads, you take a step forward. Flipping it again you get tails, you take a step backwards....

As far as player movement goes, the 'snapshot' contains current player position, click position, and a seed value and a timestamp. In this case, the seed value is ONLY used to determine that this IS the correct snapshot, not that the data IN the 'snapshot' is valid. And indeed as shown, there is no way the seed could validate the DATA.


1b) MOB MOVEMENT
A mobs movement, within reason, is completely dependent on the players position.

I'm not sure why qwave skipped this question when I asked it, but as is the example in 1a, it's just not possible to use a seed to determine mob movement, nor position after initial placement. It's another case where the 'snapshot' seed value has no relation to mob position or movement (after interaction with the player).

Even IF you could use a RNG value each roll to determine movement, the movement would be nonsensical.

2) PROJECTILES & PREDICTION

"
qwave wrote:

The seed is not used for 'prediction'. It is used to generate random numbers. The server does not need to perform any sort of prediction.


This is another question left unanswered. How can projectiles be derived from or encoded to a random number. The OP states that given a 'seed' (and other relative data) the server can verify a snapshot. Lets assume that's true.

Player shoots an arrow in the GENERAL direction of a moving mob. A random number is generated and a roll is made as to... to.. as to what? What is a roll made against? A Hit? A hit against what? No mob was selected.

Does the client predict where the mob will be? Well, in OP's solution, this is IMPOSSIBLE because mobs movement based on... you guessed it; random numbers. And since generating random numbers on the client can only happen PER snapshot, there's now way to predict whether the arrow will hit based on the random number generated when the arrow was fired.

So, now we have an arrow flying through the air, the next 'snapshot' is made, an new random number generated; can you derive the location of the arrow from the new seed, nope. The server has no way to verify the arrows position. Only that it was fired a few snapshots ago, and since the OP has flip-flopped on whether the server is saving ALL snapshots, or only the previous one, I'm not even sure the server would be aware there was an arrow after a few snapshots.

3) The Infamous White Paper
Hack-proof synchronization protocol for multi-player online games

The paper, while interesting, covers a very specific topic - 'Speed Hacks'.

This paper ONLY describes movement (and the correctness of) based on time and direction and other factors. It has absolutely nothing to do with deterministic seeds of any kind. The math alone involved in this paper puts FP precision front and center. It's important to note that the methods in this paper don't describe how to verify a players position, only that the position is within acceptable ranges. In fact the more I go over this paper, the less I understand the relationship to this discussion. I am not aware of any speed hacks in PoE at this moment.

4) HACKING
Several times, by several people, hacking has largely be ignored by the OP. 'Deterministic seeds I tell you, that's what'

The snapshot being sent to the server contains information. Attached to the snapshot is the seed used during that snapshot. This is another case where the OP is unclear, are seeds continuously sent to the client, or only one at the beginning of the instance, to seed the RNG.

Either way, a seed/random number is attached to the snapshot I assume. Here's a scenario:

- I step into a new instance, start looking for a rare
- Finding a rare I position myself just out side it detection range.
- copy the next snapshot
- From now on, I send the copied snapshot with whatever new seed/random number is being generated for these snapshots. To the server I will appear standing still.
- I fire at the mob, recording all snapshot in the process till its dead, still sending the server 'still' snapshots.
- now here is where you need to pay attention
- on mob death a loot roll is made, it doesn't matter what drops, I can't used because the server thinks I'm standing still.
- I know that I have say 10 snapshots of me killing the mob
- I force another 11 'loot' rolls (that code is on the client, right OP?)
- But I send the first of those 11 rolls as a 'still' snapshot
- from now on I make one loot roll and send the earliest loot roll as a 'still', maintaining 10 snapshots in a 'queue' - all valid, all in order.
- I can continue this until I get what I want to drop
- When it does, I replace the 10 previous loot roll 'snapshots' with the attacking snapshots (but only the data, I'm not replacing the seed or random number or whatever)
- the seeds/random number attached to the 10 previous loot roll snapshots are still valid, since nothing has been sent out of order, or skipped, just the data replaced with the attack data.
- the final snapshot sent, is the good loot roll

Now, one problem I can see immediately is the fact that the attack snapshots saved when I killed the mob will be attached to snapshots with different seeds - meaning my attacks may do a different amount of damage, but in the long run I think its safe to say that mobs consistently die ti the same number of attacks.

That's it for me, I truly did enjoy this thinking exercise. And while I don't believe you have convinced many of your methods, I do applaud your effort, as condescending as it may have seemed at times. It's the internet, you're probably the nicest person in the world.

There is nothing anything I have read, or seen, to believe that GGG has stopped working on desync, and though I feel sorry for those affected, GGG should not have to state that they are working on it everyday. It's enough for me knowing that they have smart people working there, doing what they can as a business to make sure people enjoy their game.

Edit: Typos
Last edited by MeltingPoint#1763 on Nov 20, 2013, 9:27:46 PM
MeltingPoint:

Every single assertion in your post is completely wrong, and represents a clear misunderstanding of the entire proposal.


At this point I can see that 90% of the people here do not understand it, and I blame myself for not explaining it clearly enough. I am working on a detailed writeup now that explains each and every piece.

A lot of you seem to think that the client can send 'anything' that it wants, and the server will just trust it. This is NOT the case. The client must adhere to the exact state of the game. I am going to explain why in my writeup.
Last edited by qwave#5074 on Nov 20, 2013, 9:48:07 PM
"
qwave wrote:
MeltingPoint:

Every single assertion in your post is completely wrong, and represents a clear misunderstanding of the entire proposal.


At this point I can see that 90% of the people here do not understand it, and I blame myself for not explaining it clearly enough. I am working on a detailed writeup now that explains each and every piece.

A lot of you seem to think that the client can send 'anything' that it wants, and the server will just trust it. This is NOT the case. The client must adhere to the exact state of the game. I am going to explain why in my writeup.


I'm pretty sure every one understands their so called ¨feature¨ by now.Feature that will f you up any time you are trying to pass tight spot with 1mob around it.

Damn that's like the best feature i have ever heard of.
"
qwave wrote:
MeltingPoint:

Every single assertion in your post is completely wrong, and represents a clear misunderstanding of the entire proposal.


At this point I can see that 90% of the people here do not understand it, and I blame myself for not explaining it clearly enough. I am working on a detailed writeup now that explains each and every piece.

A lot of you seem to think that the client can send 'anything' that it wants, and the server will just trust it. This is NOT the case. The client must adhere to the exact state of the game. I am going to explain why in my writeup.


Well that was a huge waste of time then. Look forward to reading your proposal.
I have edited the main post. MeltingPoint, please pay attention to important things like timestamp generation. These are key points that prevent cheating.
I am trying to build an extremely detailed/concise post. If any of you guys have anything that you would like to say/quote/add to the main post, please let me know. I think some of you have some really great feedback on improving this system. Moreover, I want to quote some of you because your wording provides a new type of 'insight'.
Last edited by qwave#5074 on Nov 20, 2013, 11:21:53 PM
.
When Stephen Colbert was killed by HYDRA's Project Insight in 2014, the comedy world lost a hero. Since his life model decoy isn't up to the task, please do not mistake my performance as political discussion. I'm just doing what Steve would have wanted.
Last edited by ScrotieMcB#2697 on Nov 20, 2013, 11:25:57 PM
MAIN POST UPDATED/REVISED

Okay, ive added quotes to the main post from numerous contributors to the topic. I have proofread it a few times and added some more questions/details.

Please let me know if I have missed any questions. I am going through all the posts on this thread and trying to consolidate all of the questions/concerns into the main post.

Thanks everyone!
Last edited by qwave#5074 on Nov 20, 2013, 11:23:08 PM

Report Forum Post

Report Account:

Report Type

Additional Info