Winboard Forum

What do programmers need to add in order to support FRC?

I want to support both shredder-fen and x-fen.

steps to do:
1)change the move generator to generate FRC castling moves
2)change the make move to enable it to make FRC castling moves
3)change the make move to enable it to change information about castling rights correctly in FRC(
today I calculate future castling rights simply by
if (castle>0)
{
castle&=castle_mask[from]&castle_mask[to];
}

I will need to change it to something similiar to glaurung like
if (from==..,)||(from==...)||(from==...)||(to==...)||(to==...)||(to==...)


3)change the function that get fen to get shredder-fen and translate it to the board structure
4)change the function that get fen to get x-fen and to translate it to the board structure.
5)change the function that get moves to understand shredder moves and x fen moves(shredder moves are king take rook for castling)

Did I forget something?

known problem that I need to handle with xfen:
1)getting fen when there is a rook that moved between the rook that can castle and the king.
In this case xfen tell me that
"traditional castling tag will be replaced by the file letter of the involved R"

2)castling when the king move one square
In this case I probably need to understand only 0-0 or o-o as short castling and 0-0-0 or o-o-o as long castling.

In supporting shredder-fen I need to have #if defined(FRC) only in the function that give the moves output(understanding does not need to have it because I can change my code to understand both FRC notation of shredder FEN and FRC notation of X-FEN)

Am I right?
Did I forget something?

Uri

Hello Uri,

2)castling when the king move one square
In this case I probably need to understand only 0-0 or o-o as short castling and 0-0-0 or o-o-o as long castling.

Your engine needs to understand O-O (Oh) for Arena and king takes rook for Shredder.

In supporting shredder-fen I need to have #if defined(FRC) only in the function that give the moves output(understanding does not need to have it because I can change my code to understand both FRC notation of shredder FEN and FRC notation of X-FEN)

To support both, Shredder and Arena, your move-to-string-conversion can do
something like this:

Code: Select all

if ( last FEN was Shredder-FEN )
{
   print king takes rook
}
else if ( Option UCI_Chess960 /* UCI */ || variant fischerandom /* WB */ )
{
   print O-O
}
else
{
   print e1g1
}


Code like that is in Hermann. I think it is ugly but still better than another option that tells the engine which GUI it runs in or to compile different versions with #if defined( FRC ).

Greetings
Volker

Uri Blass wrote:3)change the make move to enable it to change information about castling rights correctly in FRC(
today I calculate future castling rights simply by
if (castle>0)
{
castle&=castle_mask[from]&castle_mask[to];
}

I will need to change it to something similiar to glaurung like
if (from==..,)||(from==...)||(from==...)||(to==...)||(to==...)||(to==...)

I've started the same thing, although for the castling I kept the same function using the square bits. castleflags & board[from].

When the fen string is parsed, I just reset the castle bits array according to where the king and rooks are placed.

Richard

Richard Allbert wrote:

Uri Blass wrote:3)change the make move to enable it to change information about castling rights correctly in FRC(
today I calculate future castling rights simply by
if (castle>0)
{
castle&=castle_mask[from]&castle_mask[to];
}

I will need to change it to something similiar to glaurung like
if (from==..,)||(from==...)||(from==...)||(to==...)||(to==...)||(to==...)

I've started the same thing, although for the castling I kept the same function using the square bits. castleflags & board[from].

When the fen string is parsed, I just reset the castle bits array according to where the king and rooks are placed.

Richard

You are right but I think that the solution in glaurung is more elegant.

I do not like adding code only to keep the array and I think that the array by itself is not an elegant solution.

castle&=castle_mask[from]&castle_mask[to]; does not change castle in most cases and it is better to change castle only when the from or the to square is one of 6 squares like done in glaurung

if(from==InitialKSQ || from==InitialKRSQ || to==InitialKRSQ)
ProhibitOO(pos, WHITE);

Hi Uri,

actually I am writing an X-UCI version of SMIRF, which will be able both: a) to run Chess960 compatibly using X-FEN under Arena based on the UCI-2 protocol, b) to run Chess960 under a newer Shredder GUI, c) to play tratitional Chess under older traditional UCI GUIs. Unfortunately I currently have less time left for development, so it will need some weeks until SMIRF will be ready for UCI.

Regards, Reinhard.

Uri Blass wrote:What do programmers need to add in order to support FRC?

