General Discussion - Technical solution to eliminate desync in single-player sessions - Forum

@SkyCore: I'm not planning on arguing for another 70 pages. I just feel that big parts of the discussion revolved around technicalities (e.g., arguing over the definition of "dumb terminal") when there are much more serious issues that should be pointed out more clearly. " Nightmare90 wrote: However they all need to be in the range of the seed given both the client and the server, right? There won't be a "invulnerability", given that the seed changes randomly between checks. There will always be a "path of least damage taken". And if the seed would change randomly between checks, that would mean the server had to provide a new seed each time, otherwise you couldn't count on it being random. But then you have desync just like before, 'cause what do you do if you don't receive the server's response in time? " HellGauss wrote: Yes the cheating they are referring to is that, since you can calculate, you can choose the best result. Is something like saying that i can cheat during chess player because i will evaluate a lot of combinations and choose the best one. Chess is a game of perfect information. Path of Exile is a game of chance and uncertainty. It is more like saying that we're playing a dice game and instead of rolling once, I can choose between a hundred different rolls.	Posted by Amaroid#6904 on Nov 20, 2013, 2:54:01 PM Quote this Post
" ScrotieMcB wrote: You know, when you get right down to it, using shared random seed to handle combat math isn't really that relevant of a change. For the most part, it isn't combat math prediction which is causing desync, it's monster location prediction. What this game needs is much better client-side prediction in terms of when monsters will initiate the use of skills. If a Rhoa is going to charge you, the client should know this about one latency-trip-time before the server knows it. I believe right now the system is that the client waits on the server to send a command ("this Rhoa is now charging you"), then the Rhoa begins the charge on the client once the client receives said message. Naturally, this leads to massive desync, because the Rhoa movement skill begins two latency-trip-times later on the client than it should. And, in all seriousness, a shared random seed could help with this. If any part of a monster's decision tree is based on an RNG call — say, 70% chance for a Voidbearer within melee range to use melee attack, 30% chance to activate its Incinerate attack — then a shared random seed actually would be of great help. This would make monster skill selection deterministic from a simulation perspective while at the same time appear random. In short, if the player's skills initiate on the client one latency-trip-time before they begin initiating on the server, so should monster skills. Unfortunately I think that combat predictions are a source of desync as well, considering you can be stunned/frozen depending on the amount of damage that a monster can do, that will affect if you reach your destination when moving or not.	Posted by LogoOnPoE#1873 on Nov 20, 2013, 2:59:04 PM Quote this Post
@Scrotie That is only one aspect. The main flaw of current system is that there is only one 'official' version of the instance: the server one. And it is running in realtime. When the client send a command, it is 'timestamped' (=processed) by the server when it get it. Usually this is not a big issue, but that 0.1 sec difference may result in the fact that the command is valid or it is not valid, or it could get to butterfly effect after a short while. These errors are corrected only once every 5 seconds or by \oos. The server should handle client commands not in realtime, but with a few seconds of delay tolerance. The timestamp of the commands should be marked by the client. In single player, the 'official' realtime instance should be on the client, because it is on the client that I play. The server should only check the command's integrity. " Chess is a game of perfect information. Path of Exile is a game of chance and uncertainty. It is more like saying that we're playing a dice game and instead of rolling once, I can choose between a hundred different rolls. You are technically right. However i think, that with good design, it can be very difficult to exploit this cheat. Consider that the dice is only one, the only real cheat about that is that the bot knows the result of the roll. It cannot choose the roll. Roma timezone (Italy) Last edited by HellGauss#6525 on Nov 20, 2013, 3:04:58 PM	Posted by HellGauss#6525 on Nov 20, 2013, 3:02:50 PM Quote this Post
" LogoOnPoE wrote: " ScrotieMcB wrote: You know, when you get right down to it, using shared random seed to handle combat math isn't really that relevant of a change. For the most part, it isn't combat math prediction which is causing desync, it's monster location prediction. What this game needs is much better client-side prediction in terms of when monsters will initiate the use of skills. If a Rhoa is going to charge you, the client should know this about one latency-trip-time before the server knows it. I believe right now the system is that the client waits on the server to send a command ("this Rhoa is now charging you"), then the Rhoa begins the charge on the client once the client receives said message. Naturally, this leads to massive desync, because the Rhoa movement skill begins two latency-trip-times later on the client than it should. And, in all seriousness, a shared random seed could help with this. If any part of a monster's decision tree is based on an RNG call — say, 70% chance for a Voidbearer within melee range to use melee attack, 30% chance to activate its Incinerate attack — then a shared random seed actually would be of great help. This would make monster skill selection deterministic from a simulation perspective while at the same time appear random. In short, if the player's skills initiate on the client one latency-trip-time before they begin initiating on the server, so should monster skills. Unfortunately I think that combat predictions are a source of desync as well, considering you can be stunned/frozen depending on the amount of damage that a monster can do, that will affect if you reach your destination when moving or not. I don't believe a failure to predict character position is the cause of most problems. For example, the most famous desync example — teleporting into a room — is a failed character position prediction caused by a failed monster position prediction. I believe stunned-in-transit desyncs account for a very small percentage of the big picture. 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.	Posted by ScrotieMcB#2697 on Nov 20, 2013, 3:04:12 PM Quote this Post
" ScrotieMcB wrote: What this game needs is much better client-side prediction in terms of when monsters will initiate the use of skills. If a Rhoa is going to charge you, the client should know this about one latency-trip-time before the server knows it. I believe right now the system is that the client waits on the server to send a command ("this Rhoa is now charging you"), then the Rhoa begins the charge on the client once the client receives said message. Naturally, this leads to massive desync, because the Rhoa movement skill begins two latency-trip-times later on the client than it should. Partly right, but actually the problem with those kind of attacks is that the game doesn't couple this with a locational update, which is what pretty much every action game currently available does. In fact, pretty much all movement of any kind for all entities is not synchronized at all unless the server detects something so horrible that it can't possibly be close. (Hence the "I got snapped into another room" issues) Also, the server is most likely running at a different framerate than the client is, which is incredibly bad when coupled with animation based motion. This part is actually a common mistake even in action games, but they usually perform corrections an order of magnitude more frequently than this game does, so it just turns into "move X causes rubberbanding a lot" instead of "I got hit by invisible monsters until I died and teleported to another area of the map" Speaking of framerates, all of you guys speculating at crazy result manipulation hacks are overcomplicating it way too much; you can easily break what's being suggested with timestep manipulation. Often known in FPS circles as a "speed hack".	Posted by Mysterial#1424 on Nov 20, 2013, 3:08:25 PM Quote this Post
" HellGauss wrote: The timestamp of the commands should be marked by the client. Are you seriously advocating trusting the client's timestamp? " HellGauss wrote: In single player, the 'official' instance should be on the client, because it is on the client that I play. The server should only check the command's integrity. There's no way such checks could ever be made information-theoretically secure, which essentially means that it's just a matter of time before hacks are discovered (hashes aren't feasible). What we should be discussing is not misguided attempts to run the main gamestate on the client, but instead on how to ensure that the client accurately predicts the server's gamestate. I know qwave wouldn't agree with this, but gosh darn it, it's true, and I actually think that if he'd stop tilting at windmills he might actually be able to contribute some good ideas towards such a system. 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, 3:12:18 PM	Posted by ScrotieMcB#2697 on Nov 20, 2013, 3:10:12 PM Quote this Post
" Mysterial wrote: " ScrotieMcB wrote: What this game needs is much better client-side prediction in terms of when monsters will initiate the use of skills. If a Rhoa is going to charge you, the client should know this about one latency-trip-time before the server knows it. I believe right now the system is that the client waits on the server to send a command ("this Rhoa is now charging you"), then the Rhoa begins the charge on the client once the client receives said message. Naturally, this leads to massive desync, because the Rhoa movement skill begins two latency-trip-times later on the client than it should. Partly right, but actually the problem with those kind of attacks is that the game doesn't couple this with a locational update, which is what pretty much every action game currently available does. In fact, pretty much all movement of any kind for all entities is not synchronized at all unless the server detects something so horrible that it can't possibly be close. (Hence the "I got snapped into another room" issues) Also, the server is most likely running at a different framerate than the client is, which is incredibly bad when coupled with animation based motion. This part is actually a common mistake even in action games, but they usually perform corrections an order of magnitude more frequently than this game does, so it just turns into "move X causes rubberbanding a lot" instead of "I got hit by invisible monsters until I died and teleported to another area of the map" Speaking of framerates, all of you guys speculating at crazy result manipulation hacks are overcomplicating it way too much; you can easily break what's being suggested with timestep manipulation. Often known in FPS circles as a "speed hack". If only everybody understood the situation as well as you do the forums wouldn't be in such a state. I would try to comment more meaningfully, but I think this thread is ultimately as pointless as it gets, aside from the good intentions.	Posted by Deleted on Nov 20, 2013, 3:16:13 PM
" Mysterial wrote: Partly right, but actually the problem with those kind of attacks is that the game doesn't couple this with a locational update, which is what pretty much every action game currently available does. In fact, pretty much all movement of any kind for all entities is not synchronized at all unless the server detects something so horrible that it can't possibly be close. (Hence the "I got snapped into another room" issues) I know you might disagree with this, but the GGG philosophy on this is that short "teleports" break immersion. If the client simulation is known to be divergent from the server gamestate, but is still within a reasonable degree of tolerance, the GGG policy is to avoid automatic resynching on the premise that a teleport is a jarring experience, and the client simulation is close enough to allow the risk of not resynching until/unless the situation diverges even further. To be honest, I kind of agree with that. It does break immersion, and although I notice a lot of minor desyncs when I'm really paying attention, the game corrects them without needing to teleport me, and if I really cared I'd have /oos on macro. The main problem I see with this is that, instead of giving the client this information and letting it decide what to do with it (perhaps avoiding teleport), it instead keeps the information to itself. There is a difference between giving the client information and giving the player information, and I see no reason why not to perform the former. 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, 3:21:17 PM	Posted by ScrotieMcB#2697 on Nov 20, 2013, 3:19:28 PM Quote this Post
" ScrotieMcB wrote: What we should be discussing is not misguided attempts to run the main gamestate on the client, but instead on how to ensure that the client accurately predicts the server's gamestate. Correct, but it's not like that hasn't been discussed for over a year now and it isn't like there aren't a number of clear options to explore. They have been unwilling or unable to do so for reasons that we don't know. I find the pointless argument amusing. I suppose I should be working, though.	Posted by Mysterial#1424 on Nov 20, 2013, 3:22:37 PM Quote this Post
" Are you seriously advocating trusting the client's timestamp? As long as I am playing, I also feel natural to choose WHEN cast fireball. I think this is the main misconception that has leads to misunderstood the OP suggestion. There is no need of a 'realtime' running of instance on the server. Nobody is playing on the server and enjoying the game. The server should only check that the command of the client are legit. It is not the server that is moving monster, it is the client/server shared algorithm that do that. The way to do that is determinism. As long as initial conditions are the same both on the client and the server and the command are legit, the gameplay is defined in a cristalline a-temporal universe. Of course some sort of syncronization is needed to prevent cheating: this basically means that i cannot send a command timestamped 3 minutes ago, but at max (say) 4 seconds. The only interaction of the server with the client should be the definition of initial status, loot/craft et similia, and maybe some sort of scrambling moves to grant partial sincronization, so that the client is not autonomuous for too much (i suggested to send a new rng-seed each 3-4 seconds). Roma timezone (Italy)	Posted by HellGauss#6525 on Nov 20, 2013, 3:26:34 PM Quote this Post