Hello H.G.Muller : upgrading the protocol

[wgarvin]

In an ideal world:

(1) Engines could atomically send a move and claim a draw in the position that results after that move.
(2) Engines could claim draws (when allowed) in a way which did not cause spurious draw offers to be relayed to the opponent (like the current "offer draw" / "move <whatever" idiom would seem to allow).
(3) GUIs which know all of the rules of the variant being played, could accurately adjudicate draw claims by the engines.
(4) GUIs which DON'T know all of the rules of the variant being played, could accept draw claims from either engine at face value and end the game.


One problem I can see with the "offer draw" / "move <whatever>" idiom, is that GUIs which don't understand the variant being played, may not be able to recognize that it's a claimed draw.

It would be nice if engines are able to assert that the game is supposed to be over (with "1/2 - 1/2" or similar) so that GUIs which don't understand the variant can simply end the game then. But if the GUI does understand the rules of the variant and is going to accurately adjudicate draw claims etc., then I'm not sure what it should do when it receives a draw claim that it thinks is incorrect.

Forfeiting the engine making the incorrect claim is kind of harsh (and might discourage engine authors from using the mechanism), but at least it ensures that the game is over. Engines might not be prepared to play on after making such an assertion.

[Matthias Gemuh]

It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."

That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.

OK, I admit that your proposal works for future engines.
It works for the existing engines only if GUI terminates 3-fold-rep/50-move games on first occurence (as ChessGUI does).
To fix the future and stay compatible with the past, the "claim before move" sequence would have to be activated by a "feature".
When activated for both engines, 3-fold-rep/50-move games can run till a claim come in.
When activated for only one or no engine, GUI should terminate 3-fold-rep/50-move games on first occurence.
For humans, the feature would be activated.

Matthias.

[hgm]

Are you aware that your GUI now is not winboard compliant nor FIDE?
Are you ok with that? If the answer is yes, when are you going to drop en passant support?
It is pretty annoying

Miguel

Castling will soon be dropped also. It too is pretty annoying.

Matthias.

I already did all that. Not only in WinBoard, ut even in my engine!

It is called Xiangqi.

[michiguel]

Just to highlight redundantly what all this talk is about:


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

Therefore no move is to be expected after "1-0" {...}", or "0-1 {...}", or "1/2-1/2 {...}".

Matthias.

And _that_ is a serious problem. I hope you can now see why. Because it can't possibly work like that due to the example I have given more than once now.

I see your point.
This problem only arises, if game is allowed to continue after a 3-fold-rep or 50-move.
Current ChessGUI escapes by terminating the game on first appearance of 3-fold-rep or 50-move rule.
I was about to just let ChessGUI flag any 3-fold-rep or 50-move rule as a pending draw and let game continue till a claim, but now I will stay with termination till we find a solution.

Simply sending a claim before the move would indeed solve the problem, but leave hundreds of existing engines hanging.

Matthias.

It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."

That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.

I didn't read the whole discussion, but in regards to this specific situation of "engine wants to claim a draw in the position that results after engine makes its move", would it work to send the following sequence?

Code: Select all

offer draw
move <whatever>
1/2 - 1/2  &#123; draw by 3-fold repetition &#125;

In other words, (1) you first "claim" the draw using the "offer draw" followed by the move you want to play. And then (2) assert that the game is definitely now over.

GUIs which recognize a "claim" in the form of "offer draw" followed by the move, will already have ended the game. GUIs which simply forward "offer draw" to the opponent without handling claims, will hopefully be dumb enough to just believe you when you assert that the game has ended in a draw.

Any GUI which fails to treat your "offer draw" as a claim after the move is sent, and then also fails to handle the asserted result correctly, would seem to be totally broken.

That could happened with old winboard. First is ignored, second is missed by a race condition. The engine needs to know what type of behavior is being used (new or old winboard), but nobody is reading my suggestion of including a feature so the engine will know (I posted it three times).

