Question about Sjaak

[Michel]

It's hard to believe but it appears that ICC sends board with invalid castling rights in FRC.

If in the initial FRC position the rook is not in a corner then it is denied castling rights. This then results in an incorrect initial position being sent to the engine.

[hgm]

Ah yes. Now I remember I had to deal with that too when I was making WinBoard castling-aware! The ICS boards are not fully descriptive of the game state. (Also not in Crazyhouse/Bughouse, where they fail to make the distinction between promoted Pawns and primordial pieces of the same type.) So in XBoard the new position inherits some info from the previus position,and take the rest from the new ICS board.

[Michel]

Perhaps another issue...

Reading config file '/home/vdbergh/.config/sjaakii.conf'
< xboard
>
< protover 2
> feature setboard=1 time=1 sigint=0 colors=0 highlight=1 ping=1 memory=1 analyze=1 pause=1 nps=1 myname="Sjaak II 1.3.0-r601" myversion="[1.3.0-r601 (x86_64)]" variants="seirawan,shatar,makruk,shatranj,sittuyin,crazyhouse,chessgi,asean,ai-wok,super,spartan,pocketknight,kingofthehill,knightmate,berolina,losalamos,micro,capablanca,gothic,embassy,greatshatranj,courier,grand,opulent,omega,minishogi,shoshogi,shogi,torishogi,xiangqi,chess960,fischerandom,fischerrandom,nocastle,wildcastle,great,caparandom,minisho,5x5+5_shogi,tori,7x7+6_shogi,sho,9x9+0_shogi,king-of-the-hill,fairy,8x8+0_fairy,8x8+6_fairy,8x8+1_fairy,6x6+0_fairy,5x5+0_fairy,10x8+0_fairy,12x8+0_fairy,10x10+0_fairy,12x12+0_fairy,5x5+5_fairy,9x9+0_fairy,9x9+8_fairy,7x7+6_fairy,9x10+0_fairy,normal"
> feature option="Variant fairy selects -combo chess (8x8+0) /// seirawan (8x8+0) /// shatar (8x8+0) /// makruk (8x8+0) /// shatranj (8x8+0) /// sittuyin (8x8+6) /// crazyhouse (8x8+6) /// chessgi (8x8+6) /// asean (8x8+0) /// ai-wok (8x8+0) /// super (8x8+0) /// spartan (8x8+0) /// pocketknight (8x8+1) /// kingofthehill (8x8+0) /// knightmate (8x8+0) /// berolina (8x8+0) /// losalamos (6x6+0) /// micro (5x5+0) /// capablanca (10x8+0) /// gothic (10x8+0) /// embassy (10x8+0) /// greatshatranj (10x8+0) /// courier (12x8+0) /// grand (10x10+0) /// opulent (10x10+0) /// omega (12x12+0) /// minishogi (5x5+5) /// shoshogi (9x9+0) /// shogi (9x9+8) /// torishogi (7x7+6) /// xiangqi (9x10+0) /// chess960 (= chess) /// fischerandom (= chess) /// fischerrandom (= chess) /// nocastle (= chess) /// wildcastle (= chess) /// great (= greatshatranj) /// caparandom (= capablanca) /// minisho (= minishogi) /// 5x5+5_shogi (= minishogi) /// tori (= torishogi) /// 7x7+6_shogi (= torishogi) /// sho (= shoshogi) /// 9x9+0_shogi (= shoshogi) /// king-of-the-hill (= kingofthehill)"
> feature option="Mate search -combo Disabled /// *Enabled for drop games /// Enabled"
> feature option="Draw offer threshold -spin 0 0 1000"
> feature option="Moves before draw offer (0 to disable) -spin 0 0 1000"
> feature option="Resign threshold -spin 500 100 16000"
> feature option="Moves before resigning (0 to disable) -spin 0 0 1000"
> feature option="Randomise opening moves -spin 10 0 40"
> feature option="Random amplitude (0 to disable) -spin 20 0 100"
> feature option="Send 'piece' descriptions -check 1"
> feature option="Mark holes in board -check 1"
> feature option="List user-defined variants before buildin variants -check 1"
> feature option="Report fail low -check 0"
> feature option="Report fail high -check 0"
> feature option="Claim repetitions -check 1"
> feature option="Send O-O/O-O-O for castling -check 1"
> feature option="Variant 'normal' is -string chess"
> feature option="Set variant alias -string "
> feature option="Variant configuration file -file "
> feature done=1
< post
< easy
< force
< ping 14
> pong 14
< hard
< easy
< random
< name goldbaer
> # Aborted ply 1 search - no move!
> # Pick random move
> 1 0 0 2 1. Na3
> move b1a3

