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

[hgm]

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.

Well, I would not consider that "refusing a draw". Just "correcting the score on the result sheet". It does not really refer to draws, but also to win claims (non-existing checkmates or false illegal move claims). So I assumed you were talking about refusing the draw _offer_ (through "offer draw"), which is what we were discussing at the time. If this turns out to be all a miscommunication (caused by your alledged "quoting" not really matching any part of what you now actually say it refers to...), I apologize.

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

So we all have to bear our crossess. I personally find it very difficult to discuss with someone that always misrepresents my ideas, and answers like I had written the exact opposite of what I did actually write...

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.

You fail to make distinction between a draw claim made through a RESULT command, and a draw claim made by "offer draw". What you quote here was referring to the treatment of RESULT claims. They have to be treated that way, as these RESULT claims finish the game, and the only question remaining is what to put on the score sheet.

Due to the overloading the "offer draw" command, using it for both "offer draw" and "claim draw", false claims simply cannot occur, let alone be refused or result in forfeit. In situations where a claim would be without basis, it would be understood by the GUI as a genuine offer, which is always allowed, and always passed on to the opponent. (Unless the opponent had already submitted a draw offer himself, in which case it will be understood as "accept draw", and be granted by the GUI.)

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

Who said you could ask for things? You think I am Santa Claus?

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.

This was already explained above. A forfeit is not possible on an overloaded "offer draw", as disambiguating the overloading exactly remove all combinations of conditions where a claim or offer would be without bases or pointless.

The forfeit only occurs when a game end is forced by the refusal to play on, (expressed in the RESULT command), without basis. Problems like you are imagining here could only occur if separate commands "offer draw" and "claim draw" were created. Basically that would only open the possibility to create irregular situations, raising the problem how to handle them, and add no new opportunities. For this reason alone it is a very bad idea to have separate commands. It is just unfortunate that the overloaded command is called "offer draw", in stead of "request draw".

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.

Yes, and 100,000 years ago the just stuck spears into each other in stead of sitting behind a board pushing wood. Why would you think this is relevant? Protocols can change, but only the protocol that is in force now is relevant, and refusal to abide by it will result in forfeit, even if the same action would not have resulted in forfeit in other or earlier protocols.

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.

A program can _always_ end a game instantly. It does not even have to send somthing to the GUI for it. Just executing "exit(0);" does the trick. How would you have the GUI prevent that?

So deprecating the RESULT command does not really serve any purpose. In fact there is a lot to be said for allowing the program a way to bail out of the game while specifying a reason.

It can make a claim, but the game continues until the GUI says it doesn't.
You can already make such a claim through the "offer draw" command (for draws), and the only basis for a win claim would be a checkmate or an illegal move, both of which the GUI wil already have recognized before the engine could send the claim. To claim a loss, you could send "resign".

What would be the purpose of adding commands whose only purpose is to be ignored in cases where they would not do what existing commands already do? I don't see what a second claim command could add, except confusion...

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

