Two Kings bug

[Nathan826]

I have a bot that plays on a chess server using Pulsar with WinBoard 4.4.1. When it plays two kings, though, it sometimes is not able to castle queenside. In this case I see a popup window in WinBoard saying something like "Illegal move e1c1 from first engine", but it should be a perfectly legal move. I even have tried replaying the game in analysis mode, and when I try to castle by hand, it works just fine; I'm not sure why it doesn't recognize it as a legal move when Pulsar submits it to WinBoard. Thanks for any help.

[H.G.Muller]

It would help a lot when you could show a PGN of a game where this happened. One reason might be that I misunderstand the TwoKings rules for castling. Is the King on e1 allowed to castle when it is non-royal?

[Teemu Pudas]

9: There are two kings. You win if you checkmate the king that is closest to the a-file. If both kings are on the same file, you win if you checkmate the one that is closer to rank 1. For example, if your opponent has kings on a7 and c5, you win if you checkmate the king on a7. The other king is just an ordinary piece. It can be checked and captured with no consequences. The king you must mate can change during the course of the game.

A king that can't castle isn't ordinary.

[H.G.Muller]

Neither is a King that can't be checkmated. But t doesn't say that it is an ordinary King, it says it is an ordinary piece. And ordinary pieces do not castle. I am afraid this text is not shedding much light on the issue. Knowing how the ICS works, I can make a fair guess how they implemented it with minimal effort. But that is no guarantee that the engine would agree with it...

[Nathan826]

