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

[bob]

No, he is proposing that the GUI follow the formal FIDE rules of chess. Ever seen a real game with an illegal move played? The person doing that does _not_ lose. In fact, the rules of chess cover this specifically. If the move played is illegal, it must be retracted but that piece must be moved to another square, unless any move of that piece is illegal. There are rules to follow, not rules to make up. While it is unlikely that a program could recover from the above, there is absolutely nothing that says that _some_ program could not, and making a legal scenario impossible doesn't seem to be particularly reasonable.

Just follow the rule book. no more, no less, and this could work. But stop trying to define your own rules and using justifications like "nobody wants to wait 40 minutes..." When I run my big matches, I don't watch all 20,000 games, I don't care if one takes longer than usual because an engine hangs in the search or plays an illegal move or just quits moving for unexplained reasons. The official rules determine the outcome...

Is there any need to continue this idiocy?

Is there anyone, besides Bob, who uses a GUI for engine-engine tournaments, and feels the need for giving engines that make illegal moves a 'second chance'????

If you want to pose a paraphrased version of my question, any chance you could "get it right" for a change???

I did not propose anything about a "second chance for correcting a legal move, although I responded to Uri's point which was valid. I proposed the simple rule that if a program claims a draw, and there is no draw, that the game continue. If you can't grasp the reasoning behind that, fine. But I have seen more than one claim a draw on the _second_ repetition, which is incorrect. It could even happen on a hashing issue. If the program can continue, why can't it do so? Again, cite the FIDE rule that justifies "invalid draw claim == forfeit". I can't find it in anything I have.

So _please_ stop trying to put words into my mouth, and then claim that they are "way out there" and ask others if they agree with what you claimed I said.

My comments have been about _DRAWS_. Nothing else. So dump the hyperbole, and come back to the real discussion. Or go away if you prefer. But don't claim I asked for something I did not even bring up myself...

I intend for my program to play by the FIDE rules. When it fails, and someone points it out, I fix it. I am _not_ interested in playing by other non-standard rules because I don't want to have to deal with multiple different cases of how draws are handled depending on the GUI being used...

[bob]

Hm. Should I care about Winboard_F? I don't run Windows. I run Unix.
I use xboard. Latest version is 4.2.7.

By the way, from where comes this "false draw claim = forfeit" rule? FIDE? The last time I claimed a draw wrongly in a OTB game I was just IGNORED and I was told to play on. Shouldn't a GUI do the same?

The problem is that in WB protocol, sending the RESULT string is not only a draw claim, but a draw claim + unconditional refusal to play on:

RESULT {COMMENT}
When your engine detects that the game has ended by rule, your engine must output a line of the form "RESULT {comment}" (without the quotes), where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is the reason. Here "by rule" means that the game is definitely over because of what happened on the board. In normal chess, this includes checkmate, stalemate, triple repetition, the 50 move rule, or insufficient material; it does not include loss on time or the like. Examples:

I don't see how else to interpret the "definitely over". Even if a clever lawyer could argue differently, we are faced with the practical problem that virtually every engine that exists will in practice not play on after sending the draw claim, so waiting until it forfeits on time after sending it more moves would just be a gigantic waste of precious CPU time. And I think we all would agree that "False draw claim + refusal to play on = forfeit" is a quite normal rule, that FIDE also applies.

To claim a draw that might be refused, (such as in acceptig a draw offer, as due to sync problems the offer might have been withdrawn) WB protocol explicitly specifies the command "offer draw" should be used.

That's just your interpretation, for whatever reason you choose to make that your interpretation. It absolutely does not say "the game can not proceed". It never has. Personally, as I have said _many_ times, I would prefer xboard to make all game-ending decisions internally, and just accepd resignations, draw offers/acceptances, and draw claims from the program and handle them appropriately.

A resignation should end the game and nobody would expect the program to play on, although it could if the GUI is told to ignore resignations. Crafty will gladly keep playing although it tries to be polite and resign when appropriate.

A draw offer should simply be forwarded to the other engine. A draw acceptance should end the game immediately so long as the offer was properly made, relayed to the engine, and then the engine accepted it properly according to FIDE rules. Otherwise the game should continue.

Mates should be verified (and even detected) by the GUI without any need for prompting by the engine, and the game should end immediately.

That's the right way to make this work. Get rid of the result stuff since it makes no sense anyway for an engine to be able to end a game on its own. And then just relay offers and evaluate claims for correctness, and accept them or ignore them as you wish. But do not end a game based on a bad draw claim, the rules do not allow it.

