Tamerlane Chess

[hgm]

Concerning castling:

XBoard's Betza parser now also recognizes O1 as castling (where plain O means null move), but it uses the same system for it as for non-royal castling, where you first have to point out your own Rook to indicate your intention to castle, and then point out where you want the King to go.

[Greg Strong]

Also, is it possible for either SjaakII or Postduif to play Wildebeest Chess?

Note that Fairy-Max 5.0 plays a variant called 'almost-wildebeest', which is Wildebeest Chess without the castling where the King steps only one square towards the Rook. There is an ambiguity issue in the protocol there similar to what you can have in Chess960. But it is different from Fischer castling, because the King ends up elsewhere. So it is not sufficient to just identify the King and Rook (as you would do in KxR encoding).

almost-wildebeest is pretty darn close, and probably close enough. I doubt you would often want to castling moving only one square. I haven't seen any posts from R. Wayne Schmittberger recently so I don't know if he's still active. It would be nice to have the rules amended to avoid that nasty and mostly pointless complexity...

For the 'guarding' in Omega Chess, where the Queen has to castle with Rook, you have a similar problem always, as wherever the Queen would end during the castling, it would always be a legal move of the Queen. The solution I designed there is to write the guarding as a two-leg capture of your own Rook, like Qxa1-b1 (d1a1,a1b1 in protocol form). This does specify the final location of the Queen explicitly in the move notation, and taken at face value would already almost do what you want. Except that you have to re-grow a Rook at the other side of the Queen. So the convention that direct capture of an own piece implies Fischer castling (i.e. implied destinations) with that piece, while hit-and-run capture would imply castling to the indicated location, with a Rook next to it, seems to solve the problem. I am not sure if XBoard's current Betza move generator allows this for a King.

Ok, this one I had to look up. I hadn't heard of guarding in Omega. Turns out there a whole Advanced Omega I didn't know about. (Disappear for a couple of years and you can miss a lot of stuff...) I won't be rushing to implement this one any time soon though. guarding is ugly enough - the Joker induces a ton of complexity. Interesting piece, but it presents a whole host of challenges that are making my brain hurt...

Could the one-space wildebeest castling work a similar way? "f1g1,k1f1" Actually, now that I think about it, as long as the GUI understood it, the engines wouldn't need to. The engine just wouldn't make that move, and if a user or a different engine did, the GUI could just send a "setboard" command. Pretty cheesy but it could probably work...

[hgm]

Could the one-space wildebeest castling work a similar way? "f1g1,k1f1" Actually, now that I think about it, as long as the GUI understood it, the engines wouldn't need to. The engine just wouldn't make that move, and if a user or a different engine did, the GUI could just send a "setboard" command. Pretty cheesy but it could probably work...

I once added a boolean option -forceIllegal to WinBoard that did exactly that, to make it possible for Fairy-Max to play one of these 10x8 variants with wierd castling (Schoolbook?) against an engine that did use it (must have been ChessV?!) When an engine complained about an input move being illegal, it would just get the position after the move fed to it. This is the way I implemented null moves in analyze mode too.

The latest WinBoard would correctly understand f1g1,k1f1 as a castling, although it implements that in a very flaky way: internally it uses the move representation <fromSqr><toSqr>;<epSqr> , and when it sees a move <from1><to1>,<from2><to2> it transforms it to <from1><to2>;<to1> when <to1> and <from2> are on the same file, and to <from1><to1>;<from2> when they are not. Castlings with explicitly specified King and Rook move fall in the latter category, and will thus be transformed into a King move that kills the Rook. This 'trampling' of an own piece on the epSqr is then internally used as a kludge for indicating castling, similar to the K x own R kludge in FRC.

I guess it would not be impossible to make Fairy-Max understand this notation, and use the presence of a comma as a disambiguator to determine if the input move matches a castling or a normal move. For the latest release I did not feel like bothering about this though.

[Evert]

Strange - it works sometimes and not others. If I do a game where I just focus on clearing out the space and castling quickly, it works. If I run an engine-engine match where castling happens later in the game, SjaakII rejects the move as illegal. I have the engine-debug log of such a game but it's 38 K so probably too large to post here. If you PM me your email address I can send it to you.

Does it by any chance do that when black tries to castle queen-side? I just noticed that it doesn't set the queenside-castling flag for black, even if it is specified in the startup string.

[hgm]

Having the engine direct the GUI is contrary to my primary approach - the GUI knows everything and enforces everything.

Still one thought about this: it is fine if your GUI doesn't support that setup or piece commands, because it does already know all the information these convey by itself. But it would still be very nice if your engine would support it, so it can run the variants that are non-standard in WinBoard, but known to your GUI, also in WinBoard as engine-defined variant. Seen from the engine it is only a matter of printing a few predetermined lines for each variant (setup and possibly a few piece commands).

[Greg Strong]

Strange - it works sometimes and not others. If I do a game where I just focus on clearing out the space and castling quickly, it works. If I run an engine-engine match where castling happens later in the game, SjaakII rejects the move as illegal. I have the engine-debug log of such a game but it's 38 K so probably too large to post here. If you PM me your email address I can send it to you.

Does it by any chance do that when black tries to castle queen-side? I just noticed that it doesn't set the queenside-castling flag for black, even if it is specified in the startup string.

