Wild21 on ICC with Winboard?

[JVMerlino]

Ok, we have progress. It turns out the syntax on one of my ICS vars settings was incorrect. The human is now able to challenge Myrddin to a wild 20 game, load a fen, and then make a move, after which Myrddin will respond and the game will play normally to its conclusion....but ONLY if the fen has white to move. If black is to move, then it appears Winboard never sends the human's first move to Myrddin so it never knows that it is on the move. We tried this with several positions. White always worked and Black always failed.

Here's the relevant portion from the winboard debug file for one attempt. I can provide as many as you like if necessary. Note that the resignation was forced by me when it was obvious that Myrddin was not thinking.

==========================
<ICS: \015\012Challenge: frentz (1765) [black] MyrddinComp (2585) unrated wild(20) Loadgame 3 3\015\012You may accept this with "accept frentz", decline it with\015\012"decline frentz", or propose different parameters.\015\012\007aics%
ics input 0, castling = 7 0 4 7 0 4
recognized 'wild(20)' (20) as variant normal
>ICS: /accept frentz\015\012
silence
silence
<ICS: Creating: frentz (1765) [black] MyrddinComp (2585) unrated wild(20) Loadgame 3 3\015\012\007You accept the challenge of frentz.\015\012"Seeking" ad #32 removed.\015\012"Seeking" ad #48 removed.\015\012"Seeking" ad #202 removed.\015\012{Game 1535 (MyrddinComp vs. frentz) Creating unrated wild(20) match.} *\015\012\015\012<12> rnbqkbnr pppppppp -------- -------- -------- -------- PPPPPPPP RNBQKBNR W -1 1 1 1 1 0 1535 MyrddinComp frentz 1 3 3 39 39 180 180 1 none (0:00) none 0\015\012The players have agreed that disconnection will count as a forfeit.\015\012aics%
ics input 0, castling = 7 0 4 7 0 4
Ratings from 'Creating:' frentz 1765, MyrddinComp 2585
recognized 'unrated wild(20) match.' (20) as variant normal
recognized 'unrated wild(20) match.' (20) as variant normal
Switch board from normal to normal
shuffleOpenings = 0
<ICS: \015\012Game 1535: frentz does loadfen r1b1r1k1/pp3p2/2p2qn1/4p1p1/4PnPp/2PBNP2/PPQ2R1P/R3N2K b - - 0 1.\015\012\015\012<12> r-b-r-k- pp---p-- --p--qn- ----p-p- ----PnPp --PBNP-- PPQ--R-P R---N--K B -1 0 0 0 0 0 1535 MyrddinComp frentz -1 3 3 35 35 180 177 1 none (0:00) none 0\015\012aics%
ics input 0, castling = 7 0 4 7 0 4
Parsing board: r-b-r-k- pp---p-- --p--qn- ----p-p- ----PnPp --PBNP-- PPQ--R-P R---N--K B -1 0 0 0 0 0 1535 MyrddinComp frentz -1 3 3 35 35 180 177 1 none (0:00) none 0

>ICS: /moves 1535\015\012
recognized 'ICS unrated wild(20) match' (20) as variant normal
ParseBoard says variant = 'ICS unrated wild(20) match'
recognized as normal
Remembered ratings: W 2585, B 1765
load 8x8 board
13920 >first : variant normal
13920 >first : level 0 3 3
13920 >first : name frentz
13920 >first : rating 2585 1765
parseboard 1, castling = 45 45 7 45 45 6
accepted move none from ICS, parse it.
moveNum = 1
board = 0-8 x 8
Move parsed to 'none (0:00)'
nps: w=-1, b=-1
Display title 'MyrddinComp (35) vs. frentz (35) {3 3 normal}, gameInfo.variant = 1'
<ICS: \015\012MyrddinComp (2585) vs. frentz (1765) --- 2014.01.10 00:29:46 \015\012Unrated wild(20) match, initial time: 3 minutes, increment: 3 seconds\015\012\015\012<12> r-b-r-k- pp---p-- --p--qn- ----p-p- ----PnPp --PBNP-- PPQ--R-P R---N--K B -1 0 0 0 0 0 1535 MyrddinComp frentz -3 3 3 35 35 180 177 1 none (0:00) none 0\015\012\012Move MyrddinComp frentz \015\012---- ---------------- ----------------\015\012 {Game in progress} *\015\012aics%
ics input 1, castling = 45 45 7 45 45 6
recognized 'ICS Unrated wild(20) match' (20) as variant normal
Parsing board: r-b-r-k- pp---p-- --p--qn- ----p-p- ----PnPp --PBNP-- PPQ--R-P R---N--K B -1 0 0 0 0 0 1535 MyrddinComp frentz -3 3 3 35 35 180 177 1 none (0:00) none 0

