Engine authors, beware of false-draw-claim forfeits!

[bob]

As I requested? I +never+ requested the "result" stuff.

The RESULT command is a request to the GUI to terminate the game.

I did request the ability to offer and accept draws, which was not originally in the protocol. All of my changes were solely for play on ICC, where the server handles draw claims and ends the game itself. you can send xboard whatever you want when playing on ICC and result stuff gets ignored, as it should be.

This seems just babble to me. Draw offers can never be refused? Not even if I make one while I am losing? No wonder you prefer the old WinBoard... Get real!

Thick-headed beyond belief. Explain to me exactly when you can arbitrarily take a draw offer from my program and refuse it? It +must+ be relayed to the other engine.

Yes, and the engine then refuses them, of course, if you are in a lost position. Are you just pretending to be stupid? Draw offers/requests/accepts are passed on untill they reach an entity empowered to grant or refuse them.

No matter what the circumstances. So long as it is made while my clock is running. You just want to argue for the sake of arguing, even if you have to make up what you thought I said so that there is something to argue about. Engines handle draw offers, not the GUI which solely relays them without regard to the current board position. I can offer a draw one move before I mate my opponent if I want... Or even after his flag falls should I choose to ignore the flag... Do you play real chess at all, or just live in a basement surrounded by computers playing each other???

All irrelevant babble. As I never said the GUI would not pass on a genuine draw offer. WB protocol overloads the "offer draw" command, remember? It can also mean "accept draw". And when it does, the GUI knows (from the fact there is already a draw offer pending from the other side), and grants the draw _without_ passing it to the second engine. And similarly, when it means "claim draw", and the GUI recognizes a draw condition (3-fold rep, 50-move), there is no need to pass it on to the oponent, as he has no say in the matter, and the GUI can call the draw. As it knows that "offer draw" in this case means a claim, as it makes no sense to offer a draw when you have the right to claim one.

It is all so simple...

yes it is. So why all the discussion? If a program claims a draw, and the game is not drawn, it continues. the idea of calling an invalid draw claim equivalent to a loss is the entire point of this discussion. Has been from the get-go. And to do so is wrong, whether it be via the broken result mechanism, or anything else. A user must be allowed to claim a draw that is incorrect, without penalty...
The rules of chess say so.

[GothicChessInventor]

It seems that several strong engines do violate FIDE rules and WinBoard protocol by claiming repetition or 50-move draws without announcing or the move they think to salvage this draw with.

Hello H.G.,

I am in the process of converting Gothic Vortex to run under Winboard-F, as you know. One of the things I am doing is requiring Vortex to run with (at least) the 4-piece tablebases, and its Opening Book, in order to "accept" a Windboard_F challenge.

Having said that, is there any way Vortex can claim a draw that it "knows" is in its tablebases as a draw? For example, I have seen a game where Vortex swapped all the way down to a Chancellor and Pawn vs. Chancellor endgame that was a draw. It had just the Chancellor as Black, but was very short on time. The game was a certain draw in its 5-piece tablebases. It was a sudden death 5/0 game and it could draw by moving instantly, of course. But the other program kept playing on, and it only needed to be a few seconds ahead to expire the Vortex clock.

Is there a way to deal with this kind of draw?

Thanks!

[hgm]

Is there a way to deal with this kind of draw?

Dealing with it in any way other than the 50-move rule would be a violation of FIDE rules. In a sudden-death game you have to reserve enough time to last the 50 moves, or the opponent can indeed "drive you through the flag". If he has Pawns, you are even in more dire straits, as he can drag out the 50 moves by judiciously timed Pawn moves. So you better never incur a serious time lagg. But that is what sudden-death games are all about.

I don't think the rules for Gothic Chess are any different in this respect. If you don't want games to be dominated by time concerns, do not play sudden-death time controls. By giving a time increment of 1 second per move, you already pre-empt this behavior. So this is what most tournaments do.

