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.bob wrote: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..henkf wrote:you really force me to go all the way don't you?bob wrote:I am not seeing any "ics" command either. It is not in the winboard protocol specification I have.henkf wrote: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.bob wrote:Never seen a "host" command, and I don't handle such and crafty would complain...henkf wrote: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.
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.
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"
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.
Hello H.G.Muller : upgrading the protocol
Moderators: hgm, Rebel, chrisw
Re: Hello H.G.Muller : upgrading the protocol
-
- Posts: 27796
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Hello H.G.Muller : upgrading the protocol
Competely false.bob wrote: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.
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.
-
- Posts: 3245
- Joined: Thu Mar 09, 2006 9:10 am
Re: Hello H.G.Muller : upgrading the protocol
hgm wrote:Competely false.bob wrote: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.
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.
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
http://www.chess.hylogic.de
Re: Hello H.G.Muller : upgrading the protocol
But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.
-
- Posts: 27796
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Hello H.G.Muller : upgrading the protocol
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.
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.
-
- Posts: 3245
- Joined: Thu Mar 09, 2006 9:10 am
Re: Hello H.G.Muller : upgrading the protocol
HGM has already answered you.krazyken wrote:But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.
"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.
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
http://www.chess.hylogic.de
Re: Hello H.G.Muller : upgrading the protocol
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.
-
- Posts: 3245
- Joined: Thu Mar 09, 2006 9:10 am
Re: Hello H.G.Muller : upgrading the protocol
"At that almost all" should be "At that point, almost all"Matthias Gemuh wrote:HGM has already answered you.krazyken wrote:But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.
"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.
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
http://www.chess.hylogic.de
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Hello H.G.Muller : upgrading the protocol
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.hgm wrote:Competely false.bob wrote: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.
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.
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.
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.
I have seen exactly _one_ complaint.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.
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?
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.
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.
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.
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: Hello H.G.Muller : upgrading the protocol
That is why a command likeMatthias Gemuh wrote:HGM has already answered you.krazyken wrote:But that just makes no sense, why change the rules? A false draw claim should be ignored and the game should continue.
"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.
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