xboard 4.3.15 draw bug

[hgm]

If you ever want to play in a human event, you have to be FIDE compliant. Cray Blitz and now Crafty have played in dozens of human events, and you have to get the draw offer, draw claim, draw acceptance, etc right.

Sorry, this is simply nonsense.

If you play in a Human event on ICC, you have to obey ICC server rules. If these deviate from FIDE rules, you can jump high or low, but the server will not budge.

[sje]

For the record, here is the SECOND and final repetition draw from the game:
[D] 7Q/4k3/4n3/6p1/6P1/r6P/8/6K1 w - - 65 149

Code: Select all

2009.05.24 01:16:07.398 FEN: 7Q/4k3/4n3/6p1/6P1/r6P/8/6K1 w - - 65 149
2009.05.24 01:16:09.395 FEN: 7Q/4k3/4n3/6p1/6P1/r6P/8/6K1 w - - 73 153
2009.05.24 01:16:10.210 FEN: 7Q/4k3/4n3/6p1/6P1/r6P/8/6K1 w - - 77 155

[bob]

If you ever want to play in a human event, you have to be FIDE compliant. Cray Blitz and now Crafty have played in dozens of human events, and you have to get the draw offer, draw claim, draw acceptance, etc right.

Sorry, this is simply nonsense.

If you play in a Human event on ICC, you have to obey ICC server rules. If these deviate from FIDE rules, you can jump high or low, but the server will not budge.

So what. That is not what I call a "human tournament". I am talking about events where I attend in person, and enter Crafty as a player. I serve as the operator using blind player rules for the program. _those_ are the events I am talking about. I was playing on ICC before you knew how to spell it. I don't have any problems there that I am aware of. But for real human tournaments, FIDE rules are followed, and we have two _different_ mechanisms we have to use to offer/claim draws, depending on which venue we play in.

[hgm]

In operator-mediated events it is not of the slightest importance how the program claims a draw. The operator, opponent and referee never get to see anythingthat goes on between engine and GUI. Only wht the GUI displays.

You are just talking nonsense.

B.t.w. you must have lost an enormous number of games in such operator-mediated Human-engine events, using the old XBoard and sending 1/2-1/2 before giving the move that actually draws. As this XBoard would terminate the game immediately upon receipt of the RESULT command, and ignore the move, so the operator never gets to see it.

[bob]

In operator-mediated events it is not of the slightest importance how the program claims a draw. The operator, opponent and referee never get to see anythingthat goes on between engine and GUI. Only wht the GUI displays.

You are just talking nonsense.

B.t.w. you must have lost an enormous number of games in such operator-mediated Human-engine events, using the old XBoard and sending 1/2-1/2 before giving the move that actually draws. As this XBoard would terminate the game immediately upon receipt of the RESULT command, and ignore the move, so the operator never gets to see it.

You obviously do not play in human events. The operator has to do what the engine says. The operator is completely passive, according to the "blind chess player rules". The engine, therefore, needs to articulate claims in the FIDE-compliant (and correct) way.

It is not _I_ that am talking nonsense. I'm talking from experience.

[hgm]

Wrong. The operator hs to do what the _GUI_ says. He never gets to see what the _engine_ says.

[bob]

Wrong. The operator hs to do what the _GUI_ says. He never gets to see what the _engine_ says.

Wrong. I don't use a GUI when playing in human tournaments.

Never have. I have the "UI" of crafty specifically optimized for my entering moves and commands.

Try again.

[hgm]

So how is a GUI-engine communication protocol relevant if you are not using a GUI?

If you use things improperly, and don't get the desired results, the best solution would be to start using them properly. Not trying to change them to compensate for your own ineptness. If you insist eating soup with a screwdriver, you will stay hungry. You cannot expect screwdriver manifacturers (or soup manufacturers, for that matter) to change their product because of that...

[bob]

So how is a GUI-engine communication protocol relevant if you are not using a GUI?

If you use things improperly, and don't get the desired results, the best solution would be to start using them properly. Not trying to change them to compensate for your own ineptness. If you insist eating soup with a screwdriver, you will stay hungry. You cannot expect screwdriver manifacturers (or soup manufacturers, for that matter) to change their product because of that...

<sigh>

1. I play in human events where my program has to play according to the FIDE rules of chess. Including draw offers, claiming draws, etc. Got that part?

2. I play using a GUI on ICC. And there I have to conform to a slightly different set of rules that are not in agreement with FIDE with respect to offering draws, claiming draws, and such. Got that part also?

The problem, which i _did_ clearly explain earlier, is that I now have to do the same task in two different ways in my chess program. I have to claim/offer draws in a way that meets FIDE rules, _AND_ I have to offer draws (even when I want to claim a draw) in a different order that does not meet FIDE rules when I play with a GUI.

Now I do not believe that is so very difficult to understand. I quite clearly explained that having to do it two different ways is clumsy. And leads to the continual confusion caused by this "difference" as Steven's question clearly shows.

That's all there is to the argument. I have to do it two different ways to handle FIDE and xboard games. And I do. It would be better if I didn't have to do this. And that, ladies and gentlemen, was my one and _only_ point here. Why that is so hard to grasp is beyond me.

Anyone ought to be able to pick up a FIDE book, write an engine that plays exactly by those rules, and then have a very simple task of translating from their normal output to match what xboard wants. For example, sending "move Ne3" rather than sending something like "My move is Ne3". But it isn't currently that simple once you get to the draw stuff. You might have your program say "I claim a draw by the 50-move rule" without moving or "I claim a draw by the 50 move rule after I play Rh7" Try translating that to xboard. I either offer a draw and don't make a move, or I first offer a draw and then make a move, even though the draw claim is only valid after my move, and I am not even offering a draw in the first place, I am claiming a draw.

That's what is wrong with this mess. It does not exactly meet the "intuitive protocol" standard.

[hgm]

Well, just use a GUI always, and your problems will be solved. I don't consider it a useful goal to facilitate playing without a GUI.

It does make me wonder, though, why you were fighting my originally proposed solution to the race-condition problem, which did away with the need for "offer draw", and perfectly conformed to FIDE rules. But as they say, its no use crying over spilled milk.