Possible protocol issue

[jdart]

My engine tries to keep track of which side it is playing (White or Black). But I have disabled the color commands (colors=0).

Now there is an ambiguity. There was a recent server game where the opponent disconnected then resumed. When it resumed, xboard (4.7.3) sends "new" and "name", goes into force mode, then sends the moves. But the opponent lost on time before it could play another move, so the next command was "result 1-0 {<opponent> forfeits on time}". Now, who lost the game? "name" doesn't tell you who is playing White, and the move list just ends w/o indicating who had the next move. I guess if you get "result" before "go" you can assume the other side lost, but that is pretty kludgy. Or you can parse the ICC comment for the opponent name, but different servers may send different comments.

--Jon

[H.G.Muller]

I am not sure I get it. 1-0 is an absolute result, so you know white won. The player names are also given by the ICS, and parsed by WinBoard, so they will end up as player tags in the PGN. So it is known who has won.

Is the problem that the engine does not know it, and wants to know it for the purpose of learning? There is a general problem w.r.t. learning, of which this seems just a special case: the engine might not have played the entire game. Half-way the game you could have switched sides. Then who has black at the time black is checkmated doesn't really mean much; the engine could be checkmated with black, but have played white most of the game, and was really set to play black only when the mate was already in view.

When you resume an adjourned game, there is no guarantee that the color you are playing now in that game were also handled by you before it was adjourned. To the engine it looks more like a book win.

[jdart]

This is a possible issue for learning but the reason I noticed it was the PGN game log maintained by the engine had the wrong colors for the game (White and Black were reversed). When the game resumes and terminates in this way, the engine knows its opponent's name and the result, but not who played which color. It is a corner case, though: I assume if the engine does get a "go" command then the side to move at that point is the engine's side. It is only in this corner case that there was no "go" before game end.

--Jon

[H.G.Muller]

Ah, OK. I see now. The 'name' command gives you the opponent, but doesn't tell you which color it played.

The white/black commands would be of no help here; they are mainly intended to tell the engine which color has the move after an old-style 'edit' command to set up a position.

But can't you assume that the side that lost on time must have been the side to move? You cannot lose on time when you don't have the move, as your clock is not running. When WinBoard receives the start message and current board from the ICS, I think it would immediately send 'go' when it is the engine's turn. (Fetching the move list of the game is optional.) That it did not sent 'go', but started processing subsequent messages from the ICS, allowing it to see the time loss, can only mean that it must have been your opponent's turn, right? And thus that he must have been the one losing on time.

[jdart]

I suppose that is true and that is a possible fix. I don't know if a draw result could be sent w/o go first?

--Jon

[H.G.Muller]

I think that you should always get 'go' when you receive the first board of a game where you are on move, although I am not completely sure. If WinBoard would delay involving the engine until after it has retreived the move list, a draw claim could come between receiving the board and receiving the move list. I don't think ICS limit draw claiming to your own turn.

But I think the real source of these troubles is that you want the engine to do something that it should not be doing. It is not the engine's task to save PGN. That is the GUI's task. The protocol also doesn't inform the engine of other PGN tags, like event name. The whole GUI-engine system is designed on the assumption that the engine is there to think up moves, and communicates only with the GUI. And that the GUI is responsible for any contact with the outside world.