I want to support both shredder-fen and x-fen.

steps to do:
1)change the move generator to generate FRC castling moves
2)change the make move to enable it to make FRC castling moves
3)change the make move to enable it to change information about castling rights correctly in FRC(
today I calculate future castling rights simply by
if (castle>0)
{
castle&=castle_mask[from]&castle_mask[to];
}

I will need to change it to something similiar to glaurung like
if (from==..,)||(from==...)||(from==...)||(to==...)||(to==...)||(to==...)


3)change the function that get fen to get shredder-fen and translate it to the board structure
4)change the function that get fen to get x-fen and to translate it to the board structure.
5)change the function that get moves to understand shredder moves and x fen moves(shredder moves are king take rook for castling)

Did I forget something?

known problem that I need to handle with xfen:
1)getting fen when there is a rook that moved between the rook that can castle and the king.
In this case xfen tell me that
"traditional castling tag will be replaced by the file letter of the involved R"

2)castling when the king move one square
In this case I probably need to understand only 0-0 or o-o as short castling and 0-0-0 or o-o-o as long castling.

In supporting shredder-fen I need to have #if defined(FRC) only in the function that give the moves output(understanding does not need to have it because I can change my code to understand both FRC notation of shredder FEN and FRC notation of X-FEN)

Am I right?
Did I forget something?

Uri

I see that I forgot one important step and it is to change the unmake move to unmake FRC moves

I also forgot that there is one more step simply because I forgot to write step 4 after step 3 and wrote step 3 twice.

I believe that at this point of time I implemented steps 2-4 correctly
still missing is implementation of castling in the move generator unmake move and reading castling moves in FRC

Uri

Uri Blass wrote:

Code: Select all

if (castle>0)
{
castle&=castle_mask[from]&castle_mask[to];
}


It's probably not the bottleneck, and won't get you lots of Elos, but why are you using if (castle>0) instead of if (castle!=0)?

My intuition tells me that the second would be slightly faster, but then again my assembly knowledge is about 7 years out of date (and out of mind...)

Nicolai Czempin wrote:

Uri Blass wrote:

Code: Select all

if (castle>0)
{
castle&=castle_mask[from]&castle_mask[to];
}


It's probably not the bottleneck, and won't get you lots of Elos, but why are you using if (castle>0) instead of if (castle!=0)?

My intuition tells me that the second would be slightly faster, but then again my assembly knowledge is about 7 years out of date (and out of mind...)

You may be right and I have no assembly knowledge.

castle is int and can get negative values but I can also do castle to be unsigned int so it cannot get negative value and in this case
castle>0 and castle!=0 are equivalent.

Uri

Hi,
i see i am not only ones that have all kind of problems, i had before go mainz

there is a big confusing of implementation of the castles, the solution what i found is very simple.

using always O-O input/output for castles, they are not need UCI_Chess960 options, x-fen or shredder fen.

the PGN standard is O-O/O-O-O for castles, and if we humans write on the game formular to understand also O-O and O-O-O format.

Or we must wait a while if there are found a standard solution for castles for computerchess.


but for now you must implement the O-O format for Arena, the king takes rook for Shredder and winboard.

i will make a UCI option for castles IO can selectable in 3 ways.

1) O-O/O-O-O (chess960 under Arena)
2) e1g1/e1c1 (standard)
3) e1h1/e1a1 (chess960 under shredder/winboard)

best wishes,
Engin

Engin Üstün wrote:Hi,
i see i am not only ones that have all kind of problems, i had before go mainz

there is a big confusing of implementation of the castles, the solution what i found is very simple.

using always O-O input/output for castles, they are not need UCI_Chess960 options, x-fen or shredder fen.

the PGN standard is O-O/O-O-O for castles, and if we humans write on the game formular to understand also O-O and O-O-O format.

Or we must wait a while if there are found a standard solution for castles for computerchess.


but for now you must implement the O-O format for Arena, the king takes rook for Shredder and winboard.

i will make a UCI option for castles IO can selectable in 3 ways.

1) O-O/O-O-O (chess960 under Arena)
2) e1g1/e1c1 (standard)
3) e1h1/e1a1 (chess960 under shredder/winboard)

best wishes,
Engin

I want to be able to use all options
today movei already can read fen and solve perft problems correctly

I believe that I have no bugs in reading output but I am not sure about it.

The only thing that I still did not implement is the output of castling moves.

