Winboard Forum

Maybe the error is sitting 60 cm in front of my monitor but I found the following problem:

In this position

[diag]5k2/8/8/8/8/8/8/5K1R w K - 0 1[/diag]

5k2/8/8/8/8/8/8/5K1R w K - 0 1

Kg1 maybe a simple King move or a castling move. Arena's help file tells me:

To castle, just move the king or the rook, the move of the other piece will be made automatically. Be careful, especially with the rook: In many cases the rook move could be legal by itself (so might be the king move). To distinguish between a normal move and castling press Ctrl on the keyboard while you make the move with the mouse. You only need to press Ctrl if you must distinguish between castling and normal move.

Whatever I tried (pressing Ctrl also tested Shift, Alt) the Rook move hasn't been executed when I moved the King to g1. Maybe I got the help file wrong. Any hints how to convince Arena to make the castling move appreciated.

Volker

Are the castling rights in your FEN correct for Arena, Volker?
(Please don't involve me now in the Shredder/Arena/Smirf or
whatever FEN discussion )

Regards,
Guenther

As I have mentioned earlier, Arena sometimes seems to be unable to import FEN with nonstandard castling rights. When manually playing games between SMIRF and other FRC enabled engines under Arena, FEN only could be transported into the direction of SMIRF, which is also handling this X-FEN correctly.

[diag]5k2/8/8/8/8/8/8/5K1R w K - 0 1[/diag]
X-FEN: 5k2/8/8/8/8/8/8/5K1R w K - 0 1

Shredder also (as far as I know) is not able to import this FEN and then to perform a castling, because of its different FRC-FEN invention.

Read more about X-FEN at: http://f51.parsimony.net/forum204700/messages/71.htm

Regards, Reinhard.

Guenther Simon wrote:Are the castling rights in your FEN correct for Arena, Volker?...

I setup the position manually in Arena and copied the FEN to my editor. To my understanding it is correct.

Volker

Reinhard Scharnagl wrote:As I have mentioned earlier, Arena sometimes seems to be unable to import FEN with nonstandard castling rights. ...

Great. At least that phenomenon (which I also observed) seems not to be related to my engine.

Reinhard Scharnagl wrote:Read more about X-FEN at: http://f51.parsimony.net/forum204700/messages/71.htm
...

Do you think the bug will disappear then?

Seriously: I'm testing my engine. I want to test the ability of FRC castling. For that purpose a GUI which understands FRC castling correcly would be handy.

I only want to know if this is a bug in Arena or it is a matter of handling.

Volker

(BTW: what kind of FEN support will be implemented will be decided when I think it is time to decide. Today and in the next few days it is not the time to decide. (I have read all controversies. No need to repeat any arguments at the moment.))

Volker,

No need to repeat any arguments at the moment

well, so I will avoid that.

One (less important) reason, why I have decided not to write an UCI engine to be used with Arena, has been, that a lot of little but very disturbing errors still make it not attractive to use Arena as a testing GUI. From time to time I have reported about such misbehaviours, but FRC/Chess960 under Arena actually seems not to have that importance. Nevertheless when playing from a self generated random position, Arena of course seems to be usable for Chess960.

Reinhard,

Reinhard Scharnagl wrote:...Nevertheless when playing from a self generated random position, Arena of course seems to be usable for Chess960....

Really? I looked at the position again. This is the FEN I imported to Arena:

5k2/8/8/8/8/8/8/5K1R w K - 0 1

And here is an excerpt from my log file:

Code: Select all

Input: level 40 20 0.

Input: post.

Input: hard.

Input: easy.

Input: ping 2.

pong 2
Input: force.

Input: setboard 5k2/8/8/8/8/8/8/5K1R w - - 0 1. <=== The FEN string has been changed by Arena!


+---+---+---+---+---+---+---+---+
|   | . |   | . |   | k |   | . | 8
+---+---+---+---+---+---+---+---+
| . |   | . |   | . |   | . |   | 7
+---+---+---+---+---+---+---+---+
|   | . |   | . |   | . |   | . | 6
+---+---+---+---+---+---+---+---+
| . |   | . |   | . |   | . |   | 5
+---+---+---+---+---+---+---+---+
|   | . |   | . |   | . |   | . | 4
+---+---+---+---+---+---+---+---+
| . |   | . |   | . |   | . |   | 3
+---+---+---+---+---+---+---+---+
|   | . |   | . |   | . |   | . | 2
+---+---+---+---+---+---+---+---+
| . |   | . |   | . | K | . | R | 1  White to move
+---+---+---+---+---+---+---+---+
  a   b   c   d   e   f   g   h