Some testers adjudicate games based on tablebases as soon as it gets to the 5-men stage. I would love to have that option in the GUI. But I have no experience in table-base probing whatsoever, (none of my engines use, or plan to use probing of pre-computed end-game tables) so I am not the right person to implement this. Besides, I understand that the license on Nalimov tablebases is incompatible with the GPL, under which WinBoard falls. So it would not be legal to use Nalimov probing code in WinBoard.

[hgm]

There are big differences. You said "a draw can be refused by the GUI."

Oh yeah? So now you stoop down to lying, in order to hide the fact that you habitually don't read what others post, or at least are not able to understand what they wite? Where did I write that? If you would have taken the trouble to read back even now, you would have seen that I wrote nothing of the sort, and only said that a draw can be refused by the opponent. But NOT if there is insufficient mating material on the board, more than 50 reversible moves have past, or the current position has occurred already twice before. And if the opponent cannot refuse the draw, it becomes kind of pointless for the GUI to consult the opponent if he would want to refuse it. Hence WinBoard_F grants the draw automatically in such a case.

That would necessarily cover my claiming that a position is drawn for repetitions, 50-moves, insufficient material, stalemate, etc, as well as my simply offering my opponent a draw regardless of the state of the chess board and game clocks.

The GUI/arbiter could certainly refuse a draw claim that is invalid, but then you have an ambiguity as to how a draw is offered vs how a draw is claimed. The two cases are different, and in the former, the GUI/arbiter has absolutely no say-so, while in the latter, the GUI/arbiter should be the only one that can declare the game over.

A difference that makes no difference is no difference! Give me one example where this alleged ambiguity would lead to a wrong action. (i.e. where it would be an error when the GUI receives the "offer draw" string in a legal-draw position to have it grant the draw without consulting the opponent, or where it would be an error to only relay it to the opponent through a "draw" command when there is no legal draw position.) You are just talking nonsense!

That is all I have said from the beginning. You, on the other hand, want to make a draw claim result in a loss if the claim is ruled invalid. I simply want to be able to claim a draw, and if I am wrong (crafty never is, but after a programming change I could certainly break something as I have done so in the past) then I want the draw claim to be ignored and the game to continue, just as it does under FIDE rules when a draw claim is denied by the arbiter.

The command that behaves that way is "offer draw". As you very well know, every RESULT command in every WinBoard version immediately terminates the game, so there never has been, and never will be a possibility to continue the game after a RESULT command. And there are too many engines that rely on that to change it, just because you don't like the wording of it or the prvided alternative. You are just stubbornly refusing to use the correct command.

We are discussing the case where the program can improperly end a game by claiming a draw that current xboards do not verify, and we are going from fixing that flaw to letting the GUI incorrectly end a game when it should not. The right way is to do it as the FIDE rules say. If someone loses on time, so be it. but don't tell me I lose if I claim the game is drawn, and your arbiter disagrees, because for me at least, my program can continue playing beyond 50 moves or 3-fold repetitions if desired, with no harmful effects or program crashes...

Programs will always forfeit one way or the other if they stubbornly refuse to use the protocol as it is defined. This is unavoidable, no matter how much against the FIDE rules (which do not define the protocol) that forfeit might be. If you run an UCI engine under WinBoard, it will _always_ forfeit on time. If you have an engine that does not print 'move ' but 'coup ' in fromt of the moves it makes, it will _always_ forfeit the game. Despite the fact that the FIDE rules don't specify at all that you have to yell 'move' to your opponent before making a move.

So it is totally obvious that FIDE rules are not the only rules an engine has to follow to be able to play under a given GUI. It has to handle the protocol correctly as well. That a stupid or malicious programmer can misuse the protocol in such a way that he forfeits in situations where a Human arbiter with a FIDE rule book would not have had it forfeit, is thus no evidence whatsoever for the protocol being flawed.

So again, the "claim" and "the offer" are two completely different things. The claim has to be verified by the GUI or the game continues, while the GUI has to stay out of the way of an offer/accept as it has no business doing anything other than relaying those two events back and forth between the two programs.

Repeating it forever doesn't make it so. Give the example where overloading the "offer draw" command would produce an error.

Now that isn't so hard to understand, is it.

Not hard to understand that it is not true, indeed. Give the example, or admit that you can't, and drop it!