Miguel

[Matthias Gemuh]

I find it pointless to have the GUI know whether or not the game is a draw or not, and then even bother with the result from a program. If the GUI knows, why does it need the program to tell it something?

If the GUI doesn't know, then it must wait only for both engines to agree on a draw, right ?
In that case, the protocol would have to stop mentioning "on the board" in relation with pending draws.

Matthias.

[hgm]

It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."

That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.

OK, I admit that your proposal works for future engines.
It works for the existing engines only if GUI terminates 3-fold-rep/50-move games on first occurence (as ChessGUI does).
To fix the future and stay compatible with the past, the "claim before move" sequence would have to be activated by a "feature".
When activated for both engines, 3-fold-rep/50-move games can run till a claim come in.
When activated for only one or no engine, GUI should terminate 3-fold-rep/50-move games on first occurence.
For humans, the feature would be activated.

Matthias.

I considered the method Bob proposes unacceptable, because it requires you to wait for a move after a (false) claim, which might not be coming. And this is totally unnecessary: you could reverse the order, always make the claim after the move, and then test the validity of the claim both in the current position and the previous one, if the last move was the opponent's.

Note that I don't want to drop the RESULT command from the protocol, is just for the reason Wylie states: the protocol is also intended to work for variants that the GUI does not fully understands (3checks, bughouse, ...).

A second reason is that I want to have a protocol with a command that allows the engine to say: "I now walk out on this game". Unlike what Bob says, it is in perfect agreement with FIDE rules to forfeit a player that leaves the tournament premises. It is not just a matter of ving him lose on time, eventually: even if he returs before that, he still has forfeited.

In summary:

1) engines should use 1/2-1/2 to claim draws in positions where you have the move
2) engines should use offer draw before your move to claim draws that only materialize after your move
3) A GUI should, on detecting a draw condition in the current position, certainly terminate the game as draw if there are any pending draw offers.
4) Without pending offers, it should obey the user adjudication instructions, which might be to declare draw, or play on until an engine claims, or play on somwhat longer (e.g. to a 4th repetirion or a 51st move).
5) To prevent the race condition in local play with engines that do not use the safe claiming mechanism, judge RESULT claims of the stm both in the current position and in the one before it.

[hgm]

That could happened with old winboard. First is ignored, second is missed by a race condition. The engine needs to know what type of behavior is being used (new or old winboard), but nobody is reading my suggestion of including a feature so the engine will know (I posted it three times).

Not true: old WinBoard (4.2.7) accepts any claim, so if the race condition causes the claim to come in when there is no longer a draw on the board, it still declares a draw. (Or a win, if the engine happened to claim a win by 3-fold repetition, or a win by resigning, etc...)

The engine does not have to know which behavior to expect.

[Matthias Gemuh]

No, but it shows an incredibly poor design. One doesn't use "time" to try to synchronize two parallel events. It never works.

Please, clarify.
The events of one engine don't even know that a second engine exists.
What has that got to do with synchronizing ?
What is the better design for Windows ?

[bob]

My point in the previous discussion was that I can not tell whether I am playing another engine in a local match, or playing on ICS.

I think winboard sends the host command when playing on a chess server. And if I remember correctly it sends "-" as host when playing locally.

Never seen a "host" command, and I don't handle such and crafty would complain...

You are quite correct, it is the "ics" command, i just called the argument to this command "host" in my program. But my point was that you could know if playing on server or locally.

I am not seeing any "ics" command either. It is not in the winboard protocol specification I have.

you really force me to go all the way don't you?

from http://www.tim-mann.org/xboard/engine-intf.html

ics HOSTNAME
If HOSTNAME is "-", the engine is playing against a local opponent; otherwise, the engine is playing on an Internet Chess Server (ICS) with the given hostname. This command is new in protocol version 2 and is not sent unless the engine has enabled it with the "feature" command. Example: "ics freechess.org"