If you don't like waiting, don't play matches. I automate them so I don't care if a game runs longer than normal while an engine's time burns away until the flag falls.

[bob]

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

unless?

But WB protocol already defines a command that means exactly that: "offer draw".

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.

Back to your solipsistic 'reality' indeed, where I seem to have written "WinBoard" in stead of "WinBoard protocol". Is it big enough for you to read it now?

What a particular version of WinBoard does or does not implement correctly has no bearing on what the protocol document defines as meaning of the commands. Only the obsolete version of WinBoard that you seem to prefer, and are trying the utmost of your capabilities to prevent or stop any improvement of, has that bug. WinBoard 4.3.13 does support it correctly, of course.

What you wrote seems to have no sense or relevance no matter how often one reads it...

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

The part that said 'not'. In fact I could not even see it... If you send a 1/2-1/2 string today, the game ends. As you requested. And if you were losing, it of course ends with a big fat zero! Today. If you use WinBoard 4.3.13, and did not forget to tick the 'verify claims' option.

As I requested? I +never+ requested the "result" stuff. 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.

Of course, if you fanatically insist using yesterdays software, things that happen today for others, will not happen for you. They won't even happen for you tomorrow. Or over 100 years. Or for as long as you insist remaining in the stone age...

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.

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. 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???

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.

Yes, WB protocol is far from optimal, but there are 500+ engines using it, so we will have to make do with it. So what is "better" is not only a matter of taste, but also quite irrelevant. Changing the protocol in an uncompatible way is not an option.

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.

Overloading is an unfortunate necessity to stay within the protocol. Furthermore I see no major objections against it. I see the difference between the two as very insignificant. In both cases you request a draw from the first party along the line authorized to grant you one. Sometimes the arbiter (=GUI or ICS) has the power to grant you one, sometimes the decision rests with the opponent. The GUI will know where it lies. So why use two different keywords. That the keyword is "offer" in stead of "request" is perhaps an unlucky choice, but who cares? It is just a protocol.

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.

Is it so hard for you to imagine that the GUI would not pass on the information if the timing is not appropriote and it cannot handle the command itself? Or is it unknown to you that engines only communicate with the GUI, and never directly with each other?

5. Exactly. This is why WinBoard_F makes them forfeit the game when they 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.

Well, the "offer draw" command does exactly all that. So everything is exactly as FIDE works. It seems you are making all this fuss only because you think the required command should be worded differently, "claim draw" in stead of "offer draw". It is not only beyond childish to argue aboutmere wording of a command, but there are very good reasons NOT to introduce a new one: it would make engines that use it _incompatible_ with older versions of WinBoard.

If I would add, especially for your benifit, a _new_ command to WinBoard to claim the draw, so that you would not have to use the string "offer draw" to claim a draw after which you are prepared to play on, but could send some other string, say "iamanidiot" to WinBoard in stead, (although others could still use "offer draw" for that purpose), would that make you happy? I can even make it such that the string is ignored unless you enable it in the "feature" command, by saying "iamanidiot=TRUE".

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).

Yes, very nice. I can see why you are so reluctant to get out of your world of fantasy.

But in the harsh reality what you propose is of course totally out of the question, as it would make engines that use it incompatible with older versions of WinBoard. The way I implement things in WinBoard_F stays within existing protocol, (no matter how obnoxious I think this protocol is...) so that engines would not have to support two different protocols tobe able to run in every WinBoard tournament.

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.

Your objections solely stem from the incorrect assumption that a 1/2-1/2 message is just a draw claim. But in fact it is defined as expressing the absolute refusal to play on. So tell me, what would the FIDE rules specify if you told the arbiter, after he ordered you to keep playing: "f** you, not n your life", and would leave the tournament hall? I doubt he would be staying up two more hours until your flag finally fell... And even if he was, you cannot expect such leniency from testers that donate their precious CPU time to testing your roque engine.

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.

You most certainly lose if you tell the referee you refuse to play on at the same time... And if you did not want to imply that, you should not have used the WinBoard command that is defined to imply that, but the other way to claim a draw (explicitly specify as "offer draw", how silly that might sound).

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.

Not a chance any tester would accept or adopt a rule that would waste so much of their CPU time for no reason or benifit at all.

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 think you are fighting an uphill battle. No tester is going to use a GUI that forces them to wait out 99% of the games in stead of terminating them immediately when it becomes clear that one of the engines is no longer playing. If your engine will depend on such an interface for proper functioning, they will simply refuse to test it, and not admit it to their tournaments. WBEC doesn't admit any programs that don't send RESULT claims already for a long time. Get real.

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.