That is all I have said _from the beginning_... Nothing more, nothing less. Hyperbole notwithstanding...

I have pointed out technical issues that have to be resolved in the synchronization of making a move and offering / claiming a draw, as well as the special case of claiming a draw without making a move. If you require move and then draw claim, there is a hole because you absolutely must send the move to the other engine as soon as the GUI gets it, otherwise you distort the timing in very fast games. It would be possible for me to send the move, you relay it, you then get a reply from the opponent and relay it to me, before you get the draw claim from me that went with my previous move.

Yes, this is the way WinBoard_F handles it, the third way I mentioned above:

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.

This is a must in any solution for claim verification, as it is the only way to solve the false-claim problem without causing incompatibility with the way most engines handle after-the-move draw conditions, namely by sending the claim after their move, in a non-atomic fashion, relying on the fact that old WinBoard versions accept the it no matter what. Even if sync problems did allow the opponent to sneak in a reply before the claim got through to WinBoard.

That has to be handled, and can be, but it is non-trivial. I don't care about the illegal move problem myself, I'll leave Uri to worry about that. I am only interested in drawing issues and there are several. Each has to be handled correctly to be useful...

[hgm]

OK. You don't understand it. You don't want to understand it. So there is little left to discuss. My interpretation of how the current winboard works is 100% correct. I have used it for 15 years now. And I understand _exactly_ what it does, and where the problems are.

Apparently not. Or you would know that a RESULT command would _always_ end the game instantly, when not in ICS mode. And thus, when you don't want your engine having to behave differently in two-machines mode as in ICS mode, you cannot sent RESULT strings in ICS mode either.

WB protocol is what it is, and it is not in my power to change it. Unlike Human OTB Chess, there is a great need in computer Chess for an engine->GUI command that unconditionally ends the game, by telling the GUI that no more moves have to be expected from the engine no matter what. Lack of such a command would result in huge wastes of CPU time in many situations, by having to wait out the game for a flag to drop.

Like it or not, original WinBoard has only one command to unconditionally terminate a game, namely the RESULT command. Most engines rely on the command having this effect, so it would be extremely detrimental to suddenly redefine this command to mean something else. If you have a sick desire to waste computer time and needlessly drive up CO2 emissions, just because you have enough of it to burn, doesn't mean that I am going to harm others this way. So the RESULT command will have to terminate the game unconditionally in future versions of WinBoard as well, as it always has. No matter how much we would like there to be a separate "stop game", "abandon" or "leave" command decoupling this effect from the actual result specification. Existing engines do not use these command, and we cannot 'fix' problems by breaking a hundred times as many things that are working properly right now.

So the only solution is to use another command than RESULT for cases were the engine might want to play on. This could be an entirely new command, but using "offer draw" in the situation where this new command would be used does not result in any different behavior, so it might as well be used. Note that there are _many_ undocumented commands that are understood by WinBoard for accomodating older engines, from before the time the protocol definition was published, and that many sentences containing the word 'draw', recognized by that fact alone, will be considered as an equivalent to the RESULT message in existing WinBoard. So things like "claim draw" would certainly cause improper operation of any engine using it, when it runs under such an old WinBoard. There would be no backward compatibility. The only way to guarantee this backward compatibility is to use a command that old WinBoard versions already know, and is harmless in that context. This is why overloading"offer draw" is such a perfect solution.

Implement what you want, and then when the problems I have explained pop up, maybe _THEN_ you will "get it" the hard way...

I will certainly do that (I never planned otherwise ), as following your advice would lead to a crap product that no one would want anyway...

I suppose all of that rambling is supposed to make some sort of sense? Again, two cases. Draw claim. Draw offer/draw offer accept. Two different animals. The former requires verification. The latter does not. I don't exactly like the "offer draw" to accept a draw, but it has worked perfectly for years and is OK. With ICC that is also all that is needed to claim a draw. ICC's interpretation is as follows: If a player offers a draw, and the game is drawn by rule (50 move, 3-fold repetition, etc) then the draw is enforced instantly. Otherwise the draw offer is relayed to the opponent. If he accepts, or if he offers a draw in response, the game ends immediately.