White's turn: (1.)
Input: f1g1. <==== *1


*1: How should my (or any other engine) decide if "f1g1" is a castling move or not?

I guess Arena is only usable if the King is standing more than one square away from the castling target square. Then of course it is easy to detect.

Regards

Volker

Volker,

it is a FEN import problem. Take the following PGN instead (same final position):

[Event ""]
[Site ""]
[Date "2005.08.11"]
[Time "19:07:44"]
[Round ""]
[White ""]
[Black ""]
[Result "*"]
[SetUp "1"]
[FEN "nnbbrkqr/pppppppp/8/8/8/8/PPPPPPPP/NNBBRKQR w KQkq - 0 1"]

1. a4 a5 2. b4 b5 3. c4 c5 4. d4 d5 5. e4 e5 6. f4 f5 7. g4 g5 8. h4 h5 9. gxh5
gxh4 10. fxe5 fxe4 11. dxc5 dxc4 12. bxa5 bxa4 13. Rxe4 Rxe5 14. Rexh4 Rexh5
15. Rxc4 Rxc5 16. Rxa4 Rxa5 17. Nb3 Nb6 18. Nc3 Nc6 19. Nxa5 Nxa4 20. Nxa4 Nxa5
21. Bg5 Bg4 22. Bxg4 Bxg5 23. Nc5 Nc4 24. Ne6+ Qxe6 25. Qd4 Qxg4 26. Qxg4 Ke8
27. Qxg5 Ne5 28. Qh6 Nf7 29. Qg7 Nh6 30. Qxh6 Rf8+ 31. Qxf8+ Kxf8 *

Reinhard.

Reinhard Scharnagl wrote:Volker,

it is a FEN import problem. Take the following PGN instead (same final position):

[Event ""]
[Site ""]
[Date "2005.08.11"]
[Time "19:07:44"]
[Round ""]
[White ""]
[Black ""]
[Result "*"]
[SetUp "1"]
[FEN "nnbbrkqr/pppppppp/8/8/8/8/PPPPPPPP/NNBBRKQR w KQkq - 0 1"]

1. a4 a5 2. b4 b5 3. c4 c5 4. d4 d5 5. e4 e5 6. f4 f5 7. g4 g5 8. h4 h5 9. gxh5
gxh4 10. fxe5 fxe4 11. dxc5 dxc4 12. bxa5 bxa4 13. Rxe4 Rxe5 14. Rexh4 Rexh5
15. Rxc4 Rxc5 16. Rxa4 Rxa5 17. Nb3 Nb6 18. Nc3 Nc6 19. Nxa5 Nxa4 20. Nxa4 Nxa5
21. Bg5 Bg4 22. Bxg4 Bxg5 23. Nc5 Nc4 24. Ne6+ Qxe6 25. Qd4 Qxg4 26. Qxg4 Ke8
27. Qxg5 Ne5 28. Qh6 Nf7 29. Qg7 Nh6 30. Qxh6 Rf8+ 31. Qxf8+ Kxf8 *

Reinhard.

Yes, I think there is something wrong with the FEN handling in Arena. If I import that game to Arena and move the King to g1 my engine receives:

Code: Select all

+---+---+---+---+---+---+---+---+
|   | . |   | . |   | k |   | . | 8
+---+---+---+---+---+---+---+---+
| . |   | . |   | . |   | . |   | 7
+---+---+---+---+---+---+---+---+
|   | . |   | . |   | . |   | . | 6
+---+---+---+---+---+---+---+---+
| . |   | . |   | . |   | . |   | 5
+---+---+---+---+---+---+---+---+
|   | . |   | . |   | . |   | . | 4
+---+---+---+---+---+---+---+---+
| . |   | . |   | . |   | . |   | 3
+---+---+---+---+---+---+---+---+
|   | . |   | . |   | . |   | . | 2
+---+---+---+---+---+---+---+---+
| . |   | . |   | . | K | . | R | 1  White to move
+---+---+---+---+---+---+---+---+
  a   b   c   d   e   f   g   h