All that can already be done with existing commands. I see little benefit in encouraging or facilitating false claims. Tho err might be Human, but it is not machine-like. Engines can easily be made to do their claiming perfectly, and anything encouriging lazy or sloppy programming (e.g. by just claiming "1-0 { checkmate }" on every move, so you don't actually have to test for checkmate in your engine" I would consider a large step backwards.

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.

WRONG EXAMPLE. WinBoard 4.3.13, handling the protocol I described, does consider the claim valid.

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?

Before the move it would be passed on to the opponent immediately, as a draw condition would not be detected by the GUI to be present. Now why do you see that as a problem? The opponent either takes the draw before you send your move, saving you the trouble to make one (the GUI would declare "result 1/2-1/2" before you got the chance, with the result you wanted to claim), or the opponent would not react to it, or reacted too late, and you would make your move first. The GUI would then spot the draw condition, and declare draw. In all cases the result would be draw.

Now a real example. I am still waiting.

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

So you ask for protocol changes. Well, they are not mine to grant. I can only implement the existing protocol definition. Ask someone else.

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

I don't know where you got the idea that only what you want would be important. In fact I could not care less. You are not even a WinBoard user. I built in features for which there is popular demand, using existing protocol wherever possible. Write your own GUI, and make it as compatible with WinBoard as you can, for all I care. And experience how popular that will make your engine.

[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

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

The result command should have the meaning that the game ends now if the engine is not ready to play after sending the result command.

I suggest that winboard will have a list of engines that are ready to continue and for them it is not going to mean that the game ends now.

Crafty can be in the list of engines that are ready to continue.
I believe that Movei is going to refuse to continue as winboard engine
but not as uci engine but I am unsure if movei is always going to refuse to continue as winboard engine.

I believe that cases when movei makes a wrong claim never happens and if I am wrong I prefer to have a loss and not to continue the game and not know about the bug.

Uri

[hgm]

I don't see any advantage in allowing any engine to go on after it has declared that the "game is definitely over". If the engine might want to continue, it should simply not send the RESULT message. Why burden a GUI programmer to make it possible for engine programmers to violate protocol? Just stick to the protocol.

WB protocol does not _oblige_ engines to sent a RESULT claim at any time. If they don't think the "game is definitely over", they should not send it. If they do want the option to continue, they should not think "the game is definitely over".

If you want a draw or play on if you can't get it, use "offer draw".
If you want to win or play on if you can't, play on until you recieve a result message from the GUI. (No need to send anything, as this is the default assumption.)
If you want to lose, or play on if you can't, use "resign".

[Uri Blass]

I don't see any advantage in allowing any engine to go on after it has declared that the "game is definitely over". If the engine might want to continue, it should simply not send the RESULT message. Why burden a GUI programmer to make it possible for engine programmers to violate protocol? Just stick to the protocol.

WB protocol does not _oblige_ engines to sent a RESULT claim at any time. If they don't think the "game is definitely over", they should not send it. If they do want the option to continue, they should not think "the game is definitely over".

If you want a draw or play on if you can't get it, use "offer draw".
If you want to win or play on if you can't, play on until you recieve a result message from the GUI. (No need to send anything, as this is the default assumption.)
If you want to lose, or play on if you can't, use "resign".

There is no problem for me but I do not think that engine that is able to continue after claiming a draw is breaking the protocol.
From the protocol:
"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."

Engine that does not continue after sending the result{comment} does not break the protocol but the same for an engine that continues.

Knowing a list of engines that continue after making draw claims can help to have more engines.

Note that I do not understand the complain of Bob Hyatt about it because the new situation is certainly an improvement relative to the earlier situation.

Claiming a loss by the gui for engine that claims draw with no justification is better than deciding that the game is a draw only because of the fact that one engine claimed a draw.

The option to continue the game after claiming a draw never happened with the old winboard protocol.

giving the engine the option to decide if to continue the game or not
in case of claiming a draw based on some string that the engine sends in the beginning of the game or based on some known list of engines is even better but the situation that you suggest is clearly better than what we had earlier.

Uri

[bob]

Well, if you think this is acceptable, and if I already said this is what I will implement to accomodate that vast majority of engines that do not claim draws in a safe way, (i.e. by preceeding the move with a draw _offer_), why are you insisting that it should also be considered valid if the engine sends the draw claim _before_ the move, when there was no repeat or 50-moves yet???????????

Are you arguing against everything other write just out of habit?

How about discussing something like a professional, rather than like a jerk? roll your eyes all you want. laugh out loud all you want. But at least act professionally some of the time...

The problem is this: In some circumstances, you can claim a draw without making a move. In other circumstances, you have to make a move prior to claiming the draw. It all depends on the game situation.

Clear so far?

Now we have the problem of defining when a move is completed. In FIDE rules, when you stop the clock, your move is considered complete. Which means you can make the move, make the claim, or make the claim without making a move, and there is no ambiguity.

In winboard/xboard, this is not as simple, because we don't have a command we can send to indicate that our move is "completed". Our move is completed when we send the move to the GUI. And that leaves a hole in the protocol. What if I don't want to make a move, or don't need to make a move, because I have a valid draw claim right now? All the other circumstances already covered also apply.

I worked with ICC to come up with something that would work, without instantly invalidating all existing chess engines and prior versions of xboard/winboard and other interfaces (lokasoft, etc) that rely on the existing way things work. The solution we ended up with was the most logical way to maintain compatibility, while addressing the timing hole previously mentioned.

For the N+1th time, if you send the move first, then the draw claim, there is a significant window of opportunity for the engine to send the move, the GUI gets the move and sends it to the other engine, and that engine responds with a move of its own, before the GUI ever sees the draw claim. how to solve that? You can slightly modify the usual moves of chess, and say that if a valid draw claim follows a move, even if the opponent has already made a move in response, That's somewhat messy if you allow take-backs and other things that real GUIs handle... Ideally the GUI behaves like a "stateless entity" rather than having to remember context surrounding each move, so that draw offers can be handled much later

That's why I would prefer two different things to offer a draw vs to claim a draw. But the currently overloaded draw mechanism can work. So long as the GUI doesn't invent new rules that violate traditional chess rules...

If you don't understand how the 50-move and repetition rules work precisely, then reading is in order. But you have to properly handle the case where the draw claim is valid _before_ making a move, as well as the case where the draw claim is valid _after_ making a move. Both cases are common enough to require correct handling.

Now if this sounds like "arguing against everything others write out of habit", then you really need some help...

[bob]

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.

Well, I would not consider that "refusing a draw". Just "correcting the score on the result sheet".

So now we play semantical games? "if the claim has no basis, treat it as a resign" is pretty unambiguous, IMHO. And is in direct violations of existing tournament chess rules. That is, and has been, my point. That's what you wrote. I'm not going to try to look at every word you write, and enumerate every possible meaning for each one, and then semantically tie all that together to see how many possible different interpretations might exist. I took it to mean _exactly_ what it said, that if my engine mistakenly claims a draw, you are going to terminate the game as a loss. That's no good.

It does not really refer to draws, but also to win claims (non-existing checkmates or false illegal move claims). So I assumed you were talking about refusing the draw _offer_ (through "offer draw"), which is what we were discussing at the time. If this turns out to be all a miscommunication (caused by your alledged "quoting" not really matching any part of what you now actually say it refers to...), I apologize.

Claiming a win does _not_ result in a loss. I can point you to one classic example where Cray Blitz played in a tournament with humans. It was the first game on the first quad-cpu cray with the first dynamic-resplitting parallel search, and I had a bug. Program said "My move is BxP mate". My opponent replied "My move is NxB out of mate" and the game continued as it should. Mistaken claims do _not_ cause you to lose a game. At least in real tournaments...

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

So we all have to bear our crossess. I personally find it very difficult to discuss with someone that always misrepresents my ideas, and answers like I had written the exact opposite of what I did actually write...

And I did this above? Even after precisely quoting you to show that I did not misrepresent anything???

Think about what you are saying from time to time... I didn't put _any_ words in your mouth. Yet you claimed that I wanted illegal moves to not result in a loss. I agreed with Uri, but I never mentioned the issue until he did, yet suddenly it was something I wanted... And that isn't misrepresentation, when I supply direct quotes that somehow are???

jeez...

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.

You fail to make distinction between a draw claim made through a RESULT command, and a draw claim made by "offer draw". What you quote here was referring to the treatment of RESULT claims. They have to be treated that way, as these RESULT claims finish the game, and the only question remaining is what to put on the score sheet.

I don't see any difference, as I have already stated. I'd be happy if you ignored the result completely, it is a bad idea. But if you want to recognize it and respond to it, fine, but don't forfeit an engine that uses it improperly. Given the choice of ending a game on a bad claim, or ignoring the claim completely, I would go with the latter. The GUI becomes less intrusive and lets the engines play the game.

Due to the overloading the "offer draw" command, using it for both "offer draw" and "claim draw", false claims simply cannot occur, let alone be refused or result in forfeit. In situations where a claim would be without basis, it would be understood by the GUI as a genuine offer, which is always allowed, and always passed on to the opponent. (Unless the opponent had already submitted a draw offer himself, in which case it will be understood as "accept draw", and be granted by the GUI.)

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

Who said you could ask for things? You think I am Santa Claus?

Fine. Let's just end this here. If you don't want to deal with requests from someone that has been doing this longer than any other active chess programmer, stick your head in the sand, or up any body orifice you prefer. I won't make any more suggestions. I will continue to support the protocols as they exist, and do my best to ensure my engine will not run under modified protocol versions that are too intrusive.

I have much more important things to work on that to have these pointless discussions. Particularly if you are the type that makes up your mind, and that's the end of the matter. I understand the concept of standards, of compatibility, and of complying with well-known and long-standing rules. Once you figure that out, you might offer something worth discussing. You may have the last word...

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.

This was already explained above. A forfeit is not possible on an overloaded "offer draw", as disambiguating the overloading exactly remove all combinations of conditions where a claim or offer would be without bases or pointless.

The forfeit only occurs when a game end is forced by the refusal to play on, (expressed in the RESULT command), without basis. Problems like you are imagining here could only occur if separate commands "offer draw" and "claim draw" were created. Basically that would only open the possibility to create irregular situations, raising the problem how to handle them, and add no new opportunities. For this reason alone it is a very bad idea to have separate commands. It is just unfortunate that the overloaded command is called "offer draw", in stead of "request draw".

You keep saying that, but that is not the way the winboard engine interface command is defined. It does not say that once the result command is sent, the engine officially refuses to play any further.

I agree that offer draw vs claim draw is the optimal solution. There's absolutely nothing wrong with defining winboard protocol version 3, and doing that. It can continue to limp along on the current protocol, and engines that begin to support the new version can do it the better way. That's why winboard supports protocol version 1 and 2 today. Adding 3 would be the best overall solution... And it wouldn't wreck existing programs, and allow future migration to doing it the right way...

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.

Yes, and 100,000 years ago the just stuck spears into each other in stead of sitting behind a board pushing wood. Why would you think this is relevant? Protocols can change, but only the protocol that is in force now is relevant, and refusal to abide by it will result in forfeit, even if the same action would not have resulted in forfeit in other or earlier protocols.

Do you realize that protocol version 1 is still used? Try gnuchess 4, which many people still use. So forget the 100K years ago crap, grow up, and grasp the big picture. That is why there are two versions, old for compatibility, new to fix some issues the old one had. That's why there are version numbers in RPC programming. That's why there are 3 versions of NFS APIs running around, so that the old still works, while new applications migrate to the new and better version.

Not everything has to be thrown out when a new idea comes along. The old can be kept for compatibility to avoid wrecking thousands of versions of chess engines that only talk protocol version 1...

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.

A program can _always_ end a game instantly. It does not even have to send somthing to the GUI for it. Just executing "exit(0);" does the trick. How would you have the GUI prevent that?

So deprecating the RESULT command does not really serve any purpose. In fact there is a lot to be said for allowing the program a way to bail out of the game while specifying a reason.

Not IMHO. If the reason can be bogus, what's the point? If the GUI validates the reason, and ends the game if it is correct, or ignores it if it is not, that would be useful.

It can make a claim, but the game continues until the GUI says it doesn't.
You can already make such a claim through the "offer draw" command (for draws), and the only basis for a win claim would be a checkmate or an illegal move, both of which the GUI wil already have recognized before the engine could send the claim. To claim a loss, you could send "resign".

What would be the purpose of adding commands whose only purpose is to be ignored in cases where they would not do what existing commands already do? I don't see what a second claim command could add, except confusion...

Because the two circumstances are different. Claiming a draw is far different from offering a draw. In real chess, I have to have an arbiter if I claim a draw, while my opponent and I can agree, shake hands, and end the game as a draw whenever we want. Or one of us can resign, and the arbiter can't make us play on. Or one of us can make an incorrect claim of mate, stalemate or draw, and the arbiter can say "play on, the claim is invalid" or "play on, your score sheet is incomplete so I can't verify the claim", etc... the two cases are just different...

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

All that can already be done with existing commands. I see little benefit in encouraging or facilitating false claims. Tho err might be Human, but it is not machine-like. Engines can easily be made to do their claiming perfectly, and anything encouriging lazy or sloppy programming (e.g. by just claiming "1-0 { checkmate }" on every move, so you don't actually have to test for checkmate in your engine" I would consider a large step backwards.

Pure hyperbole. Who would _actually_ do that?

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.

WRONG EXAMPLE. WinBoard 4.3.13, handling the protocol I described, does consider the claim valid.

OK so I can make a move, let my opponent make a move, then say "oh shit, I didn't see that, I offer a draw"??? That's the other side of the "hole" if the claim/move is not atomic..

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?

Before the move it would be passed on to the opponent immediately, as a draw condition would not be detected by the GUI to be present. Now why do you see that as a problem? The opponent either takes the draw before you send your move, saving you the trouble to make one (the GUI would declare "result 1/2-1/2" before you got the chance, with the result you wanted to claim), or the opponent would not react to it, or reacted too late, and you would make your move first. The GUI would then spot the draw condition, and declare draw. In all cases the result would be draw.

Now a real example. I am still waiting.

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

So you ask for protocol changes. Well, they are not mine to grant. I can only implement the existing protocol definition. Ask someone else.

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

I don't know where you got the idea that only what you want would be important. In fact I could not care less. You are not even a WinBoard user. I built in features for which there is popular demand, using existing protocol wherever possible. Write your own GUI, and make it as compatible with WinBoard as you can, for all I care. And experience how popular that will make your engine.

I really don't care how popular my engine is. I suspect most people will tell you it is one of the only engines that simply does not misbehave when playing with winboard. this based on _millions_ of games, not a few hundred. I believe I have shown that I know what I am doing, quite clearly... Crafty just doesn't break winboard and ruin matches.

[GothicChessInventor]

This brings up an interesting question regarding the "insufficeint losing chances rule".

In the absence of a digital clock, when in a sudden death time control, a player can summon a T.D. and request a draw due to insufficient losing chances.

Is there a programming equivalent that must be adhered to if tablebases are present at the side "down" in material is in a drawn tablebase position?

I think a program down a pawn in a 5-piece draw should be able to declare the draw and not have to lose on time.

[hgm]

To prevent out-of-order posting, I am not able to further react in this thread until my comments addressing the points made earlier are put back. Sorry about that.

[pedrox]

The GUI should not automatically without proof submit the command result and stop the game when he receives a command result of one of the engines. This is a failure of the GUI and I think we should all agree.

DanaSah ignores the command result sent by the GUI, therefore continue the game if she think this is not complete, but with this I am not safe because the GUI may send also a command new.

If DanaSah think that there is a game finish with mate, stalmate or draw by repetition, insufficient material or rule 50 moves then sends the result to the GUI and stop the engine. As I stop the engine I assume if the result is not correct I miss the game. The ideal here is that the GUI could reset the 2 engines, sent by the command edit or setboard the earlier position that it was correct and that the game continued with a penalty of time for the engine that had made the incorrect claim. (On one occasion I claimed draw in a tournament time active 30 minutes finish, the arbitrer said you no reason and I had 2-minute penalty).

If there is a problem in claim draw after sending a move to GUI because the GUI gives the turn to another engine, then why not extend the protocol to version 3?, Protover 3, that version would be consistent with the earlier, and would include the command stop_clock. The protocol xboard was prepared to take further improvements.

This would not affect any engines made to date, they continue playing with protover 1 or 2 and ensure the new engines with protover 3 a claim correct.

[swami]

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

Bob, I think UCI is the popularly termed as "modern" and "future protocol" for chess engines, you may have noticed the fact that most of the new engines that were released since the last year all support UCI and that some of the engines that were released as UCI don't come with winboard support, some of them do but lately it's uci, uci and uci.

I wonder why you think it is a crappy standard?

Regards.