Repetition detection structure.

[bob]

Sorry, but that is wrong, once agan. If you offer a draw on ICC, and the game is drawn by any valid rule, the game ends immediately, and the opponent gets no say-so. This means repetition, 50-move draws will completely and instantly end the game. Otherwise the draw offer is sent to the opponent.

Since this is _exactly_ what I say, I wonder what exactly is wrong. But it must be something pretty bad, at your end...

Sorry. I simply mis-read your multiple negations.

Always been this way. You just send "draw" (not offer draw) to the server, and if it is a legit draw, the game ends right then. Otherwise the draw command is sent to the opponent which effectively offers him the opportunity to accept the draw and still end the game...

Why you try to mix up WinBoard protocol with ICS communication now is also a mystery. Seems to me I could not have stated more explicitly what command to use in which protocol.

Simple. the winboard protocol was designed explicitly as an interface to ICC. You did know that, right???

[bob]

Could it just be made to work like this?

(1) If you send "offer draw" to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(2) If you send "offer draw" to the GUI in a situation where you CAN'T legally claim a draw, it is forwarded to the opponent who can then respond to it in the usual way.

(3) If you send a RESULT of draw to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(4) If you send a RESULT of draw to the GUI in a situation where you CAN'T legally claim a draw, you have made an erroneous draw claim, *and* your engine is refusing to continue the game, so you forfeit.