Well, it is your choice if you want Crafty to be considered WB compatible or not. Good luck in convincing the testers that they have to wait out games were one of the engines is not going to move anymore.[/quote]

[hgm]

That's just your interpretation, for whatever reason you choose to make that your interpretation. It absolutely does not say "the game can not proceed". It never has.

Well, and that is just your interpretation. I cannot be held responsible for the fact that the protocol definition is not explicit enough for you. But when various interpretations are possible, it escapes me why you would insist on using one that causes problems and makes life hard for everyone involved. In the end, it apparently boils down to the fact that the way WinBoard_F handles the draw claims is not at odds with the FIDE rules per se, but that you _choose_ to give an interpretation to the WinBoard commands that is different from what they actually do in any existing WinBoard, including WinBoard_F, and that only that interpretation is in conflict with the FIDE rules. The problem is entirely fabricated by you.

The protocol definition is clear enough. It explicitly states that you should not use a RESULT claim in cases were the claim might be denied, e.g. in the case of accepting a draw that is offered to you. (As it might be retracted.) Hence there is no command "1/2-1/2 { draw agreed }". It explicitly state that you should use "offer draw" to accept a draw that was offerred to you. And accepting a draw is just as much different from offering one as claiming a draw is. But the protocol does not define a command "accept draw", so it explicitly overloads the "offer draw" command. This is all hard fact, nothing of it is interpretation of mine.

Personally, as I have said _many_ times, I would prefer xboard to make all game-ending decisions internally, and just accepd resignations, draw offers/acceptances, and draw claims from the program and handle them appropriately.

Well, your wishes could all be fulfilled, as this is the reality of WinBoard_F. Except that you are too pig-headed to profit from it.

A resignation should end the game and nobody would expect the program to play on, although it could if the GUI is told to ignore resignations. Crafty will gladly keep playing although it tries to be polite and resign when appropriate.

I don't really see what would be gained by having the GUI interfere with this. If you don't want your engine to resign, you can instruct it so directly.

A draw offer should simply be forwarded to the other engine. A draw acceptance should end the game immediately so long as the offer was properly made, relayed to the engine, and then the engine accepted it properly according to FIDE rules. Otherwise the game should continue.

All done.

Mates should be verified (and even detected) by the GUI without any need for prompting by the engine, and the game should end immediately.

All done.

That's the right way to make this work. Get rid of the result stuff since it makes no sense anyway for an engine to be able to end a game on its own. And then just relay offers and evaluate claims for correctness, and accept them or ignore them as you wish. But do not end a game based on a bad draw claim, the rules do not allow it.

If you don't like waiting, don't play matches. I automate them so I don't care if a game runs longer than normal while an engine's time burns away until the flag falls.

Are you competing for the most-silly-remark-of-the-day awards? If people don't want to wait, they forfeit engines that make them wait, of course, or use GUIs that do it for them... Not everyone is an idiot, and putting up with things they don't need to put up with.

[hgm]

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...

[Graham Banks]

Whilst you all have useful points to make, attacking the character of those who disagree shouldn't really be necessary.

Regards, Graham.

[Uri Blass]

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...

If you do not know that you have the right to claim a draw then offering a draw make sense and there are engines that do not know that they have the right to claim a draw.

Following the fide rules is a problem because in this case you will need to add accept draw command so I do not support it in engine-engine games but if we want to support it in the interface the best solution is that engines that want to follow the fide rules are going to send some comments to the interface about it and if an engine support accept draw
it should tell it to the interface when it starts.

Most engines do not support the fide rules(I believe most engines are not going to continue after the interface does not accept their draw claim and send them a move)
so the assumptions for engines should be that the engine does not support fide rules unless it said something different in the beginning.

Uri

[bob]

Can you please explain how a GUI is to determine whether a draw claim is legitimate without knowing the move the engine would draw with ?
Should the GUI assume some random legal move for engine ?

Matthias.

I have already given two alternatives.

1. Send the move, then send the draw claim. The GUI can certainly figure out that even if the opponent makes a move after receiving the move just played, that the draw claim should be enforced, and do so.

2. the move and draw offer/claim can be combined into one string if desired.

ICC handles this with absolutely no problems.

Basic idea:

move Re1+
draw

and if the position is a 3-fold or 50 move draw, the draw is enforced. How hard is that???