Well, this is exactly what I descibed, and how WinBoard 4.3.13 works. So why are you going off like a loose cannon?

The "GUI" does it correctly. Programs can't end the game themselves (unless they outright resign or else get mated or mate the opponent, but they can handle draws just as FIDE intended. And if a player claims a draw and nothing happens, the game continues. Again just as FIDE rules say. Surely if ICC can do it, you can do it too? And make it work reasonably without artificially changing game results?

As I told from the very beginning, it already works exactly that way in WinBoard_F. You have to offer the draw, not use the RESULT message (which unconditionally ends the game, with the GUI forced to decide on a result), just as you describe above in the interaction with ICS.

And not everyone is an idiot that is making up rules as they go along and forcing everyone to abide by them.

Indeed. Only GUI programmers have that privilege.

A mistaken draw claim should not end the game.

But a protocol violation will. Claims not made by the proper protocol command can and will not be an exception to this universal truth.

if it does, I won't be using it even though my program is never guilty of doing this. But I don't want wins in positions where there is still play left. It really is as simple as following the rules of chess, rather than the whims of testers that are really doing nothing to help the engines out anyway...

Well, seems you are not using current WinBoard either, so who cares? Why would anyone care what you use or don't? What you use is not a factor in this at all. What matters is how others will use Crafty, and how they will appreciate its behavior.

It is all so simple...

yes it is. So why all the discussion? If a program claims a draw, and the game is not drawn, it continues. the idea of calling an invalid draw claim equivalent to a loss is the entire point of this discussion.

Not at all. The point of this discussion is if refusing to play on, or misusing the protocol in such a way as to create the impression refusing to play on, should be equivalent to a loss.

Has been from the get-go. And to do so is wrong, whether it be via the broken result mechanism, or anything else. A user must be allowed to claim a draw that is incorrect, without penalty...
The rules of chess say so.

Yes. And protocol specifies how you have to do it. It would for instance, not be very smart to claim a draw by sending "resign", or 1-0, or "OFFER DRAW", or "half-half", or an invalid move, or "remise, s'il vous plait?"... If you don't stick to protocol, your engine will forfeit, and be considered buggy. Always has been that way...

[bob]

There are big differences. You said "a draw can be refused by the GUI."

Oh yeah? So now you stoop down to lying, in order to hide the fact that you habitually don't read what others post, or at least are not able to understand what they wite?

Then how about this DIRECT quote from you earlier in this thread:

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.

Do you _still_ maintain that "I am lying when I said that you claimed the GUI could refuse to accept a draw claim (if the claim has no basis)???

I believe that is exactly what you wrote above.

I personally find it difficult to discuss this with a child, that can only resort to name-calling when his points get shot down repeatedly.

Grow up...

Where did I write that? If you would have taken the trouble to read back even now, you would have seen that I wrote nothing of the sort, and only said that a draw can be refused by the opponent. But NOT if there is insufficient mating material on the board, more than 50 reversible moves have past, or the current position has occurred already twice before. And if the opponent cannot refuse the draw, it becomes kind of pointless for the GUI to consult the opponent if he would want to refuse it. Hence WinBoard_F grants the draw automatically in such a case.

perhaps that is what you _meant_ to write. But the quote above _clearly_ shows it is not _what_ you wrote. You said a draw claim, that is not correct, will be treated as a forfeit "by the GUI" in the above quote. wiggle and dance, your words are there in this thread for all to see. And that idea violates the rules of chess, which is what I have been arguing against since the beginning.

See the bottom of this post for a specific summary of what I have asked for, rather than continuing to make up things you think I want...

That would necessarily cover my claiming that a position is drawn for repetitions, 50-moves, insufficient material, stalemate, etc, as well as my simply offering my opponent a draw regardless of the state of the chess board and game clocks.

The GUI/arbiter could certainly refuse a draw claim that is invalid, but then you have an ambiguity as to how a draw is offered vs how a draw is claimed. The two cases are different, and in the former, the GUI/arbiter has absolutely no say-so, while in the latter, the GUI/arbiter should be the only one that can declare the game over.