I guess that reading input should be always clear and I will assume that move in the format e1g1 is castling move only in case that the distance is different than 1 square(otherwise I will assume that it is king move)

I hope that when the distance is 1 there are only 2 format for castling 0-0 and king take rook.

Uri

Uri wrote:... I guess that reading input should be always clear and I will assume that move in the format e1g1 is castling move only in case that the distance is different than 1 square(otherwise I will assume that it is king move) ...

More precise is:

a) UCI-2 standard: use source and target coordinates, this would be downwards compatible to old UCI GUIs playing traditional chess. I suggest to use the "Rook jostling" move, King's and Rook's source coordinates, only, when the King's castling move consists of less than two steps (to avoid misinterpretations with regular King steps and technical nullmoves). To remain compatible it is necessary to support X-FEN, if the engine should be aware of all possible positions, if not being merely starting array positions.

(That encoding moreover does define a clear input gesture for to enter castling moves at the GUI simply by clicking at the two involved coordinates, without changing the behaviour for traditional castlings. P.S.: I am just writing such an UCI-engine, the SMIRF TMCI GUI acts like that already for long.)

b) Arena handling: UCI engines supply a (constant) option "FRC" and a switch to always communicate castlings using "O-O/O-O-O".

c) Shredder UCI: uses an option switch into a UCI_Chess960 mode, where an incompatible FEN extension is used (different position encodings exist for identical positions), and castlings are communicated always by a "Rook jostling".

Reinhard.

Reinhard Scharnagl wrote:

Uri wrote:... I guess that reading input should be always clear and I will assume that move in the format e1g1 is castling move only in case that the distance is different than 1 square(otherwise I will assume that it is king move) ...

More precise is:

a) UCI-2 standard: use source and target coordinates, this would be downwards compatible to old UCI GUIs playing traditional chess. I suggest to use the "Rook jostling" move, King's and Rook's source coordinates, only, when the King's castling move consists of less than two steps (to avoid misinterpretations with regular King steps and technical nullmoves). To remain compatible it is necessary to support X-FEN, if the engine should be aware of all possible positions, if not being merely starting array positions.

(That encoding moreover does define a clear input gesture for to enter castling moves at the GUI simply by clicking at the two involved coordinates, without changing the behaviour for traditional castlings. P.S.: I am just writing such an UCI-engine, the SMIRF TMCI GUI acts like that already for long.)

b) Arena handling: UCI engines supply a (constant) option "FRC" and a switch to always communicate castlings using "O-O/O-O-O".

c) Shredder UCI: uses an option switch into a UCI_Chess960 mode, where an incompatible FEN extension is used (different position encodings exist for identical positions), and castlings are communicated always by a "Rook jostling".

Reinhard.

Movei is aware of both x-FEN and smk-FEN

I still need to check that it has no bugs and I still did not check SMK-fen or X-fen in the rare cases when there are 2 rooks on the same side of the king.

I understand that you suggest king take rook even when the king does not move to avoid understanding castle as null move.


I did not think about b1b1 as null move(if I need to translate null move to string then I translate it to a1a1 that is not possible castling move) but
if you say that your interface is going to understand b1b1 as null move and b1a1(when white has rook at a1 and king at b1) as castling move then of course there is a reason to use b1a1 for castling in that case.

Uri

Uri wrote:Movei is aware of both x-FEN and smk-FEN

I try to have the same with SMIRF X-UCI version then.

Uri wrote:I still need to check that it has no bugs and I still did not check SMK-fen or X-fen in the rare cases when there are 2 rooks on the same side of the king.

That is just, where X-FEN would be needed (or Shredder FEN).

Uri wrote:I understand that you suggest king take rook even when the king does not move to avoid understanding castle as null move.

I did not think about b1b1 as null move(if I need to translate null move to string then I translate it to a1a1 that is not possible castling move) but
if you say that your interface is going to understand b1b1 as null move and b1a1(when white has rook at a1 and king at b1) as castling move then of course there is a reason to use b1a1 for castling in that case.

Well, it has to do with the idea to relate the move encoding also to a clearly defined input gesture of the GUI to enter castling moves. It would be more difficult to enter a double field click for to define a King's move.

Reinhard.

P.S.: I am rather talking of 'jostling' the Rook instead of 'capturing' it.

Volker Annuss wrote:Hello Uri,

