Heres my give on what should happen upon a desync, its fairly complex, allot of work, but I'm sure one the developers could bundle up and do it:
1) A desync occurs. 2) Screen fades out, like when pause is on, message says "Games desynced". It has a progresss bar underneath, progressing through the following steps. *important* cancel button. 3) System dumps full game memory 4) System zips the "glob2.world-desynchronization.dump.txt" 5) System sens this zipped file to yog, along with any applicable system information (like gcc -v on unix) 6) Yog logs this information from all of the users 7) Each player, except the game host (the one who created the game) contacts the host, and resyncs from them (this could be as simple as feeding the output of save from the host to the input of load in the children, provided endian-correctness) 8) The game has been magically resynced, so the game continues 9) If it desyncs 3 times in one game, the game is not allowed to proceed. Steps 3-6 are the most important, steps 2 and 7-9 are mainly for end users who probably would be quite angry/confused at the window dissapearing for no apparent reason, and if they are as techie enough to have run it on the console, the might be further concerned with the words "Dump full game memory" and "World desynchronisation". This system has the added advantage that every desync gets recorded and can be examined, and that the dumps from every player in the game are garunteed to be accurrate. Several of us often forget to save our desync dumps after a crash, most notably appleboy, who just loads up the save game and we all restart. Steps 3-6 are most important for now, and they are easiest. Steps 2 & 7-9 are more difficult, but are going to become increasingly important as we approach a 1.0 release. _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
