Sorry HG, more FRC - bug in Winboard?

[Richard Allbert]

Ok, in this position

[d]

I played Kg1 to c1.

Code: Select all

moveType 4 = 35, promochar = 0
TC string = '+1+3'
mps=0 tc=60000 inc=3000
move: g1c1
, parse: Kg1c1 (
)
time odds: 1.000000 1.000000 
Interrupting first
38676 >first : time 6578
38676 >first : otim 6344
book hit = (NULL)
38676 >first : usermove 38676 >first : g1c1

And on the actual board, winboard moved the King to C1, but the white queen to D1 !

I've just reloaded the position in winboard again, and the same thing happened. The queen on A1 moves to D1, the rook on F1 stays where it is.

Regards

Richard

[hgm]

I am not sure what exactly you did. You seem to play a white piece, while black has the move. This should always be refused, even with legality checking off. Did you have legality checking off? If you did, it will accept anything, of course. Was it your program that played this move, was it you typing the move, or did you enter it by dragging a piece with the mouse. Were you doing this in variant normal or in variant fischerandom?

[Richard Allbert]

I'm sorry, you're right. I moved before the engine had a chance to with no legality checking. Apologies!!!

I'm still in the same place as this morning trying to iron out the bugs. With the exception of 45mins running, a bit of lunch the entire day has been spent getting the silly castling rules to work.

It's finally done... I eventually settled on clearing both the King and rook squares, before placing them, in both makemove and takemove.

I've managed to get test games to work in WB, Shredder, but Arena gives me some problems.

WB protocol says that a castling move is "O-O" or "O-O-O".
UCI procotol says K takes R

... and arena uses KingFrom KingTo.

So I'm giving up with Arena.

Thanks for the reply

Richard

PS If a mod reads this, can you change the title to "Solved, no bug" or something like that?

[hgm]

Indeed, with legality checking off, it is up to the engine to accept or refuse the move, and WB will follow its recommendation. For the purpose of displaying the board, it still has to guess at side effects: for castlings you want an unmentioned Rook to be moved, and with e.p. captures an unmentioned Pawn to disappear. It uses a heuristic for that, which causes the effect that puzzled you:

When a King moves more than one square on the back rank, with a move that is illegal in the currently selected variant (but must be accepted because legality checking is off), it assumes it is a castling with the corner piece in the direction of which you move. It then put the King where you move it, and swings the corner piece around it. It does not have to be a Rook; in some variants (e.g. Chess with Different Armies) you can caste with other pieces than Rooks. FRC-type castling internally is represented as KxR in WB internally, and to enter one with the mouse you have to drag the King on top of the Rook. And you could also type e1h1 to play O-O in variant normal, if legality checing is off.

[Aaron Becker]

WB protocol says that a castling move is "O-O" or "O-O-O".
UCI procotol says K takes R

... and arena uses KingFrom KingTo.

So I'm giving up with Arena.

Strangely, Arena seems to take KingFrom KingTo for nomal chess, while insisting on O-O and O-O-O for FRC. I had to implement a separate option to Daydreamer to support the Arena format for FRC games.

[hgm]

This is actually how WB protocol specifies it. (king-from, king-to) is supported in normal and other non-shuffle variants for historic reasons, but it cannot be used in shuffle variants with Fischer-type castling, as it is not always unambiguous to normal King moves. This is why WB protocol insists on O-O and O-O-O for such variants. WinBoard itself would actually understand O-O and O-O-O in all variants with castling, as this is normal SAN, and WB understands SAN. But this is not a protocol requirement.

So all this is pretty well defined. The only tricky issue is what you woud want the GUI to do if it gets a move that is not recognized as a legal castling, or any other legal move. E.g. when on an 8x8 board your King is on f1, and you enter f1b1, or drag the King to b1. It then has to guess what you mean by this. Of course you could always interpret it as a normal King move, but it is actually more useful to interpret it s a castling: there exist several variants, especially on 10x8, with 'free castlng' where you can choose if Kf1 castles to b1, c1, d1. Although WB does not officialy support these variants, it is still added value to allow it to act as GUI for such variants with legaity checking off. So it does in general consider such King moves castlings. The only exception is when the King starts from an edge file, because you want moves like Ka1-h1 or Kh1-a1 to be normal, wrapping moves in cylinder Chess.

[Sven]

There are still two points that I don't understand here:

1) Why did the WinBoard GUI accept a white move while black was the side to move? This should *never* be possible IMO, so what do I miss here?

2) Why should it *ever* be acceptable that a GUI makes and displays a castling move with king+queen? I see nothing good in that, *never*, except in the "user confuser" mode ... Whether "legality check" is on or off should be irrelevant since I would expect that a GUI does *only* make moves which are pseudo-legal at least, i.e. no "black knight on a8 captures black pawn on g4 and promotes to white king" or something like that ...

Sven

[hgm]

I can't help you with point 1, as I agree that this should be impossible. What you propose in (2), however, (accepting only pseudo-legal moves) would make it impossible to use WinBoard as a GUI for unsupported variants by switching legality testing off.

It could very well be that Na8xg4=K capturing an own Pawn is a legal move in some variant. Promotion to opposite color is too exotic even for my taste, but I did consider allowing promotion of any piece on any move, and I might still do it. (But you could not enter such mover with the mouse then, and in XBoard you cannot enter moves by typing, so I shelved the idea.)

I currently also do not allow capture of own pieces through the GUI interface. This would interfere very much with the current way of entering moves by mouse, where a new click on another piece selects it in stead of the one you selected before, and people really value that. Even abandoning this for Rook-after-King clicks for the purpose of entering FRC castling led to immediate complaints, so now I limit that to FRC and CRC. And even there it never means that you really want to capture the Rook. I might add a variant where capturing own pieces is legal, though, and then only in that variant the mouse behavior would have to be changed. For now you would be abe to play such variants only by typing the fratricidal captures in WinBoard, where they accidentally worked even in 4.2.7, and I saw no reason to change that.

Apart from the above weirdness, it does not strike me as odd at all to have WinBoard accept Na8xg6 or Na8-g6. There can be variants with pieces that move like that, and where a Knight would be the natural representation. There are all kinds of variants with augmented Knights. The sole purpose of being able to switch legality testing off is to play such variants. Note that WinBoard has always had this design philosophy: in WinBoard 4.2.7 you could only play Shatranj (w28) on ICC by switching legality testing off, because otherwise moves like Bf1-d3 would be refused if e2 was occupied. (And of course many moves would be refused because WinBoard would think you are in check by the Queen, not knowing that the Queen was just a Ferz in Shatranj.)

Fairy-Max supports castling with corner pieces of any type. This is needed for Chess with Different Armies, where to most one side has Rooks, and the other side has something else, while both sides should be able to castle. E.g. the army of the Color-bound Clobberers has a corner piece that moves like a Bishop or makes a (2,0) jump in any direction. A Bishop would be a much more natural representation for that than a Rook, and an Archbishop would be even better. But they must be able to castle. If WinBoard could not handle that, it would not be a suitable GUI for Fairy-Max.

If people enter strange moves, with legality testing off, they should be neither surprised nor confused when strange things happen: the result of such moves is undefined. Only with legality testing on, there is the defined response of the illegal-move popup, (or a forfeit when you are an engine). With legality testing off, only moves (pseudo-)legal in the current variant have a defined respose (namely performing that move). Users that find that confusing, should not switch legality testing off!