Note you can set it to 0 in XBoard to turn 50-move adjudication off completely.MikeB wrote:The above output from xboard three 50 move rule settings to be turned off, the one in Stockfish, the polyglot adapter ( requires a modified version of ployglot, pm me if anyone would like the source) and finally set the GUI xBoard setting to draw after 999 moves ( or something sufficiently high enough- I think 600 would do it).
First of all, when you would use UCI2WB instead of Polyglot as UCI adapter (as the WinBoard-AA package does), the adapter would not interfere with anything, including draw claiming.It is ridiculous today that it require three switches in three places - but xBoard and polyglot were originally written when the 50 move rule was almost always enforced and many engines were not coded to follow the 50 move rule, Crafty and a few others being the exceptions. So the GUI and polyglot programmers took it upon themselves to enforce the 50 move rule as a convenience for the users (that is conjecture on my part).
Your recount of history is not entirely accurate. In WB protocol the responsibility for claiming 50-move draws lies with the engine (in accordance to FIDE rules). UCI is defective in this respect, as it does not specify how to claim draws at all. (A work-around is possible, by playing a null move ("bestmove 0000") in combination with a 0 score, but this is not generally used.) So for Polyglot to make a UCI engine work as WB engine, it had to perform this functionality on behalf of the engine.
At that point XBoard did not even count reversible plies, it purely relied on engine claiming. (And I remember that for participating in the prestigious WBEC competition, supporting such claiming was mandatory!) As this was inconvenient for some tournaments with a less restrictive admission policy (such as ChessWar), I made XBoard more rule aware, including the 50-move rule, to make it possible to adjudicate games that otherwise would drag on forever (like KBNKR) when the engines did not support claiming, and to intercept false claims.
The number of moves after which such an adjudication would take place was made configurable, and by default set to 51, to allow testing of the engine claim logic. (The number of repeats before adjudication by default was set to 6, rather than 3 for that same reason.) This should be seen as support of the FIDE 70-move rule, where a referee (XBoard being that referee) can declare a draw even against the wishes of the players.
The problem is that there is no standard option for affecting an engine's 50-move behavior, neither in WB nor in UCI. If there was, the GUI could use a 'draw count' setting common to all engines, and enforced automatically on any engine supporting this option. Like hash size is automatically set on all engines. This would then be distinct from the value set in the adjudications dialog, which is really the setting for the 70-move rule. So that the user still keeps the option to adjudicate only after the engine has had an opportunity to claim.
Now there also is the problem that not all variants have the same rule for reversible-move draws and repetition draws. In Team-Mate Chess, for instance, a draw can be claimed only after 64 reversible moves, and in Crazyhouse there is no such rule at all (as all moves are reversible there). And in Shogi only the 4th repeat can be claimed. So it would actually be necessary for the engine to tell the GUI what move count it should enforce, in response to selection of the variant, in cases where the rules of the variant are unknown to the GUI. This argues for a design where the first engine should enslave the GUI, rather than where the GUI, on user command, enslaves the engines. This could be achieved by having the GUI recognize engine output like
info string variant rules drawmoves 64
feature drawmoves=64
(where UCI2WB would translate the former into the latter) in response to variant selection (through the WB variant command or setting of the UCI_Variant option). And then adapt its own setting according to that.
. It is the longest cursed win with the KRRvKRP ending. As part of the syzygy tablebase creation process, the syzygy creation tool outputs the longest cursed win for each endgame set in a text file.