Your first answer is exactly what I said I agree with, so your example is 100% correct.
I think our lengthy arguments are solely about some engines and FIDE who feel the move preceding the claim may be skipped.

In ChessGUI, the philosophy is simply: at the moment a draw claim comes in, the GUI has to have received all moves necessary to determine whether to terminate game or not.
A claim that is not preceeded by a move is ignored and if the drawing engine then prematurely terminates, it forfeits.
I will not read FIDE rules about drawing. They were not formulated to cover engine-engine matches with GUI as arbiter.


Matthias.

Actually, when you think about it, the FIDE rules are _perfectly_ suited to enforcement electronically, because an arbiter is the final authority for all such things except when the players agree, say for draw offer and accept. But for claims of finality, the arbiter makes the decision, not the player, although generally if both agree the game ends...

[bob]

Very funny to read this.

As reading a little back shows that it was actually me who proposed these two ways. (Having the GUI judge the claim both before and after the last move of the opponent, or placing claim and move in a single line, namely in the result string and the comment field.) And that Bob is still fighting them as hard as he can when he addresses me. But when speaking to others, it is now suddenly his idea... ?

There are big differences. You said "a draw can be refused by the GUI." 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.

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.

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...

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.

Now that isn't so hard to understand, is 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. 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...

[bob]

That's just your interpretation, for whatever reason you choose to make that your interpretation. It absolutely does not say "the game can not proceed". It never has.

Well, and that is just your interpretation. I cannot be held responsible for the fact that the protocol definition is not explicit enough for you. But when various interpretations are possible, it escapes me why you would insist on using one that causes problems and makes life hard for everyone involved. In the end, it apparently boils down to the fact that the way WinBoard_F handles the draw claims is not at odds with the FIDE rules per se, but that you _choose_ to give an interpretation to the WinBoard commands that is different from what they actually do in any existing WinBoard, including WinBoard_F, and that only that interpretation is in conflict with the FIDE rules. The problem is entirely fabricated by you.

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.

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

The protocol definition is clear enough. It explicitly states that you should not use a RESULT claim in cases were the claim might be denied,

It does _not_ say that. Although I happen to believe that is how the result _should_ be used, but there is absolutely nothing in the protocol definition that explicitly or implicitly makes that statement correct. I have argued that the result option ought to be completely removed, but _only_ when we have an arbiter that is 100% reliable in doing this for us. e.g. in the case of accepting a draw that is offered to you. (As it might be retracted.) Hence there is no command "1/2-1/2 { draw agreed }". It explicitly state that you should use "offer draw" to accept a draw that was offerred to you. And accepting a draw is just as much different from offering one as claiming a draw is. But the protocol does not define a command "accept draw", so it explicitly overloads the "offer draw" command. This is all hard fact, nothing of it is interpretation of mine.[/

Personally, as I have said _many_ times, I would prefer xboard to make all game-ending decisions internally, and just accep resignations, draw offers/acceptances, and draw claims from the program and handle them appropriately.
[/quote

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. 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?

]

Well, your wishes could all be fulfilled, as this is the reality of WinBoard_F. Except that you are too pig-headed to profit from it.

A resignation should end the game and nobody would expect the program to play on, although it could if the GUI is told to ignore resignations. Crafty will gladly keep playing although it tries to be polite and resign when appropriate.

I don't really see what would be gained by having the GUI interfere with this. If you don't want your engine to resign, you can instruct it so directly.

A draw offer should simply be forwarded to the other engine. A draw acceptance should end the game immediately so long as the offer was properly made, relayed to the engine, and then the engine accepted it properly according to FIDE rules. Otherwise the game should continue.

All done.

Mates should be verified (and even detected) by the GUI without any need for prompting by the engine, and the game should end immediately.

All done.

That's the right way to make this work. Get rid of the result stuff since it makes no sense anyway for an engine to be able to end a game on its own. And then just relay offers and evaluate claims for correctness, and accept them or ignore them as you wish. But do not end a game based on a bad draw claim, the rules do not allow it.

If you don't like waiting, don't play matches. I automate them so I don't care if a game runs longer than normal while an engine's time burns away until the flag falls.

Are you competing for the most-silly-remark-of-the-day awards? If people don't want to wait, they forfeit engines that make them wait, of course, or use GUIs that do it for them... Not everyone is an idiot, and putting up with things they don't need to put up with.

And not everyone is an idiot that is making up rules as they go along and forcing everyone to abide by them. A mistaken draw claim should not end the game. 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...