A difference that makes no difference is no difference! Give me one example where this alleged ambiguity would lead to a wrong action. (i.e. where it would be an error when the GUI receives the "offer draw" string in a legal-draw position to have it grant the draw without consulting the opponent, or where it would be an error to only relay it to the opponent through a "draw" command when there is no legal draw position.) You are just talking nonsense![/quote]

No, I am speaking as an experienced tournament chess player. You have two issues. If the position is drawn by rule, you stop _both_ clocks and call the arbiter over to have the claim verified. If it is correct, the game is over. If not, he will start your clock if youur claim did not have a move, or he will start the opponent's clock if you gave a move along with the claim. He may penalize you some clock time for the interruption if he sees fit.

If I offer my opponent a draw, he has the option of accepting, explicitly declining the offer by saying "no" or something to that effect, or he can implicitly decline by just playing a legal move and starting my clock.

Combining the two is OK, as that is how ICC does it with no problems. But the two circumstances are entirely different since one ends the game instantly if the claim is upheld, otherwise the game continues. The other ends the game only if the opponent agrees. Nowhere in that do you see a forfeit mentioned. And that is what is unacceptable.

Just follow the rules, don't make 'em up.

That is all I have said from the beginning. You, on the other hand, want to make a draw claim result in a loss if the claim is ruled invalid. I simply want to be able to claim a draw, and if I am wrong (crafty never is, but after a programming change I could certainly break something as I have done so in the past) then I want the draw claim to be ignored and the game to continue, just as it does under FIDE rules when a draw claim is denied by the arbiter.

The command that behaves that way is "offer draw". As you very well know, every RESULT command in every WinBoard version immediately terminates the game, so there never has been, and never will be a possibility to continue the game after a RESULT command. And there are too many engines that rely on that to change it, just because you don't like the wording of it or the prvided alternative. You are just stubbornly refusing to use the correct command.

We are discussing the case where the program can improperly end a game by claiming a draw that current xboards do not verify, and we are going from fixing that flaw to letting the GUI incorrectly end a game when it should not. The right way is to do it as the FIDE rules say. If someone loses on time, so be it. but don't tell me I lose if I claim the game is drawn, and your arbiter disagrees, because for me at least, my program can continue playing beyond 50 moves or 3-fold repetitions if desired, with no harmful effects or program crashes...

Programs will always forfeit one way or the other if they stubbornly refuse to use the protocol as it is defined. This is unavoidable, no matter how much against the FIDE rules (which do not define the protocol) that forfeit might be. If you run an UCI engine under WinBoard, it will _always_ forfeit on time. If you have an engine that does not print 'move ' but 'coup ' in fromt of the moves it makes, it will _always_ forfeit the game. Despite the fact that the FIDE rules don't specify at all that you have to yell 'move' to your opponent before making a move.

So it is totally obvious that FIDE rules are not the only rules an engine has to follow to be able to play under a given GUI. It has to handle the protocol correctly as well. That a stupid or malicious programmer can misuse the protocol in such a way that he forfeits in situations where a Human arbiter with a FIDE rule book would not have had it forfeit, is thus no evidence whatsoever for the protocol being flawed.

The winboard protocol does _not_ require that you precede your move with "move". The latest version does, but for many years you just send the SAN move by itself, and winboard/xboard would figure out it was a move to be played and do so.

I doubt anyone would maliciously claim a draw since it would have no effect on the game, if handled properly. Again, I would be happy to see the result option removed, so that a program can _never_ end a game instantly. It can make a claim, but the game continues until the GUI says it doesn't. If both opponents agree, the game ends whether the GUI likes it or not. So draws/wins/losses _BY RULE_ are acceptable circumstances for the GUI to end the game and inform both engines of the correct result. Draws by offer are up to the engines. Invalid claims should be ignored as they will have no effect on the opponent at all...

So again, the "claim" and "the offer" are two completely different things. The claim has to be verified by the GUI or the game continues, while the GUI has to stay out of the way of an offer/accept as it has no business doing anything other than relaying those two events back and forth between the two programs.