Thanks for the replies. In the game, the king that tried to castle was the "royal" king (I'm not sure what would or should happen otherwise). I don't have a debug file for the time this happened, but I can run it again and get one if you want. Anyway, here's the PGN. White tried to castle on move 9, but WinBoard popped up a window saying that e1c1 was an illegal move, so the game had to be aborted. The weirdest thing is, if I open up WinBoard in analysis mode with Pulsar and enter in the moves of the game, I can manually do 9. O-O-O with no problems.


[Event "ICS unrated wild(9) match"]
[Site "207.99.83.244"]
[Date "2009.12.21"]
[Round "-"]
[White "VariantsBot"]
[Black "Nathan826"]
[Result "*"]
[WhiteElo "2198"]
[BlackElo "1901"]
[TimeControl "120"]
[Variant "twokings"]
[Annotator "1. +0.02"]

1. Nc3 {+0.02/4} Nf6 2. e4 {+0.02/7 5} d5 3. exd5 {+0.24/7 5} Nxd5 4. d4
{+0.17/7 5} Nc6 5. Nf3 {+0.08/6 5} Bg4 6. Be3 {+0.14/6 4} e6 7. Qe2
{+0.12/6 4} Qe7 8. Nxd5 {+0.15/6 4} exd5
{Game aborted by mutual agreement} *

[H.G.Muller]

Hmm, that is indeed strange. It suggest that it is something in the parser, where O-O-O and e1c1 are still treated differently. I will try to feed the game to 4.4.1 and see if I can reproduce the error.

[Teemu Pudas]

And now for something completely different: you can't castle on ICC after you've moved either king. But if the other king is captured on its starting square, you can!

[H.G.Muller]

I tried both e1c1 and OOO forms of entering castling, and in local mode these seem to work. So I guess it will be essential to have a debug file of an occurrence of such a castling rejection. It could very well be an ICS problem. The information flow in ICS play is that the ICS sends WinBoard a new board after every move, which overwrites the position that WinBoard itself had derived from the previous position and the move. So if the ICS sends a board with bogus castling rights (as it does in FRC, for instance), it might very well be that WinBoard is led to believe by the ICS that castling is no longer allowed in this position. And then it would be normal that it refuses the engine's castling move.

In FRC I solved this by having WinBoard ignore the ICS castling flags in this variant. Perhaps this is also needed in TwoKings. But it is not a sure remedy: if the ICS says castling is impossible, it could very well mean it. And then having WinBoard accept the move of the engine and relay it, would only lead to the ICS rejecting it as an illegal move further down the chain. In FRC that fortunately does not happen; if the ICS says that castling is not possible there, it does not mean that it will not accept castling as a valid move, but just that the Rook is not on a1/h1 etc.

[Nathan826]

I played it twice more in two kings. The first time, I castled queenside, and WinBoard thought it was an illegal move. The second time, Pulsar tried to castle and WinBoard thought it was an illegal move. Here is the part of the debug file for the last move of the first game:

load 8x8 board
parseboard 18, castling = 7 0 5 -1 -1 5
accepted move O-O-O from ICS, parse it.
moveNum = 18
board = 0-8 x 8
move to parse: O-O-O
long castling 4 2
7 0 5 7 0 5 Legality test? e8c8
move to parse: o-o-o
long castling 4 2
7 0 5 7 0 5 Legality test? e8c8
Illegal move from ICS 'O-O-O'
board L=0, R=8, H=8, holdings=0
Move parsed to 'O-O-O (0:05)'
nps: w=-1, b=-1
Display title 'VariantsBot (35) vs. Nathan826 (35) {2 0 twokings}, gameInfo.variant = 10'
silence
<ICS: aics%
ics input 18, castling = 7 0 5 -1 -1 5
<ICS: aics%
ics input 18, castling = 7 0 5 -1 -1 5
<ICS: aics%
ics input 18, castling = 7 0 5 -1 -1 5
<ICS: \015\012Your opponent requests that the game be aborted.\015\012\007Use "abort" to end the game. The offer is valid until you make a move.\015\012aics%
ics input 18, castling = 7 0 5 -1 -1 5
silence
silence
>ICS: abort\012
<ICS: {Game 123 (VariantsBot vs. Nathan826) Game aborted by mutual agreement} *\015\012aics%
ics input 18, castling = 7 0 5 -1 -1 5
GameEnds(40, Game aborted by mutual agreement, 0)

And for the second:

ics input 10, castling = 7 0 5 7 0 5
202074 <first : #testing crazyhouse evaluate is -46
202074 <first : # proccessed time
202074 <first : #testing crazyhouse evaluate is -46
202074 <first : # finished call to getmove and turn is 10 and wstat is 2
202075 <first : # made opponents move on board
202075 <first : # k1c 5 r1c 1 r2c 0 : k1p 61 r1p 57 r2p 0
202075 <first : #board before search
202075 <first : # 4 0 0 0 6 6 0 4
202076 <first : # 1 1 1 0 1 1 1 1
202076 <first : # 0 0 2 5 0 2 0 0
202076 <first : # 0 0 0 1 0 3 0 0
202076 <first : # 0 0 0 7 0 0 0 0
202076 <first : # 0 0 8 0 7 8 0 0
202076 <first : # 7 7 7 9 0 7 7 7
202077 <first : # 10 0 0 11 12 12 0 10
202077 <first : 1 68 0 0 e1c1
202078 <first :
202078 <first : # maxdepth = 1
202078 <first : 2 60 0 0 e1c1 c6e7
202080 <first :
202080 <first : # maxdepth = 2
202080 <first : 3 66 0 0 c3b5 a8c8 e1c1
202081 <first :
202081 <first : # maxdepth = 3
202081 <first : 4 58 0 0 c3b5 a8c8 e1c1 f6e4
202082 <first :
202082 <first : # maxdepth = 4
202274 <first : 5 56 0 0 e1c1 c6b4 d3d2 a7a5 h2h4
202275 <first :
202275 <first : # maxdepth = 5
203460 <first : 6 52 0 0 e1c1 c6b4 d3d2 a7a5 a2a3 b4c6
203461 <first :
203462 <first : # maxdepth = 6
206000 <first :
206000 <first : tellics whisper depth: 6 + 4/48 moves evaluate: 61 nps: 284037 maxsearchside: 7 topc=0, topp=0
>ICS: whisper depth: 6 + 4/48 moves evaluate: 61 nps: 284037 maxsearchside: 7 topc=0, topp=0
>ICS: \012
206002 <first : 6 61 0 0 e1c1 c6b4 d3d2 a7a5 a2a3 b4c6 h2h4
206004 <first :
206004 <first : # maxdepth = 7
206035 <first : # board before move
206035 <first : # 0 0 0 4 6 6 0 4
206035 <first : # 1 1 1 0 1 1 1 1
206036 <first : # 0 0 2 5 0 2 0 0
206036 <first : # 0 0 0 1 0 3 0 0
206036 <first : # 0 0 0 7 0 0 0 0
206036 <first : # 0 0 8 0 7 8 0 0
206036 <first : # 7 7 7 9 0 7 7 7
206036 <first : # 10 0 0 11 12 12 0 10
206036 <first :
206036 <first : move e1c1
machine move 10, castling = 7 0 5 7 0 5
move to parse: e1c1
7 0 5 7 0 5 Legality test? e1c1
206040 <first : 
206040 <first : # 0 0 6 4 0 6 0 4
206040 <first : # 1 1 1 0 1 1 1 1
206040 <first : # 0 0 2 5 0 2 0 0
206040 <first : # 0 0 0 1 0 3 0 0
206040 <first : # 0 0 0 7 0 0 0 0
206040 <first : # 0 0 8 0 7 8 0 0
206040 <first : # 7 7 7 9 0 7 7 7
206040 <first : # 10 0 0 11 12 12 0 10
206040 <first : # calling getmove turn is 12
<ICS: (whispered to 0 observers)\015\012aics%
ics input 10, castling = 7 0 5 7 0 5
>ICS: abort\012
<ICS: Sending abort request.\015\012aics%
ics input 10, castling = 7 0 5 7 0 5
<ICS: \015\012{Game 131 (VariantsBot vs. Nathan826) Game aborted by mutual agreement} *\015\012aics%
ics input 10, castling = 7 0 5 7 0 5
GameEnds(40, Game aborted by mutual agreement, 0)

The first game:

1. e4 {+0.02/4} Nc6 2. Nc3 {+0.02/7 4} e6 3. d4 {+0.37/7 6} Nf6 4. Bf4
{+0.42/6 3} d6 5. Nf3 {+0.41/6 4} Bd7 6. e5 {+0.52/6 4} dxe5 7. dxe5
{+0.54/6 4} Nh5 8. Be3 {+1.01/6 3} Qe7 9. g4 {+2.41/6 5} O-O-O
{Game aborted by mutual agreement} *

And the second:

1. Nf3 {+0.02/4} e6 2. d4 {+0.34/7 5} d5 3. Bf4 {+0.42/7 5} Nf6 4. Nc3
{+0.45/7 5} Bd7 5. Qd3 {+0.56/6 4} Nc6
{Game aborted by mutual agreement} *

[H.G.Muller]

Weird. It seems that the _other_ King has castling rights! (7 0 5 means that the rooks at file 7=h, 0=a and the King at 5=f can still castle). I wonder how it got that way. (As this does not seem to happen in local play, the castling rights must be initially correct after setting up the opening position.) Cn you e-mail me the entire debug file (h.g.muller ATSIGN hccnet PERIOD nl)?

[H.G.Muller]

I might have found the problem. Because of FRC, WinBoard was scanning each position received from the ICS for the King on the back rank. But in TwoKings this does not work. Not only was it scanning in the wrong direction (so that it always found the one in the f-file on an opening position), but there is no right direction: later in the game Kf1 could have moved to d1, and you would till want Ke1 to be able to caste in that case. (I hope...) So I now explicitly check for a King in the e-file, in TwoKings.

Please try the version at http://hgm.nubati.net/winboard.zip to see if that fixes it.

[Nathan826]

Thank you, it works just fine now! One thing though, why is the interface set to "WinBoard 4.20100107 + Program"? Seems like kind of a strange number for a version!

[H.G.Muller]

We forked the XBoard project into a stable and a development branch. Stable versions have numbers like 4.4.x, and we only do simple or well-tested bugfixes there. New features will be implemented in the development branch. There we use numbers like 4.DATE to identify the alpha versions. So the number means it was made on Jan 7, 2010. (Because that was the last time I had not forgotten to update the version number and recompile before I up-loaded...)

Eventually features that are sufficiently well tested will be picked for a new stable version, which then will become 4.5.0. The TwoKings bugfix will of course go into the 4.4.x branch as well, but I only have a version of the development version on my wesite. (I do not have enough quota on that server to host two winboard.exe.)

Current features that are in the development version and not in 4.4.x are:
Settings file (XBoard)
Eval graph (XBoard)
File-browse dialog (XBoard)
PV display
Multi-PV display (WinBoard)
Variation support
Possible-move highlighting
Variant Makruk

So the posted version you tested has these last 5 features. (WinBoard 4.4.x already had the first 3, of course.) For a more elaborate descrption of the new features, see http://hgm.nubati.net