Baffled by Xboard

[ambrooks1]

I have a chess engine nicknamed "javalin." It runs with the Xboard interface
on Mac ( could probably be ported to windows with a little tweaking.)

When javalin is white, there is no problem playing any other engine. Also,
human-white versus javalin-black runs with no problem.

The problem is - if javalin is, for example, set as both white and black ( fcp, scp)
the following situation occurs, which has me baffled:

START fcp
...
StartChildProcess (dir=".") java -Xms512m -Xmx1024m -jar javalin.jar
681 >first : xboard
protover 2
shuffleOpenings = 0
1268 <first : Finished
1280 <first : Welcome to Javalin Chess Engine 1.1
1280 <first : feature sigterm=0
1280 >first : accepted sigterm
1280 <first : feature sigint=0
1280 >first : accepted sigint
...
1283 >first : level 40 5 0
1283 >first : post
1283 >first : hard
2962 >first : force
StartChildProcess (dir=".") java -Xms512m -Xmx1024m -jar javalin.jar
2963 >second: xboard
protover 2
...

3539 >first : go
...
3614 <first : move e2e4 fcp MAKES THE FIRST MOVE

3624 >second: e2e4 xboard TRANSMITS move to scp
3624 >second: go
3933 <second: move g8f6 scp REPLIES ( WITH ALEKHINES' DEFENSE )

3933 >first : g8f6 xboard TRANSMITS move to fcp
4045 <second: move e4e5 scp allegedly "makes a move (?) " which in reality will be the next move played by fcp

Ignoring move out of turn by second, gameMode 5, forwardMost 2 xboard CALLS FOUL!!!

4046 >second: e4e5
4132 <second: Illegal move e4e5
GameEnds(25, False illegal-move claim, 4)
GE(25, False illegal-move claim, 4) bare king k=16 color=0
4132 >first : result 1-0 {False illegal-move claim}
4132 >second: result 1-0 {False illegal-move claim}

This debug log is incomprehensible to me, unfortunately.

The actual moves played on the board were :

1. e2e4 g8f6
2. e45e5 ... TERMINATION

Any clues, suggestions are appreciated.

[H.G.Muller]

It seems that XBoard sends a 'go' command after the move to scp when the program was already playing back. So it responds to the move spontaneously, then receives 'go', and interprets that (as the protocol prescribes) as that it now have to start playing for the other side. Hence the second move. Apparently XBoard assumes the program was in force mode here.

I remember that I once fixed a bug that could cause this in the GUI-book code. When the engine would get out of book XBoard assumed it was in force mode, but this was not true if no book moves were played at all.

What version of XBoard exactly are you running here?

[ambrooks1]

Thanks HGM - I am running Xboard 4.6.2.

[ambrooks1]

Anyhow I solved all the problems by just putting in some bulletproofing code.

I just focused on making sure that the internal state of the engine was always consistent, regardless of the
order of the "go" or the actual move commands received from Xboard.

At the start the sideToMove and computerSide are in a NONE state, and I now have a myTurn variable :

else if( input.equals("go") )
{
if (sideToMove==NONE) {
sideToMove=GameState.WHITE;
}
forceMode=false;
computerSide=sideToMove;
myTurn=true;
findAndApplyMove();

}
...

else < if the input represents a move >
if (sideToMove==NONE) {
//we have received a move for the first time, so the computer must be playing black
sideToMove=GameState.BLACK;
computerSide=GameState.BLACK;
}
applyMove(input);
if (sideToMove == computerSide) myTurn=true;
// do the normal search
if (myTurn) findAndApplyMove();
}

[H.G.Muller]

Well, if XBoard is really at fault here by sending a spurious 'go', I don't think you can fix it in the engine without breaking its operation on GUIs that work correctly. The command sequence with the extra 'go' is a valid sequences of XBoard commands, and if you decide to do something else that what the protocol specifies, it means the engine would malfunction when the user really instructs it to do this. (E.g. when the user starts doing a move, waits for the engine to respond with black, and then clicks 'Machine White' to let it continue with white.)

Better try using XBoard 4.7.2 first.

[ambrooks1]

Hi HG,

I wouldn't presume to have any more than the minimum understanding of Xboard
in order to make my engine behave sensibly for the average user playing a
typical chess game.

But if there were an "Chess Protocols for Dummies" book - I would happily
check it out of the library. (:-)