Repeating it forever doesn't make it so. Give the example where overloading the "offer draw" command would produce an error.

For the umpteenth time:

I make a move that repeats for the third time. I send a draw claim. Two messages at present. The first is sent, I lose control of the processor, the gui gets the move, sends it to the opponent, who makes a move to escape the 50 move rule counter or the repetition, and when the GUI gets the draw claim, it is invalid.

I can't legally offer my opponent a draw after I make a move, by FIDE rules. Because to offer a draw while my clock is stopped could cause me to incur a penalty from the TD up to and including forfeiting the game because of harassing tactics (if I were to do it repeatedly, for example). So do I offer the draw _before_ I make my move? What if it is a draw claim, but prior to my move, no repetition has been detected. Do you forward it to my opponent as you should, because I can certainly offer him a draw while my clock is running? Do you hold on to it to see if it is a valid claim once you get the move?

There are some sync issues to make it work correctly.

Now that isn't so hard to understand, is it.

Not hard to understand that it is not true, indeed. Give the example, or admit that you can't, and drop it!

That is all I have said _from the beginning_... Nothing more, nothing less. Hyperbole notwithstanding...

I have pointed out technical issues that have to be resolved in the synchronization of making a move and offering / claiming a draw, as well as the special case of claiming a draw without making a move. If you require move and then draw claim, there is a hole because you absolutely must send the move to the other engine as soon as the GUI gets it, otherwise you distort the timing in very fast games. It would be possible for me to send the move, you relay it, you then get a reply from the opponent and relay it to me, before you get the draw claim from me that went with my previous move.

Yes, this is the way WinBoard_F handles it, the third way I mentioned above:

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.

This is a must in any solution for claim verification, as it is the only way to solve the false-claim problem without causing incompatibility with the way most engines handle after-the-move draw conditions, namely by sending the claim after their move, in a non-atomic fashion, relying on the fact that old WinBoard versions accept the it no matter what. Even if sync problems did allow the opponent to sneak in a reply before the claim got through to WinBoard.

That has to be handled, and can be, but it is non-trivial. I don't care about the illegal move problem myself, I'll leave Uri to worry about that. I am only interested in drawing issues and there are several. Each has to be handled correctly to be useful...

I have asked for the protocol to allow draw offers that can be explicitly or implicitly declined, but _only_ by the opponent. I have asked for the protocol to allow draw claims (by rule) that can be declined, but only by the GUI. I have asked that the GUI follow the FIDE rules of chess, rather than something made up with little forethought about the potential difficulties when using the GUI both in local matches, in online matches, etc...

I have not ask for any of the other stuff you keep saying I want. I definitely don't want a 'super-GUI' that can forfeit an opponent for any reason other than by official rule of chess. FIDE rules even cover illegal moves, if you want to really get picky.. And they do _not_ end the game...

[bob]

OK. You don't understand it. You don't want to understand it. So there is little left to discuss. My interpretation of how the current winboard works is 100% correct. I have used it for 15 years now. And I understand _exactly_ what it does, and where the problems are.

Apparently not. Or you would know that a RESULT command would _always_ end the game instantly, when not in ICS mode. And thus, when you don't want your engine having to behave differently in two-machines mode as in ICS mode, you cannot sent RESULT strings in ICS mode either.

Will you ever get this conversation right? Show me where I have said anything "good" about the result command at all. What have I asked you to do? Change the protocol? Absolutely not. Just _IGNORE_ the result command. Engines should not be able to end the game unless both agree to a draw. No other circumstance should end the game, unless the GUI verifies that the game should end by RULE, not by WHIM.

So no, you don't have to "change" the winboard protocol. Just ignore the damned result command so that an engine can not incorrectly claim a victory (as an example) when it is drawing or losing. Don't allow the engine to end the game at all. I send a draw offer, my opponent accepts, the GUI should end the game but I am prepared to play on anyway, because ICGA events require TD approval for draws anyway to prevent collusion from affecting the tournament standings.

It _really_ isn't that hard to do. I did it for my non-X referee program I use on the cluster. And it works perfectly.

