Technical solution to eliminate desync in single-player sessions

"

qwave wrote:

Zero impact on performance means it will not reduce your framerate. Obviously it will cost microseconds, but these are not tangible in a game like this. Line of sight calculations are even cheaper because they can be done by the GPU. (although that is highly unlikely given the simplicity of the algorithm)

The client already performs line of sight calculations, so that's not anything new.

"

qwave wrote:

Tantabobo, virtually every RPG out there performs similar combat calculations. If these were expensive, then RPGs would require massive hardware. The truth is, RPGs perform very few calculations compared to games like RTSs.

Try calculating the paths of 5000 units on a map, now that's taxing. Calculating the next critical strike? Not so much.

"

SkyCore wrote:

"

Citronvand wrote:

"

SkyCore wrote:

Sarcasm detected.
Analyze post content: . . . . . . . . . . . . .
None detected.
Request thread lock.

I don't see how locking this thread would achieve anything desirable. Even if qwave is completely wrong it is an important issue to talk about and try to solve. I suppose you want to lock all threads relating to desync so we can all stick our heads in the sand and pretend it doesn't exist.

Oh, I almost forgot.

Request thread to be open.

[...]

As for this thread, its laced with misleading and contradictory solutions and information. It has boiled down into insults and sarcasm from the OP. In my eyes, grounds for thread locking.

"

Rhys wrote:

As the programmer responsible for maintaining the client/server synchronization of the random level generation, I can tell you that this sounds like a nightmare, for a few reasons.

1) The server must validate the snapshots in real-time, not once the client leaves the instance. This is because the client can potentially muck around in one instance for huge lengths of time. Hours, days, weeks even, if the realm stays up. Processing so much all at once would lag the instance to hell and back, and changing areas has to wait on this task. Also, you will still need the ability to resync players to a recent state, when desync inevitably occurs (see next point). Also also, you need to be able to save the player's data at a moment's notice to prevent item dupes with trading.

"

ScrotieMcB wrote:

Spoiler

"

Daefecator wrote:

Actually, desyncs are not even remotely the same experience for any given two machines. It's not like we are in the same room, our IP routing paths differ, our ping fluctuates and is not somehow synchronized etc. I really don't feel like both clients could ever see the same distorted (or desync'ed) game state.

You're looking at the wrong things. Reread Chris' example of how client prediction works; the only key factor is latency, and it's still possible for clients with very different latency to fail the same prediction.

For example, let's say you have 75ms latency, and your friend has 125ms latency.

-125ms: Your friend orders to attack Monster 1 with a melee attack. He begins moving to within range on his screen.
-75ms: You order to attack Monster 1 with a melee attack. You begin moving to within range on your screen.
0ms: The server receives both you and your friends commands simultaneously. On the server, you both begin moving to within range.
2875ms: According to your friend's client, he arrives at the monster and begins the attack animation.
2925ms: According to your client, you arrive at the monster and begin the attack animation.
2950ms: On the server, Monster 2 (a Skeletal Rhoa) makes contact with a Charge, stunning you. It sends information to both clients indicating that you've been stunned.
3000ms: On the server, your friend arrives at the monster and begins attacking it.
3025ms: Your client receives the information that you've been stunned by a Rhoa. You are resync'd back to the spot where you were hit.
3075ms: Your friend's client receives information that you've been stunned by a Rhoa. Your character on his screen is resync'd back to the spot where you were hit.

Note that you have only 60% of the latency of your friend, yet both of you suffered essentially the same desync. That's because the desyncing event took place during a time where both clients were in a latency period. Keep in mind that, usually, you and your friend would be unlikely to have that large of a difference in latency; most users have similar latency during the same times of day, even with different ISPs, and that most times one of you might have a 5% or 10% advantage, if even that much.

"

ScrotieMcB wrote:

Spoiler

"

Daefecator wrote:

Spoiler

It is actually very amusing encountering these "predicting" mistakes eventually leading to desyncs. I am regularly playing with my brother, and we are actively communicating via Skype while playing. We both use /oos macro at about every 6-10 seconds.

It is just freaking amazing, that 90+% of the time we both see the exact same game state before using /oos macro - let's say mob is in front of us, but after /oos it appears to be behind us.

It is really rare when one of us actually sees the other desync'ed. I can actually recall yesterday's event, when we were farming ledge merciless and I was using Weapon Throw and was unable to damage anyone (despite having Resolute Technique). After using /oos I saw i was hitting wall all the time, but my brother saw me hitting the wall for all that time already.
The other case was when he saw he was at least half a screen away from Volatile Stormblood but got hit nevertheless, but I saw he was actually in range all the time.

This makes me think that "Client Prediction" (if we call it like that) is very similar for all clients (like me and my brother both playing), but at the same time it looks like it completely differs from "Server Prediction"!

TLDR: Doesn't the root of the D problem lie in that client predicts game state in a totally different way that server does?

How comes we both see boss is here, but loot drops somewhere else? Couldn't it be because of some bug fix applied to server code somehow just didn't make it to the client code, or vice versa?

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.

"

qwave wrote:

SkyCore, we're 70 pages into this thread and you still don't understand even the most basic principles of the system. I am completely floored, seriously. It's like you don't even want to try to understand.

Why do you continually post on this thread if you're not interested in understanding the proposal from the get-go?

"

The problem with D2 was that items were being created in parallel to the destruction, as far as I could tell from an end-user perspective and it was sensitive to latency and multi-threading weaknesses in the code when it comes to verifying the object has been destroyed before re-creating it somewhere else.