That was indeed the case, at least this time, and quite possibly every time. I was starting to think that it was a more general castling bug rather than an issue with the notation, so you've probably found it.

Thanks!

[Greg Strong]

Could the one-space wildebeest castling work a similar way? "f1g1,k1f1" Actually, now that I think about it, as long as the GUI understood it, the engines wouldn't need to. The engine just wouldn't make that move, and if a user or a different engine did, the GUI could just send a "setboard" command. Pretty cheesy but it could probably work...

I once added a boolean option -forceIllegal to WinBoard that did exactly that, to make it possible for Fairy-Max to play one of these 10x8 variants with wierd castling (Schoolbook?) against an engine that did use it (must have been ChessV?!) When an engine complained about an input move being illegal, it would just get the position after the move fed to it. This is the way I implemented null moves in analyze mode too.

Ah yes. I remember now. So I actually got this idea from you. I had just forgotten that
Yeah, a bunch of Capablanca variants use the "flexible castling" rule - Schoolbook, Grotesque, Ladorean, and Univers. Fortunately, flexible castling requires the king to move 2 or more squares toward the rook so we don't have any ambiguity with from sq-to sq notation.

The latest WinBoard would correctly understand f1g1,k1f1 as a castling, although it implements that in a very flaky way: internally it uses the move representation <fromSqr><toSqr>;<epSqr> , and when it sees a move <from1><to1>,<from2><to2> it transforms it to <from1><to2>;<to1> when <to1> and <from2> are on the same file, and to <from1><to1>;<from2> when they are not. Castlings with explicitly specified King and Rook move fall in the latter category, and will thus be transformed into a King move that kills the Rook. This 'trampling' of an own piece on the epSqr is then internally used as a kludge for indicating castling, similar to the K x own R kludge in FRC.

Interesting. Sounds a little funky but I guess it works for almost every variant. Good to know it would support a Wildebeest engine that supported that castling move and communicated it in that way. Too bad Wildebeest doesn't just use the more standard flexible castling rule, which is what your almost-wildebeest is.

I guess it would not be impossible to make Fairy-Max understand this notation, and use the presence of a comma as a disambiguator to determine if the input move matches a castling or a normal move. For the latest release I did not feel like bothering about this though.

Yeah, certainly not something I'd worry about unless it was an easy fix. almost-wildebeest is probably good enough.

[hgm]

Interesting. Sounds a little funky but I guess it works for almost every variant.

That was exactly the justification for this hack: variants with true multi-move requirements (like Marseillaise Chess or Progressive) are very rare, but non-standard castling and locust pieces are reasonably common. So I wanted to make at least the latter two cases generally available in the regular edition of WinBoard. In the Alien Edition there was a 'variant alien' where the engine would send a board update after every move, so you could handle any type of side effects. But it was very cumbersome, and would lead to big problems when you wanted the GUI to interpret the PVs of an engine for implementing a variation board. And it seemed a way to heavy tool to handle the occasional castling or Lion move. Locust capture in the regular edition of Win/XBoard is still limited to a single locust victim, however; I would still like to expand that to two, to handle the Lion Dog of the large Shogi variants.

Mouse entry of these moves was initially a problem; in the Alien Edition I originally designed it such that pressing Ctrl during the move would identify it as a non-final leg. This proved unworkable; you would always forget it. Making the engine indicate it through a special color in the highlight command was a big improvement, but would only work in the presence of an engine for variants WinBoard did not know the rules of. But the Betza parser (and the possibility to describe multi-leg moves in the XBetza extension) offers a solution for that too: with engine, locust pieces can be defined in advance by the engine, so the GUI can do the highlighting that identifies the non-final legs by itself. And I introduced a 'VariantMen' PGN tag, so that even without engine it should be possible to make an agnostic GUI aware of how the pieces move (so it can decode the SAN).

[Greg Strong]

Having the engine direct the GUI is contrary to my primary approach - the GUI knows everything and enforces everything.

Still one thought about this: it is fine if your GUI doesn't support that setup or piece commands, because it does already know all the information these convey by itself. But it would still be very nice if your engine would support it, so it can run the variants that are non-standard in WinBoard, but known to your GUI, also in WinBoard as engine-defined variant. Seen from the engine it is only a matter of printing a few predetermined lines for each variant (setup and possibly a few piece commands).

Yes, I think that's totally reasonable. I'll make sure this is in the initial release, although the engine is probably still a year away...

[Evert]

Strange - it works sometimes and not others. If I do a game where I just focus on clearing out the space and castling quickly, it works. If I run an engine-engine match where castling happens later in the game, SjaakII rejects the move as illegal. I have the engine-debug log of such a game but it's 38 K so probably too large to post here. If you PM me your email address I can send it to you.

Does it by any chance do that when black tries to castle queen-side? I just noticed that it doesn't set the queenside-castling flag for black, even if it is specified in the startup string.

That was indeed the case, at least this time, and quite possibly every time. I was starting to think that it was a more general castling bug rather than an issue with the notation, so you've probably found it.

I uploaded the fixed source (http://www.eglebbk.dds.nl/program/downl ... src.tar.gz) if you want to test if this indeed fixes the problem for you (to compile in Linux, go to the Build/ directory in a terminal and type "cmake .. && make". You will need the CMake program, which should be available from the package manager if it isn't installed already).