load 8x8 board
Parsing game history: MyrddinComp frentz
---- ---------------- ----------------
{Game in progress} *
Feeding position and moves 1 through 1 to first chess program
14000 >first : variant normal
14000 >first : force
write FEN 50-move: 0 1 1
e1. p=-4
14000 >first : setboard r1b1r1k1/pp3p2/2p2qn1/4p1p1/4PnPp/2PBNP2/PPQ2R1P/R3N2K b - - 0 1
feedMoves
14000 >first : time 18000
14000 >first : otim 17700
14000 >first : playother
<ICS: \007\015\012<12> r-b-r-k- pp---p-- --p--qn- ----p-p- ----P-Pp --PnNP-- PPQ--R-P R---N--K W -1 0 0 0 0 0 1535 MyrddinComp frentz 1 3 3 32 35 180 173 2 N/f4-d3 (0:10) Nxd3 0\015\012aics%
ics input 1, castling = 45 45 7 45 45 6
Parsing board: r-b-r-k- pp---p-- --p--qn- ----p-p- ----P-Pp --PnNP-- PPQ--R-P R---N--K W -1 0 0 0 0 0 1535 MyrddinComp frentz 1 3 3 32 35 180 173 2 N/f4-d3 (0:10) Nxd3 0

load 8x8 board
parseboard 2, castling = 45 45 7 45 45 6
accepted move Nxd3 from ICS, parse it.
moveNum = 2
board = 0-8 x 8
Move parsed to 'Nxd3 (0:10)'
nps: w=-1, b=-1
Display title 'MyrddinComp (32) vs. frentz (35) {3 3 normal}, gameInfo.variant = 1'
silence
<ICS: aics%
ics input 2, castling = 45 45 7 45 45 6
>ICS: resign\015\012
<ICS: {Game 1535 (MyrddinComp vs. frentz) MyrddinComp resigns} 0-1\015\012Game was not rated. No rating adjustment.\015\012aics%
ics input 2, castling = 45 45 7 45 45 6
GameEnds(26, MyrddinComp resigns, 0)
write FEN 50-move: 0 2 1
e1. p=-4
e2. p=-2
33799 >first : result 0-1 {MyrddinComp resigns}
silence
33799 >first : quit
==========================

The only obvious (to my eyes) weird thing is the "accepted move none", although I have no idea what that means or if it really is weird or not. But you can see that later on the human played Nxd3, which Winboard recognized but did not send to Myrddin.

Any ideas? Now that it is working, would it help to coordinate a time in which you could try this on ICC or FICS? Whatever works for you. Many thanks in advance....

jm

[JVMerlino]

Pinging again on this. Is there any hope, H.G.?

Many thanks,
jm

[H.G.Muller]

There is always hope! But I did not have time to look at it yet, because there were some more general problems (engine-output sorting and sticky windows not working on Win8) that gave me a very hard time to fix. Those seem to be fixed now, however, so I will try to solve this one too in the fixed version I am going to release this weekend. The log you posted should be sufficient to find the problem.

[H.G.Muller]

14000 >first : time 18000
14000 >first : otim 17700
14000 >first : playother
<ICS: \007\015\012<12> r-b-r-k- pp---p-- --p--qn- ----p-p- ----P-Pp --PnNP-- PPQ--R-P R---N--K W -1 0 0 0 0 0 1535 MyrddinComp frentz 1 3 3 32 35 180 173 2 N/f4-d3 (0:10) Nxd3 0\015\012aics%
ics input 1, castling = 45 45 7 45 45 6
Parsing board: r-b-r-k- pp---p-- --p--qn- ----p-p- ----P-Pp --PnNP-- PPQ--R-P R---N--K W -1 0 0 0 0 0 1535 MyrddinComp frentz 1 3 3 32 35 180 173 2 N/f4-d3 (0:10) Nxd3 0

load 8x8 board
parseboard 2, castling = 45 45 7 45 45 6
accepted move Nxd3 from ICS, parse it.
moveNum = 2
board = 0-8 x 8
Move parsed to 'Nxd3 (0:10)'

Actually this is the point where things seem to go wrong. The engine is already set to play white by the 'playother', and is waiting for the black move. The WinBoard code from this point on says it is now going to send the move to the engine:

Code: Select all

  if (appData.debugMode) {
    fprintf(debugFP, "Move parsed to '%s'\n", parseList[moveNum - 1]);
    setbuf(debugFP, NULL);
  }