[Evert]

Perhaps another issue...

Note to self: be careful about matching strings using "strstr". You might interpret "name goldbaer" as a "go" command.

Fixed. http://www.eglebbk.dds.nl/program/downl ... src.tar.gz

[Michel]

Perhaps another issue...

Note to self: be careful about matching strings using "strstr". You might interpret "name goldbaer" as a "go" command.

Fixed. http://www.eglebbk.dds.nl/program/downl ... src.tar.gz

Ah yes. It hadn't occurred to me that that could be the cause. Thx.

I think everything is now resolved. The O-O issue is entirely due to an ICC bug.

[hgm]

I fell into that same trap with the variant recognition in XBoard, which was originally done by strstr(engineVariantsFeatureList, variantName). First time it bit me was when I added variants daishogi and daidaishogi to the Alien Edition, which I solved by using the names dai and dada instead. With the introduction of engine-defined variants the situation became more critical, and I finally repaired it by also checking if there is a comma or null behind the matched name, and whether it is at the beginning of the string and there is a comma before it at the start. All quite inelegant and cumbersome testing. I guess a general function substr(string, word, separator) would find a lot of employment.

[hgm]

I have a question: what is the reference for a crazyhouse FEN?

There doesn't seem to be an official standard for this, but XBoard uses the format

<board>[<holdings>] <color> <virginity> <e.p.> <plycounter> <movenr>

where the brackets are literals and not meta-characters to indicate the part is optional. There is no significance to the ordering of the held pieces, and ultiple pieces of the same type will have to be simply repeated. On reading it understands an optional space between board and holdings. This was partly based on the bFEN standard for Bughouse, which does write the holdings as a 9th board rank. I did not like it that you cannot see the difference with an 8x9 and 8x8 board + holdings, however, so I used brackets around the holdings. XBoard would understand slashes on reading, though.

In fact, SjaakII does understand SAN, with one exception: the + at the end of a checking move. I could just make it ignore that.
The reason it doesn't advertise that it understands SAN is that it does this purely for convenience when used from the commandline, not for interaction with another program.

It is a CECP violation, however, to send SAN to an engine that did not explicitly request it through feature san=1. It would in general be a miriacle if that would work, but as we all know Sjaak II performs miracles.

[Michel]

t is a CECP violation, however, to send SAN to an engine that did not explicitly request it through feature san=1. It would in general be a miriacle if that would work,

It's not a miracle. Most winboard engines understand SAN. And of course UCI engines through polyglot also do.

Personally I think it would be nice if a winboard engine had a way to tell the GUI that it understands SAN, without forcing the GUI to send SAN.

[hgm]

Most winboard engines understand SAN.

I doubt that very much. Understanding SAN requires significant effort, through disambiguation, for absolutely no purpose. There are many hundreds of WB engines, mostly weak and not very highly developed. In fact none of my engines understands SAN, and all eight are WB. Does TSCP understand SAN?

IMO it would not be nice at all that engines can tell they understand SAN. What would be nice is if GUIs were required to reply 'rejected san' to every 'feature san=1' command...

[Michel]

Understanding SAN requires significant effort, through disambiguation

Well it is more or less trivial if you have a move generator. Which a chess engine must have anyway.