2)castling when the king move one square
In this case I probably need to understand only 0-0 or o-o as short castling and 0-0-0 or o-o-o as long castling.

Your engine needs to understand O-O (Oh) for Arena and king takes rook for Shredder.

In supporting shredder-fen I need to have #if defined(FRC) only in the function that give the moves output(understanding does not need to have it because I can change my code to understand both FRC notation of shredder FEN and FRC notation of X-FEN)

To support both, Shredder and Arena, your move-to-string-conversion can do
something like this:

Code: Select all

if ( last FEN was Shredder-FEN )
{
   print king takes rook
}
else if ( Option UCI_Chess960 /* UCI */ || variant fischerandom /* WB */ )
{
   print O-O
}
else
{
   print e1g1
}


Code like that is in Hermann. I think it is ugly but still better than another option that tells the engine which GUI it runs in or to compile different versions with #if defined( FRC ).

Greetings
Volker

I have one question
What is the string that winboard send to the engine in order to know that the following condition happens?

if ( Option UCI_Chess960 /* UCI */ || variant fischerandom /* WB */ )

Reinhard Scharnagl wrote:

Uri wrote:Movei is aware of both x-FEN and smk-FEN

I try to have the same with SMIRF X-UCI version then.

Uri wrote:I still need to check that it has no bugs and I still did not check SMK-fen or X-fen in the rare cases when there are 2 rooks on the same side of the king.

That is just, where X-FEN would be needed (or Shredder FEN).

Uri wrote:I understand that you suggest king take rook even when the king does not move to avoid understanding castle as null move.

I did not think about b1b1 as null move(if I need to translate null move to string then I translate it to a1a1 that is not possible castling move) but
if you say that your interface is going to understand b1b1 as null move and b1a1(when white has rook at a1 and king at b1) as castling move then of course there is a reason to use b1a1 for castling in that case.

Well, it has to do with the idea to relate the move encoding also to a clearly defined input gesture of the GUI to enter castling moves. It would be more difficult to enter a double field click for to define a King's move.

Reinhard.

P.S.: I am rather talking of 'jostling' the Rook instead of 'capturing' it.

If I understand correctly the notation is the same for jostling and capruring.

Uri

I think that I solved the problem and winboard command random simply tell the engine to print castle as 0-0 under winboard

I noticed that under winboard movei get the winboard command random if I try to start FRC game.

Uri

winboard send the variant=fischerrandom option to the engine to play FRC/Chess960

UCI engines use polyglot 1.4 that can handle FRC for winboard.

and use winboard_X a modified winboard for FRC, but something is wrong with this.

Engin Üstün wrote:winboard send the variant=fischerrandom option to the engine to play FRC/Chess960

UCI engines use polyglot 1.4 that can handle FRC for winboard.

and use winboard_X a modified winboard for FRC, but something is wrong with this.

I tried winboard_X and the logfile of movei has
only to log main lines 1082-1083 got winboard command random
Error (unknown command): random
only to log main lines 1082-1083 got winboard command variant
Error (unknown command): variant

The engine did not get variant=fischerrandom but maybe it is because it did not respond correctly but I am not sure how it should respond.

I may look at the winboard protocol but I am not sure if the old protocol include instructions for it and I am not sure where I can find the new protocol.

I can add that when I tried to play movei under winboard with chess960 movei assumed it is the opening position and it seems that winboard never told movei the setboard command.

Note that I used
-variant fischerandom in the additional option line in order to play chess960

Uri

Uri wrote:If I understand correctly the notation is the same for jostling and capruring.

Of course! It is said to underline, that this type of encoding is meant merely as a hint to the later castling move.

Reinhard.

run winboard with the option

-variant fisherandom /debug

you get a debug file and you can see what GUI and engines send.

the winboard must be know WB-2 protocol
with "protover 2"

then engine send:
feature variants="normal,fischerandom"

GUI:
accepted variants

engine:
variant=fischerandom


or you look out of the logprints by Arena that esier to see what hapen.

winboard sending the castles also with O-O format if the fisherandom variant is set.

it's long time ago with my provious engine EnginMax as winboard engine i am programed, then when i write my newer engine Tornado i give up the winboard protocol and use only UCI protocol because thats easy, and get no problems with pondering.

only if you use Tornado + polyglot by short time controls bullet then Tornado lost many games on time.
but on the shredder or Arena have no problems