I have about a million log files from playing on ICC and I have _never_ seen that command sent to crafty. I just did a grep for "ics" in the log files and it is not present in a single one. Which simply means xboard is not sending it to crafty..

That's all I have said. I just looked and one has to enable that feature to get it which is probably why I don't see it. But it is a moot point in my opinion. The point is that a protocol is a _standard_ that you follow all the time. Not one that you modify for playing online or when playing locally, or anything else. I really don't care how I (Crafty) am playing. I accept the same commands whether playing online or not, although some commands will not normally be sent (rating, name, etc). But I make no distinction, and don't want to make a distinction. That only makes for more code and more bugs.

I just responded to your original point that you could not see if playing on an ics or locally. You could if you wanted to, just send a feature ics=1 to xboard and from then on you will see a lot of ics strings in your log files. If you want to change your original statement to that you don't care whether you are playing on an ics or locally or can't see it because you didn't implement the protocol or even call your point moot, that's fine by me.

That misses the point. How would you like a TCP/IP protocol that behaves differently whether you run on a real ethernet connection, a gigabit connection, a DSL connection, or even a PPP connection via a modem? What good is a protocol if you have to know which version of the protocol you are dealing with by querying to see what is on the other end? TCP/IP would not be in use today if it had this kind of horrible weakness.

The xboard protocol should simply work for any case. The protocol should be consistent, logical, and it should be up to the GUI to do anything needed to deal with issues outside the protocol. If ICC wants to handle draw offers differently than they do now, that's a gui issue, not an xboard protocol issue. I want a protocol to be explicit and logical, with no kludges necessary on my end to work around dumbness in the protocol itself as we currently are discussing.

[bob]

Just to highlight redundantly what all this talk is about:


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

Therefore no move is to be expected after "1-0" {...}", or "0-1 {...}", or "1/2-1/2 {...}".

Matthias.

And _that_ is a serious problem. I hope you can now see why. Because it can't possibly work like that due to the example I have given more than once now.

I see your point.
This problem only arises, if game is allowed to continue after a 3-fold-rep or 50-move.
Current ChessGUI escapes by terminating the game on first appearance of 3-fold-rep or 50-move rule.
I was about to just let ChessGUI flag any 3-fold-rep or 50-move rule as a pending draw and let game continue till a claim, but now I will stay with termination till we find a solution.

Simply sending a claim before the move would indeed solve the problem, but leave hundreds of existing engines hanging.

Matthias.

It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."

That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.

I didn't read the whole discussion, but in regards to this specific situation of "engine wants to claim a draw in the position that results after engine makes its move", would it work to send the following sequence?

Code: Select all

offer draw
move <whatever>
1/2 - 1/2  &#123; draw by 3-fold repetition &#125;

In other words, (1) you first "claim" the draw using the "offer draw" followed by the move you want to play. And then (2) assert that the game is definitely now over.

GUIs which recognize a "claim" in the form of "offer draw" followed by the move, will already have ended the game. GUIs which simply forward "offer draw" to the opponent without handling claims, will hopefully be dumb enough to just believe you when you assert that the game has ended in a draw.

Any GUI which fails to treat your "offer draw" as a claim after the move is sent, and then also fails to handle the asserted result correctly, would seem to be totally broken.

That could happened with old winboard. First is ignored, second is missed by a race condition. The engine needs to know what type of behavior is being used (new or old winboard), but nobody is reading my suggestion of including a feature so the engine will know (I posted it three times).

Miguel

And you can keep on posting it as long as you like. But we can't get past the "the current protocol works somewhat, even if it is based on an illogical kludge that continues to cause issues." This is an example of the difference between a C programmer and a C++ programmer. Overloading operators is quite normal in C++, where in C it is impossible.

I like the Clarity of C in knowing that a function does the same thing every time, I don't want to have to look at the number and types of arguments to figure out which piece of code is going to be used.