Hello H.G.Muller : upgrading the protocol

[henkf]

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.

[hgm]

Correct, but notice we are _not_ talking about winboard at the moment. This is another interface that uses the winboard protocol and missed this important nuance of offering/claiming a draw before making the move. If someone does this just like xboard currently does, all is well. Otherwise there are issues and a race condition that is ugly.

Competely false.

ChessGUI follows the protocol specs faithfully, in exactly the same way as current XBoard does. Crafty would also forfeit these games on XBoard or Winboard, for committing this protocol violtion that you so long have exploited. Except that the message appearing in the PGN would be more to the point: it would not say 0-1 {resign} but it would say something like 0-1 {False draw claim by Crafty}.

It is just that there are more testers that use ChessGUI than that use XBoard or WnBoard that you get complaints about ChessGUI first.

I also don't understand your logic. The XBoard protocol specs say that you should not do what Crafty does. These are specs for XBoard, not for "another interface". On any interface, XBoard or other, that closely follows the specs, Crafty is broken. Only some old XBoard versions that implement the protocol in a very sloppy way, you happen to get away with it. In essence you are exploiting undocumented bugs in XBoard. You cannot expect other GUI writers to mimic XBoard's bugs. You cannot expect later versions of XBoard to have the same bugs. We are not going to elevate bugs to standards.

And in reponse to some of the remarks dircted at Henk: The protocol is completely independent from if you are playing an ICS or locally: first send offer draw to solve the race condition, then send your move to create the repetition (or 50-move draw), then terminate the game with 1/2-1/2 {3-fold repetition}. And if you want, you can play on then, but that is really moot, as there is no interface that should ever let you play on after this, if your draw claim was justified.

[Matthias Gemuh]

Correct, but notice we are _not_ talking about winboard at the moment. This is another interface that uses the winboard protocol and missed this important nuance of offering/claiming a draw before making the move. If someone does this just like xboard currently does, all is well. Otherwise there are issues and a race condition that is ugly.

Competely false.

ChessGUI follows the protocol specs faithfully, in exactly the same way as current XBoard does. Crafty would also forfeit these games on XBoard or Winboard, for committing this protocol violtion that you so long have exploited. Except that the message appearing in the PGN would be more to the point: it would not say 0-1 {resign} but it would say something like 0-1 {False draw claim by Crafty}.

Thanks, HGM, for emphasizing this
I was already thinking "1/2-1/2 {3-fold repetition}" is a legitimate way of offering a draw and that I had misunderstood the protocol.
I will undo the "bugfix" I introduced in latest ChessGUI and correct only the misleading "resign" comment by ChessGUI.

Matthias.

[krazyken]

But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.

[hgm]

The vast majority of engines mean it when they send a game-termination command. Allowing an engine that is already dead to 'continue' the game is thus just a waste of valuable CPU time. It is bad enough when engines crash during a game without any warning. But when they explicitly say that they will not continue the game, it is overall better to take them seriously.

If they afterwards complain that they were perfectly prepared to continue... Well, just their bad luck. Then they shoud not have tolde the GUI that they were done. Just like they should not resign when they are winning, and then complain that the 'resign' message was meant only to spur on the opponent to resign.

[Matthias Gemuh]

But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.

HGM has already answered you.

"1/2-1/2 {bla bla bla}" means "I herewith exit this game because it has ended as can be seen on the board".

If the board says the game is not over, GUI cannot just assume that the engine is still able to continue. At that almost all engines have quit the game.

Matthias.

[krazyken]

CPU time isn't more valuable than the time I spend correcting results. A forfeit on time is a valid result, losing due to false draw claim is not a valid result.

[Matthias Gemuh]

But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.

HGM has already answered you.

"1/2-1/2 {bla bla bla}" means "I herewith exit this game because it has ended as can be seen on the board".

If the board says the game is not over, GUI cannot just assume that the engine is still able to continue. At that almost all engines have quit the game.

