xboard protocol discussion - restart

[bob]

In this particular case, ChessGUI is waiting for a move from Crafty.
Crafty then suddenly claims a draw by repetition, without having sent the drawing move. ChessGUI rejects the claim because it cannot prove that Crafty found the drawing move.

I think a human can draw by 3-fold-rep in a human game without playing the move, but he has to tell the TD which move it is.
In computer chess, the drawing move should be played before any claims.

BTW, I will change "resign" to something else.

OK, let's make sure we agree what problem is described here. I understand from this description that Crafty sends 1/2-1/2 ('claims a draw'). If it would have sent offer draw there would never be a reason for any GUI to forfeit it, because it is legal to send draw offers in any position. In the previous discussion there seemed to be some confusion about this. Perhaps the relevant part of the debug file can be posted here, to avoid any unnecessary misunderstandings?

Two important points.

1. One can claim a draw without playing a move. The FIDE rules say that the side on move can claim a draw by repetition, if the same position has occurred three times in a row, with the same side on move. This means that if I reach a position with me to move, and the position has already occurred three time (including this one) I do not have to make a move. I can just claim the draw and the game ends when the TD/arbiter verifies this.

Agreed. I would say that any GUI that would ignore any 1/2-1/2 here sent by the engine and require the engine to go on (or forfeit it on time when it doesn't) is broken. Any GUI that would forfeit the engine immediately is even more broken. If the position occurred indeed for the 3rd time, that is. If it didn't... Well let me leave that for later.

2. One can claim a draw after playing a move. Crafty does this with the "1/2-1/2 {Draw by 3-fold repetition}" string it sends to xboard. It always sends this prior to making a move. Because we do not have a "end of my move" sentinel like a real game, where pressing the clock signifies you have done everything you intend to do. You have made a move. You have (or have not) offered a draw. Etc. In xboard games, you can't safely claim the draw _after_ the move, because of the previously mentioned race condition. So the claim of a draw for any reason has to go _before_ the move, unless the GUIs are all changed to realize that a claim _after_ the move might apply to the position after the mover, or it might apply to the position before the next move, and the GUI has to decide which.

Agreed. There is need for a command that allows you to claim a draw in advance, to solve the race condition. That command should translate to the correspondig ICS command in ICS mode. (I.e. it should trigger the sending of 'draw' to ICC.)

After the last lengthy discussion, I tried the "offer draw" trick that works on ICC, and had a couple of testers try this. They uniformly reported that it did not work for several GUIs making it problematic. I personally don't even like the wording "offer draw" because I am not offering a draw, I am trying to claim a draw.

Well, I don't like that wording either, but on the other hand, there is absolutely nothing to be gained by adding a new command claim draw, to distinguish it from offer draw. It would only create possibilities for errors, making it possible to claim in situations where it is only allowed to offer, and making it possible to offer in situations where it is silly to offer. One only offers a draw if one wants one, and if one wants one, and can claim it, one should claim it. So the protocol really needs a single command from the engine, saying "I want a draw". The GUI cn then grant it when it is claimable, and if not, the opponent can grant it. Well, this command now happens to be badly worded, as offer draw. Well, it is just protocol, and who cares if it is "offer draw", "want draw", or "%&123=A"? It is certainly not the only command in the protocol that has obscure wording ("easy", "hard", ...).

Not that the FIDE rules stipulate that a draw claim is automaticly also a draw offer. So even if a separate command claim draw existed, and it would be used by an engine in a position where claiming was not legal, the GUI would still have to treat is like it was offer draw.

HGM is going to say that Crafty is doing it wrong. I claim that currently _most_ GUIs are doing it wrong. That was why I thought it useful to clear up the ambiguity that "offer draw" has. In a normal game, if I offer you a draw, you can just ignore it and keep playing. If I claim a draw, you can not continue until the TD/arbiter has ruled that this is not a drawn position. If it is a drawn position, the game ends with my claim.

As you already spoke for me, what seems most important is to know exactly what most GUIs are doing wrong, then. In ICS play, it can only go wrong when the GUI does not relay the offer draw to the ICS as a "draw" command. The ICS should have taken this as a draw claim, as the ICS protocol also does not have separate commands for claiming and offering a draw. (But, admittedly, uses better wording for it. As, unike WB protocol, the ICS protocol is meant for Human use, this is just as well.)

In local mode, I can imagine that som GUIs simply relay offer draw immediately as a draw offer, and that the opponent refuses it (or that the Gui ignores the offer on behalf of the engine). Then you play the move. On a state-of-the-art GUI (like on an ICS) this should terminate the game. But, just to make sure, you could now send 1/2-1/2 to claim the draw. No GUI that did not interpret offer draw as a claim should forfeit you on a false claim when you send a 1/2-1/2 command that was pe-empted. Old XBoards would grant you the draw no matter what, even if you had a bare King against 3 Queens. It seems to me tha GUIs that now still would not terminate the game as a draw are very badly broken.

Miguel suggested "offer draw" is fine for offering draws. And that "claim draw" would be more to the point of claiming a draw. And by using the syntax "claim draw <move>" you are saying "I play <move" and claim the resulting position is a draw (doesn't specify 3-fold, stalemate, 50-move, insufficient material, or anything else, just a draw that the GUI needs to figure out). It might be worthwhile to specify the "why" as well to further resolve ambiguities, such as "claim draw 3-fold <move>" or "claim draw 50-move <move>" or whatever.

I can only repeat myself: "What problem is the introduction of this command supposed to solve?". All the broken GUIs that are giving you trouble with the existing offer draw will most certainly give you even more troule if you send them a command that we introduce, as it will not be implemented in them. If their programmers would be prepared to implement it, they might as well start implementing the offer draw. One can never solve refusal to comply with existing protocol by adding even more protocol to not comply with...

Adding new command to the protocol will not solve the problem of the non-compliant GUIs; at best they will ignore it. This is why I initially proposed to use a backward ompatible way for an atomic draw-after-moe claim, as

1/2-1/2 {3-fold repetition after Rh7+ }

Old XBoard versions that would accept any claim would understand this, and newer GUIs that verify claims could scan the (REASON} for an "after" and parse the following move to see if it should treat the game as a draw or a false claim. But for better analogy with the ICS I finally opted for the offer draw overloading.

The problem, stated again, is that we do not have an "end-of-move" indicator, so the draw claim / offer and move need to be combined into one message, so that the ambiguity of what goes with what becomes perfectly clear. At the moment, the "offer draw" may need to appear "out of sequence" where you want to use this to claim a draw _after_ your move causes a draw condition to become valid. This has come up enough times, it is apparent (at least to me) that this is problematic and confusing. It took some explaining in talking with Darooha 13-14 years ago before he understood the problem caused by the reaction time of computers.

It makes little sense to "offer a draw" when I am really claiming a draw. It makes little sense to offer a draw before a move, when I am really claiming a draw after a move (and I might really want to claim a draw and not make a move at all, which is perfectly legal according to FIDE/ICC rules.).

According to FIDE rules, you still have to make the move nown through whic you wantto draw, by writing it on your score heet. Keeping the score sheet is one of the tasks we deligated to the GUI in computer Chess. So you still have to send the move to the GUI, before it could accept your claim.

Not entirely correct. I can claim a draw where no move is needed to make the claim. I have already made 50 moves without a pawn push or capture. You just made the 50th move also but did not claim the draw. When it is my move I can claim it immediately and do not have to record a move or make a move known. The game is over at that point. That's one component of the problem here. You can offer or claim a draw before or after the move, and you can claim a draw without even making a move.

The ambiguity needs to go. So that this can be the last time this long-winded and pointless discussion happens.

BTW, to HGM: You are certainly correct that I am a long way from an expert on the xboard protocol. But you clearly don't understand why. The "why?" is answered by "Crafty played its first game on ICC in December of 1994. That is 15+ years ago. And it has been working just fine for that length of time. So I do not continually look at the protocol, because I do not continually modify the code to offer/claim draws, mates and losses. It just works. I made one significant change a few years ago, to offer a draw _before_ displaying a move, to match the FIDE rules for offering draws. Ditto for claiming draws.

There is nothing wrong with not being a protocol expert. Before I started workig on WinBoard I wasn't one either. But then, please, do have a peek in the protocol specs before side-tracking the discussion with nonsense claims like "the ics HOST command does not exit" or "there should be a result before 1/2-1/2".

If no one sees the need to fix this, fine by me. But problems are going to _continue_ to pop up as new programs come along. Wrong results are going to get recorded when GUIs do something insane and call a draw claim that they don't understand, a loss. FIDE rules address invalid draw claims, and there is no mention of a forfeit. But even worse, the timing problem demands a logical solution. And it seems that demand is not going to be met.

The problem is that no single person controls all GUIs that are in existence. XBoard and ChessGUI do now propely address this point. They do it in a backward-compatible way, which does not interfere with the compatibility of the output an engine has to give with existing protocol. That is the best we can do. Non-compliance in other GUIs will have to be addressed by the authors of hose other GUIs.

It is not 100% backward compatible, because I have an xboard version here that does _not_ record the game as a loss if the engine sends a 1/2-1/2 result. I'd be happy to post a couple of games if you want to verify this.

I don't think it is a viable policy to exploit GUI bugs to devise work-arounds for other GUI bugs. If a GUI does not implement the offer draw command, and refuses to relay it to the ICS, let it be a problem of the GUI. Do not resort to illegal use of 1/2-1/2 just because the offending GUI happens to send that as a draw offer to the ICS.

Preceeding your move by a draw offer should work on any GUI that relays the draw offer to an ICS, when playing an ICS, and it completely solves the race condition. And if they do not relay draw offers, let them fix it. There are plenty of other reasons than this race condition why the should relay draw offers. And if it does not solve the race condition in local mode, don't worry. Users of that GUI will be used to it, as other engines will suffer the effects of the race condition just as Crafty does, and the GUI users will correct the false results. Do not try to fix the GUI problems by quirky engine behavior.

I suppose I could verify proper operation of each GUI and if Crafty can detect that it is running on a non-rational GUI, just refuse to play. That at least will stop these occasional "strange behavior" issues when a GUI author makes an assumption that might seem logical at the time, but which is nonsensical when carefully analyzed. Draw claims do not end the game unless the TD says they end the game. But electronically we can't seem to get that idea across...

Well, it would definitely be a good idea to report details of GUIs where Crafty encountered problems using the method the protocol describes. Then the authors of those GUIs could address the problem and fix their GUI bugs, to the benefit of all. That would do a whole lot more than complaining to the authors of GUIs where thing do work according to protocol that it does not work on all GUIs...

[ilari]

I noticed this when I was testing Cute Chess with Crafty. It was a very simple problem to fix: when an engine that is on move sends a draw claim when the position isn't a draw, Cute Chess remembers the claim and checks its validity after the engine has made its move.

Ah, caught second time!

Yeah, you got me

So now what does Cute Chess do when no move is forthcoming (as would almost always be the case)?

If there's no move coming, then Cute Chess waits until the engine's flag falls. But that only happens if the draw claim was false, which doesn't happen with any decent engines.

[henkf]

I am replying to your post since it's the most extensive post on this subjects, but not all points i'm going to make are addressed to you ( maybe even none ).

To comply with the Fide rules of chess, a draw offer can not be delayed and should be sent to the opponent immediately. The relevant article in the handbook is:

[quote]
9.1a A player wishing to offer a draw shall do so after having made a move on the chessboard and before stopping his clock and starting the opponent`s clock. An offer at any other time during play is still valid, but Article 12.6 must be considered. No conditions can be attached to the offer. In both cases the offer cannot be withdrawn and remains valid until the opponent accepts it, rejects it orally, rejects it by touching a piece with the intention of moving or capturing it, or the game is concluded in some other way.
[\quote]

For completeness I'll also add article 12.6

[quote]
12.6 It is forbidden to distract or annoy the opponent in any manner whatsoever. This includes unreasonable claims or unreasonable offers of a draw.
[\quote]

Although it's preferred to send the draw offer after your move, it seems not to forbidden to do it at any other time. If the opponent accepts it, there is no need to make another move. When ahead in material and low on time it doesn't seem unreasable to me to offer a draw to the opponent.

There is another interesting article

[quote]
13.6 The arbiter must not intervene in a game except in cases described by the Laws of Chess. He shall not indicate the number of moves made, except in applying Article 8.5 when at least one flag has fallen. The arbiter shall refrain from informing a player that his opponent has completed a move or that the player has not pressed his clock.
[\quote]

So maybe we shouldn't call a chessgui an arbiter?

[michiguel]

In this particular case, ChessGUI is waiting for a move from Crafty.
Crafty then suddenly claims a draw by repetition, without having sent the drawing move. ChessGUI rejects the claim because it cannot prove that Crafty found the drawing move.

I think a human can draw by 3-fold-rep in a human game without playing the move, but he has to tell the TD which move it is.
In computer chess, the drawing move should be played before any claims.

BTW, I will change "resign" to something else.

OK, let's make sure we agree what problem is described here. I understand from this description that Crafty sends 1/2-1/2 ('claims a draw'). If it would have sent offer draw there would never be a reason for any GUI to forfeit it, because it is legal to send draw offers in any position. In the previous discussion there seemed to be some confusion about this. Perhaps the relevant part of the debug file can be posted here, to avoid any unnecessary misunderstandings?

Two important points.

1. One can claim a draw without playing a move. The FIDE rules say that the side on move can claim a draw by repetition, if the same position has occurred three times in a row, with the same side on move. This means that if I reach a position with me to move, and the position has already occurred three time (including this one) I do not have to make a move. I can just claim the draw and the game ends when the TD/arbiter verifies this.

Agreed. I would say that any GUI that would ignore any 1/2-1/2 here sent by the engine and require the engine to go on (or forfeit it on time when it doesn't) is broken. Any GUI that would forfeit the engine immediately is even more broken. If the position occurred indeed for the 3rd time, that is. If it didn't... Well let me leave that for later.

2. One can claim a draw after playing a move. Crafty does this with the "1/2-1/2 {Draw by 3-fold repetition}" string it sends to xboard. It always sends this prior to making a move. Because we do not have a "end of my move" sentinel like a real game, where pressing the clock signifies you have done everything you intend to do. You have made a move. You have (or have not) offered a draw. Etc. In xboard games, you can't safely claim the draw _after_ the move, because of the previously mentioned race condition. So the claim of a draw for any reason has to go _before_ the move, unless the GUIs are all changed to realize that a claim _after_ the move might apply to the position after the mover, or it might apply to the position before the next move, and the GUI has to decide which.

Agreed. There is need for a command that allows you to claim a draw in advance, to solve the race condition. That command should translate to the correspondig ICS command in ICS mode. (I.e. it should trigger the sending of 'draw' to ICC.)

After the last lengthy discussion, I tried the "offer draw" trick that works on ICC, and had a couple of testers try this. They uniformly reported that it did not work for several GUIs making it problematic. I personally don't even like the wording "offer draw" because I am not offering a draw, I am trying to claim a draw.

Well, I don't like that wording either, but on the other hand, there is absolutely nothing to be gained by adding a new command claim draw, to distinguish it from offer draw. It would only create possibilities for errors, making it possible to claim in situations where it is only allowed to offer, and making it possible to offer in situations where it is silly to offer. One only offers a draw if one wants one, and if one wants one, and can claim it, one should claim it. So the protocol really needs a single command from the engine, saying "I want a draw". The GUI cn then grant it when it is claimable, and if not, the opponent can grant it. Well, this command now happens to be badly worded, as offer draw. Well, it is just protocol, and who cares if it is "offer draw", "want draw", or "%&123=A"? It is certainly not the only command in the protocol that has obscure wording ("easy", "hard", ...).

Not that the FIDE rules stipulate that a draw claim is automaticly also a draw offer. So even if a separate command claim draw existed, and it would be used by an engine in a position where claiming was not legal, the GUI would still have to treat is like it was offer draw.

No, it should be treated differently by FIDE rules in case that the claim was invalid. An "offer draw" as Xboard does it now is not the same as a claim because an invalid claim involves a time penalty.
see point 9.5b
http://www.fide.com/component/handbook/ ... ew=article

In other words, the GUI needs to know whether it is a claim or an offer. I admit that this may not be a huge point if we decide not to penalize engines who make wrong claims, but this is not how it is suppose to be. Let' not forget human-comp games!! Humans can make mistakes and penalties should not be left out of protocol if they want to be enforced.

HGM is going to say that Crafty is doing it wrong. I claim that currently _most_ GUIs are doing it wrong. That was why I thought it useful to clear up the ambiguity that "offer draw" has. In a normal game, if I offer you a draw, you can just ignore it and keep playing. If I claim a draw, you can not continue until the TD/arbiter has ruled that this is not a drawn position. If it is a drawn position, the game ends with my claim.

As you already spoke for me, what seems most important is to know exactly what most GUIs are doing wrong, then. In ICS play, it can only go wrong when the GUI does not relay the offer draw to the ICS as a "draw" command. The ICS should have taken this as a draw claim, as the ICS protocol also does not have separate commands for claiming and offering a draw. (But, admittedly, uses better wording for it. As, unike WB protocol, the ICS protocol is meant for Human use, this is just as well.)

In local mode, I can imagine that som GUIs simply relay offer draw immediately as a draw offer, and that the opponent refuses it (or that the Gui ignores the offer on behalf of the engine). Then you play the move. On a state-of-the-art GUI (like on an ICS) this should terminate the game. But, just to make sure, you could now send 1/2-1/2 to claim the draw. No GUI that did not interpret offer draw as a claim should forfeit you on a false claim when you send a 1/2-1/2 command that was pe-empted. Old XBoards would grant you the draw no matter what, even if you had a bare King against 3 Queens.

This may not work with old xboards (or other old GUIs) because a race condition. As I said before, the engine wants to know that. Otherwise, it risks being forfeited by the GUI. An approach I always thought was to actually claim 3 rep ONLY when the position occurred after the opponents move. 99.9% of the time it should be ok, I need to know when I am facing old vs. new winboard!! that is why I think you could easily implement

feature atomic_offers=1
and send back accepted atomic_offers
so the engine knows whether draw offer is atomic or not. Old winboard will not send accepted.

Miguel

It seems to me tha GUIs that now still would not terminate the game as a draw are very badly broken.

Miguel suggested "offer draw" is fine for offering draws. And that "claim draw" would be more to the point of claiming a draw. And by using the syntax "claim draw <move>" you are saying "I play <move" and claim the resulting position is a draw (doesn't specify 3-fold, stalemate, 50-move, insufficient material, or anything else, just a draw that the GUI needs to figure out). It might be worthwhile to specify the "why" as well to further resolve ambiguities, such as "claim draw 3-fold <move>" or "claim draw 50-move <move>" or whatever.

I can only repeat myself: "What problem is the introduction of this command supposed to solve?". All the broken GUIs that are giving you trouble with the existing offer draw will most certainly give you even more troule if you send them a command that we introduce, as it will not be implemented in them. If their programmers would be prepared to implement it, they might as well start implementing the offer draw. One can never solve refusal to comply with existing protocol by adding even more protocol to not comply with...

Adding new command to the protocol will not solve the problem of the non-compliant GUIs; at best they will ignore it. This is why I initially proposed to use a backward ompatible way for an atomic draw-after-moe claim, as

1/2-1/2 {3-fold repetition after Rh7+ }

Old XBoard versions that would accept any claim would understand this, and newer GUIs that verify claims could scan the (REASON} for an "after" and parse the following move to see if it should treat the game as a draw or a false claim. But for better analogy with the ICS I finally opted for the offer draw overloading.

The problem, stated again, is that we do not have an "end-of-move" indicator, so the draw claim / offer and move need to be combined into one message, so that the ambiguity of what goes with what becomes perfectly clear. At the moment, the "offer draw" may need to appear "out of sequence" where you want to use this to claim a draw _after_ your move causes a draw condition to become valid. This has come up enough times, it is apparent (at least to me) that this is problematic and confusing. It took some explaining in talking with Darooha 13-14 years ago before he understood the problem caused by the reaction time of computers.

It makes little sense to "offer a draw" when I am really claiming a draw. It makes little sense to offer a draw before a move, when I am really claiming a draw after a move (and I might really want to claim a draw and not make a move at all, which is perfectly legal according to FIDE/ICC rules.).

According to FIDE rules, you still have to make the move nown through whic you wantto draw, by writing it on your score heet. Keeping the score sheet is one of the tasks we deligated to the GUI in computer Chess. So you still have to send the move to the GUI, before it could accept your claim.

The ambiguity needs to go. So that this can be the last time this long-winded and pointless discussion happens.

BTW, to HGM: You are certainly correct that I am a long way from an expert on the xboard protocol. But you clearly don't understand why. The "why?" is answered by "Crafty played its first game on ICC in December of 1994. That is 15+ years ago. And it has been working just fine for that length of time. So I do not continually look at the protocol, because I do not continually modify the code to offer/claim draws, mates and losses. It just works. I made one significant change a few years ago, to offer a draw _before_ displaying a move, to match the FIDE rules for offering draws. Ditto for claiming draws.

There is nothing wrong with not being a protocol expert. Before I started workig on WinBoard I wasn't one either. But then, please, do have a peek in the protocol specs before side-tracking the discussion with nonsense claims like "the ics HOST command does not exit" or "there should be a result before 1/2-1/2".

If no one sees the need to fix this, fine by me. But problems are going to _continue_ to pop up as new programs come along. Wrong results are going to get recorded when GUIs do something insane and call a draw claim that they don't understand, a loss. FIDE rules address invalid draw claims, and there is no mention of a forfeit. But even worse, the timing problem demands a logical solution. And it seems that demand is not going to be met.

The problem is that no single person controls all GUIs that are in existence. XBoard and ChessGUI do now propely address this point. They do it in a backward-compatible way, which does not interfere with the compatibility of the output an engine has to give with existing protocol. That is the best we can do. Non-compliance in other GUIs will have to be addressed by the authors of hose other GUIs.

I don't think it is a viable policy to exploit GUI bugs to devise work-arounds for other GUI bugs. If a GUI does not implement the offer draw command, and refuses to relay it to the ICS, let it be a problem of the GUI. Do not resort to illegal use of 1/2-1/2 just because the offending GUI happens to send that as a draw offer to the ICS.

Preceeding your move by a draw offer should work on any GUI that relays the draw offer to an ICS, when playing an ICS, and it completely solves the race condition. And if they do not relay draw offers, let them fix it. There are plenty of other reasons than this race condition why the should relay draw offers. And if it does not solve the race condition in local mode, don't worry. Users of that GUI will be used to it, as other engines will suffer the effects of the race condition just as Crafty does, and the GUI users will correct the false results. Do not try to fix the GUI problems by quirky engine behavior.

I suppose I could verify proper operation of each GUI and if Crafty can detect that it is running on a non-rational GUI, just refuse to play. That at least will stop these occasional "strange behavior" issues when a GUI author makes an assumption that might seem logical at the time, but which is nonsensical when carefully analyzed. Draw claims do not end the game unless the TD says they end the game. But electronically we can't seem to get that idea across...

Well, it would definitely be a good idea to report details of GUIs where Crafty encountered problems using the method the protocol describes. Then the authors of those GUIs could address the problem and fix their GUI bugs, to the benefit of all. That would do a whole lot more than complaining to the authors of GUIs where thing do work according to protocol that it does not work on all GUIs...

[ilari]

I interpreted his description as follows:

If the position was a claimable draw, Cute Chess would treat the "offer draw" as a claim and end the game.

If the current position was NOT a claimable draw, then Cute Chess would wait until it had received the engine's move, and if THAT position was also a claimable draw, then it would end the game.

That's exactly what I meant, if you replace "offer draw" with "the result command".

[hgm]

Yes, and this is exactly why no move would be forthcoming if the claim was invalid. Engines tend to play on after offer draw. They tend to stop paying after 1/2-1/2.

[bob]

I'm not sure I followed all of that, so let me try to be as concise as possible. If I am using a current version of xboard, and my move will create a 3-fold repetition, how do I make my claim after my move but before my opponent moves? To make it easy on me, show me the exact command sequence.

You send the counter-intuitive messages as follows:

offer draw
move Rh7+

ICC was the first to fix this to solve the problem. Tim then incorporated the fix into xboard to make it work with ICC. But when you look at it, it looks _wrong_. You are not "offering a draw" which is a far different thing from "claiming a draw" and it would seem logical to me to clean this up and make it clear enough that no one encounters a problem. Right now, most programs are doing things in odd ways that make the draw issue complex. So complex I decided to have my referee play 400 pound gorilla and end games on 3-fold / etc type conditions automatically and ignore any reference to the word "draw" or "1/2-1/2" coming from a chess engine. But my referee is not suitable for a FIDE event since it doesn't adhere to FIDE rules. Crafty adheres to FIDE rules perfectly, but has a problem with the draw claim to be made after a move since there is not a clean way of doing this without the current race condition showing up at a bad time.

[hgm]

...
Not that the FIDE rules stipulate that a draw claim is automaticly also a draw offer. So even if a separate command claim draw existed, and it would be used by an engine in a position where claiming was not legal, the GUI would still have to treat is like it was offer draw.

No, it should be treated differently by FIDE rules in case that the claim was invalid. An "offer draw" as Xboard does it now is not the same as a claim because an invalid claim involves a time penalty.
see point 9.5b
http://www.fide.com/component/handbook/ ... ew=article

In other words, the GUI needs to know whether it is a claim or an offer. I admit that this may not be a huge point if we decide not to penalize engines who make wrong claims, but this is not how it is suppose to be. Let' not forget human-comp games!! Humans can make mistakes and penalties should not be left out of protocol if they want to be enforced.

You want to diversify the command just to create the possibility for the engine do do it wrong, so you can penalize it? (Isn't that called "entrapment"?) I think that is just bad protocol design. The fewer errors a protocol allows, the better.

For Human-comp games XBoard does not do any adjudication. I never felt there is any need for this. In the end the Human can do and think what he wants, and is in total control. When an engine makes a false claim, the Human can laugh, and think "wow, what a stupid engine, it does not even know when or what it can claim!" And then edit the saved PGN. It does not need XBords assistance or approval for that. So XBoard might as well go with the engine.

So if the opponent is a Human or an ICS, the GUI becomes completely pasive, and relays everything the engine says faithfully to the higher authority (the Human or ICS).

This may not work with old xboards (or other old GUIs) because a race condition. As I said before, the engine wants to know that. Otherwise, it risks being forfeited by the GUI. An approach I always thought was to actually claim 3 rep ONLY when the position occurred after the opponents move. 99.9% of the time it should be ok, I need to know when I am facing old vs. new winboard!! that is why I think you could easily implement

feature atomic_offers=1
and send back accepted atomic_offers
so the engine knows whether draw offer is atomic or not. Old winboard will not send accepted.

It would work on all XBoards, because the old ones (perhaps except 4.3.12) would always accept your claim in local mode, and there would be no race condition at all. I cannot speak for all GUIs, but I doubt if there exist GUIs on which the offer-move-claim sequence could ever give you problems. Except that if they did not solve the race condition, they might accept neither the offer or the claim (if they were programmed to ignore false claims).

The later seems unavoidable. What sequence of commands would you propose to use against a GUI that did not solve the race condition? (i.e. it does not interpret offer draw as a claim, and it only judges 1/2-1/2 claims against the curent position.) I don't think you could do anything that is guaranteed to work, or that has better chances of working than offer+move+claim. So you might as well stick to that universal solution. You are afraid the claim could be ignored, and you want to play on to avoid losing on time. You can still do that, but you can still lose then, and your rightful draw claim would have been stolen from you. The tester now would not notice that you were wronged, while when you had lost on time because Gaviota suddenly stopped moving, he might have taken a second look and correct the GUIs result. People using such GUIs are accustomed to using LGPGNVER to correct the GUI game results.

In short, I think it is bad strategy to try to make problems of buggy GUIs the problem of your engine. Take a firm stance, and do tngs the right way. Don't let oher peoples bug drag you down to their level. If buggy GUIs forfeit you, it is their problem. File a protest, and laugh about how stupid they are.

I am not going to make new protocol, just to make it easier for others to violate existing protocol. That is totally counter-productive.

[krazyken]

So if I'm running under old xboard, I have to send 1/2-1/2, if I am running under new xboard, I have to send offer draw. How does the engine know which xboard it is running under?

[michiguel]

So if I'm running under old xboard, I have to send 1/2-1/2, if I am running under new xboard, I have to send offer draw. How does the engine know which xboard it is running under?

That is exactly my point. That is why I want a feature to know. HGM solution is to send both just in case.

Miguel