Sending of RESULT strings seems kind of bogus anyway (it should be the GUI's job to recognize the end of the game and report it to both players?) but since its in the protocol, and since most engines can't continue sensibly after they send it, it makes sense to me for engines to forfeit if they send an incorrect RESULT string. Maybe its the moral equivalent of, claiming the draw and then standing up and walking away from the board and not coming back. Engines should prefer not to send RESULT strings anyway, and just use "offer draw" both to claim draws when that is legal, and to offer a draw to the opponent in other situations.

Have I missed anything important?

No. This is why I have suggested eliminating the "result" string completely since I do not believe it reasonable for an engine to have absolute power to terminate a game, and inform the GUI of the result. If someone wants, they can badly bias a match by sending result strings that credit them with a win.

The GUI should be the _only_ entity that terminates the game, and it ought to use the FIDE rules in doing so so that any program can play legal FIDE (human vs computer) or computer vs computer games without requiring any differences for the two game types...

[bob]

You didn't miss anything, and this is indeed exactly how it works in WinBoard 4.3.13 (already available for month for download under the name alpha.tst from my website, but still undergoing regular bugfixes to make it ready for release). Problem is that Bob takes perpetual offense to that...

Think it would be possible to correctly attribute what I have been saying, rather than what you think I said or imagined that I said or wanted me to say?

I have said (a) the result command should be removed because engines should not be able to terminate an engine-vs-engine match any more than a single player can terminate a real chess game other than to resign himself and walk away. (b) we ought to have two different draw mechanisms... one to offer draws, one to claim a draw. Offers simply get forwarded to to the opponent untouched/unedited. The other tells the GUI that the engine is claiming a draw (whether or not the type of claim is included (repetition, insufficient material, 50 moves, stalemate, etc) is up to you. But if the GUI disagrees, the game does not end.

I have never said more, or less, than what I just wrote above. Consistently...

The official description of WinBoard protocol supports your interpretation: The RESULT command should only be used "when the game is definitely over", i.e. when the engine under no circumstances is prepared to continue the game. For situations where you unexpectedly might have to continue the game (such as accepting draw offers, as they might be retracted by the time you accept them), the protocol specifies that "offer draw" should be used, not RESULT.

The RESULT command is a legacy from the time where the GUI was merely a dumb graphical display program meant for communication between a Human user and an all-knowing engine. But I should stress that this situation still exists in many Chess variants. WinBoard can be used as a GUI for many games for which it doesn't even know how the pieces move (with legality checking turned off, obviously). In such variants it has to trust the engines to inform it about the game end.

I could also add that WinBoard 4.3.13 delays passing draw offers to the opponent until it is also ready to pass the move of the draw offerer. This way it can also check if a draw condition is fulfilled after the move of the offerer (and then declare the draw without consulting the opponent). This is also good for not disturbing the pondering process: you will only get input from the GUI when your turn started anyway (draw offer + times + move).

To give engines that claim draws that exist after their own move through the RESULT command, without being tricked by the opponent sneaking in a fast move between this move and the draw claim, no forfeits will be declared if the draw condition existed before the opponent's move, but not after it.

[bob]

Why you can't grasp this stuff is beyond me...

Not surprising, as you made it pretty obvious that about anything we are discussing here is beyond you. But unfortunately there is no way to say it any simpler than this:

If you send a signal or perform an action that is defined to mean resignation, you will lose the game instantly.

If you think that is in violation of FIDE rules.. Well, then think again! It might help eventually. And now stop wasting our time, please...

Unfortunately for your argument, I have _never_ said that have I? Please feel free to quote any text written by me that suggests that I believe the "resign" command violates FIDE rules. And that is the only command that does end a game without any GUI/TD/Arbiter intervention. The ICGA has a slightly different take that requires that the TD approve resignations to prevent collusion between multiple players in a tournament to "pick a winner" by illicit means. But that is an exception based on a well-known issue with commercial chess programmers years ago...

By the same token, your intent to make an incorrect draw claim end the game clearly is in violation of FIDE rules, and that is the point I have been trying to make. If a program claims a draw, and the GUI doesn't believe the game is drawn, then the game continues...

And again, don't get side-tracked on the result command, because I have already suggested, many times, that it should be removed completely.

[Uri Blass]

Could it just be made to work like this?

(1) If you send "offer draw" to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(2) If you send "offer draw" to the GUI in a situation where you CAN'T legally claim a draw, it is forwarded to the opponent who can then respond to it in the usual way.

(3) If you send a RESULT of draw to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(4) If you send a RESULT of draw to the GUI in a situation where you CAN'T legally claim a draw, you have made an erroneous draw claim, *and* your engine is refusing to continue the game, so you forfeit.


Sending of RESULT strings seems kind of bogus anyway (it should be the GUI's job to recognize the end of the game and report it to both players?) but since its in the protocol, and since most engines can't continue sensibly after they send it, it makes sense to me for engines to forfeit if they send an incorrect RESULT string. Maybe its the moral equivalent of, claiming the draw and then standing up and walking away from the board and not coming back. Engines should prefer not to send RESULT strings anyway, and just use "offer draw" both to claim draws when that is legal, and to offer a draw to the opponent in other situations.

Have I missed anything important?

No. This is why I have suggested eliminating the "result" string completely since I do not believe it reasonable for an engine to have absolute power to terminate a game, and inform the GUI of the result. If someone wants, they can badly bias a match by sending result strings that credit them with a win.

The GUI should be the _only_ entity that terminates the game, and it ought to use the FIDE rules in doing so so that any program can play legal FIDE (human vs computer) or computer vs computer games without requiring any differences for the two game types...

The result string is about terminating the game.
The meaning of the result command is that the engine claim result and refuse to continue(it does not contradict the fide rules because it can also happen in human-human games and if a player claim a draw and refuse to continue in case that the claim is not accepted then the player is going to lose the game).

A good interface should decide if to accept the claim of the engine or to decide that the result is different .

If you want a command to allow engines to claim draw without terminating the game(as done by the fide rules) then you need a different command because it is not logical to change the meaning of existing interface commands.

Today offer draw is command with that meaning but it is not consistent with the fide rules because based on the fide rules offering a draw when you can claim a draw does not finish the game if the opponent does not accept the draw.

Uri

[Uri Blass]

Why you can't grasp this stuff is beyond me...

Not surprising, as you made it pretty obvious that about anything we are discussing here is beyond you. But unfortunately there is no way to say it any simpler than this:

If you send a signal or perform an action that is defined to mean resignation, you will lose the game instantly.

If you think that is in violation of FIDE rules.. Well, then think again! It might help eventually. And now stop wasting our time, please...

Unfortunately for your argument, I have _never_ said that have I? Please feel free to quote any text written by me that suggests that I believe the "resign" command violates FIDE rules. And that is the only command that does end a game without any GUI/TD/Arbiter intervention. The ICGA has a slightly different take that requires that the TD approve resignations to prevent collusion between multiple players in a tournament to "pick a winner" by illicit means. But that is an exception based on a well-known issue with commercial chess programmers years ago...

By the same token, your intent to make an incorrect draw claim end the game clearly is in violation of FIDE rules, and that is the point I have been trying to make. If a program claims a draw, and the GUI doesn't believe the game is drawn, then the game continues...

And again, don't get side-tracked on the result command, because I have already suggested, many times, that it should be removed completely.

The point of H.G Muller is that the winboard interface rules are that claiming a draw by the result command is equivalent to resigning the game if the claim is not correct.

sending the result command means that the engine claim for specific result and does not continue.

"does not continue" means resigning if the claim has no basis.
You can claim that it was a bad idea to have that command but this is the way the winboard protocol works and if you want to change things then the only way is to add different command with different meaning.

Uri

[hgm]

Simple. the winboard protocol was designed explicitly as an interface to ICC. You did know that, right???

From intimately knowing both protocols, this seems about as likely as that English was designed explicitly as a way to communicate with Dolphins. (You did know that, right??? )

It is also not what the WinBoard documentation says: according to that WinBoard protocol originated from the text-based user interface of GNU Chess. But hey, this was only written by the people that made WinBoard, so why would I believe them???

You might have meant to say instead that _WinBoard_ was developed as an interface for ICC. WinBoard _protocol_, however, is not even used in that task! It is exclusively used for communication between WinBoard and engines.

No. This is why I have suggested eliminating the "result" string completely since I do not believe it reasonable for an engine to have absolute power to terminate a game, and inform the GUI of the result. If someone wants, they can badly bias a match by sending result strings that credit them with a win.

The GUI should be the _only_ entity that terminates the game, and it ought to use the FIDE rules in doing so so that any program can play legal FIDE (human vs computer) or computer vs computer games without requiring any differences for the two game types...

This is all nonsense, and has been discussed ad nauseam before. A command for the engine, to inform the GUI that it will not generate any future output, is a very useful time saver. That the engine can give a suggestion for the game result with this command, and an explanation, is also very useful. Because the GUI will not always be aware of the rules of the game, and thus might not have a clue why the game is ended. (FIDE rules do not apply to variants twokings, 3checks, suicide, atomic, Shatranj, Xiangqi, Shogi... You did know that, right??? )

Unfortunately for your argument, I have _never_ said that have I? Please feel free to quote any text written by me that suggests that I believe the "resign" command violates FIDE rules.

WinBoard protocol defines the RESULT command as a possible way to resign. You did know that, right???

And that is the only command that does end a game without any GUI/TD/Arbiter intervention. The ICGA has a slightly different take that requires that the TD approve resignations to prevent collusion between multiple players in a tournament to "pick a winner" by illicit means. But that is an exception based on a well-known issue with commercial chess programmers years ago...

Hey, isn't that a violation of FIDE rules? FIDE rules say that you always can resign, don't they? You don't need permission from an arbiter. Or do you if you are sight impaired?

By the same token, your intent to make an incorrect draw claim end the game clearly is in violation of FIDE rules, and that is the point I have been trying to make. If a program claims a draw, and the GUI doesn't believe the game is drawn, then the game continues...

The game does _not_ continue, because the engine has terminated it. The RESULT command is defined to be the equivalent of stopping the clock and leaving the tournament room after informing the referee that you will not be coming back. Quote us the FIDE rules that say you can do that without forfeiting the game.

And again, don't get side-tracked on the result command, because I have already suggested, many times, that it should be removed completely.

Yes, and I could add the suggestion that it should rain less, and that the second law of thermodynamics needs to be abolished... All totally irrelevant, as we are not discussing how to design a protocol or how to improve the weather, just how the existing protocol is handled by the GUI.

[bob]

Could it just be made to work like this?

(1) If you send "offer draw" to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(2) If you send "offer draw" to the GUI in a situation where you CAN'T legally claim a draw, it is forwarded to the opponent who can then respond to it in the usual way.

(3) If you send a RESULT of draw to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(4) If you send a RESULT of draw to the GUI in a situation where you CAN'T legally claim a draw, you have made an erroneous draw claim, *and* your engine is refusing to continue the game, so you forfeit.


Sending of RESULT strings seems kind of bogus anyway (it should be the GUI's job to recognize the end of the game and report it to both players?) but since its in the protocol, and since most engines can't continue sensibly after they send it, it makes sense to me for engines to forfeit if they send an incorrect RESULT string. Maybe its the moral equivalent of, claiming the draw and then standing up and walking away from the board and not coming back. Engines should prefer not to send RESULT strings anyway, and just use "offer draw" both to claim draws when that is legal, and to offer a draw to the opponent in other situations.

Have I missed anything important?

No. This is why I have suggested eliminating the "result" string completely since I do not believe it reasonable for an engine to have absolute power to terminate a game, and inform the GUI of the result. If someone wants, they can badly bias a match by sending result strings that credit them with a win.

The GUI should be the _only_ entity that terminates the game, and it ought to use the FIDE rules in doing so so that any program can play legal FIDE (human vs computer) or computer vs computer games without requiring any differences for the two game types...

The result string is about terminating the game.

Not the intent. I was around when this was added, and the idea was that the engine could tell xboard when it thought the game was over. Crafty was the first to use it and I used it for my own local testing when I wanted to play the max number of games possible in a given period of time. But it was implemented as a general feature, and it has been abused because engines can trivially claim the wrong result and produce misleading results.

But there is nothing that says that "the game can't continue".

My point has been that (a) this ought to be removed, because in a real game, I don't get to declare my game as won. The TD can do so, or my opponent can do so by resigning. (b) if it isn't removed, then it ought to be sanity-checked by the GUI and if it fails the check, it should simply be ignored.

On ICC, the result string is ignored by xboard. I'd like to see it ignored completely, but then xboard/winboard has to be able to reliably detect the end of the game. If Crafty is stalemated, it is not going to be able to move, ever. And if the GUI doesn't realize this and waits on it to produce a move, it will incorrectly lose on time. So the GUI has to do it right. And it might as well do it in a way that matches the FIDE Laws of Chess as closely as possible to avoid requiring two sets of rules internal to a program...

But to again recap, the Result string does not say "I refuse to continue playing". It says "I believe this game has ended with the following result..." I send it in Crafty, and I am prepared to continue because if you are playing on ICC, it is ignored completely. And until ICC fixed the draw offer problem previously discussed (a timing issue) one had to be prepared to continue the game, because a draw claim could be ignored since it was sent _after_ your move and with network delays, your draw claim could arrive after your opponent has already made his move invalidating the claim. If you could not continue, you would lose on time. I doubt many programs that play on ICC could not continue after sending a result command...

The meaning of the result command is that the engine claim result and refuse to continue(it does not contradict the fide rules because it can also happen in human-human games and if a player claim a draw and refuse to continue in case that the claim is not accepted then the player is going to lose the game).

But how does he lose? He does not lose instantly. He will get a time forfeit. And again, there is nothing at all that says "Result: if the engine sends this command, it is notifying the GUI that it is refusing to play on." Again, if this were the case, there would have been massive problems on ICC until last year when the draw offer/claim code was fixed to eliminate a race condition that could result in your sending a result command and it being ignored and the game would continue. The "refuses to continue to play" has simply not been a part of the standard as implemented. If you want to see this, just log on to ICC and start a game and have your program send a "result 1-0 {white mates}" after every move and see what happens. The game will be played as if the result was never sent. So how can it be that the engine has refused to play, if xboard allows it to do so? Answer is that is not the interpretation of the result command we used when defining or using it.

A good interface should decide if to accept the claim of the engine or to decide that the result is different .

I agree 100% and have been saying this since the beginning.

If you want a command to allow engines to claim draw without terminating the game(as done by the fide rules) then you need a different command because it is not logical to change the meaning of existing interface commands.

(1) This still assumes that everyone uses the result command to say "I refuse to play on." I do not believe this to be the case, else on ICC and FICS we would have seen way too many games lost on time when an engine sent the result and was then forced to play on because of the draw race bug.

(2) I don't want a command from a program that terminates the game, other than "resign". A program should be able to resign and stop playing. But it should not be able to claim any other result, that should be the GUI's responsibility.

Today offer draw is command with that meaning but it is not consistent with the fide rules because based on the fide rules offering a draw when you can claim a draw does not finish the game if the opponent does not accept the draw.

Uri

"offer draw" simply tells the gui to send "draw" to the opponent. It is, as I have repeatedly mentioned, overloaded in the winboard protocol, and should be fixed.

To repeat.

result should be removed entirely.

"offer draw" and "claim draw" should be used to offer or claim a draw, respectively. "claim draw" should not imply "I won't continue so if you don't approve the claim, I resign..." It should simply mean "I claim a draw, if you (the arbiter) disagree, I will continue to play.

[bob]

Why you can't grasp this stuff is beyond me...

Not surprising, as you made it pretty obvious that about anything we are discussing here is beyond you. But unfortunately there is no way to say it any simpler than this:

If you send a signal or perform an action that is defined to mean resignation, you will lose the game instantly.

If you think that is in violation of FIDE rules.. Well, then think again! It might help eventually. And now stop wasting our time, please...

Unfortunately for your argument, I have _never_ said that have I? Please feel free to quote any text written by me that suggests that I believe the "resign" command violates FIDE rules. And that is the only command that does end a game without any GUI/TD/Arbiter intervention. The ICGA has a slightly different take that requires that the TD approve resignations to prevent collusion between multiple players in a tournament to "pick a winner" by illicit means. But that is an exception based on a well-known issue with commercial chess programmers years ago...

By the same token, your intent to make an incorrect draw claim end the game clearly is in violation of FIDE rules, and that is the point I have been trying to make. If a program claims a draw, and the GUI doesn't believe the game is drawn, then the game continues...

And again, don't get side-tracked on the result command, because I have already suggested, many times, that it should be removed completely.

The point of H.G Muller is that the winboard interface rules are that claiming a draw by the result command is equivalent to resigning the game if the claim is not correct.

And my claim is that this is an incorrect interpretatoin of this command. One more time, one can send a "result 1/2-1/2" when playing on ICC and it is 100% ignored by both winboard and xboard. And the game does _not_ end, the GUI does not assume the program will not continue playing. That is simply a wrong interpretation of the command.

"result" was added so that an engine could tell xboard when a game ended because xboard does not detect all such conditions. It was added because I requested it (I requested most of the current winboard/xboard protocol options, including rating, opponent's names, and the list goes on and on. But it does not imply that the game will not continue if the command is incorrect. Currently there is no "incorrect" result in a comp vs comp match, which I consider a huge problem because I have had test results biased by an opponent getting the 1-0 backward. But it certainly does not imply that the engine won't continue, else you could send a result when playing on ICC and you would lose on time since why would the GUI send you a move and wait for a reply if the result had that implicatoin?

sending the result command means that the engine claim for specific result and does not continue.

"does not continue" means resigning if the claim has no basis.
You can claim that it was a bad idea to have that command but this is the way the winboard protocol works and if you want to change things then the only way is to add different command with different meaning.

Uri

Here is the relevant section from the engine.intf document:
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:

0-1 {Black mates}
1-0 {White mates}
1/2-1/2 {Draw by repetition}
1/2-1/2 {Stalemate}

xboard relays the result to the user, the ICS, the other engine in Two Machines mode, and the PGN save file as required.

Now exactly where does it say that the game can't continue??? One might want to infer that from the above, but it is not how the command is actually implemented.

[bob]

Simple. the winboard protocol was designed explicitly as an interface to ICC. You did know that, right???

From intimately knowing both protocols, this seems about as likely as that English was designed explicitly as a way to communicate with Dolphins. (You did know that, right??? )

It is also not what the WinBoard documentation says: according to that WinBoard protocol originated from the text-based user interface of GNU Chess. But hey, this was only written by the people that made WinBoard, so why would I believe them???

You might have meant to say instead that _WinBoard_ was developed as an interface for ICC. WinBoard _protocol_, however, is not even used in that task! It is exclusively used for communication between WinBoard and engines.

No. This is why I have suggested eliminating the "result" string completely since I do not believe it reasonable for an engine to have absolute power to terminate a game, and inform the GUI of the result. If someone wants, they can badly bias a match by sending result strings that credit them with a win.

The GUI should be the _only_ entity that terminates the game, and it ought to use the FIDE rules in doing so so that any program can play legal FIDE (human vs computer) or computer vs computer games without requiring any differences for the two game types...

This is all nonsense, and has been discussed ad nauseam before. A command for the engine, to inform the GUI that it will not generate any future output, is a very useful time saver. That the engine can give a suggestion for the game result with this command, and an explanation, is also very useful. Because the GUI will not always be aware of the rules of the game, and thus might not have a clue why the game is ended. (FIDE rules do not apply to variants twokings, 3checks, suicide, atomic, Shatranj, Xiangqi, Shogi... You did know that, right??? )

And exactly who cares since xboard/winboard is about 8x8 chess _only_??? Winboard doesn't work very well for go either. Nor connect-4, checkers, monopoly, poker and such...

Unfortunately for your argument, I have _never_ said that have I? Please feel free to quote any text written by me that suggests that I believe the "resign" command violates FIDE rules.

WinBoard protocol defines the RESULT command as a possible way to resign. You did know that, right???

Yep. And once I resign I can not be expected to continue, nor would I. But if I claim a draw, it has been _absolutely_ expected that I might have to continue due to the old race bug that was well-known and which happened frequently in fast games. And nobody had a problem continuing after sending a result 1/2-1/2. You did know that, right?

And that is the only command that does end a game without any GUI/TD/Arbiter intervention. The ICGA has a slightly different take that requires that the TD approve resignations to prevent collusion between multiple players in a tournament to "pick a winner" by illicit means. But that is an exception based on a well-known issue with commercial chess programmers years ago...

Hey, isn't that a violation of FIDE rules? FIDE rules say that you always can resign, don't they? You don't need permission from an arbiter. Or do you if you are sight impaired?

OK, so you aren't stupid. You just want to argue over nothing. Let me explain using words of 2 syllables or less...

The FIDE rules are _explicitly_ followed with respect to how the game is played (oops, more than 2 syllables in explicitly, hope I did not lose you that early in this paragraph... oops, did it again...) Many of the fide rules have various exceptions, dealing primarily with the abilities of the opponent. No hands? You can have someone move the pieces. Can't see? You can use a braille board or have a helper. A computer, the piece is touched when the computer displays its move, not when the helper touches the wrong piece... The list goes on and on. But the basic principle behind each FIDE rule remains in place, adapted only as needed to fit the abilities of an opponent. ICGA rules with respect to resigning have always been as follows: (a) if a program resigns, the game ends. Exactly as FIDE says. (b) if the operator/author wants to resign on behalf of the program, _then_ the TD has to approve. In the case of FIDE, the operator is not allowed to offer draws or resign, only the program can (see FIDE web site for complete details). In the ICGA events, the program can do whatever it wants within the rules. But if the operator wants a voice in resigning or agreeing to a draw (if the program can not offer draws, resign, or accept draws by itself) then that is treated differently, and in most cases, the decision is to "play on"...

How is that confusing? Other than perhaps you have never played in such a real event...

By the same token, your intent to make an incorrect draw claim end the game clearly is in violation of FIDE rules, and that is the point I have been trying to make. If a program claims a draw, and the GUI doesn't believe the game is drawn, then the game continues...

The game does _not_ continue, because the engine has terminated it.

You can say this as often as you want, but it doesn't make it true. How can _I_ terminate the game by saying "I win" and get up and walk away? Doesn't happen. And the result command does not automatically end the game. I have already explained that it is ignored when playing on ICC already because ICC is the authority for ending games, except when one side chooses to resign, which does end the game immediately.

The RESULT command is defined to be the equivalent of stopping the clock and leaving the tournament room after informing the referee that you will not be coming back. Quote us the FIDE rules that say you can do that without forfeiting the game.

Not in my xboard documentation it doesn't say that... And it doesn't work like that. Just log on to ICC and send a "result" command during a game and see if it ends... and see if you can continue playing. It doesn't and you can.

And again, don't get side-tracked on the result command, because I have already suggested, many times, that it should be removed completely.

Yes, and I could add the suggestion that it should rain less, and that the second law of thermodynamics needs to be abolished... All totally irrelevant, as we are not discussing how to design a protocol or how to improve the weather, just how the existing protocol is handled by the GUI.

No we aren't, because you are claiming that the result command always ends the game because the program has notified the GUI that it will not play on. This is not the case. I have already given you a test scenario to prove it. yes, it ends the game in engine vs engine matches. I can be at -20 and claim a win. And that should be removed. But it doesn't end the game in cases involving ICC... It should not end the game ever.