An FRC compatible xboard (sort of)

[Fabien Letouzey]

Why not use the sceme SMIRF does? Between engine and GUI castling moves are translated corresponding to the GUI input gesture which is: a) King moves to his castling target field, if this would cause at least two elementary steps, b) otherwise King moves to the involved Rook to signal a matching castling. That way even short range castling moves are distinct from King's single step moves. Castling moves from traditional chess also compatibly fit still into that scheme.

Hi Reinhard,

The internal representation is not important in this case, as long as it's not ambiguous. We only need to be careful with output (to engines and servers).

The only problem is lack of knowledge regarding XBoard's design, and I don't want to spend a lot of time on this software.

In other words, there is no chess-related problem.

Thanks,

Fabien.

[Reinhard Scharnagl]

Fabien,

We only need to be careful with output (to engines and servers).

That is what I am talking about. I pointed to the way how algebraic notation (pairs of coordinates) will be exchanged between Smirf's GUI and engine. The internal representation of castling moves in SMIRF is very different to this.

For me it has been very important, that the communicated pairs of coordinates would also correspond to the to be clicked squares on the GUI to manually signal a castling move to be entered.

Reinhard.

[milix]

I made more changes in xboard 4.2.7 and now is working properly. My previous mods were not complete and (based to what I change lately) worked only in rarer cases, sorry for this. So, my complete list of mods are:
- Added the menu entry File->New FRC Game. You can start a new FRC game by entering pos id or fen.
- Added menu entry Options->Set time control.
- Added menu entries and buttons for A-side and H-side castling. Works in normal chess too.
- PGN saving works ok now with FRC games.

I modified the following files: common.h, backed.h, backend.c, xboard.c, moves.c. All mods are marked with a '// milix hack' remark.
I tested the new xboard-frc in various positions inlcuding normal chess, and frc position 417 (caused problems with my previous mods and helped me to track down the bugs).

My mods can be found in http://www.milix.net/aice/downloads.html

[Tord Romstad]

My mods can be found in http://www.milix.net/aice/downloads.html

Hi Anastasios,

Thanks for your work. I would like to try your FRC xboard, but unfortunately the download link on your home page doesn't work for me. I get "The requested URL /aice/xboard-4.2.7-frc.tar.bz2 was not found on this server".

By the way, did you get my personal message yesterday? The Linux version of AICE 0.90 seems to be seriously broken. It's not just the one game I sent to you, AICE quite often hangs pieces and makes elementary blunders in my tests, and loses lots of won or drawn positions.

Tord

[milix]

Hi Tord,

I get "The requested URL /aice/xboard-4.2.7-frc.tar.bz2

Perhaps this is a problem with cached page. The new name is 'xboard-frc-4.2.7.tar.bz2', the frc is in front of the version number.

By the way, did you get my personal message yesterday? The Linux version of AICE 0.90 seems to be seriously broken. It's not just the one game I sent to you, AICE quite often hangs pieces and makes elementary blunders in my tests, and loses lots of won or drawn positions.

Yes, thank you! AICE 0.90 had many bugs in its search, sorry. AICE 0.92 and 0.93 still have known bugs in frc short castle. They blunder also but not in the way 0.90 did

[Tord Romstad]

Hi Tord,

I get "The requested URL /aice/xboard-4.2.7-frc.tar.bz2

Perhaps this is a problem with cached page. The new name is 'xboard-frc-4.2.7.tar.bz2', the frc is in front of the version number.

Thanks, this time I managed to download the file! I've only tested it for a few minutes, but so far everything seems to work well. Your XBoard-FRC is compatible with the recent PolyGlot beta without any modifications to either program.

I used your program to play my first ever FRC game. The opponent, of course, was my own engine. Considering that Mainz is less than one week away, the result was rather depressing:

Code: Select all

[Event "Computer chess game"]
[Site "aload.uio.no"]
[Date "2005.08.05"]
[Round "-"]
[White "Tord Romstad"]
[Black "Glaurung 050804"]
[Result "1-0"]
[TimeControl "40/300"]
[Variant "fischerandom"]
[FEN "qnnrkrbb/pppppppp/8/8/8/8/PPPPPPPP/QNNRKRBB w KQkq - 0 1"]
[SetUp "1"]

