Technical solution to eliminate desync in single-player sessions

GGG needs to explain this as clearly as possible, post it in the forums, and sticky it so we can refer people to read it every time someone complains about desync.

"

I'm not sure how I, an application developer, can fail to "follow a standard" for compilers. Other than playing with compiler flags (which doesn't work), what else can I do?

Most C++ compilers should be following the IEEE 754 standard. Here's a brief whitepaper on the topic. If you're using C++, it should be doable:
http://www.appinf.com/download/FPIssues.pdf

"

Yes, but the client knows exactly what the new seed will be ... I don't see how this would help. What exactly are you hashing? Do you mean encrypting the RNG state (which isn't hashing, btw)??

So what im saying is that you would generate each random number using a cryptographic hash against the seed. This would make it computationally expensive for bots to discover enough permutations to be efficient. Although more research should probably be done on mitigating this, the elimination of desync/lag is far more important for the overall sanctity of the game.

At the end of the day, botters may gain a slight advantage. However, solving desync/lag issues should be the primary focus at this time. You can worry about botters once the rest of the playerbase is satisfied with the game.

"

In which case you get instant desync every time you fiddle with your gear and a monster happens to be nearby.

I don't believe that you can craft with equipped gear, right? As long as gear must be unequipped to craft, then the server can perform the upgrade. Once new gear is equipped, no synchronization should be necessary because it's a known state of the character.

"

But the whole point is that the character isn't supposed to die. Even a 1ms lag can mean the difference between life and death. I think it will feel quite bad (especially for Hardcore players) to have the client as the authority for movement and combat but NOT death.

I think you misread my post. Death would only be simulated by the server in the event that there is a lapse in snapshots/input (a disconnect). You indicated that players could cheat death by ending their snapshots, I am saying they cannot cheat death because in that event the server would continue the simulation.

"

But the server has to send map data to a client operating "in the future" as far as the simulation is concerned. The server doesn't know where the player is located on the client, and it has to send the map data in advance. So it still needs to send map data for regions the serverside player can't see. Regardless, it's a massive "buff" to maphack.

Good point, but the server only needs to feed the client enough map data to account for projectiles. If projectiles have unlimited range, then that could be a problem. May need to put a limit on projectile range in order to solve this.

"

-Because we'd have to overhaul the entire skill system (and, indeed, game engine)

This is a tricky one. The client basically needs to be able to perform the skill and combat calculations for this to work. If you don't have a way to move this code to the client, then yeah, this is all moot.

"

-Because we'd have to overhaul our network architecture
-Because it doesn't work for multiplayer
-Because it's still very prone to desync

You shouldn't need to overhaul the network architecture, you just need to give the game client the ability to calculate skills/combat. You then just need a server API call for snapshot validation. This is only needed for single-player sessions.

I know it doesn't work for multiplayer. The current system would not need to be changed to facilitate multiplayer sessions. The client would perform these calculations only in single-player sessions.

It's not prone to desync at all except in very high latency scenarios (1000+ ms).

So what I'm getting from this is, desync is close to fixed as it is going to get with the current engine and server architecture, so any hopes of it being fixed any time soon are far gone.

At least know we know this so we can learn to live with it, or die by it.

qwave: Clearly you do not understand how computers work with floating points. It has far more to do with underlying architecture than the compiler standard. You can take Clang and run it on 3 different machines and get 3 different results depending on the architecture underneath. For instance an ARM processor is not the same as an Intel board. Hell, even within intel boards you can have differences. Get a high-end server card vs. your standard desktop card and you will see different results. Floating point math is the BANE of complex computing. There is dedicated hardware for accurate calculations.

How do you determine the seed? and how does a cryptographic hash of the seed provide security?


If you have ever seen someone race can see how often racers will mess with equipment will fighting/moving. Yes, the piece is in their bags, but they didn't stop normal actions to do so.

You are talking about a completely different client/server model this will undoubtedly be a huge change to the network code.
This game focuses on both solo and group, so how does a solution for only one person at a time fit into their model?

So are we to take away that desync is just a fact of life in this game, it will always exist, and if you do not like the situation as it, then you should find another source of entertainment as it is not going to change?



From a customer perspective, I think it would be interesting to know what GGG's top 5 priorities are for the game moving forward and if desync is one of them. If I speculate with a bit of cynicism, I wonder how that top 5 would match the top 5 from the community. I can't speak to the former, but I highly suspect the latter would include desync, no matter what resource cost that would entail.

"

qwave wrote:

So what im saying is that you would generate each random number using a cryptographic hash against the seed.

I would really appreciate you explaining this. None of those words fit together in my head. Here's what I see:

seed = 123456 <--plainly viable
hashedSeed = SHA1.Hash(seed) <--Either a custom/builtin algorithm*
Random.Seed(hashedSeed) <--Either a custom/builtin algorithm*
rnd = Random.Next() <--Either a custom/builtin algorithm*

What I see is the seed, hashed or not, is the seed. Since its on an untrusted system, how does that hide the 'seed' from anyone?

And if your doing BOTH the 'cryptographic' hashing AND number generation on the same system (an untrusted on at that), then you've essentially given the 'hacker' all the tools he needs, providing both the hashing algorithm and the RNG algorithm.

"

TheBigNasty wrote:

So are we to take away that desync is just a fact of life in this game, it will always exist, and if you do not like the situation as it, then you should find another source of entertainment as it is not going to change?



From a customer perspective, I think it would be interesting to know what GGG's top 5 priorities are for the game moving forward and if desync is one of them. If I speculate with a bit of cynicism, I wonder how that top 5 would match the top 5 from the community. I can't speak to the former, but I highly suspect the latter would include desync, no matter what resource cost that would entail.

Where are you getting this from?

This thread is not about how GGG is working on reducing desync, it is on this particular solution.

That being said, you are correct in essence. Desync will always exist, for a myriad of reasons. That is not to say that it can't be reduced. Furthermore, GGG has stated that it is a goal to improve their code to reduce desync. But it is not a simple solution that can be easily implemented. It is an extremely complex problem that with no straightforward sure fire remedies.

"

TheBigNasty wrote:

So are we to take away that desync is just a fact of life in this game, it will always exist, and if you do not like the situation as it, then you should find another source of entertainment as it is not going to change?



From a customer perspective, I think it would be interesting to know what GGG's top 5 priorities are for the game moving forward and if desync is one of them. If I speculate with a bit of cynicism, I wonder how that top 5 would match the top 5 from the community. I can't speak to the former, but I highly suspect the latter would include desync, no matter what resource cost that would entail.

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.