Technical solution to eliminate desync in single-player sessions
|
Yeah, I believe there are a few solutions to the well-known floating point issues. However, I think the leniency solution is doable either way. =)
|
|
" I retract this statement as the error was mine in saying determining rather than validating. And i will grant myself a pardon for at the time you were proposing that the server validate gamestates without running a copy of the game. Such things have been cleared up since then. For years i searched for deep truths. A thousand revelations. At the very edge...the ability to think itself dissolves away.Thinking in human language is the problem. Any separation from 'the whole truth' is incomplete.My incomplete concepts may add to your 'whole truth', accept it or think about it
|
|
" Maybe, but it is too dangerous. IEEE math is very strange: for example (a+b)+c =/= a+(b+c). I f different compilers or different platform moves data form the CPU to memory in different way, or if multithreading do those moves automatically, things could go messy. For some unknown evil reason the intel FPU is 80 bit, which is not standard. Roma timezone (Italy) Last edited by HellGauss#6525 on Nov 20, 2013, 11:30:34 AM
|
|
|
The tiny rounding errors won't cause a problem probably, but the equality like you suggest may. I would hope that GGG is not testing equality on floating point values though, haha.
SkyCore: Sorry if I explained it poorly, its been a long day. Last edited by qwave#5074 on Nov 20, 2013, 11:35:13 AM
|
|
" Practically yes, it's a lockstep, where server provides the seeds for random numbers, the client runs it's game and passes the actions and outcome to the server, and then the server runs the game in lockstep to verify the outcome. |
|
" Actually even tiny rounding errors can cause a serious problem if there are many steps in the calculation that are rounded to integer, and if I remember correctly from some Marks posts on skils, that is the case. |
|
|
I thought that lockstep implied that the client would be waiting for a validated response before continuing. But I suppose this could be called 'asynchronous lockstep'. Not sure.
|
|
|
Actually no, I don't think it's lockstep. Lockstep implies that each system runs the simulation in parallel. In this proposal the client runs the simulation and then the server verifies it.
I actually think that Rhys_GGG thought the same thing. My intentions were for the server to perform the simulation when receiving a snapshot just to verify it. It's up to GGG really. Last edited by qwave#5074 on Nov 20, 2013, 11:46:51 AM
|
|
" As I understand lockstep can be run both in parallel, and in delayed, and to either provide redundancy or to verify the output, as long as both machines operate on the same input. |
|
" What happens when the server comes back and says the client is wrong? |
|