{--------------
q n n r k r b b
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
Q N N R K R B B
white to play
--------------}
1. b3 f5 2. g3 Bf7 3. d4 Nb6 4. Nd3 Nc6 5. c4 O-O-O 6. f4 d5 7. c5 Nd7 8.
Bf2 e6 9. O-O h6 10. b4 a6 11. Qb2 g5 12. e3 a5 13. a3 axb4 14. axb4 Bh5
15. Rde1 Bf6 16. Nc3 Qb8 17. Ra1 Rg8 18. Ra2 b6 19. Rfa1 Qb7 20. b5 Na5 21.
c6 Qb8 22. cxd7+ Kxd7 23. Ne5+ Ke8 24. Rxa5 bxa5 25. Nc6 Qc8 26. Nxd8 Bxd8
27. Rxa5 gxf4 28. exf4 c6 29. Ra7 Rf8 30. Qa3 Rf7 31. Ra8 Qc7 32. bxc6 Qxc6
33. Qa4 Rc7 34. g4 Qxa4 35. Nxa4 Rc1+ 36. Kg2 Bxg4 37. Bh4 Rc2+ 38. Kg3 Ra2
39. Rxd8+ Kf7 40. Nc3 Rd2 41. Nb5 Rb2 42. Nd6+ Kg6 43. Bg2 Kh5 44. h3 Rb3+
45. Kh2 Kxh4 46. hxg4 Kxg4 47. Re8 Re3 48. Nb5 Kxf4 49. Nc7 Kg4 50. Rxe6
Rb3
{Black resigns} 1-0


By the way, did you get my personal message yesterday? The Linux version of AICE 0.90 seems to be seriously broken. It's not just the one game I sent to you, AICE quite often hangs pieces and makes elementary blunders in my tests, and loses lots of won or drawn positions.

Yes, thank you! AICE 0.90 had many bugs in its search, sorry. AICE 0.92 and 0.93 still have known bugs in frc short castle. They blunder also but not in the way 0.90 did

OK! I hope you'll be able to solve your castling bugs before Mainz, and that there will be an updated Linux version of AICE soon.

See you next week!

Tord

[Volker Pittlik]

I've incorporated the changes into my (Windows) version and compiled, but not tested yet in play. However, everything seems ok so far...

There seems to be something strange. When I manually setup this position:

[diag]k7/8/8/8/8/8/8/1RK3R1 w[/diag]

k7/8/8/8/8/8/8/1RK3R1 w GB - 0 1

And copy the position to the clipboard I get the correct (SMK) FEN as above. But the engine gets:

Code: Select all

182594 >first : setboard k7/8/8/8/8/8/8/1RK3R1 w KQ - 0 1

if I switch from "Edit position" to "Edit game". The same happens if the FEN is pasted into Winboard:

Code: Select all

PasteTextFromClipboard(): lock count 0
PasteTextFromClipboard(): lock count 0
PasteTextFromClipboard(): err 0 locked 0
PasteFenFromString(): fen 'k7/8/8/8/8/8/8/1RK3R1 w GB - 0 1
'
14906 >first : force
14906 >first : new
random
14906 >first : variant fischerandom
14906 >first : level 40 5 0
14906 >first : hard
14906 >first : ping 2
14906 >first : force
14906 >first : setboard k7/8/8/8/8/8/8/1RK3R1 w KQ - 0 1

I can live with both, but if it where handled standardised my test would be a bit easier.

Regards

Volker

[Tord Romstad]

I've incorporated the changes into my (Windows) version and compiled, but not tested yet in play. However, everything seems ok so far...

There seems to be something strange. When I manually setup this position:

[diag]k7/8/8/8/8/8/8/1RK3R1 w[/diag]

k7/8/8/8/8/8/8/1RK3R1 w GB - 0 1

And copy the position to the clipboard I get the correct (SMK) FEN as above. But the engine gets:

Code: Select all

182594 >first : setboard k7/8/8/8/8/8/8/1RK3R1 w KQ - 0 1

Hi Volker,

Which XBoard-960 are you using? If you use the one by Fabien and me, it sends FENs to the engine with KQkq style castling rights by default. Engines which want FENs with SMK style castling rights should send "feature fen960=1" at startup.

We did it like this in order to make it compatible with existing Chess960 enabled XBoard/Winboard engines, like AICE.

Tord

[Volker Pittlik]

