Playing chess 960 against SMIRF

[Roland Chastain]

Hello!

I tried without success to play FRC against SMIRF using Smirfoglot interface. I got a message box saying "not yet implemented".

I would like to know if there was a technical difficulty for that implementation, or if it is just by lack of time or interest that it wasn't done.

I ask that question because I am interested in chess 960 and in R. Scharnagl work. I would like to understand how Smirfoglot works. I would be temptated to make a UCI interface for Smirf, on the model of Smirfoglot, but in Pascal.

Regards.

Roland

[Roland Chastain]

I started to write the Pascal code to load SmirfEngine.dll. I wonder which simple test I could make, when my code is finished, to see if it works. For now, I have no clear idea of the TMCI protocol.

Thank you for your attention.

[H.G.Muller]

Well, I made Smirfoglot. But that was long ago, and I don't remember much about it. I wonder if I could still find the source code. Perhaps on some old computer I have still lying around somewhere.

[Roland Chastain]

Well, I made Smirfoglot. But that was long ago, and I don't remember much about it. I wonder if I could still find the source code. Perhaps on some old computer I have still lying around somewhere.

Thank you for your answer. I have got the source code of Smirfoglot here.

[H.G.Muller]

Oh, I did not even remember I had ever published that source.

IIRC SMIRF always plays FRC or CRC. But the default start positions of those are such that it makes them orthodox Chess or Capablanca Chess, and to really make it random the GUI has to provide the randomized setup through the setboard command. So it seems the "not implemented" complaint is a bit unnecessary: it could have treated fischerandom as normal, and caparandom as capablanca. In fact SMIRF doesn't know the concept of a variant at all; it considers it all the same variant that happens to start from a different position, and sets the board size to what the FEN you load into it specifies.

There is one snag, though: SMIRF will almost certainly insist on the FEN being X-FEN (KQkq), while WinBoard uses Shredder-FEN (HAha) in the shuffle variants. So Smirfoglot would have to replace the castling rights by K/Q when they apply to the outermost Rook (as in initial setups they always will) before sending the FEN to SMIRF, when executing a setboard command. This is probably why I was too lazy to officially support it. A work-around would be to install the engine with the option /firstNeedsNoncompliantFEN="KQkq -", which would always force castling and e.p. field to be set to the given string, in FENs that go to the engine. That wouldn't help for setting up arbitrary positions, but for communicating the shuffled start positions it would work fine.

[Roland Chastain]

Thank you for that precious answer. I modified the source code as follows and recompiled.

Code: Select all

if((sscanf(line+8, "normal%c", &c)==1 && c=='\n')||(sscanf(line+8, "fischerandom%c", &c)==1 && c=='\n')) FEN = FENs[0]; else

After that, I could start a FRC game in Winboard!

But when I make a castling move, Smirf stops to play. Using the option that you indicated doesn't seem to solve the problem.

Anyway, thank you again for your answer. I had begun to understand how your program works.

[H.G.Muller]

Apparently SMIRF uses another notation for castling as WinBoard provides. I think the default in FRC is O-O and O-O-O. Perhaps SMIRF wants KxR format? You could get that by having the engine emit feature oocastle=0 .

[Roland Chastain]

Apparently SMIRF uses another notation for castling as WinBoard provides. I think the default in FRC is O-O and O-O-O. Perhaps SMIRF wants KxR format?

Thank you for your answer. I was working on my Pascal program and I have made quick progress. My basic UCI interface is almost finished. But I am still interested in making also Smirfoglot work for FRC. Even though I am less comfortable in C than in Pascal.

You could get that by having the engine emit feature oocastle=0 .

I don't understand that point. Where does the engine emit that message please?

[Roland Chastain]

My UCI interface is almost working. I can't get the best move. I am not sure to understand the protocol for that. I never understood what "ponder" means.

I tried two things, but I never get a move, or I get "#0#0".

Here is my code.

Code: Select all

(* deleted *)

[Roland Chastain]

I have just discovered this discussion on TMCI protocol. It seems that I will find all the answers there.

[Roland Chastain]

I confirm that Smirf accepts Schredder-FEN. For castling move notation, I still have to investigate.

My UCI interface works well. This morning I understood the method to get the engine move.

Now I just need a name for that project. Smirfoglot UCI? Smirf UCI? Smirf U?

Regards.

Roland

[Roland Chastain]

Smirf Uci could play two games with Cute Chess. It disconnected during the third game. It was relative to a promotion letter. I also tried a game in Winboard. It works but the engine disconnected after a castling (same issue than with Smirfoglot).
So, there are some corrections to do but it's a start.

