xboard protocol discussion - restart

[michiguel]

...
Not that the FIDE rules stipulate that a draw claim is automaticly also a draw offer. So even if a separate command claim draw existed, and it would be used by an engine in a position where claiming was not legal, the GUI would still have to treat is like it was offer draw.

No, it should be treated differently by FIDE rules in case that the claim was invalid. An "offer draw" as Xboard does it now is not the same as a claim because an invalid claim involves a time penalty.
see point 9.5b
http://www.fide.com/component/handbook/ ... ew=article

In other words, the GUI needs to know whether it is a claim or an offer. I admit that this may not be a huge point if we decide not to penalize engines who make wrong claims, but this is not how it is suppose to be. Let' not forget human-comp games!! Humans can make mistakes and penalties should not be left out of protocol if they want to be enforced.

You want to diversify the command just to create the possibility for the engine do do it wrong, so you can penalize it? (Isn't that called "entrapment"?) I think that is just bad protocol design. The fewer errors a protocol allows, the better.

For Human-comp games XBoard does not do any adjudication. I never felt there is any need for this. In the end the Human can do and think what he wants, and is in total control. When an engine makes a false claim, the Human can laugh, and think "wow, what a stupid engine, it does not even know when or what it can claim!" And then edit the saved PGN. It does not need XBords assistance or approval for that. So XBoard might as well go with the engine.

So if the opponent is a Human or an ICS, the GUI becomes completely pasive, and relays everything the engine says faithfully to the higher authority (the Human or ICS).

This may not work with old xboards (or other old GUIs) because a race condition. As I said before, the engine wants to know that. Otherwise, it risks being forfeited by the GUI. An approach I always thought was to actually claim 3 rep ONLY when the position occurred after the opponents move. 99.9% of the time it should be ok, I need to know when I am facing old vs. new winboard!! that is why I think you could easily implement

feature atomic_offers=1
and send back accepted atomic_offers
so the engine knows whether draw offer is atomic or not. Old winboard will not send accepted.

It would work on all XBoards, because the old ones (perhaps except 4.3.12) would always accept your claim in local mode, and there would be no race condition at all. I cannot speak for all GUIs, but I doubt if there exist GUIs on which the offer-move-claim sequence could ever give you problems. Except that if they did not solve the race condition, they might accept neither the offer or the claim (if they were programmed to ignore false claims).

The later seems unavoidable. What sequence of commands would you propose to use against a GUI that did not solve the race condition? (i.e. it does not interpret offer draw as a claim, and it only judges 1/2-1/2 claims against the curent position.) I don't think you could do anything that is guaranteed to work, or that has better chances of working than offer+move+claim. So you might as well stick to that universal solution.

Yes, there is another option as I mentioned before. I can claim draws with 1/2-1-2 only when it is my move. It is not perfect, but I do think I will miss a draw against computers (unless they have a really buggy 3-rep implementation). If I am in disadvantage and I was able to force 3 rep, I am sure I can wait and keep forcing it until the next time it is my move and the 3 reps are in the board. Also, if I know that the GUI declares all draws when they see a 3-rep, why would I risk losing the game for a race condition sending 1/2-1/2?

The only place where this approach may not work is with 50 move rule, when in the ply 101 there is a winning (Capture or mate) move. But I think I can fix this easily.

You are afraid the claim could be ignored, and you want to play on to avoid losing on time. You can still do that, but you can still lose then, and your rightful draw claim would have been stolen from you. The tester now would not notice that you were wronged, while when you had lost on time because Gaviota suddenly stopped moving, he might have taken a second look and correct the GUIs result. People using such GUIs are accustomed to using LGPGNVER to correct the GUI game results.

In short, I think it is bad strategy to try to make problems of buggy GUIs the problem of your engine. Take a firm stance, and do tngs the right way. Don't let oher peoples bug drag you down to their level. If buggy GUIs forfeit you, it is their problem. File a protest, and laugh about how stupid they are.

Really? That is what I did with SAN moves. Arena sends wrong SAN moves (Rb4 rather than Rb4+), and ChessGUI sends wrong SAN moves too. Both are not winboard compliant. That screws the strict SAN implementation of Gaviota and GUI writers are not willing to change their behavior (it is just easier/faster to ignore the checks). You suggested to fix Gaviota and make it more flexible to(accept non-standard behavior, which contradicts your suggestion above. Anyway, I did somehow followed your suggestion, I dropped SAN support as a default

Miguel

I am not going to make new protocol, just to make it easier for others to violate existing protocol. That is totally counter-productive.