On Mon, 2007-10-08 at 21:20 +0100, Nick Wedd wrote: > I have added this to my report: > > # In its round 1 game with WeakBot50k, HBotSVN achieved a convincingly > # won position with all the dame filled and 25 seconds left on its > # clock. There was then some disagreement about status, and the game > # was resumed. WeakBot50k made a pointless move, and HBotSVN did not > # respond or pass but timed out. > > I was not watching this game when it ended, the above is based on what I > can deduce from the SGF record. It seems to me that one of the players > (I can't tell which, and I consider that it doesn't matter) made a > totally unjustifiable claim about status, and that HBotSVN then failed > to support the clean-up protocol, timing out when it could and should > have passed, and lost as a consequence. > > Nick
The summary looks good. In the private e-mail with the kgs issue with the length of the gameNotes field, I gave a summary of what went wrong in that game. It wasn't that HBotSVN made an unjustifiable claim, it simply doesn't support final_status_list and kgsGtp makes an unjustifiable claim on its behalf (it'll claim everything is alive). Obviously, this led to the 3 dead black stones forcing cleanup to begin. Previous explanation of what went wrong in the game end protocol: It appears that an undo in the cleanup phase confused the adaptive time management in HBotSVN. While undo's are not supported, kgsGtp will start a new game and resend all time_left commands and moves as play commands. The adaptive logic expected genmove commands between time updates and errored in response to every time_left command in the replay. The net effect was that when it finally got a genmove, it was treating it like the first move in a game with the full time remaining. _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