#if ZIPPY
   /* Send move to chess program (BEFORE animating it). */
   if (appData.zippyPlay && !newGame && newMove &&
      (!appData.getMoveList || backwardMostMove == 0) && first.initDone) {

       if ((gameMode == IcsPlayingWhite && WhiteOnMove(moveNum)) ||
      (gameMode == IcsPlayingBlack && !WhiteOnMove(moveNum))) {
      if (moveList[moveNum - 1][0] == NULLCHAR) {
        snprintf(str, MSG_SIZ, _("Couldn't parse move \"%s\" from ICS"),
             move_str);
          DisplayError(str, 0);
      } else {
          if (first.sendTime) {
         SendTimeRemaining(&first, gameMode == IcsPlayingWhite);
          }
          bookHit = SendMoveToBookUser(moveNum - 1, &first, FALSE); // [HGM] book
          if (firstMove && !bookHit) {
         firstMove = FALSE;
         if (first.useColors) {
           SendToProgram(gameMode == IcsPlayingWhite ?
               "white\ngo\n" :
               "black\ngo\n", &first);
         } else {
           SendToProgram("go\n", &first);
         }
         first.maybeThinking = TRUE;
          }
      }
       } else if (gameMode == IcsObserving || gameMode == IcsExamining) {
         if (moveList[moveNum - 1][0] == NULLCHAR) {
      snprintf(str, MSG_SIZ, _("Couldn't parse move \"%s\" from ICS"), move_str);
      DisplayError(str, 0);
         } else {
      if(gameInfo.variant == currentlyInitializedVariant) // [HGM] refrain sending moves engine can't understand!
      SendMoveToProgram(moveNum - 1, &first);
         }
       }
   }
#endif


The problem seems to be in the if-clause that controls whether the move will truly be sent. I guess in this case it is the !newGame that actually breaks it, because newGame should be set to TRUE here: upstream code should have detected both the game number and game mode changed by the reception of the board with the move. (newGameMode should be IcsPlayingWhite here.)

Code: Select all

    if (gamenum != ics_gamenum || newGameMode != gameMode ||
   relation == RELATION_ISOLATED_BOARD) {

   /* Forget the old game and get the history (if any) of the new one */
   if (gameMode != BeginningOfGame) {
     Reset(TRUE, TRUE);
   }
   newGame = TRUE;
   if (appData.autoRaiseBoard) BoardToTop();
   prevMove = -3;
   if (gamenum == -1) {
       newGameMode = IcsIdle;
   } else if ((moveNum > 0 || newGameMode == IcsObserving) && newGameMode != IcsIdle &&
         appData.getMoveList && !reqFlag) {
       /* Need to get game history */
       ics_getting_history = H_REQUESTED;
       snprintf(str, MSG_SIZ, "%smoves %d\n", ics_prefix, gamenum);
       SendToICS(str);
   }


The problem is that I am not sure why this condition !newGame is there. Probably there are other situations where the first board in a game should be ignored , because it will be overruled by a later board. (Actually I might have added it there myself, to solve the previous problem with loadable games, that it should not set the engine playing before the user has uploaded a board for the start position. I would have to check that.)

We are breaking new ground here, as never before it was possible that an engine would have to be sent a black move as the first move of a game... It could also be that the 'backwardMostMove == 0' is the deal breaker here. In WinBoard black moves must have odd move number (the side-to-move is recognized by that), so games where black starts there is no move 0. Perhaps it should be replaced by 'backwardMostMove <= 1'

[JVMerlino]

This is starting to get scary....

jm

[H.G.Muller]

Indeed, the ICS code in WinBoard is very scary. You see the strangest things, and you never know what problem they were supposed to solve, and what would go wrong once you alter them. I really try to stay away from it as much as possible.

It would probably be a good idea if I made a version that would print (to the debiug file) all the variables involved in the decision whether to send the move to the engine just before the #ifdef ZIPPY block, so that you could run the same test again, and we could exactly figure out why it decides to not send the move.

The more I think about it, the more I think it must be backwardMostMove that is the problem, however. In a black-moves-first game backwardMostMove will definitely always be 1. Not sure if there are still other variables that could suppress the move, though. But you might already be able to test that in the current version by switching 'Get Move List' off (in the ICS Options dialog), and then try the same thing. Because now the condition says (!appData.getMoveList || backwardMostMove == 0). So when appData.getMoveList gets set to zero, a wrong backwardMostMove can no longer be a show stopper. And if it was the only show stopper, that means things should already work.

In that case we could relax the condition on backwardMostMove, so that it would also work with 'Get Move List' on. But in that mode there might be problems later, because I think that each time WinBoard receives a board when backwardMostMove > 0, it concludes that you must have entered a game that was already in progress, and it starts to request a move list from the ICS to fill in the gap. So I must find the code that does that, and somehow communicate to it that for this particular game it is normal that it starts at move 1.

[JVMerlino]

As soon as I can organize a test with Alex (the guy on ICC who is interested in this feature) I'll give it a try with the move list disabled.

[JVMerlino]

Turning off the "Get Move List" option worked! We were able to play games starting from loaded FENs with both White and Black to move.

You're a genius! Thanks, H.G.!!

jm

[H.G.Muller]

Well, there are disadvantages too, I guess. E.g. if you resumed an adjourned game the engine would not be made aware of the previous move history, and could thus fall in a repetition trap.

Fetching a move list when backwardMostMove is not zero is sort of an XBoard reflex, however (when the Get Move List option is enabled.) So I guess to make it also work with the option on this must be suppressed when the game really started with a black move. At least I know now what is needed.