That is not addressing the problem we are talking about here, which is how to follow the rules of chess and make them work in a GUI. To date, only the ICC gui handles draw offers in a way that is consistent with FIDE, because they directly addressed the timing issue I mentioned, while no GUI I have run under understands the idea of a move and a repetition claim being tied together. If you send the claim first, they complain that it is invalid. If you send the move first, the GUI can't wait around to see if you are going to send a draw claim next because that introduces artificial lag and screws up the time-keeping...
We have discussed now already two work-arounds for this: the draw offer before the move, and giving the move in the comment field. In fact there even is a third: the GUI can judge the validity of a claim both in the position before and after the last move of the opponent, if the the side making the claim is on move, and accept the claim if it would be valid in either of these positions.
And I explained why that won't work in the general case where a _program_ is allowed to claim an actual result. You can't claim a draw before you repeat the position for the third time. The GUI has no business holding up the game for what has to be an indeterminate amount of time waiting to see if the engine is also going to send a move after the draw offer. And, in fact, the idea is broken. Does that mean while it is my move, I can't simply offer my opponent a draw and see how he response, as the rules of chess specify?
The _right_ way to do this would be the following:
1. A specific string to claim a draw by repetition or by 50-move rule, where the claim is valid _right now_ without my having to make a move. In real chess, I can claim a forced draw before or after making my move.
2. A specific string to claim a draw by repetition or by 50 move rule, where the claim is valid _after_ I make a move, and the move has to be sent with the claim (but not as a comment, since it is a real move and needs to be entered in the PGN correctly).
3. A mechanism to offer draws to my opponent, and accept draw offers from my opponent without having to make a move.
4. A mechanism to offer my opponent a draw, but includes a move. It is now his turn to move, his clock is running, he has a draw offer that is valid until he accepts or makes a move of his own.
5. programs must _not_ be able to tell the GUI the game outcome. Or, at the very least, they can only claim they lost. They can not claim draws or wins. Causes too many problems for non-debugged programs.
When winboard/xboard can do all of that correctly, it will be worth something. As it is, I rely on ICC which does know how to handle draw offers/claims, and which _never_ lets an opponent tell it how the game ended...
What it "should do" vs what it "actually does" might well be two different things,
This will not be two different things, as I personally will see to that.
but the result string from the engine to the GUI will certainly terminate the game. Right, wrong or indifferent.
A result string has to terminate the game, as engines are in general not prepared to play on after sending one. But you can be sure that many existing and future GUIs will end the game
right, i.e. forfeit it for the engine sending an improper result string. Such as a rep-draw claim before the move realizing it.
This makes no sense to me. Why allow an engine to send a result string if the GUI might or might not use it? In real chess I can't just say "I win" and the game ends. That is not something either player should be able to do. If the GUI handles the clocks, the players should not have to call "flag" either, as there is a timing hole there. The one that should call the flag is the one watching the flag. Since the program might not know that the flag dropped when the opponent took .6 seconds too long, but then the clock increment took it back to positive, the program is unsuited to handling this. Makes no sense for the GUI to tell the program "his clock went below 0.0" either... Because who would not claim the win, making the tit-for-tat messages redundant...
Does that mean programs can't claim a win draw or loss themselves?
They can claim it, but if the claim has no basis, it will be treated as a 'resign', and the game will be forfeited.
Any chance this can follow the _real_ rules of chess and not use some ad-hoc policy? If I claim a draw in a tournament, I don't lose if the draw is not upheld. I am forced to play on, sometimes with a time penalty, sometimes not. But I certainly do not lose.
and what is "winboard_f"???
The latest version of WinBoard, of course.