WB protocol is what it is, and it is not in my power to change it. Unlike Human OTB Chess, there is a great need in computer Chess for an engine->GUI command that unconditionally ends the game, by telling the GUI that no more moves have to be expected from the engine no matter what. Lack of such a command would result in huge wastes of CPU time in many situations, by having to wait out the game for a flag to drop.

There is no such "great need" at all. And, in fact, this "result" nonsense was not even present in early xboard versions and they worked on ICC just fine. I asked Tim to send "ME" a result command when I was working on book learning and needed to know how the game ended. But I certainly don't need the ability to tell the GUI "I think the game is over." Because the GUI should not care "What I think". It can make game-termination decisions by itself... as it should..

Like it or not, original WinBoard has only one command to unconditionally terminate a game, namely the RESULT command.

I don't like it. It should be completely ignored.

Most engines rely on the command having this effect, so it would be extremely detrimental to suddenly redefine this command to mean something else. If you have a sick desire to waste computer time and needlessly drive up CO2 emissions, just because you have enough of it to burn, doesn't mean that I am going to harm others this way. So the RESULT command will have to terminate the game unconditionally in future versions of WinBoard as well, as it always has. No matter how much we would like there to be a separate "stop game", "abandon" or "leave" command decoupling this effect from the actual result specification. Existing engines do not use these command, and we cannot 'fix' problems by breaking a hundred times as many things that are working properly right now.

If an engine wants to leave the game, it can always exit. The GUI should be smart enough to pick up on that. But the engine should not try to tell the GUI how to end the game, the GUI should make that determination after verifying the conditions required by the rules have been met.

So the only solution is to use another command than RESULT for cases were the engine might want to play on. This could be an entirely new command, but using "offer draw" in the situation where this new command would be used does not result in any different behavior, so it might as well be used. Note that there are _many_ undocumented commands that are understood by WinBoard for accomodating older engines, from before the time the protocol definition was published, and that many sentences containing the word 'draw', recognized by that fact alone, will be considered as an equivalent to the RESULT message in existing WinBoard. So things like "claim draw" would certainly cause improper operation of any engine using it, when it runs under such an old WinBoard. There would be no backward compatibility. The only way to guarantee this backward compatibility is to use a command that old WinBoard versions already know, and is harmless in that context. This is why overloading"offer draw" is such a perfect solution.

Implement what you want, and then when the problems I have explained pop up, maybe _THEN_ you will "get it" the hard way...

I will certainly do that (I never planned otherwise ), as following your advice would lead to a crap product that no one would want anyway...

We'll see who has the "crap product" when it is all said and done, won't we?

something that violates the basic rules of chess won't be taken seriously anyway, so it is really a moot point at the moment..

I suppose all of that rambling is supposed to make some sort of sense? Again, two cases. Draw claim. Draw offer/draw offer accept. Two different animals. The former requires verification. The latter does not. I don't exactly like the "offer draw" to accept a draw, but it has worked perfectly for years and is OK. With ICC that is also all that is needed to claim a draw. ICC's interpretation is as follows: If a player offers a draw, and the game is drawn by rule (50 move, 3-fold repetition, etc) then the draw is enforced instantly. Otherwise the draw offer is relayed to the opponent. If he accepts, or if he offers a draw in response, the game ends immediately.

Well, this is exactly what I descibed, and how WinBoard 4.3.13 works. So why are you going off like a loose cannon?

The "GUI" does it correctly. Programs can't end the game themselves (unless they outright resign or else get mated or mate the opponent, but they can handle draws just as FIDE intended. And if a player claims a draw and nothing happens, the game continues. Again just as FIDE rules say. Surely if ICC can do it, you can do it too? And make it work reasonably without artificially changing game results?

As I told from the very beginning, it already works exactly that way in WinBoard_F. You have to offer the draw, not use the RESULT message (which unconditionally ends the game, with the GUI forced to decide on a result), just as you describe above in the interaction with ICS.

And not everyone is an idiot that is making up rules as they go along and forcing everyone to abide by them.

Indeed. Only GUI programmers have that privilege.

