hgm wrote:bob wrote:
OK, in that same tone, "HELLO..." Who gives a damn about some non-standard version of winboard that drastically changes the way things work from the 100 previous releases?
Organizers of engine-engine tournaments, and (rating) testers give a damn. It is at their request that I am building these features in WinBoard. They want a GUI that takes a firm stance against faulty engines, rather than one that lets such engines call the shots (as WinBoard 4.2.7 and earlier does).
You yourself just stated that WinBoard was unacceptable to you, and you had to write your own software for engine-engine tplay. So it must be easy to see even for you how likely it is that this new WinBoard will become the new 'industry standard' in most tournaments that are now played under WinBoard.
My posting was just a friendly warning. Give as many damns as you like. But if you want to be stubborn, be prepared to see Crafty forfeit games, loose a few Elo points and drop a few places on the rating lists.
Won't happen unless you adopt something contrary to FIDE rules. Then I won't care because I am not going to support crappy standards (such as UCI) that differ from the rules I have to use in real tournaments... Current crafty handles draw offers, accepting draws, draw claims, perfectly. I don't see that changing
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.
that's how ICC does it and it works perfectly...
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?
Oh man... Why don't you for once
READ what others write, in stead of immediately starting fumigating against your own silly misconceptions?
NONE of the three methods did involve waiting of the GUI for what the engine might send. I am sorry if you don't like the tone, but it seems the only way to get through to your imaginary world, and pull you back to reality...
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...
Well, WinBoard protocol does support ALL that correctly, so why are you arguing against my implementation of stricter enforcement of the protocol? Do you just want to be difficult?
Back to reality. Winboard does _NOT_ support that correctly. An engine can claim any result it wants. If you will simply re-read what I wrote above, you won't be off into never-never land. The "result" is not used by winboard when playing on ICC. But in match mode, it is, and it is a bad idea.
1. This string is the RESULT command: "1/2-1/2 { 3-fold repetition }" (or whatever the reason: 50-move rule, stalemate).
What part of "that is bad" don't you understand? If you send the 1/2-1/2 string today, the game ends. Even if you are losing
2. This string is "offer draw". Such an offer can be refused if there is no legal draw condition, but it is never penalized to make it.
Eh? I can offer a draw any time I choose, so long as my clock is running when I make the offer (see FIDE rules of chess for clarification). Such an offer can _never_ be refused, unless it comes _after_ I make a move, because when I make a move, that implicitly stops my clock and starts my opponent's clock.
Better solution would be a "hit the clock" command so that I can send anything I want, a move, a draw offer/claim, etc, and my "move" is not completed (by the FIDE rules of chess) until I press the clock button.
3. Again, "offer draw" does this, in absence of a legal draw condition. If the GUI cannot grant the draw, because there is no legal basis to claim one, it sends "draw" to the opponent to inform it of the offer.
There is a significant difference between "offering a draw" and "claiming a draw". I see no sense in overloading the "offer draw" to behave as above.
4. Same as 3. The engine can send "offer draw" at any time, before its move or after its move. It is a separate command.
It should not be able to send anything while the opponent is on move. We have already had interesting problems with this. I make a move, then while it is not my move I flood my opponent with draw offers to slow him down. In human games, it is against the rules to offer a draw while he is on move.
5. Exactly. This is why WinBoard_F makes them forfeit the game when the claim a draw through the WinBoard RESULT command in a position that is not a legal draw. Remember that WinBoard protocol defines the RESULT command as what the engine sends when it is not possible or prepared under any circumstances to continue with the game. So when an engine sends it, the GUI has no option but to terminate the game; refusing the RESULT command and waiting for the engine to reconsider its decision, will just hang the game and the tournament.
So what exactly is your problem????
I want to see it done correctly, according to the rules of chess. I want two options. I want to be able to offer a draw, only when it is my move, otherwise the offer is simply ignored; I want to be able to claim a draw, only when it is my move, and the claim is accepted or rejected, but without causing me to lose the game. That is the way FIDE works. If a program can't handle a rejected draw claim, then let it lose on time since it is not playing legal chess.
I prefer one of the following, syntactically:
offer draw Re1+
{I am offering a draw, because I think the position is either eventually drawn or it is dead even at the moment. I am also playing the move Re1 whether he accepts the offer or not.}
Re1+ draw
{I am playing the move Re1+ and I claim it is a draw (it is up to the GUI to figure out if it is a 50 move draw, or a repetition, or insufficient material, or a double-flag, or whatever. Again I have to be prepared to play on if the GUI disagrees for whatever reason}
Re1+ draw stop clock or
draw Re1+ stop clock
{I give my move, a draw claim, and tell the GUI my move is complete by giving the stop clock. The GUI doesn't inform my opponent of the move until I "stop the clock" as in FIDE human games.}
To offer a draw, this would become:
re1+ offer draw stop clock
We also need the special case:
draw stop clock
as it is possible that the position before I even move is a repetition or 50-move rule draw and I don't have to make a move to make the claim (again by the FIDE rules).
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...
Should I read this as an admission that it starts to dawn on you why WinBoard_F is superior to the WinBoard you prefer, which does allow the engines to claim any result at any time?
ONLY if your fix is better than what we have. So far it does not seem to be so since it is violating FIDE rules in the way it behaves. For example, in FIDE rules, claiming a draw does not cause me to lose if the arbiter disallows the claim (perhaps I have an incomplete score sheet, or I incorrectly ignored enpassant on the first repetition or whatever... I just have to keep playing.
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.
Unfortunately Chess engines are not reasonably entities, that you can argue with. They are stupid state machines, and when the get into the state "game finished", no amount of input given to them is going to convince them that this game is not finished. WinBoard protocol does not specify any mechanism to tell an engine to restart a game after a RESULT command has been received; it defines it as the ultimate refusal to play on. If a Human would refuse to play on in the case you describe above, wouldn't you think that the _real_ rules of Chess would in the end declare the game forfeited? Seems to me you have no case...
Apples and oranges. I have already said that the "result" operation should not be allowed. Claiming a draw is a different matter. Crafty will play on after a 3-fold repetition if you want, as it depends on the GUI to enforce the draw, but doesn't quit...
"Of Course"??? I've worked with Tim Mann for many years adding features to the winboard/xboard protocol. "winboard_f" certainly doesn't conjure up ideas of "the latest winboard version" to me. Does this carry to xboard as well???
Well, WinBoard is open source, and Tim Mann currently doesn't seem to be a very active developer. If you only look at Tim Mann, you will be likely to find yourself in the stone age soon.
That means that making the claim before the move will result in a forfeit under any conditions, even when you specify a move in the COMMENT. Due to a protocol violation, rather than a FIDE rules violation.
Again, that is wrong. If this doesn't follow the FIDE rules of chess, nobody is going to use/accept it. I can _always_ claim a draw without making a move. If you make a move, hit your clock, and I notice that both sides have made at least 50 or more moves without a capture or pawn push, I can claim a draw "right now" without having to make a move or anything. Ditto for repetitions. If the position before my move has occurred twice previously with me on move, I can claim a draw without having to make any move at all, and it ends the game once verified.
We were talking here about the case where no draw condition exists before the move. So the examples you give here are irrelevant. Draw claims in these situations are accepted by WinBoard_F without any problems. The whole issue is what the GUI should do if an engine unconditionally refuses to play on (by sending the 1/2-1/2 command) in a position 3 moves after a capture, that has never been on the board before, and isn't a stalemate. If you would deem such a claim to "follow FIDE rules", I think it is you who are wrong!
Thinking doesn't make it so, however. If an engine refuses to play on, let it lose on time, as it would in a FIDE event. Only step in what you are saying that I would advocate is to ELIMINATE the 1/2-1/2, 1-0 and 0-1 strings from the engine to the GUI. If the engine sends 'em, ignore 'em. By the rules of chess, one player can not end the game on his own. I can't end a game on a 50-move claim without someone agreeing. So we do it like that in the engines, or we lose games until we do...
I'm not going to beware, I am not going to use it if it doesn't actually match the official FIDE rules. And assuming the "feature" command doesn't get broken, I would probably modify Crafty to refuse to play if the GUI behaves as you are describing, since it is broken.
Well, as I am an engine programmer next to being a GUI programmer, I always enjoy seeing competitors drop in rating...
Nice attitude. You won't see Crafty drop in rating. You just won't see it running under your GUI, unless you do it reasonably. If you think you can dictate a new and flawed standard, go for it. I won't follow, and I'll bet many others won't either. Do it right and most will be happy to have an improved protocol. But bury your head in the sand, and do it "your way or no way" and it ain't going to happen.
