Page 1 of 1

Chess960 castling in Xboard 4.7.2

PostPosted: 16 Sep 2013, 13:03
by chessplayer
Hello, I have two question about castling in Chess960.
Consider this game
Code: Select all
[Event "?"]
[Site "?"]
[Date "?"]
[Round "-"]
[White "?"]
[Black "?"]
[Result "*"]
[Variant "fischerandom"]
[FEN "rbknrqbn/pppppppp/8/8/8/8/PPPPPPPP/RBKNRQBN w EAea - 0 1"]
[SetUp "1"]

{--------------
r b k n r q b n
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
R B K N R Q B N
white to play
--------------}
1. Nc3 Nc6 2. O-O-O O-O-O
*

You can castle even if the rook has to travel through the bishop. Is it expected?
The dot on the rook which tells you that you can castle is red, not yellow. Is it expected?
Regards

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 16 Sep 2013, 14:23
by Reinhard Scharnagl
no castling possible here yet.

Image

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 16 Sep 2013, 15:39
by H.G.Muller
chessplayer wrote:You can castle even if the rook has to travel through the bishop. Is it expected?

No, this is surely a bug. Thanks for spotting it.

The dot on the rook which tells you that you can castle is red, not yellow. Is it expected?
Regards

The algorithm for deciding the color of the dot is pretty sloppy (and it can afford to be, as in the standard edition of WB the color of the dots has no official function so far). It just checks if the square is empty or not. I guess that without much more effort I could also have it check if the square is an opponent or not. In that case the dot would be yellow, which is indeed more natural for a castling.

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 16 Sep 2013, 21:52
by H.G.Muller
Turns out that WinBoard did not test if the Rook path was clear at all. Only the King path (ignoring the Rook). It did test if the square inside the King was empty when the King was not passing over it, though (so f1 for Kg1 and d1 for Ka1, b1 or c1) to make sure the Rook could land. But in a-side castling the Rook might also need to pass over b1, if it starts at a1, which is the only case where the King path does not cover the Rook path on the outside. (And it must allow the King to be on that square!)

As for the color, I think I keep it red. It seems helpful to make castling stand out compared to the other moves. Perhaps I should even define a separate color for it. (But v4.7.x only has red and yellow, or actually the highlight and premoveHighlight colors. So I will leave that for the development version, which already supports 8 colors, which can be specified by the engine.)

Btw, thank you for testing WinBoard this thoroughly.

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 16 Sep 2013, 22:46
by chessplayer
Thank you for your explanation.
Just to clarify, is the dot red because you are "capturing" your own rook? Nevertheless, fortunately there aren't variants which use Chess960 castling and compulsory capturing

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 17 Sep 2013, 06:36
by H.G.Muller
Indeed, the idea was to indicate captures different from non-captures. There wasn't a real reason for this, I did it just because ChessV does it too. (In variants with mandatory capture there are never any non-captures when there are captures, so I decided to use the yellow there to highlight captures with other pieces.)

In the Alien Edition this distinction is used for a purpose, though: when the mouse pointer enters a square marked in red, the GUI sends a 'hover' command to the engine, so the engine can put new markers on the board to indicate what was captured. It doesn't do so when you enter a yellow square. This is useful for variants where capture can be on another square than the to-square (such as in e.p. capture or Checkers). But this is only used when legality checking is off, and the engine would also be responsible for putting the red markers. Similarly, releasing the piece on a purple marker (put there by the engine) would trigger the promotion procedure, even when the square is outside the regular promotion zone. I have now put the code that does that in the development version of the regular edition of WinBoard too, because it is very helpful when using WinBoard for variants it does not know the exact rules of (played with legality testing off).

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 18 Sep 2013, 09:30
by chessplayer
Thank you for your explanation.
I'm sorry for going a little off-topic but let me clarify again: after all, it's called Xboard with no reference to chess, so do you mean that you plan to add Checkers support some time in the future?

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 18 Sep 2013, 12:25
by chessdrone
chessplayer wrote:Thank you for your explanation.
I'm sorry for going a little off-topic but let me clarify again: after all, it's called Xboard with no reference to chess, so do you mean that you plan to add Checkers support some time in the future?


I've never tried it but it seems to me that Checkers is already supported http://hgm.nubati.net/news.html#tag-C2

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 18 Sep 2013, 13:26
by H.G.Muller
Indeed, there already exists an experimental fork of WinBoard, called 'the Alien Edition', which aims at making it more generally useful as a GUI for any kind of board game. The idea is to delegate as much as many as the game-specific tasks to the engine. In principle WB protocol already allowed a lot of that, as there are for instance commands with which the engine can tell the GUI that a move was illegal.

Other extensions compared to the standard edition is that the engine can define board size and initial setup, or even update the full board position after every move, to implement side effects. Also, the engine is informed how the user manipulates a piece (with lift, put and hover commands), and can cause marker dots of 8 different colors to appear on the board by sending the GUI a 'highlight' command. The GUI can use that information to decide with moves are legal (when it gets it when the piece is picked up, and before the piece is released), but also to trigger special actions (like moving a second piece, or showing a promotion popup) depending on the dot color.

Checkers, Go, Reversi and Amazons are standard variants in the Alien Edition.

My plan is to slowly port some of the more successful features to the standard edition. I already did so for the 'highlight complex' in the development version.

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 18 Sep 2013, 14:00
by chessplayer
Is the Alien Edition available for Linux, Microsoft Windows, or both? I can't figure it out.

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 18 Sep 2013, 20:48
by chessdrone
chessplayer wrote:Is the Alien Edition available for Linux, Microsoft Windows, or both? I can't figure it out.

I do not know which version was used for binary windows but you can try to download a snapshot of the source code tagged Aliennew http://hgm.nubati.net/cgi-bin/gitweb.cg ... new;sf=tgz

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 18 Sep 2013, 22:47
by chessplayer
Thank you, it seems to work on both the operating systems

Re: Chess960 castling in Xboard 4.7.2

PostPosted: 19 Sep 2013, 07:35
by H.G.Muller
The 'aliennew' branch is indeed the current version of the Alien Edition. Actually I have some patches here at home that I now realize I never pushed to the on-line repository. They aim at making the Alien version suitable for playing Chu Shoi and even larger Shogi variants. (For this the number of pieces had to be greatly expanded.) These patches only work for WinBoard, however, there is no XBoard version that can play Chu Shogi. They are also not really finished (but they work for Chu).

You should realize that the 'aliennew' branch forked from 'master' at the time of XBoard 4.5.x, so there is a lot in 4.7.2 that is not in the Alien Edition. XBoard underwent huge changes since then (switching to the Cairo lib for plotting). It is not easy at all to apply the patches that made the Alien Edition out of 4.5.x to 4.7.x, the code has grown too different between 4.5 and 4.7.