White's turn: (32.)
Input: O-O. <===

Here "O-O" was send instead of "f1g1" ( I had pressed the Ctrl button). Therefore the move was unambiguous. So it seems there is a bug in Arena.

But I think there is a problem in general:

It is impossible to decide if a King move is a castling move if the King is located only one square away from his e.p. target square if coordinate or SAN notation is used. If the King is already standing on the e.p. target square makes it even more worse!

To use "O-O(-O)" (as Arena does and as it is used if Xboard/Winboard is playing at ICS) or "King x ownRook" (SMK method) for the King's castling move in FRC games solves that problem.

Regards

Volker

Volker,

the use of O-O or O-O-O is not a downwards compatible way. SMIRF communicates between engine and GUI:

a) if the King does at least two steps: use source and target coordinate as usual,
b) else use the coordinate of the involved Rook instead as target to signal the castling.

This method defines a unique move and also associates a matching input gesture for the GUI.
This solution might be recommended for UCI or Winboard, even if SMK does it by unnecessaryily establishing a separate FRC view.

Thus Smirf shows a compatible and unique method to encode castlings and to remain compatible.
(Just test it out! Download at: http://www.chessbox.de/Compu/schachsmirf_e.html)

Reinhard.

Reinhard Scharnagl wrote:...SMIRF communicates between engine and GUI:

a) if the King does at least two steps: use source and target coordinate as usual,
b) else use the coordinate of the involved Rook instead as target to signal the castling.

That seems the be a violation of the rules of chess. I don't think I'm going to allow this (at least not in console mode). I see that the GUIs must do something different if the King is located on his target square (or less than 2 squares away from it). Double clicking means something different in all GUIs I know.

Reinhard Scharnagl wrote:...This method defines a unique move and also associates a matching input gesture for the GUI.

Yes, as well as "O-O(-O)" and "KxOwnR" do. The oldest FRC games I found on ICC are from 1997 using the "O-O" notation. I'm not aware if Xboard/Winboard supported that from that time on, but it seems it works very well.

Reinhard Scharnagl wrote:This solution might be recommended for UCI or Winboard,...

A working solution is already implemented in Winboard for many years (if running at ICSs). I see no reason to change it.

Reinhard Scharnagl wrote:...even if SMK does it by unnecessaryily establishing a separate FRC view.

Interpreting "KxOwnRook" as "O-O(-O)" seems to be easy. It may be a reinvention of the wheel, but from a programming point of view I don't see big problems with that notation.

Volker

Hi Volker,

there are different problems related to use only O-O or O-O-O to signal
castlings between the GUI and an engine.

a) following the idea to compatibly include SP-518 (traditional chess) that
conflicts with the use of algebraic notation: source and destination coordinates.

b) it is not necessary, that a GUI knows about valid moves. In Smirf it
gets such information by a trusted engine. A move in the GUI is per-
formed by requesting a trusted engine for an actual FEN string after that
move. So Smirf would not have any problems using O-O or O-O-O, but
this would not be compatible in UCI or WINBOARD.

c) because of a GUI like Smirf does not know about valid moves, it has
to be supported by coordinate encoded moves to become able to relate
clicks to moves. In an earlier version of Smirf there have been smaller
selection dialogs in the case of promotions or ambiguities between simple
King's moves and castlings. The proposed formula avoids such selection
dialogs in case of castlings.

Overall the proposed formula solves a lot of problems and is compatible.

Reinhard.

P.S.:

That seems the be a violation of the rules of chess.

The communication between engine and GUI is not subject of the rules
of chess. My proposal does in no way change the move encoding itself
e.g. in PGN file entries.

Reinhard Scharnagl wrote:...

a) following the idea to compatibly include SP-518...

b) it is not necessary, that a GUI knows about valid moves. In Smirf it
gets such information by a trusted engine....

c) because of a GUI like Smirf does not know about valid moves, it has
to be supported by coordinate encoded moves to become able to relate
clicks to moves.

To associate clicks to the intended moves seems to be a problem of the GUIs. Using Ctrl+click (as implemeted in Arena) or typing "O-O" (as at ICC) seems to be usable solutions too.

In console mode I'm going to allow "O-O" and "KxR" in my engine.

Volker