Resign annoyance

[bob]

I think the best approach is to simply kill both engines when a game ends, start them back up, and play the next game. This avoids a messy re-initialization that can introduce strange bugs, and solves the problem you mention.

That is how ChessGUI works, even in a 2-engine match or testsuite.
No engine gets "reused".

Matthias.

Best possible solution, IMHO.

all the bizarre race conditions go away the way you are doing it, which eliminates some incorrect results.

[henkf]

I don't understand how resigning a game can be annoying for anybody, except for the one who resigns. Also resigning can not be forced in the game of chess, so it is a courtesy. The Fide rules of chess allow to resign at any moment during a game and why shouldn't they.

I used to have an engine that resigned ( before I took it out ), but only after it made a move. Maybe without apparent logic, but it fitted the design of my program. To comply with the solution for your little annoyance, I probably would have send the move anyway and have waited until I received a move from the opponent ( and maybe have waited just another move, just to annoy you some more ) before sending the resignation. I don't see why this would be less annoying.

It is also rather strange that people that say that engines have to obey the Fide rules of chess, because otherwise it could not be called chess, agree with your solution here.

[Tony]

Similar to the problem of non-atomic draw claims, there is a timing issue in loss claims (= resigning) too. Most engine do this in a very annoying way, still sending a move before they resign:

move Kh1
0-1 {white resigns}

But this causes the move to be relayed to the opponent (as the GUI cannot afford to wait an indeterminate time after every move to see if it happens to be followed by a resignation). So when the resignation comes in, the opponent is already thinking. Many engines do not allow their thinking to be interrupted, and for engines that do not support 'ping' there is not even a way to probe when they are done thinking. This cause big problems in matches, as the GUI does not know when it is safe to start a new game. The superfluous move can fall in the next game, be mistaken for a true move, and lead to illegal moves later. Even when you are not playing in match mode, but restart the GUI with new engine processes, or just start new engine processes, the other engine might still hang some time, using CPU, as the killing process in Windows is not always reliable.

I think engines should resign before giving their move. (i.e. not give the move at all.) What is the point of giving a move when you resign? Apparently you failed low and no move was worth playing to continue the game.

So just like with draw offers, also here holds:
only resign in your own time!

I think I should make WinBoard hold up resignations that are handed in when the opponent's clock is running until after that opponent produced his move.

(Note that this is different from claiming checkmtes: after

move Qg2#
0-1 {white is checkmated}

the opponent wil not start thinking on a move after receiving Qg2, as he will (presumably) see that he is checkmated too.)

The more I think about it the more I like the idea of a new command "stop clock" or "press clock" or something similar to indicate that we are through with our move. Making a move and then resigning is not incorrect. Many games end like this, which can be verified by looking at PGN collections. In fact, I am not sure it is not allowable to resign on my opponent's time. I watched an IM make a move, hit the clock, and after about a minute's thought, he tipped his king over and resigned, while his opponent was thinking, after he realized he had just made a horrible blunder.

...

It could be as simple as ending the line with a ;
In that case the GUI should wait with sending.
Anything else is a "press clock"

Enabling it with a feature command might not even be nescessairy. Though it might be safer, because the programmer is aware to not end normal ( ending) lines with a ;

Tony

[hgm]

I don't think that such protocol extensions would be of any help:

1) None of the exsting engines would be using it
2) We have to continue to support the old way of non-atomic sending to keep these engines wrking
3) New engines that are not aware of the problem, the can and will continue to use the old way, as using the new way requires extra commands, and extra handshakng to ensure that you are working on an interface that supports these commands.
4) new engines that are aware of the problem could have solved it in a much simpler way within the existing protocol by not sending the move, or sending it after resigning.

In summary: it is very easy to design protocols that do not have these problems, when they would be strictly enforced. But then by definition they would not offer the required backward compatibility. "Optional enforcement" is an oxymoron. It is completely pointless. It is like solving the crime problem by inviting would-be criminals to report to he police station to apply for a tracker ankle bracelet.

[wgarvin]

I don't think that such protocol extensions would be of any help:

1) None of the exsting engines would be using it
2) We have to continue to support the old way of non-atomic sending to keep these engines wrking
3) New engines that are not aware of the problem, the can and will continue to use the old way, as using the new way requires extra commands, and extra handshakng to ensure that you are working on an interface that supports these commands.
4) new engines that are aware of the problem could have solved it in a much simpler way within the existing protocol by not sending the move, or sending it after resigning.

In summary: it is very easy to design protocols that do not have these problems, when they would be strictly enforced. But then by definition they would not offer the required backward compatibility. "Optional enforcement" is an oxymoron. It is completely pointless. It is like solving the crime problem by inviting would-be criminals to report to he police station to apply for a tracker ankle bracelet.

There are enough problems with the winboard/xboard protocol (such as the race conditions, time controls, legacy commands with quirky behaviour, the complexity of dealing with both SAN and algebraic moves, etc), that I almost think it would be better to design a new protocol from scratch. Take all the good elements from both winboard/xboard protocol and UCI protocol, and make them as clear, simple, and unambiguous as possible. The protocol would be designed only for Engine-to-Engine, Engine-to-GUI or Engine-to-automated-TD type of scenarios. Specifically, it would NOT be designed for direct use by humans.

I think the first step would be to rigorously specify the new protocol, and write a standard adapter between this new protocol and the winboard/xboard protocol (and possibly UCI as well). The adapter could be open-source code so that engine and GUI authors can consult it as a reference.

New engines and new GUIs would then have a consistent, sensible protocol they could be written to use. They would not have to handle the race conditions and other crap (assuming the adapter could successfully hide it all from them; which I hope is possible but I'm not 100% convinced yet). Existing engines could either add support for the new protocol (if they already support multiple protocols) or they could just rely on the adapter.

There would be no direct backward compatibility with winboard/xboard in the new protocol, but it might end up having some "convenience" features to make it easier to port engines and GUIs to it. I think it would be important to minimize the number of features it has though.

Ideally, neither the engines nor the GUIs would have to maintain a complex amount of "protocol state" in order to communicate successfully. I vaguely recall that Winboard contains a bunch of backward compatibility hacks for certain old engines, etc. which require it to know how to support every protocol flavor that exists, some of which require it to remember detailed things about what the engine has already sent to it in order to correctly interpret the new stuff. (This may not be true anymore, I don't know.) Anyway, the new protocol should try to minimize or completely eliminate the need for that sort of stuff.

[Edit: it might be useful to consider other board games when designing the protocol. I.e. What would need to be changed, to make it also support checkers? Or chinese chess? Other than the details of what constitutes an appropriate argument for "setboard" or "move" or "time control", and when certain things like "claim draw" are allowed... there might be more similarity than difference.]

[bob]

Similar to the problem of non-atomic draw claims, there is a timing issue in loss claims (= resigning) too. Most engine do this in a very annoying way, still sending a move before they resign:

move Kh1
0-1 {white resigns}

But this causes the move to be relayed to the opponent (as the GUI cannot afford to wait an indeterminate time after every move to see if it happens to be followed by a resignation). So when the resignation comes in, the opponent is already thinking. Many engines do not allow their thinking to be interrupted, and for engines that do not support 'ping' there is not even a way to probe when they are done thinking. This cause big problems in matches, as the GUI does not know when it is safe to start a new game. The superfluous move can fall in the next game, be mistaken for a true move, and lead to illegal moves later. Even when you are not playing in match mode, but restart the GUI with new engine processes, or just start new engine processes, the other engine might still hang some time, using CPU, as the killing process in Windows is not always reliable.

I think engines should resign before giving their move. (i.e. not give the move at all.) What is the point of giving a move when you resign? Apparently you failed low and no move was worth playing to continue the game.

So just like with draw offers, also here holds:
only resign in your own time!

I think I should make WinBoard hold up resignations that are handed in when the opponent's clock is running until after that opponent produced his move.

(Note that this is different from claiming checkmtes: after

move Qg2#
0-1 {white is checkmated}

the opponent wil not start thinking on a move after receiving Qg2, as he will (presumably) see that he is checkmated too.)

happens every day in human events. You make a move. Realize that it is a blunder. And you tip your king.

Much of this is due to the missing "stop my clock" command that FIDE uses to indicate when your move and any potential offers have been made/completed and you now want your opponent to decide what to do.