...
Which XBoard-960 are you using? If you use the one by Fabien and me, it sends FENs to the engine with KQkq style castling rights by default. Engines which want FENs with SMK style castling rights should send "feature fen960=1" at startup.

We did it like this in order to make it compatible with existing Chess960 enabled XBoard/Winboard engines, like AICE.

Tord

I used the executable made by Alessandro (http://www.ascotti.org/programming/chess/zip/winboard_x_frc.zip).

I thought it is based on your version. Therefore this may happen in your version too?

For whatever reason I can't compile your version here. MSVC++ 6 always complains about missing include files. I tried the winboard.dsw, msvc.mak and also by trying to create a new project.

Volker

[Tord Romstad]

...
Which XBoard-960 are you using? If you use the one by Fabien and me, it sends FENs to the engine with KQkq style castling rights by default. Engines which want FENs with SMK style castling rights should send "feature fen960=1" at startup.

We did it like this in order to make it compatible with existing Chess960 enabled XBoard/Winboard engines, like AICE.

Tord

I used the executable made by Alessandro (http://www.ascotti.org/programming/chess/zip/winboard_x_frc.zip).

I thought it is based on your version.

I think it is, although I am not quite sure it is based on the latest version.

Therefore this may happen in your version too?

Yes, as far as I can see the behaviour you observe is exactly what I would expect from my version. And as I said, it is like this by design. I want XBoard to send FENs with castling rights in the KQkq format, unless the engine explicitly asks for the HAha format. This is the only way I can maintain compatibility with existing Chess960 XBoard/Winboard engines.

Is there a problem with this solution?

For whatever reason I can't compile your version here. MSVC++ 6 always complains about missing include files. I tried the winboard.dsw, msvc.mak and also by trying to create a new project.

I can't help you with this, I'm afraid.

Tord

[Volker Pittlik]

...
Yes, as far as I can see the behaviour you observe is exactly what I would expect from my version. And as I said, it is like this by design. I want XBoard to send FENs with castling rights in the KQkq format, unless the engine explicitly asks for the HAha format. This is the only way I can maintain compatibility with existing Chess960 XBoard/Winboard engines.

Is there a problem with this solution?

Not a big one. I allready modify my setboard.c. The only problem I can see now when reading a FEN using KQkq format is the following:

If there is more than one rook in the direction the King moves I have to choose one of them to establish the castling right with. In such a case I choose the rook standing closest to the King. That is complete arbitrariness, but I can't think of something better. (Before someone asks: my engine will understand X- and SMK- FEN too.)

Regards
Volker

[Tord Romstad]

...
Yes, as far as I can see the behaviour you observe is exactly what I would expect from my version. And as I said, it is like this by design. I want XBoard to send FENs with castling rights in the KQkq format, unless the engine explicitly asks for the HAha format. This is the only way I can maintain compatibility with existing Chess960 XBoard/Winboard engines.

Is there a problem with this solution?

Not a big one. I allready modify my setboard.c. The only problem I can see now when reading a FEN using KQkq format is the following:

If there is more than one rook in the direction the King moves I have to choose one of them to establish the castling right with. In such a case I choose the rook standing closest to the King.

XBoard-960 does exactly the opposite. It assumes that the outermost rook is the one involved in castling.

But why not just use "feature fen960=1"? This will give you SMK-FENs.

Tord

[Volker Pittlik]

...
XBoard-960 does exactly the opposite. It assumes that the outermost rook is the one involved in castling...

Changed. I thought about it and found there is no difference. Both decisions may be false.

But why not just use "feature fen960=1"? This will give you SMK-FENs...

Stupid me tried to enter that as command line parameter . I will implement that later this day.

Regards

Volker

BTW: Thank you (and all others involved) for the FRC capability of Winboard!

[Volker Pittlik]

...

But why not just use "feature fen960=1"? This will give you SMK-FENs.

Tord

Confirmed! Works perfectly:

winboard.debug:

Code: Select all

562 <first : feature fen960=1
562 >first : accepted fen960
562 <first : feature done=1
562 >first : accepted done
578 >first : new
random
578 >first : variant fischerandom
578 >first : level 40 5 0
578 >first : hard
578 >first : ping 1
578 <first : pong 1
PasteTextFromClipboard(): lock count 0
PasteTextFromClipboard(): lock count 0
PasteTextFromClipboard(): err 0 locked 0
PasteFenFromString(): fen 'k7/8/8/8/8/8/8/1RK3R1 w GB - 0 1 '
11375 >first : force
11375 >first : new
random
11375 >first : variant fischerandom
11375 >first : level 40 5 0
11375 >first : hard
11375 >first : ping 2
11375 >first : force
11375 >first : setboard k7/8/8/8/8/8/8/1RK3R1 w GB - 0 1


Pelikan.log:

Code: Select all

Input: variant fischerandom.
Input: level 40 5 0.
Input: hard.
Input: ping 2.
pong 2
Input: force.
Input: setboard k7/8/8/8/8/8/8/1RK3R1 w GB - 0 1.

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

White's turn: (1.)

Regards
Volker

[Volker Pittlik]

One last comment: Wouldn't it be more consistent to send the notation in the KQkq style (if pressing <Shift>+<Alt>+<C>) if feature fen960=0 is choosen?

Personally I prefer the HAha style because it is unambiguous but this behaviour of the program may cause confusion. (Again I'm the best example . )

Best regards
Volker

[Tord Romstad]

One last comment: Wouldn't it be more consistent to send the notation in the KQkq style (if pressing <Shift>+<Alt>+<C>) if feature fen960=0 is choosen?

I'm not sure I understand what you mean. What is the key combination <Shift>+<Alt>+<C> supposed to do? It does nothing at all in XBoard in Mac OS X; I suppose it is some Winboard-only thing. The notation is sent in KQkq style to the engine when feature fen960=0 is chosen, if that is what you ask.

Personally I prefer the HAha style because it is unambiguous but this behaviour of the program may cause confusion. (Again I'm the best example . )

I also prefer the HAha style, but it must be disabled by default -- otherwise AICE, Hermann, etc. will not work.

Tord

[Volker Pittlik]

...I'm not sure I understand what you mean. What is the key combination <Shift>+<Alt>+<C> supposed to do? It does nothing at all in XBoard in Mac OS X; I suppose it is some Winboard-only thing. The notation is sent in KQkq style to the engine when feature fen960=0 is chosen, if that is what you ask.

The key combination does the same as if "Copy Position To Clipboard" was choosen from the "File" menu. I assumed positions in identical notation were send to the engine and to the clipboard. Now I know this may be different it is not a problem for me.

...

...I also prefer the HAha style, but it must be disabled by default -- otherwise AICE, Hermann, etc. will not work.

Tord

Yes.

Regards
Volker

[Tord Romstad]

...I'm not sure I understand what you mean. What is the key combination <Shift>+<Alt>+<C> supposed to do? It does nothing at all in XBoard in Mac OS X; I suppose it is some Winboard-only thing. The notation is sent in KQkq style to the engine when feature fen960=0 is chosen, if that is what you ask.

The key combination does the same as if "Copy Position To Clipboard" was choosen from the "File" menu. I assumed positions in identical notation were send to the engine and to the clipboard.

OK, Now I understand better. It wouldn't make sense to let the format used when choosing "Copy Position to Clipboard" depend on whether the engine sends "feature fen960=1" or "feature fen960=0". The "feature" system in the XBoard protocol is meant as a way to configure the communication between the engine and the GUI, nothing more. It has nothing to do with how the GUI looks or behaves to the user, or how the saved representation of games or positions look.

It may be a good idea to make it possible to choose between HAha and KQkq notation when saving games and positions in XBoard-960, but the "fen960" feature is the wrong place to do it. It makes no sense that the engine decides what format to use when saving files. This choice should be left to the user, perhaps in the form of a new menu item or startup option.

Tord

[Reinhard Scharnagl]

Hi Tord,

... This choice should be left to the user, perhaps in the form of a new menu item or startup option.

reading this makes me shake my head. Could there be any intelligent reason to enable storing of FEN or PGN into an incompatible form? I am wondering, why so much people are joining that wrong way of SMK-FEN.

They all will have a lot of work again, when SMK will be changing his lonely approach in short...

Reinhard.

[Volker Pittlik]

... Could there be any intelligent reason to enable storing of FEN or PGN into an incompatible form? I am wondering, why so much people are joining that wrong way of SMK-FEN...

Maybe because all these people are intelligent enough to recognise SMK's style is an easy and comprehensive solution of the problems?

When you discover that you are riding a dead horse, the best strategy is to dismount.

Wisdom of the Dakota Indians

Regards
Volker