Technical solution to eliminate desync in single-player sessions

"

ScrotieMcB wrote:

This makes a lot of sense when you really think about it. The client is a computer program, after all; given the same inputs, the exact same calculations are made on all clients. Since you were partying together and for the most part in very similar situations (very similar inputs), wouldn't it necessarily follow that most of the time failed predictions would exist on both machines simultaneously? To be honest, I'm a little surprised there was any variance whatsoever.

Actually it is a bit surprising that the predictions on 2 clients are very close, while they differ from server state, unless the actions of one client are sent directly to the other client, not through server, and the latency between clients is very low.

The main source of desync is latency. Lets say at time t there's a monster coming to attack a character and the client and server states are synchronized. If on the client the character starts to move from the monster at time t+100ms and at that time, the monster still hasn't landed a hit, the character moves away. The command to move reaches the server at t+200ms due to latency and at that time the monster has already reached the character and hit him, interrupting/freezing him. Now we have a desynched states where the character location on the client is different than the character location on the server.

Now if there are two clients, and they send the commends to one another directly with little latency, the second client will receive the first clients move command in t+110ms, and at that time the character might still be able to move away. However if the latency between clients is the same 100ms, then the second client receives the first client move command at t+200ms, the same as the server, and in that case, the client states are desynced from one another.

"

qwave wrote:

I have supported my proposal with white papers

You can use white papers to support anything, there is a reason they are called white papers

"

qwave wrote:

, code,

The code is irrelevant and doesn't actually address any problems with your system

"

qwave wrote:

and detailed explanations to each and every query.

The fact that your responses are detailed amounts to nothing in regards of the validity of your system. Your posts are full of waffle and buzz words.

I can make a detailed response as to why I think the earth is the center of the universe, it doesn't make it correct

"

qwave wrote:

I have adapted the solution to the meet the needs of GGG and their constraints.

No you havn't

"

qwave wrote:

There is only so much I can do to help with the desync problem, and im doing my absolute best.

The only thing you are doing is wasting your time. I can guarantee you that GGG will not do anything at all, to do with your system, and this is judging by Rhys's posts, which say that your system has more holes than swiss cheese

Also get off your pedestal and stop talking in a tone as if you are working for GGG or doing a favor for them. They, and no one else here, give a shit about your system, your explanations for your system, or a workaround for your systems flaws

'Nobody cares', yet you continue to make posts trying to refute it.

"

The main source of desync is latency.

No, the main sorce of desync is lack of info. The client must predict server response (= big amount of data) to know the effects of its action, instead of precisely calculate these effect by itself.

The core of the idea of OP is so simple that it actually blows my mind to read how it is misunderstood, even if I must admit that OP did not explain it so well. I do not know... maybe there is a global misconception about the fact that a 'real time' simulation of the game should be on the server. This is not the case, a real time simulation should only be on the client to ensure playability.

"

qwave wrote:

'Nobody cares', yet you continue to make posts trying to refute it.

Refute what?

The only reason that Rhys is posting here is because you are spreading bullshit about a subject that you don't know about (which he does know about), so he is setting the record straight

Which is why all of his posts have been stating why you have been incorrect, why your system doesn't work, and why you don't know what you are talking about.

Nothing you have said has changed his mind, this is his last post

"

Rhys wrote:

"

qwave wrote:

This is combat/pathing we're talking about, just use a consistent rounding mode and you're safe.

No. It doesn't matter which rounding mode you use consistently, you can still get the client/server rounding different because of small inconsistencies.

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.

"

qwave wrote:

Equipping/unequipping would not desync you. The client and server both know the stats of the equipment.

But they will disagree on whether it's equipped, or disagree on the quality, which affects the stats. This can easily cause desync, especially in a system like this which is so fragile and intolerant of minor inconsistencies.

"

qwave wrote:

You would only potentially desync in situations that involve heavy latency. Equipping/unequipping items will not require a re-sync.

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

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

There is nothing in that post that states he thinks your idea is a good idea, that GGG will adopt it, o that your workarounds make sense. You are being delusional if you think GGG is taking you seriously

what should be tuned is the "100 % autoritative server" and when the RESYNCH occurs.
Resynch should be a lot more often in some situations. Beeing in a room in the client and in another room in the server is not acceptable, especially if you have to die or to type /oos to discover it.

A big stun should resynch automatically, it's a good opportunity to do it without imapcting gameplay.

"

deteego wrote:

No the reason why he is replying is because he is calling out bullshit on what you are saying, and he wants to explain to the general public how desync works. More importantly, he wants to make sure that the public aren't being deceived about what desync is, which is precisely what you are doing

That's bollocks. If it was absolute crap he wouldn't reply, why would he waste the time?

Qwave may be very wrong with his solution, but regardless it's raising an issue that many players have with the game.

Should it go to PM's from here, sure, should you bash the fuck out of the bloke? I don't think so.

"

ScrotieMcB wrote:

"

qwave wrote:

There is obviously something different about this one.

Have you considered the possibility that it might have less to do with your ideas, and more to do with your attitude?

Or possibly the Blue Diamond Supporter tag.

deteego is so mad. I love it. ;-)

"

qwave wrote:

deteego is so mad. I love it. ;-)

Troll confirmation received.
Activate thread locking procedures.