ChessGUI and Chess960

[TonyJH]

There seems to be a total of 3 engines that use the new approach.
2 of them are Sjaak and TJchess, whose authors have posted in this thread.
Maybe TJchess goes the new way only for variants other than FRC.

The author of the 3rd engine may not be aware of the different approach.


Matthias.

OK - but TJChess runs perfectly under ChessGUI

I think the UCI version of TJchess works fine with ChessGUI for FRC. There's also a WB version of TJchess, which I guess will not work with ChessGUI for FRC, because of this issue. I'm glad at least one works.

[TonyJH]

Does anyone have the list of XBoard FRC engines that use KxR notation? I'm curious how many there are.

3 as I said, using AHah.

Thanks, I missed that.

[Matthias Gemuh]

Does anyone have the list of XBoard FRC engines that use KxR notation? I'm curious how many there are.

3 as I said, using AHah.

Oops, wrong ! I was distracted on phone.

[Alexander Schmidt]

We argue about trivial, and what you say is often inconsistent.

Indeed. But in fact I did not change anything...

What I 'changed' was the FEN format castling field,

No, sorry, but you are again mis-informed. As you can see from my other post there was a standard already in 1998.

WinBoard protocol did not support FRC castling rights at all,

There never has been another standard than the one we have now for FRC castling moves in WB protocol.

at least get your facts straight,

[Modern Times]

I think the UCI version of TJchess works fine with ChessGUI for FRC. There's also a WB version of TJchess, which I guess will not work with ChessGUI for FRC, because of this issue. I'm glad at least one works.

Oh of course, sorry, it is indeed the UCI version of TJChess that I use under ChessGUI.

[Evert]

Speaking of Seirawan Chess - does XBoard understand what I want if I send "O-O/Eh1" rather than h1e1e?

[hgm]

We argue about trivial, and what you say is often inconsistent.

Indeed. But in fact I did not change anything...

What I 'changed' was the FEN format castling field,

Sorry for being not clear, then. What I meant is that I did not change anything with respect to the subject we were discussing in this thread. In fact I changed a lot of things. (I redecorated my house, retired from my job...) But that hardly relevant. Castling rights are not the discussion topic of this thread. What this thread is about is the move notation of castlings.

No, sorry, but you are again mis-informed. As you can see from my other post there was a standard already in 1998.

WinBoard protocol did not support FRC castling rights at all,

There never has been another standard than the one we have now for FRC castling moves in WB protocol.

at least get your facts straight,

Again, the confusion is between castling rights in FEN and move notation in SAN or the long-algebraic protocol move format. Which are completely different subjects, which have a completely different history:

Move notation:
Foreseen long before WinBoard actually supported FRC in any form, and defined somewhere before 1998 in the protocol specs to be O-O / O-O-O. Which have remained the official specs upto this very day.

FEN Castling rights:
Unforseen by the WinBoard developers, and not payed much attention to as castling rights did not even work in WinBoard for normal Chess. Early implementation of FRC in WinBoard forks therefore ignored this FEN and assumed all conceivable castlings were always possible.
A (never published) protocol v3 proposal was made somewhere after 2003, where the rights problem is first recognized, and the HAha notation is proposed standard.
In the mean time Arena does an FRC implementation that violates all standards (it seems that upto today you need Polyglot to run UCI FRC engines under Arena because the UCI implementation does not work at all), and for WB protocol is broken for positions twith both Rooks on the same side of the King (which cannot occur as start positions).
Somewhere in 2007/2008 I made WinBoard castling-rights aware, and to fix the FRC implementation I had to adopt a FEN standard, as the rights would no longer be ignored. So I had WinBoard use Shredder FEN, which is the same as UCI uses, and in general is the easiest on engine programmers. ChessGUI uses that too.

I hope this clears up all confusion.

P.S.
I always believed that the problem with the UCI implementation of FRC in Arena was exactly that it does uses O-O castling rather than KxR castling, which is a fatal violation of the UCI specs. (Please correct me if I am wrong.) That would make it hard to believe Arena would use KxR notation in WB protocol...

[hgm]

Speaking of Seirawan Chess - does XBoard understand what I want if I send "O-O/Eh1" rather than h1e1e?

I am afraid not...

This is still something that has not crystallized into its final form. When writing and reading SAN WB actually uses Rhxe1/E (while O-O/E would gate at e1). Which is awful. But as this is mostly a hypothetical move that never occurs in practice, fixing it did not have a very high priority.

[Evert]

1. I will accept AHah and KQkq for castling moves in FRC. I already should, but I don't (I mis-read the protocol specs as saying XBoard will send KQkq when the king and rooks are in their normal positions and AHah when they are not). This is a bug in Sjaak, I'll fix it.

This is now done by internally converting KQkq-style FENs to AHah-style FENs in all situations. This should always work, but I may have messed something up.

If anyone wants to help test this, I have (Windows) executables up at http://www.eglebbk.dds.nl/program/downl ... 10-win.zip

[Evert]

Speaking of Seirawan Chess - does XBoard understand what I want if I send "O-O/Eh1" rather than h1e1e?

I am afraid not...

This is still something that has not crystallized into its final form. When writing and reading SAN WB actually uses Rhxe1/E (while O-O/E would gate at e1). Which is awful. But as this is mostly a hypothetical move that never occurs in practice, fixing it did not have a very high priority.

Ok. Oh well.

I currently special-case gating on the rook square when sending the move, and I have some ugly code that fudges the from/to squares in case it doesn't find a legal move with the specified squares to see whether it's a castle move. It seemed to work when I tried it by hand and I haven't seen a problem in games (but I haven't payed close attention to those to be honest, so the problem may not present itself at all).

My impression is that the many heavy pieces make Seirawan Chess less interesting than it could be...