Technical solution to eliminate desync in single-player sessions

The RNG state would only be modified by actions which result in a random roll, and each action type could have it's own seed. Even still, a bot is not going to have the computing power to take advantage of that. I would rather eliminate desync/lag than split hairs on whether highly sophisticated neural-net bot farms could gain a slight advantage. In general, these types of bot farms do not exist. The expenses related to that much computing power far exceeds the RMT value of goods.

"

qwave wrote:

The rng state would only be modified by actions which result in a random roll, and each action type could have it's own seed. Even still, a bot is not going to have the computing power to do any of this, so I feel that it's a moot point.

I worry of these two specific types of "hack":

Problem: I want to not get crit by Kole. Treat the "crit RNG" as a black box -- I don't care how it's implemented for this thought experiment, but I think it would likely fall into one of the following two cases: it either changes rapidly enough to be modified easily, or changes infrequently enough that I can predict future behavior, and modify my own behavior as appropriate.

Solution 1, if "crit RNG" is not modified often: Using the RNG seeds, predict whether or not Kole's next attack will be a crit. When a crit is predicted, do whatever necessary to change the RNG state and cancel the crit. Alternately, if it cannot be changed, be very very careful -- use granite flasks, etc. to mitigate that incoming damage.

Solution 2, if "crit RNG" is modified often: upon receiving a crit, "go back in time" 250ms or whatever necessary, and wiggle history until the "crit RNG" changes state to something desirable. You don't need to compute everything, just one or two cases. If I get crit in all of these small number of cases, oh well. If, in one of these alternate histories, I don't receive the crit, submit that alternate history and update what I see as the player to the result.

"

Problem: I want to not get crit by Kole. Treat the "crit RNG" as a black box -- I don't care how it's implemented for this thought experiment, but I think it would likely fall into one of the following two cases: it either changes rapidly enough to be modified easily, or changes infrequently enough that I can predict future behavior, and modify my own behavior as appropriate.

In one-on-one fights like this (Brutus comes to mind as well), more entropy could be added to increase the complexity of doctoring the events. However, I still feel that we're splitting hairs. If a player can gain a slight advantage in fighting Kole or Brutus using advanced software, I would prefer that instead of worrying about lag/desync. Heck, without lag and desync normal players would actually be able to perform like they should. I don't think that the few situations where this system can be 'gamed' will provide any significant advantage. The biggest edge players will gain is the fact that they no longer need to worry about lag or desync. I won't get killed by Kore/Brutus/Vaal because I could actually dodge their attacks - no hacks needed! ;-)

"

qwave wrote:

2. The server must mandate that it receives a continuous stream of data, otherwise it will forcefully sync you back to the last known state. You might consider this the same thing as the 'desyncs' that we already have. However, this particular 'desync' has nothing to do with being out of 'sync' as much as it has to do with an actual 'loss of connection' (The actual data stream connection has been severed). This would not occur nearly as frequently as the current desync.

Which would make playing even worse compared to now.

Think about it: State snapshots = big data.

Currently desync is experienced whenever you try to send big data and are on a moderately slow connection i.e. flicker multistrike, cyclone multistrike, etc.

What you're proposing is that we make EVERYTHING be sending big data, so the moment we go above 200 ms ping, we get warped back. Whoop de doo, that's WORSE than what we have right now.

"

qwave wrote:

The client can control the order of events, but it cannot 'assign specific numbers' to events. There is not a 'pool of random numbers', its a deterministic seed. You are misunderstanding the nature of how this works.

Congratulations, I shall start making a hack tool that checks this seed. If I see a consistent skew towards low values (since PRNG implementations will always have some sort of skew over a small sample size), I shall now be alerted by my hack tool that playing through this instance is bad, and I should re-instance.

"

qwave wrote:

Packet loss is completely different from a full lapse in the data stream. This data stream would utilize a TCP stream, whereas the current system relies heavily on UDP packets.

