Testers wanted for Winboard_F

[H.G.Muller]

I am nearly finished making all planned modifications to Winboard, but a lot of testing will have to be done to verify if everything works as intended. Fortunately this can all be done at very short time control. To bring about rare adjudication events, such as 50-move draws or KBKN end-games, it might be advisable to start from set-up positions. Testing should also be done with engines that do not claim properly (this can be partly circumvented by making the GUI claim early, e.g. a 30-move draw, or a 2-fold repetition).

I made modifications in the following areas:

1) Adjudication and claim verification
2) Fairy pieces and board sizes other than 8x8
3) Miscellaneous

Miscellaneous

/matchPause=10000
is an option to set the length of the pause between two games of a match. The value is in msec, default value is 10000 (I will present all newly implemented options with their default value as example). Be aware that some engines might not be stopped yet if you make the pause too small, but might still be puking output, which then will interfere with the next game. But the fixed value of 10 sec of the old Winboard seemed like overdoing it.

Time info in PGN
When you ask for the PV-info to be stored in the PGN (a Winboard_x option), it now also stores the time spent on the move with it.

Flag fell
In engine-engine games the messge "white/black/both" flag(s) fell" no longer appears in the window caption, but as an exclamation point behind the clock time. (To prevent the annoying overwriting of the normal header line).

Adjudications and Claim verification.

