SjaakII 1.0 RC1

[Evert]

Sjaak also doesn't seem to understand an '=' suffix as deferral, in Shogi-like variants.

Ah, looks like a side-effect of when I rewrote the move matcher. It used to simply skip over '=' when parsing a move string (assuming promotions are deferred by default).

Simple enough to put that in, and uncovered another (minor) bug in the SAN output code.

[Evert]

Well, I don't really know the rules of Sittuyin. But when I select it, and then try to drop a white piece somewhere behind the Pawn line, Sjaak (64 bit) crashes. Which seems always wrong.

Hmm… not sure what's up with that. It works here, but "test legality" must be switched off (not that it crashes otherwise). Pieces can be dropped behind the own pawns, with some restrictions: rooks must be on the back rank, kings must not be on the back rank (off the top of my head).

Looking into this did reveal a nasty bug that caused Sjaak to sometimes ignore commands that were sent while it was thinking, but then respond to later ping commands as though they were. Somehow that actually could lead to a crash after a while.

http://www.eglebbk.dds.nl/program/downl ... src.tar.gz holds the fixed sources, if you would be up for checking if it now works for you.

[hgm]

I haven't tested it yet, but there might be yet another issue: Sjaak claims rep-draws, but after how many repeats? For Shogi it needs 4-fold repeat rather than 3. And it would be logical to extend that to variants that have Shogi as parent variant.

If this is too complex, it would be nice if there was a general option 'Claim draws', so that draw claiming could be switched off alltogether. Recognizing repeats is something that a GUI can do (in a user-configurable way) even with legality testing off. In Fairy-Max I recently added an option to suppress its claiming of 50-moves draws (actually make it possible to claim after any other number of moves), because I adopted a 75-move rule for Team-Mate Chess (and also Makruk has a 64-move rule), and configuring those in XBoard did not have the desired effect if the engine would still claim after 50...

[Evert]

I haven't tested it yet, but there might be yet another issue: Sjaak claims rep-draws, but after how many repeats? For Shogi it needs 4-fold repeat rather than 3. And it would be logical to extend that to variants that have Shogi as parent variant.

Good point: the number of repeats needed for Sjaak to claim a rep-draw is a variable, which defaults to 2 (so the position is repeated twice, that is, occurs 3 times) but it is set to 3 for Shogi (so the position must occur 4 times).

However, this is apparently not settable from the config file, which is an oversight I will fix before release. I'll probably make it so you specify "4" for the Shogi rule and "3" for the standard rule (rather than 3 and 2, which would probably just be confusing).

If this is too complex, it would be nice if there was a general option 'Claim draws', so that draw claiming could be switched off alltogether.

This I can do either way (but it's more complicated than adding rep-draw repeat counts to the config file). I should perhaps also add something for a resign threshold (although I'm not a fan of the "below an arbitrary number for at least N consecutive plies" variety).

Recognizing repeats is something that a GUI can do (in a user-configurable way) even with legality testing off. In Fairy-Max I recently added an option to suppress its claiming of 50-moves draws (actually make it possible to claim after any other number of moves), because I adopted a 75-move rule for Team-Mate Chess (and also Makruk has a 64-move rule), and configuring those in XBoard did not have the desired effect if the engine would still claim after 50...

I should be able to configure that one as well. That should probably by a variant-specific option rather than a global option though.
Does XBoard implement 64-move/counting rules for Makruk?

[hgm]

The highlight command is working now. But there is something strange: the purple highlights for promotion do not work on Pawns, in Judkins. They do work on Silver and Knight. Sjaak does accept bot promotion and deferral for Pawns, though.

[Evert]

The highlight command is working now. But there is something strange: the purple highlights for promotion do not work on Pawns, in Judkins. They do work on Silver and Knight. Sjaak does accept bot promotion and deferral for Pawns, though.

That's a bit odd, since there is nothing special about pawns (but pawn-moves are generated differently). Does it affect optional and mandatory promotions in the same way (what is the correct high-light colour for those anyway? Or for promotion-captures?)? Does it work with other Shogi-variants?

What happens if you change the pawn definition for Judkins Shogi to

Code: Select all

Piece: Pawn
Move: aleap (0,1)
Symbol: "P", "P,p"
Promotion: white_promotion, black_promotion, "+"
Flags: drop_no_mate, drop_one_file
Value: 80

?

There is an ambiguity in the creation of the colour-FEN if there are both promotion and normal (or capture) possibilities for a target square. Which colour the square ends up with is arbitrary in the sense that it depends on the order in which the moves are generated. I'm going to change it so that if there is a promotion option, the colour is set to purple regardless of the order in which moves are generated. This is the relevant patch:

Code: Select all

Index: ../src/xboard.cc
===================================================================
--- ../src/xboard.cc	(revision 277)
+++ ../src/xboard.cc	(working copy)
@@ -772,6 +772,7 @@
       if (get_move_from(move) != from) continue;
       int s = game->bit_to_square[get_move_to(move)];
       if (s < 0) continue;
+      if (move_board[s] == 3) continue;
       if (is_promotion_move(move))
          move_board[s] = 3;
       else if (is_capture_move(move))

[hgm]

Well, I did not try any of that, because your explanation seems entirely satisfactory. So I applied the patch you suggest, and now the Pawns give a nice purple highlight whenever they enter the zone.

The purple triggers XBoard's promotion procedure. So if there are any moves that promote, the square should be highlighted in purple. Even if there are other non-promoting moves to that square. The promotion procedure will allow the user to somehow choose between the various promotion options (promote/defer or select a piece).

Even if promotion is mandatory, the square should be highlighted in purple. There is no separate color defined for that as yet. The idea behind that is that normally you would use sweepPromotions, which by default promote unless you do a click-click move with a non-stationary to-click. So it requires a concious action to attempt deferral, and in case deferral was illegal, the engine would simply refuse the move. (Similar when you pick non-allowed promotion pieces on Pawn promotions, like Aanca in Team Mate Chess or King in Spartan when you already have two.)

That you can no longer see the difference between capture / non-capture on promotions is in practice only a cosmetic problem. The only function of red as opposed to yellow (or most other colors) is that it triggers sending of a 'hover' command when the mouse cursor enters that square. This gives the engine opportunity to highlight side-effect-capture victims of that move. I guess XBoard should also send a hover command on purple squares; when it is not a capture the engine can simply ignore it. (In fact it also can ignore it when it was a normal replacement capture, so highlighting those in red is really pointless. The 'hover' system is only useful for variants like Ultima and Checkers.)

[hgm]

I should be able to configure that one as well. That should probably by a variant-specific option rather than a global option though.
Does XBoard implement 64-move/counting rules for Makruk?

Oh, missed this question. XBoard does not implement counting (yet). But it must be able to at least play out the number of moves counting would maximally allow, and Fairy-Max claiming always after 50 moves prevented that.

How is it decided whether perpetual checking is a loss? Is it automatic, or must it also be set from the config file? (And is that possible?)

[Evert]

How is it decided whether perpetual checking is a loss? Is it automatic, or must it also be set from the config file? (And is that possible?)

Nothing so clever. To declare perpetual checking a loss I currently just declare repetitions in general to be illegal. Check evasions are an exception and are always allowed.

It's marked as "TODO: perpetual checking".

[Evert]

Well, I did not try any of that, because your explanation seems entirely satisfactory. So I applied the patch you suggest, and now the Pawns give a nice purple highlight whenever they enter the zone.

Fair enough.

I was thinking as I typed, so I didn't know what the problem was likely to be when I started typing but figured it out by the end of the post.