Here is the binaries and the source code.
smirf-uci-20190603.zip

It includes the modified Smirfoglot source.

[H.G.Muller]

Congratulations!

As to castling: TMCI has this command to request the list of all legal moves from the engine. End Reinhard told me that these are exactly in the same format as the engine needs as input. (And indeed promotion suffix is always upper case). Perhaps you could use that to see what it does for castling. Or perhaps you could already see that from itrs PVs. UCI uses KxR format in FRC for castlings. If SMIRF needs a different format that would be a bit nasty, as these moves cannot be recognized without reconstructing the board first.

[Roland Chastain]

Thank you for the congratulations and for the tips. I will try what you suggest.

I confirm that Smirf accepts Schredder-FEN.

No, I spoke too fast. You were right: Smirf wants X-FEN. But, as you said, the modification is easy since only starting positions are concerned.

[Roland Chastain]

To be precise, SMIRF accepts S-FEN but doesn't read it correctly.

Code: Select all

uses
  SysUtils, SmirfEngine;
 
begin
  // Set initial position
  WriteLn(DoCmd('E', 'F', 0, 'nrnkbrqb/pppppppp/8/8/8/8/PPPPPPPP/NRNKBRQB w FBfb - 0 1'));
  // Get current position
  WriteLn(DoCmd('F', 'S'));
end.

// Output
{
  nrnkbrqb/pppppppp/8/8/8/8/PPPPPPPP/NRNKBRQB w KQ - 0 1
}


For the castling move, here is what I discovered:

Code: Select all

position fen rnqnkrbb/pppppppp/8/8/8/8/PPPPPPPP/RNQNKRBB w FAfa - 0 1 moves d2d3 b8c6 f2f3 d8e6 g1f2 g7g5 e2e4 h8e5 e1f1 // nok
position fen rnqnkrbb/pppppppp/8/8/8/8/PPPPPPPP/RNQNKRBB w FAfa - 0 1 moves d2d3 b8c6 f2f3 d8e6 g1f2 g7g5 e2e4 h8e5 O-O  // nok
position fen rnqnkrbb/pppppppp/8/8/8/8/PPPPPPPP/RNQNKRBB w FAfa - 0 1 moves d2d3 b8c6 f2f3 d8e6 g1f2 g7g5 e2e4 h8e5 e1g1 // ok

So, it seems that Smirf uses e1g1 for any white castling on the h side.

Finally I will need a little chess module in my interface, to detect castling moves. So I will also use it for castling rights translation, even if in that case a simple constant (as Winboard option does) is a good solution.

By the way, is it possible to see somewhere which commands Winboard send and receives?

PS I didn't find how to get Smirf's move list. I see only methods to get the best move.

[Roland Chastain]

I made a function to translate castling moves. Smirf sometimes accepts it, sometimes not, I don't know why.

Here is the latest version of the program (binary + source code).

smirf-uci-20190605.zip

To detect castling moves, instead of including a heavy chess module able to replay moves, I ask to SMIRF the position after each move replayed.

PS I created a git repository.

[Roland Chastain]

In this position, Smirf accepts g8h8!

Code: Select all

position fen nrnqbbkr/pppppppp/8/8/8/8/PPPPPPPP/NRNQBBKR w HBhb - 0 1 moves e2e4 c8d6 f2f3 a8b6 b2b3 e7e6 c2c4 f7f5 c4c5 f5e4 c5d6 f8d6 f3e4 g8h8

[Roland Chastain]

I tried many things but until now I don't see Smirf logic for castling moves formulation.

The problem is that you cannot always replace kxr by e1g1 (for example), because sometimes e1g1 is an (other) existing move.

I have to do manual tests until I see the rule that Smirf follows.

[H.G.Muller]

I think you would need the following (from the text in the TMCI discussion):

Code: Select all

   'M' 'A' nr -- => show the currently prepared move <nr> in
                    algebraic form (letter, digit, letter, digit, extra),
                    source before target, where extra is the lower promotion
                    piece code (English) or zero. When a King's castling
                    move does less than two elementary steps, the involved
                    Rook's coordinate will be used as target coordinate.
                    (or else 0L, if move <nr> does not exist)
                    This codes are sent back to the engine in case that
                    a move would be selected.


This has to be used to get the moves 1 by 1, for different 'nr'.

The text also suggests that you need to use the true King location as from-square, and the true King destination as to-square in the algebraic move. Except when the King is next to that to-square (e.g. on d1 while you wanted to a-side castle), in which case you should use KxR notation.

[Roland Chastain]

Thank you for that precious answer. It works now (the move list and the castling)!
Without your help I think I would have given up.
I am very glad of that little program.