These functions are only present in engine-engine games, and only if legality-testing is switched on. (The latter will be typically switched off in games with bizarre rules, which the GUI doesn't know, and in that case the GUI can never have an opinion on the outcome of a game.)

Illegal-move forfeit
As soon as one of the engines plays an illegal move, it forfeits the game. This feature was already present, but it should be 100% reliable now, as it also takes e.p. and castling rights into account, rather than erring on the safe side.

Illegal-move claim
From the above, it follows that any illegal-move claims by an engine must be false, and will result in forfeiting the game. (In Winboard_x this message is ignored, causing the game or match to hang.)

Checkmate adjudication
As soon as one of the engines does a move that results in checkmate, the GUI declares the game won, without waiting for the engine to claim it.

Insufficient mating material
As soon as the material on the board has shrunk to KK, KNK or KBK, the game is declared draw.

/adjudicateLossThreshold=0
This option was already present in Winboard_x, (to declare a game lost for which both engines agree for 3 moves that the score is below the given threshold), but a non-zero value is now also used to enable the following adjudications. If you only want the latter, just make the threshold impossibly low (-40000 will usually do the trick).

Trivial draws
If we are 3 moves into a KQKQ, KRKR, KBKB KBKN or KNKN end-game, the game is adjudicated as draw.

/repeatsToDraw=6
When the specified number of repeats occurs, the game is adjudicated draw. Should keep track of e.p. and castling rights. This does not require legality-testing to be switched on. The engines retain the legal right to claim after a 3-fold repetition, though. If you set this parameter to 3 or less, they will never get the chance. Better not set it to 1 or less.

/ruleMoves=51
After the given number of full moves without capture or Pawn move, the game is adjudicated draw. Even without legality testing. The engines retain the legal right to claim after 50 moves.

/testClaims=FALSE
When enabled, this option verifies all result claims made by the engines, and overrules the claim if it is false (forfeiting the game for the claimer). An engine can still safely claim a win for its opponent on a nonsense reason, though; this is taken to be the equivalent of 'resign'. Draw claims (made before a draw adjudication) are checked against the 50-move, 3-fold-repetition or insufficient-material rules. Win claims are always considered false, as the GUI adjudicates checkmates (and stalemates) before any engine can claim them.

Fairy Chess support

/boardWidth=8
Sets the number of files on the board. The additional files are named i, j, k, l... in PGN, and should be indicated this way in communicating moves to and from the engine. Currently works upto 12. No guarantees on how the rest of the display (clocks, etc.) looks if you make this number < 8.

/boardHeight=8
Sets the number of ranks. Extra ranks are numbered 9, 10, 11... in PGN. A zero is taken to mean 10 in communication with the engine. This is so far totally untested, and unlikely to work for double-digit ranks. Displaying boards with upto 12 ranks seems to work, though.

/fontPieceToCharTable="......."
This paramater, controlling the mapping of font symbols to piece types, was already present in Winboard_x. The default is dependent on the font selected with the /renderPiecesWithFont option. It can now accept upto 22 pieces, but the length should always be even. The first half designates the white pieces, the second half the black, both in the order PNBRQKHACFM.
The last 5 are new pieces, that won't show up differently from NBRQK if you don't use font-based rendering. Missing pieces of the group HACFM are also copied from NBRQK, respectively.

fairy-FEN support
The letters HACFM can be used in FENs, and are passed on to the engine in FENs or in the edit menu. Alternatives for HACFM are LEWGD, respectively. Whichever of the alternatives you use first will from then on be the only one accepted for the particular display symbol, but the engine will still be informed if you are using A or E, for example. The chosen alternative will also be used in PGN. To make the difference also obvious to the user, one should give the /fontPieceToCharTable parameter a different value.
Double-digit skips are acceptable in FENs. 'x' is interpreted as a skip of 10.
Castling rights should no longer be ignored. (Doesn't work for FRC yet, though.)
The 50-move-plies field should also be meaningful now.

/variant="normal"
The variant names "capablanca", "gothic", "courier" and "fairy" are added (replacing "variant33" upto "variant36"). They affect the initial position. The "fairy" variant plays on 8x8 with HAC in stead f NBR on the Queen side, so that all back-rank pieces are (potentially) different. Make sure the selected board size matches the variant; this is not automatic.

ArchBishop and Chancellor
In variants "capablanca" and "gothic" the piece designators A and C are preselected (over E and W). The GUI knows about these pieces, so legality testing can be kept on when playing these games. The promotion pop-up box also allows you to select those pieces in the mentioned variants.
The GUI also knows about the deviating moves of Bishop, Queen and Pawn in Shatranj. (Untested yet).

[H.G.Muller]

Those who want to act as testers, send me a PM.

It would also be very helpful if people could point out engines with claim difficiencies they happen to know of, would post the name of these engines here.

[GothicChessInventor]

I have compiled a list of Winboard_F programs, and other dedicated engines, that currently play Gothic Chess on the 10x8 board.

That list is here (and is still incomplete):

http://www.gothicchess.com/Winboard_F.html

One program not yet on the list is "Variant Pulverizer" which scores a nice win over SMIRF recently:



That game can be replayed here:

http://www.gothicchess.com/javagames/db_masterfile/0000024/game.htm

[GothicChessInventor]

/ruleMoves=51
After the given number of full moves without capture or Pawn move, the game is adjudicated draw. Even without legality testing. The engines retain the legal right to claim after 50 moves.

The 50-Move Rule states that any irreversible move should reset the counter. This means castling should have the counter go to 0 also. From your description above, it sounds like castling would still have the counter increase. This should not be the case.

[Teemu Pudas]

/ruleMoves=51
After the given number of full moves without capture or Pawn move, the game is adjudicated draw. Even without legality testing. The engines retain the legal right to claim after 50 moves.

The 50-Move Rule states that any irreversible move should reset the counter. This means castling should have the counter go to 0 also. From your description above, it sounds like castling would still have the counter increase. This should not be the case.

From the FIDE Handbook, Article 5.1 e:

The game may be drawn if each player has made at least the last 50 consecutive moves without the movement of any pawn and without any capture. (See Article 9.3)

Besides, your rule would also reset the counter on all non-capturing moves in positions where the ep capture is possible. Why didn't you comment on that?

[H.G.Muller]

This is indeed theFIDE 50-move rule as I understood it. I can only speculate that the designers considered mere castling not enough progress towards a win to warrant an exception.

I don't know if this is different in Gothic Chess, I suppose this is for you to say...

[GothicChessInventor]

This is indeed theFIDE 50-move rule as I understood it. I can only speculate that the designers considered mere castling not enough progress towards a win to warrant an exception.

I don't know if this is different in Gothic Chess, I suppose this is for you to say...

There was a very famous game involving Karpov or Kasparov where one of them claimed a draw too early, I think for a 3-fold repetition. But, the draw claim was declined, and a time penalty was applied.

The reason: While the piece arrangements were the same in each position, in one of the positions castling was a legal move option, and in another this was not the case (perhaps a king move, then king back to previous square. Before the king move, castling is an option when allowed, after the king move back, and if the opponent repeats the move, it "looks" the same, but the position is different since the castle rights are different.)

A very small distinction, and one which was somehow in the rule then.

[Teemu Pudas]

There was a very famous game involving Karpov or Kasparov where one of them claimed a draw too early, I think for a 3-fold repetition. But, the draw claim was declined, and a time penalty was applied.

The reason: While the piece arrangements were the same in each position, in one of the positions castling was a legal move option, and in another this was not the case (perhaps a king move, then king back to previous square. Before the king move, castling is an option when allowed, after the king move back, and if the opponent repeats the move, it "looks" the same, but the position is different since the castle rights are different.)

A very small distinction, and one which was somehow in the rule then.

That continues to be the rule for 3-fold repetition.

Positions as in (a) and (b) are considered the same, if the same player has the move, pieces of the same kind and colour occupy the same squares, and the possible moves of all the pieces of both players are the same. Positions are not the same if a pawn that could have been captured en passant can no longer in this manner be captured or if the right to castle has been changed temporarily or permanently.

4k3/8/8/8/8/4q3/8/4K2R w K - 0 1
4k3/8/8/8/8/4q3/8/4K2R w - - 3 3

[Uri Blass]

This is indeed theFIDE 50-move rule as I understood it. I can only speculate that the designers considered mere castling not enough progress towards a win to warrant an exception.

I don't know if this is different in Gothic Chess, I suppose this is for you to say...

There was a very famous game involving Karpov or Kasparov where one of them claimed a draw too early, I think for a 3-fold repetition. But, the draw claim was declined, and a time penalty was applied.

The reason: While the piece arrangements were the same in each position, in one of the positions castling was a legal move option, and in another this was not the case (perhaps a king move, then king back to previous square. Before the king move, castling is an option when allowed, after the king move back, and if the opponent repeats the move, it "looks" the same, but the position is different since the castle rights are different.)

A very small distinction, and one which was somehow in the rule then.

I remember it and I remember that karpov claimed a draw too early.
The rules were not changed.

Castling rights are relevant for draw by repetition.
They are not relevant for draw by the 50 move rule.


50 move rule is simply not about irreversible move.

Even if after 100 plies you are forced to move a pawn if you want to play a legal chess move so you have no chance for repetition then you can still avoid doing it and claim a draw.

Uri

[Guenther Simon]

This is indeed theFIDE 50-move rule as I understood it. I can only speculate that the designers considered mere castling not enough progress towards a win to warrant an exception.

I don't know if this is different in Gothic Chess, I suppose this is for you to say...

There was a very famous game involving Karpov or Kasparov where one of them claimed a draw too early, I think for a 3-fold repetition. But, the draw claim was declined, and a time penalty was applied.

The reason: While the piece arrangements were the same in each position, in one of the positions castling was a legal move option, and in another this was not the case (perhaps a king move, then king back to previous square. Before the king move, castling is an option when allowed, after the king move back, and if the opponent repeats the move, it "looks" the same, but the position is different since the castle rights are different.)

A very small distinction, and one which was somehow in the rule then.

You mixed up the rules for repetition and 50moves draw claim.

Guenther

[GothicChessInventor]

You mixed up the rules for repetition and 50moves draw claim.

Guenther

Thanks for the clarifications, to you, and the others.

[H.G.Muller]

The WInBoard_F project is nearing its completion. (I hope to release next week.) In the process of creating it, I did change the specifications somewhat. This is what I implemented:

/variant=normal
This (already existing) option has been expanded with several new variants, involving non-conventional pieces and deviating board sizes. The board size is automatically adapted to the selected variant, unless explicitly overruled (see below). The new variants are (with default board size, files x ranks, in parentheses):

Code: Select all

Knightmate        (8x8)  Variant where the King moves as a Knight, and vice versa
Capablanca Chess (10x8)  Variant featuring Archbishop and Chancellor as new pieces
Gothic Chess     (10x8)  Same as Capablanca, with a more interesting opening position
Courier Chess    (12x8)  a Medieval form that combines elements of Shatranj and modern Chess
Shogi             (9x9)  Japanese Chess
Xiangqi          (9x10)  Chinese Chess
Fairy Chess       (8x8)  Variant were you can use all pieces of other variants together


The variant can be set from the newly added "File -> New Variant..." sub-menu.
Extra board files are indicated by the letters i, j, k, l, ... For boards with more than 9 ranks, the counting starts at zero! Non-FIDE pieces will be referred to in FENs and PGN by letters that depend on the variant, and might collide with piece designators in other variants. E.g. in Xiangqi 'C' is a Cannon, in Capablanca Chess it is a Chancellor. Pieces that do not belong in a variant cannot be addressed in FEN and PGN either as long as that variant is selected, unless the letter assignment is overruled by the /pieceToCharTable option. The variant is not saved in the winboard.ini file; on start-up we always get variant "normal" unless we use the command-line opton, or have added the option to the winboard.ini file manually (in which case it will disappear when this file is overwritten).
WinBoard_F knows the movement of all pieces occurring in Capablanca Chess (of which FIDE Chess is a subset), Shatranj, Courier, Xiangqi and 9x9 Shogi, so that these games can be played with legality testing enabled.

/pieceToCharTable="PNBRQFWEMOUHACGSKpnbrqfwemouhacgsk"
Each piece that WinBoard knows (in its legality test) has a letter associated with it, by which it will be referred to in FEN or PGN. The default assignment can be overruled with this option. The value has to be a string of even length, with at least 12 characters. The first half of the string designates the white pieces, the second half the black.
The last letter for each color will be assigned to the King. (This is the piece that moves as an orthodox King; note that Nightmate and Xiangqi have a different royal piece.) All letters before it will be assigned to the other pieces in the order:

Code: Select all

P Pawn                 (move often depends on variant)
N Knight               (move subtly different in Xiangqi or Shogi)
B Bishop
R Rook
Q Queen                (Lance in Shogi)
F Ferz/General         (Silver General in Shogi)
W Wazir/GrandVizer     (Gold   General in Shogi, in Xiangqi it is royal)
E Alfil/Elephant       (Moves subtly different in Xiangqi vs Shatranj/Courier)
M Commoner/Man
O Cannon/Pao
U Unicorn              (representation of Royal Knight in Knightmate, used as promoted Pawn in Shogi)
H Nightrider           (Promoted Knight in Shogi and CrazyHouse)
A Archbishop/Cardinal  (Promoted Bishop in Shogi and CrazyHouse)
C Chancellor/Marshall  (Promoted Rook   in Shogi and CrazyHouse)
G Grasshopper          (Promoted Queen in Crazyhouse, promoted Lance in Shogi)
S                      (Promoted Silver in Shogi)
K King


Pieces that are not mentioned (because the argument has less than 34 characters) will retain the default representation of the variant. Pieces can be disabled by assigning them a '.' (period). They are then not recognized in FEN or PGN input. It is not possible to disable a piece that is present in the opening position of the selected variant, though.
Promoted pieces that need to be distinguished from original pieces of the same type (because of demotion on capture and transfer to the holdings) will be indicated by the letter for the unpromoted piece with a '+' in front of it (Shogi), or by the letter of the promoted piece with a '~' after it (Crazyhouse, Bughouse, in general everything with holdings that is not Shogi).

/fontPieceToCharTable="PNBRQFWEMOUHACGSKpnbrqfwemouhacgsk"
This option is similar to /pieceToCharTable, but sets the font character that is used to display the piece on the screen (when font-based rendering is in use), rather than in the FEN or PGN. The default setting should work with the WinboardF font, which uses the 'intuitive' mapping of font characters to symbols.
Note that UHACGS are also used to represent the promoted versions of PNBRQF, in games like Crazyhouse and Shogi, where the promotion has to be undone on capture.

/boardWidth=-1 /boardHeight=-1
Set a number of files and ranks of the playing board to a value that will override the defaults for the variant that is selected. A value of -1 means the variant default board size will be used for the corresponding parameter (and is itself the default value of these options). These parameters can be set in the "Files -> New Variant..." sub-menu, where they are reset to the default -1 is you OK the chosen variant without typing something to overrule it. These parameters are saved in the winboard.ini file. (But unless you saved while a variant with board-size override was selected, they will always be saved as -1.)
A variant with a non-standard board size will be communicated to the engine(s) with the board size prefixed to the variant name, e.g. "variant 12x8_capablanca". In protocol 2 the engine must first enable this feature by sending "boardsizeFxR" amongst the accepted variants, where F is the maximum number of files, and R the maximum number of ranks as decimal numbers.

/holdingsSize=-1
Set the size of the holdings for dropable pieces to a value that will override the default for the variant that is selected. A value of -1 means the variant default holdings size will be used for that parameter (and is itself the default value of this options). This parameter can be set in the Files -> New Variant... sub-menu, where it is reset to the default -1 is you OK the chosen variant without typing something to overrule it. This parameters is saved in the winboard.ini file.
To disable holdings, set their size to 0. They will then not be displayed. For non-zero holding size N, the holdings are displayed left and right of the board, and piece drops can be effected by dragging pieces from the holdings to the drop square. In bughouse, the holdings will be filled by the ICS. In all other variants, captured pieces will go into the holdings (after reversing their color). Only the first N pieces of the /pieceToCharTable argument will go into the holdings. All other pieces will be converted to Pawns. (In Shogi, however they will be demoted in the regular way before determining if they fit.) In future implementations, pieces that are disabled (per default and per /pieceToCharTable option) might not be counted when determining what are the first N pieces.
Non-standard holdingsize will be communicated to the engine by prefixing it (together with the board size, even if this is standard) to the variant name, e.g. "variant 7x7+5_shogi". In protocol 2 the engine should enable this feature by sending "holdingsH" amongst the variant names, where H is the maximum acceptable holdings size as a decimal number.

/alphaRank=FALSE
When this parameter is true, a-h are converted to 1-9, and vice versa, in all move output and input (to PGN files or SAN move display as well as in communication with the engine). This might be useful for Shogi, where conventionally one uses letters to designate ranks, and digits to designate files. Engines that want to use this option must make sure pieces are never represented by lower case! This option can be set from the Files -> New Variant... menu, where it defaults to FALSE unless you explicitly set it. It is not saved in the winboard.ini file.

/allWhite
Causes the outline of the 'white' pieces to be superimposed onto the 'black' piece symbols as well (as a black outline) when native bitmaps are used (as opposed to font-based rendering). This is useful if we choose a very light color to represent the 'black' pieces. It might be particularly useful in Shogi, where the conventional representation of the 'black' pieces is as upside-down white pieces, so that both colors would be white. This option is saved in the winboard.ini file, and can be set in the "Options -> Board..." sub-menu.

/detectMate=TRUE /testClaim=TRUE /materialDraws=TRUE /trivialDraws=FALSE /ruleMoves=51 /repeatsToDraw=6
These are options that only affect engine-engine play, and can be set from the Options -> Engine... sub-menu. They are all related to adjudication of games by the GUI. Legality checking must be switched on for them to work.
If /detectMate is TRUE, the GUI recognizes checkmate and stalemate (but not in games with holdings!), and ends the game accordingly before the engines can claim. This is convenient for play with engines that fail to claim, and just exit.
With /testClaim set, all result and illegal-move claims by engines that claim more than their own loss are scrutinized for validity, and false claims result in forfeit of the game. Useful with buggy engines.
The option /materialDraws=TRUE causes games with insufficient mating material to be adjudicated immediately as draws, in case the engines would not claim them.
The option /trivialDraws adjudicates KNNK, KBKB, KNKN, KBKN, KRKR and KQKQ to draws after 3 moves.
The /ruleMoves determine after how many reversible moves the game is adjudicated as a draw. Setting this to 0 turns this option off. Draw claims by the engine are still accepted (by /testClaim) after 50 reversible moves, even if /ruleMoves species a larger number. Note that it is perfectly legal according to FIDE rules to play on after 50 reversible moves, but in tournaments having two engines that want to play on forever is a nuisance in endings like KBNKR, where one of the engines thinks it is ahead and can avoids repeats virtually forever.
The option /repeatsToDraw makes the GUI adjudicate a game as draw after the same position has occurred the specified number of times. If it is set to a value > 3, engines can still claim the draw after 3-fold repeat.
All these options are saved in the winboard.ini file.

/matchPause=10000
Determines the number of milliseconds that is paused between two games of a match.