SjaakII 1.2 RC1

[Evert]

SjaakII 1.2 RC1 is available from http://www.eglebbk.dds.nl/program/chess-download.html . So far source, Linux and OS X binaries are up. Windows binaries will follow.

Compared to the last public release (1.0.0) this version includes the following changes:

• A new "Demotion:" tag that can be specified for pieces. This forces the piece to demote to a particular type when captured (in case the default Shogi/Crazyhouse style rules don't do what you want them to do, for instance in Kyoto Shogi).
• The "Prison:" tag now works correctly.
• A new piece property, "assimilate": if a piece with this property is captured, the capturing piece changes into its victim.
• A new piece property, "no_retaliate": if you capture a piece with this property, your own piece may not be captured in retaliation (this makes exchanges of pieces with this property difficult).
• A new piece property, "endangered": pieces with this flag may not capture each other if the victim is protected.
• The property "capture_flag" is now exposed in the config file: pieces with this property are able to "capture the flag" in games with capture-the-flag victory conditions.
• Allow a "N-check" victory condition: if a side can check N times, it wins.
• Fix a bug that caused the wrong piece-type to be placed in holdings after en-passant capture (affects crazyhouse).
• Allow double-steps from leapers, in particular for the Chu Shogi lion.
• User-defined variants now take precedence over build-in variants if both have the same name.
• Xiangqi: many evaluation tweaks and bug fixes; this version is much stronger than 1.0.0
• Promotions are now mandatory in Tori Shogi
• Fix notation for gating moves
• Fix a bug that could cause some drop moves to be sent to the GUI as null-moves (which would forfeit the engine).
• The FEN parser is now more robust when it is passed an incomplete FEN string, and it no longer assumes that castling can only occur on the back rank.
• Fix a bug that caused the engine to spam the GUI with thinking output if a ponder search found a forced mate (which could crash the GUI).
• New variants: Ouk Chatrang, mini Xiangqi, Elven Chess, 3-check, Mighty Lion Chess, Musketeer Chess (with Seirawan gating moves)
• Some previously build-in variants are now defined in the configuration file instead.
• Minor tweaks to search and evaluation. These cannot be manipulated by the user, but this is planned.

As always, I would love to hear about any issues or missing features!

[hgm]

Super!

About the N-check victory condition: the number of checks still to go is a new attribute of the game state, so it would have to be recorded in FEN. XBoard does not do that yet, in variant 3check. (In fact it does not record the check count at all, so it cannot adjudicate 3check games.) This obviously has to be fixed.

I want to propose putting the number of checks needed to win in a field behind the e.p. field, with the format W+B, where W is the number of checks white still needs to deliver to collect a win, and B the same for black. So the 3check starting position would be

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 3+3 0 1

The trait for identifying this as a check-counter field would be the embedded '+' sign (chosen because in SAN '+' means check).

This implies a 0 would be needed to represent final positions (even though it is not useful to send those to an engine). I don't know if there would even be any need to represent infinity here; in games wihout a finite check budget you would simply omit the field, so it would be needed only in asymmetric games where only one side can win through checking. Perhaps infinity could be represented by 00, should that need ever arise.

A question:
Would the new two-step ability enable Sjaak II to handle the Werewolf of Werewolf Chess, which moves as a range-3 Queen, but in addition can directly jump to the second square in all directions, but can optionally capture an enemy piece it jumps over as a side effect (K3ADcafK)?

[Evert]

Super!

About the N-check victory condition: the number of checks still to go is a new attribute of the game state, so it would have to be recorded in FEN. XBoard does not do that yet, in variant 3check. (In fact it does not record the check count at all, so it cannot adjudicate 3check games.) This obviously has to be fixed.

I want to propose putting the number of checks needed to win in a field behind the e.p. field, with the format W+B, where W is the number of checks white still needs to deliver to collect a win, and B the same for black. So the 3check starting position would be

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 3+3 0 1

The trait for identifying this as a check-counter field would be the embedded '+' sign (chosen because in SAN '+' means check).

That's a good point, actually. The check-count should be recorded in the hash as well (which it currently isn't, I didn't get round to doing that yet).
However, the proposed extension looks fine to me and I can certainly incorporate that.
I had the impression that XBoard could and did adjudicate 3-check games correctly, but perhaps my memory is hazy here.

Would the new two-step ability enable Sjaak II to handle the Werewolf of Werewolf Chess, which moves as a range-3 Queen, but in addition can directly jump to the second square in all directions, but can optionally capture an enemy piece it jumps over as a side effect (K3ADcafK)?

That's basically a locust-style capture, right? I can't do those at the moment; I'll have to take a closer look to see what it would take to make it work.

[hgm]

I had the impression that XBoard could and did adjudicate 3-check games correctly, but perhaps my memory is hazy here.

Or mine. I am pretty sure I don't store this part of the game state in the board[][] array, as I do for castling rights, e.p. rights and last-rank virginity. But perhaps the adjudication is done by running through the entire game. I also don't store 50-move counter in the board, and run through the game history to find the last irreversible move.

That's basically a locust-style capture, right? I can't do those at the moment; I'll have to take a closer look to see what it would take to make it work.

Indeed, that is locust capture, possibly combined with ordinary capture on the to-square. But a Lion also does locust capture. What is the difference that would make it work for Lion and not for Werewolf? That in Lion the first and second step are the same (both King moves)?

Locust capture is very much like lame leaping: the only difference is that the intermediate square has to be a foe rather than empty. Btw, would Sjaak II be able to do a lame leaper that goes to the second square in all 8 directions (nAnD)?

[Evert]

That's basically a locust-style capture, right? I can't do those at the moment; I'll have to take a closer look to see what it would take to make it work.

Indeed, that is locust capture, possibly combined with ordinary capture on the to-square. But a Lion also does locust capture. What is the difference that would make it work for Lion and not for Werewolf? That in Lion the first and second step are the same (both King moves)?

Sortof. SjaakII has no concept of direction for leaper moves (they're just bitmasks indexed by origin square); for Locust-style captures you need direction information, for Lion moves you don't.

Locust capture is very much like lame leaping: the only difference is that the intermediate square has to be a foe rather than empty.

You know, perhaps that's something I could make work with a little more thought (although I'd really like to then have locusts work in general).

Btw, would Sjaak II be able to do a lame leaper that goes to the second square in all 8 directions (nAnD)?

Hmm... tricky. I guess not. The way to specify it would be something like "leap ((1,1)|(1,0) + (1,1)|(1,0)) & ((2,0)|(2,2))", but then it would be allowed to use two F moves to simulate a D and bypass the blockade. I guess it only handles lame leapers for the case where the final move is that of a simple leaper.
That would also be good to fix, I'll look at that.

There is a sortof-workaround for that particular case though, but it's tedious and fragile: because A and D are both parity-bound (not sure what the correct term is, it's a higher order of colour-boundedness) nAnD could be defined as F2W2 with a prison that disallows moves to the forbidden squares, but that does require advance knowledge of where the pieces can be placed (so feeding it a FEN with pieces where it doesn't expect them will break things).

[hgm]

Locust capture in general is not different from lameness, is it? You have to specify a trajectory of intermediate squares in both cases.

BTW, the XBoard parser indeed did not yet pay attention to the new castlingRank arrays I had introduced (and which were filled in the FEN parser), but still had hard-coded 0 and BOARD_HEIGHT-1 for the ranks when parsing O-O and O-O-O. I knew I had tackled that problem, because of Omega Chess, but I did not prepare for OO castlings because it was not a shuffle variant, so that slipped through. So this will be fixed in future XBoards; the setup FEN will define the castling rank (together with the pieceToChar that indicates which ID corresponds to the piece that XBoard considers royal in the current (parent) variant).

[hgm]

I just discovered that Sjaak II 1.0.0 seems to have a limitation in the length of the "XBoard pieces" string. When I specify more than 24 pieces per side, the pieceToChar info in the setup statement gets clipped, (including the closing parenthesis). Does this new version of Sjaak II still have that limitation?

With chu as parent variant each side could have 44 pieces, but I just expanded that to 54. In particular I wanted to assign a duplicat of the Lance (which XBoard will not consider a Pawn, and is now the 27th piece) to the Amazon.

[hgm]

After Martin provided me with a Windows compile, I can confirm that this new version can handle pieceToChar tables of 28 pieces per side. I don't know if that means there is no limit at all now, or that we might still run into problems when the number of XBoard pieces is increased further.

After a lot of changes in WinBoard (move parser, FEN parser, FEN generator) Sac Chess now seems to run fine!

[Evert]

After Martin provided me with a Windows compile, I can confirm that this new version can handle pieceToChar tables of 28 pieces per side. I don't know if that means there is no limit at all now, or that we might still run into problems when the number of XBoard pieces is increased further.

There is no limit, I remember fixing this (but somehow it didn't end up in the change log). It now checks how much space it needs to allocate and allocates exactly that amount. I'm not sure what I was on when I wrote the original code; obviously I figured that 44 pieces would be enough for anybody.

After a lot of changes in WinBoard (move parser, FEN parser, FEN generator) Sac Chess now seems to run fine!

Cool. If you like, I can include the definition in the default variants.txt.

[Evert]

Windows 32 and 64 bit binaries (courtesy of Martin Sedlak) are up now.