[gnugo-devel] avoid .sgf problem

[Arend Bayer]

We have a .sgf-problem:

Handicap stones should be set up with AB[]. If gnugo detects a game with
handicap, but no AB[]'s, it adds them (after the first move).

KGS uses B[] instead of AB[] in case of free handicap placement. This may
not be according to the letter of the sgf-specification, but I think it is
correct according to its spirit -- AB[] is for preset stones (starting position
of a problem, handicap stones), B[] is for moves that are an actual decision
by one of the players.

In fact, it seems to me that the text in the description of the HA[]
property was only thinking about fixed handicap.

I suggest to avoid this issue by only manually adding the handicap stones
if we detect a _white_ move on the empty board in a handicap game.

Arend



Index: engine/interface.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/interface.c,v
retrieving revision 1.48
diff -u -p -r1.48 interface.c
--- engine/interface.c  19 Jul 2004 12:23:08 -0000      1.48
+++ engine/interface.c  20 Aug 2004 23:41:23 -0000
@@ -502,7 +502,6 @@ gameinfo_play_sgftree_rot(Gameinfo *game
   
   int untilm = -1, untiln = -1;
   int until = 9999;
-  int addstone = 0;          /* handicap stone detector */
   
   if (!sgfGetFloatProperty(tree->root, "KM", &komi)) {
     if (gameinfo->handicap == 0)
@@ -569,7 +568,6 @@ gameinfo_play_sgftree_rot(Gameinfo *game
                  i, j);
        else
          gnugo_add_stone(i, j, BLACK);
-       addstone = 1;
        break;
              
       case SGFAW:
@@ -580,16 +578,9 @@ gameinfo_play_sgftree_rot(Gameinfo *game
                  i, j);
        else
          gnugo_add_stone(i, j, WHITE);
-       addstone = 1;
        break;
              
       case SGFPL:
-       /* following really should not be needed for proper sgf file */
-       if (movenum != 0 && !addstone) {
-         gnugo_sethand(gameinfo->handicap, 0);
-         sgfOverwritePropertyInt(tree->root, "HA", gameinfo->handicap);
-       }
-
        /* Due to a bad comment in the SGF FF3 definition (in the
          * "Alphabetical list of properties" section) some
          * applications encode the colors with 1 for black and 2 for
@@ -601,13 +592,20 @@ gameinfo_play_sgftree_rot(Gameinfo *game
          next = WHITE;
        else
          next = BLACK;
+       /* following really should not be needed for proper sgf file */
+       if (stones_on_board(GRAY) == 0
+           && next == WHITE) {
+         gnugo_sethand(gameinfo->handicap, 0);
+         sgfOverwritePropertyInt(tree->root, "HA", gameinfo->handicap);
+       }
        break;
              
       case SGFW:
       case SGFB:
        next = prop->name == SGFW ? WHITE : BLACK;
        /* following really should not be needed for proper sgf file */
-       if (movenum != 0 && !addstone) {
+       if (stones_on_board(GRAY) == 0
+           && next == WHITE) {
          gnugo_sethand(gameinfo->handicap, 0);
          sgfOverwritePropertyInt(tree->root, "HA", gameinfo->handicap);
        }