TCP? Seriously? So you're okay with 5 minute loading screens then?

I wrote a long post which got deleted immediately somehow. ><

Recapping briefly: I'd agree the advantage gained is very small, and it would be at huge cost to whoever wrote the hack. It's certainly not comparable to a lot of the hacks that GGG set out to thwart. I'd rather let a very weak hack leak through than deal with monsters streaming through doors and camping out next to my character for 5 seconds when they aren't actually there on the server simulation.

That said, the cost to implementing this system could be substantial, and applies only to single-player which limits its applicability. It also isn't perfect, and for some that may be unacceptable.

However, I think this is a good idea for how to solve single-player desync without trusting the client entirely.

From a dev point of view I can already tell that the development time of this proposal would take at least 6 months with about 10 devs.

Maintenance and keeping up with managing client side issues, hacking and general other extended support would be a waste of resources.

That time and money could be better spent finding a more elegant server-side solution.

"

Think about it: State snapshots = big data.

Currently desync is experienced whenever you try to send big data and are on a moderately slow connection i.e. flicker multistrike, cyclone multistrike, etc.

What you're proposing is that we make EVERYTHING be sending big data, so the moment we go above 200 ms ping, we get warped back. Whoop de doo, that's WORSE than what we have right now.

The snapshots could be compressed and streamed via an active TCP connection. It is not prone to desync, so it is not volatile like the current system is.

"

Congratulations, I shall start making a hack tool that checks this seed. If I see a consistent skew towards low values (since PRNG implementations will always have some sort of skew over a small sample size), I shall now be alerted by my hack tool that playing through this instance is bad, and I should re-instance.

Like I have stated in previous posts, you are misunderstanding how the seed works. 'lower values' are not worse, in fact, the value itself means nothing without a context. You would not be able to gain an advantage by evaluating the seed.

"

TCP? Seriously? So you're okay with 5 minute loading screens then?

TCP is already being used for this. The snapshots would be streamed during play. The server would evaluate the snapshot after leaving the instance. It would not take more than a few seconds to evaluate whether a snapshot is accurate or not.

"

From a dev point of view I can already tell that the development time of this proposal would take at least 6 months with about 10 devs.

Maintenance and keeping up with managing client side issues, hacking and general other extended support would be a waste of resources.

That time and money could be better spent finding a more elegant server-side solution.

If the client/server is the same language and they practiced modern software paradigms, it may not take them as long to implement. I do not think it would take 6 months to make these changes, but it may take up to 3 months. They already need to deal with these 'issues' you describe in their current system. They still have to validate for hacks currently.

There is not a more elegant server-side solution, otherwise they would have implemented it from the get-go. There are only so many solutions to this sort of problem in computer science/physics.

"

Baxta wrote:

From a dev point of view I can already tell that the development time of this proposal would take at least 6 months with about 10 devs.

Maintenance and keeping up with managing client side issues, hacking and general other extended support would be a waste of resources.

That time and money could be better spent finding a more elegant server-side solution.

Practically, I must agree with this, especially if GGG has progress towards a better universal desync solution.

"

qwave wrote:

To 'avoid' a crit, you would have to roll yourself back 500 milliseconds and re-evaluate all permutations that do not result in a crit. I believe this is virtually impossible. It would take modern computers a few seconds just to perform a single attack. And the 'optimal solution' could easily result in your character's death as a result of the next set of permutations. In other words, 'avoiding that crit' may have gotten your character surrounded by deadlier mobs.

So now you don't have desync, you have computational lag introduced into the game. Congratulations.

"

qwave wrote:

TCP is already being used for this. The snapshots would be streamed during play. The server would evaluate the snapshot after leaving the instance. It would not take more than a few seconds to evaluate whether a snapshot is accurate or not.

And it would take several MINUTES to transfer state snapshots especially if you have a backlog due to a large amount of user actions taken, i.e. Multistrike, Summoners, Totem Sporkers, ETC.