Matthias.

"At that almost all" should be "At that point, almost all"

[bob]

Correct, but notice we are _not_ talking about winboard at the moment. This is another interface that uses the winboard protocol and missed this important nuance of offering/claiming a draw before making the move. If someone does this just like xboard currently does, all is well. Otherwise there are issues and a race condition that is ugly.

Competely false.

Complete and utter bullshit. If you re-read what I wrote, the "result" is no longer sent. I send "offer draw" followed by the move that would cause the 3-fold repetition. ChessGUI rejects the draw offer because it is not a draw. And it won't be a real draw until after the move is played.

The offer draw has to come first, and it does.

I have no idea what _you_ are talking about. I _know_ what I am talking about.

ChessGUI follows the protocol specs faithfully, in exactly the same way as current XBoard does. Crafty would also forfeit these games on XBoard or Winboard, for committing this protocol violtion that you so long have exploited.

And when you eventually wake up, read the discussion, you will notice that the "result" is not an issue here. It is not sent by Crafty any longer. Do you get that subtle point? "result" is no longer sent. This is about the issue of claiming a draw _before_ the move is played. If I claim the draw _after_ the move is played, ChessGUI is happy. Except for the race condition I have pointed out.

Except that the message appearing in the PGN would be more to the point: it would not say 0-1 {resign} but it would say something like 0-1 {False draw claim by Crafty}.

It is just that there are more testers that use ChessGUI than that use XBoard or WnBoard that you get complaints about ChessGUI first.

I have seen exactly _one_ complaint.

I also don't understand your logic. The XBoard protocol specs say that you should not do what Crafty does. These are specs for XBoard, not for "another interface". On any interface, XBoard or other, that closely follows the specs, Crafty is broken. Only some old XBoard versions that implement the protocol in a very sloppy way, you happen to get away with it. In essence you are exploiting undocumented bugs in XBoard. You cannot expect other GUI writers to mimic XBoard's bugs. You cannot expect later versions of XBoard to have the same bugs. We are not going to elevate bugs to standards.

Can we move on to the current version of crafty? We agreed that the old result claim was not the way to deal with this. It is no longer used. Can I repeat that enough?

And in reponse to some of the remarks dircted at Henk: The protocol is completely independent from if you are playing an ICS or locally: first send offer draw to solve the race condition, then send your move to create the repetition (or 50-move draw), then terminate the game with 1/2-1/2 {3-fold repetition}. And if you want, you can play on then, but that is really moot, as there is no interface that should ever let you play on after this, if your draw claim was justified.

Strong feeling of deja vu. That is _exactly_ what I am sending. He wanted the "offer draw" _AFTER_ the move that causes the repetition. Perhaps you will eventually pick up on that important point. And we can get back to the issue that is being discussed. Not something a year old that has long since been repaired, at least in Crafty.

[michiguel]

But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.

HGM has already answered you.

"1/2-1/2 {bla bla bla}" means "I herewith exit this game because it has ended as can be seen on the board".

Matthias.

That is why a command like

drawclaim move

would be FIDE compliant. "offer draw" would do what is necessary, at least partially (claim+offer a draw and if it is not a draw, game continues). However, an engine does not know whether is playing with a new xboard, or an old one (or a GUI that did not update the protocol behavior). For that reason, it needs to send 1/2-1/2 afterwards just in case. That is an redundancy that creates the risk of losing the game if the claim is invalid. That does not comply with FIDE rules.

That is the reason why I said that a feature new_behavior_for_offer_draw=1 is needed.
The engine needs to know what kind of xboard flavor is facing.

The engine needs a way to claim a draw in a way that if invalid, it will be allowed to continue. It do not see there is one. is it? The problem I see is that if I am facing an old win/xboard, my claim goes unnoticed, but if I send 1/2-1/2 afterwards just in case I face an old one, I risk losing for no reason.

Miguel