Several have pointed out the timing issue with "offer draw" being overloaded. It can be handled, but you are not explaining a way to do that as of yet, that solves all the issues.

A mistaken draw claim should not end the game.

But a protocol violation will. Claims not made by the proper protocol command can and will not be an exception to this universal truth.

if it does, I won't be using it even though my program is never guilty of doing this. But I don't want wins in positions where there is still play left. It really is as simple as following the rules of chess, rather than the whims of testers that are really doing nothing to help the engines out anyway...

Well, seems you are not using current WinBoard either, so who cares? Why would anyone care what you use or don't? What you use is not a factor in this at all. What matters is how others will use Crafty, and how they will appreciate its behavior.

It is all so simple...

yes it is. So why all the discussion? If a program claims a draw, and the game is not drawn, it continues. the idea of calling an invalid draw claim equivalent to a loss is the entire point of this discussion.

Not at all. The point of this discussion is if refusing to play on, or misusing the protocol in such a way as to create the impression refusing to play on, should be equivalent to a loss.

Has been from the get-go. And to do so is wrong, whether it be via the broken result mechanism, or anything else. A user must be allowed to claim a draw that is incorrect, without penalty...
The rules of chess say so.

Yes. And protocol specifies how you have to do it. It would for instance, not be very smart to claim a draw by sending "resign", or 1-0, or "OFFER DRAW", or "half-half", or an invalid move, or "remise, s'il vous plait?"... If you don't stick to protocol, your engine will forfeit, and be considered buggy. Always has been that way...

Hasn't for most of us. Won't always be that way for most of us...

[Uri Blass]

I think that there is a possible solution to all the problems that both Bob Hyatt and H.G.Muller may accept.

No need to new winboard commands and no need to changing existing engines.

It is possible to tell winboard the names of the engines that continue the game after claiming a draw.

Winboard can consider to continue the game after an engine claims a draw only if the engine is in the list of engines that continue the game.

If the engine is not ready to continue it is simply a waste of computer time not to finish the game immediatly.

Uri

[bob]

I think that there is a possible solution to all the problems that both Bob Hyatt and H.G.Muller may accept.

No need to new winboard commands and no need to changing existing engines.

It is possible to tell winboard the names of the engines that continue the game after claiming a draw.

Winboard can consider to continue the game after an engine claims a draw only if the engine is in the list of engines that continue the game.

If the engine is not ready to continue it is simply a waste of computer time not to finish the game immediatly.

Uri

There are still timing issues when we overload a single command so that it can either claim a draw or offer a draw.

But more importantly, I want the "result" command to be ignored when sent from a program, because a program really should not have a mechanism to say "end the game now". It should ask either its opponent to agree to a draw, or the GUI to declare a draw.

That latter issue caused me lots of trouble in cluster testing, because some programs (arasan 9 was one example) would reverse the result when it was playing black, so that it would mean to resign, but would instead declare a win...

[bob]

It seems that several strong engines do violate FIDE rules and WinBoard protocol by claiming repetition or 50-move draws without announcing or the move they think to salvage this draw with.

Hello H.G.,

I am in the process of converting Gothic Vortex to run under Winboard-F, as you know. One of the things I am doing is requiring Vortex to run with (at least) the 4-piece tablebases, and its Opening Book, in order to "accept" a Windboard_F challenge.

Having said that, is there any way Vortex can claim a draw that it "knows" is in its tablebases as a draw? For example, I have seen a game where Vortex swapped all the way down to a Chancellor and Pawn vs. Chancellor endgame that was a draw. It had just the Chancellor as Black, but was very short on time. The game was a certain draw in its 5-piece tablebases. It was a sudden death 5/0 game and it could draw by moving instantly, of course. But the other program kept playing on, and it only needed to be a few seconds ahead to expire the Vortex clock.

Is there a way to deal with this kind of draw?

Thanks!

Yes. don't play sudden death time controls. Otherwise, this is _exactly_ what they are designed to do. One side was able to win material, and if it can win on time, that's just the way sudden death works out. I never test that way to avoid the idiocy that occurs in almost-zero-time-left endgames....