As it is not supported, it wouldobvosly have to be played as something else, in this case with legality testing off, because there is no supported variant with the required promotion rules. The most suitable variant to use for this would be Seirawan Chess, because that uses holdings in which captured pieces are not placed.
With legality testing off, any promotion suffix is taken seriously (even on moves with non-Pawns), and WinBoard simply substitutes the moved piece for the one indicated by the suffix. The user would have to type promotion moves, as there will be no automatic promotion or promotion popupon moves that WinBoard does not think are promotions when you enter them with the mouse.
So what you would have to do is to define a pieceToCharTable that defines the participating pieces, and the letters to indicate them. You can have the engine do that, in the setup command it sends in response to receiving variant seirawan. This then also should specify a FEN, including holdings.
Ok, that sortof works.
It correctly starts up with the pawns along third and fourth ranks and all other pieces (King, Rooks, Knights, Ferz and Elephants) in holdings. However, XBoard seems to reject all but the first two drops, even with legality testing switched off. It doesn't seem to be a problem with the engine, since it accepts the moves just fine if I enter them from a terminal.
I didn't implement the promotion rule yet; I simply never promote at all. Since the only promotion option is the Ferz and you can only get a new one if the first one was taken, there doesn't seem to be much of a point anyway.
I am not sure I fully understand the problem (or the rules,in fact). For one, you would either have to enlarge the holdingsSize (to fit the King), or alter the pieceToCharTable (to squeeze out Hawk and Elephant).
White and black are supposed to drop alternately, one piece per turn, right? Or must white drop all his pieces first, before black can start dropping? The latter would be a problem. But dropping one by one in Seirawan with holdingsSize set to 8 did not cause any problems for me.
hgm wrote:I am not sure I fully understand the problem (or the rules,in fact). For one, you would either have to enlarge the holdingsSize (to fit the King), or alter the pieceToCharTable (to squeeze out Hawk and Elephant).
Aha!
I thought that with legality testing off and me sending a string containing 8 pieces in holdings , XBoard would do the right thing. It certainly seemed to.
This may work better; for some unclear reason I get bus errors now when running either Burmese or Makruk (but not Spartan or Normal). Clearly I broke something.
White and black are supposed to drop alternately, one piece per turn, right? Or must white drop all his pieces first, before black can start dropping? The latter would be a problem. But dropping one by one in Seirawan with holdingsSize set to 8 did not cause any problems for me.
There are apparently different rules: either black and white set up pieces one by one, or they take turns, or they do it "at the same time", revealing their setup when everything is done.
I picked the one that was easier to implement.
XBoard uses a mapping of piece types on holdings squares derived from the pieceToCharTable. (If the holdings size is N, the N lowest pieces defined in the table will go into the holdings, and every other piece will be demoted to Pawn first. At least on capture.) It uses that mapping to translate drop moves entered in text form, to know where to look to see if the piece is available.
The variant where you have to drop taking turns is indeed the most natural one.
I have managed to install and run WinBoard Alien Edition + Nebiyu 10x10 checkers, including the Draughts Utrecht fonts. There is one glitch for me: entering multiple captures will crash Nebiyu. E.g. in analysis mode there is 1 mandatory capture e4c6a4 in this position.
It sounds like you are doing it as intended. Could you start WinBoard with the 'Additional option' /debug , paste the FEN, perform the fatal move, and then post the resulting winboard.debug file here? So that I can check if Nebiyu is to blame, or if it is WinBoard that sends it something erroneous on which it chokes.
39828 >first : usermove 39828 >first : e4c6,c6a4
Animate 1 t=108425921
Animate 2 t=108425921
Fatal Error: Error: first chess program (NebiyuCheckers) exited unexpectedly
GameEnds(26, Error: first chess program (NebiyuCheckers) exited unexpectedly, 2)
42453 >first : exit
42453 >first : quit
It seems this is a Nebiyu problem. The notation e4c6,c6a4, which is sent to the engine, is the intended syntax for this move.
So it is up to Daniel now.
OK thanks for sorting this out so quickly!
@Daniel: your program is nice and plays quite OK (I'm a 10x10 checkers player myself). However, it seems to be missing the "majority capture" rule. When you have the choice of multiple captures, you have to capture the most number of pieces (where pieces and queens count equally). If you could fix this, that would be great!
Hello Rein
I think I have fixed that problem sometime ago, so maybe I forgot to upload a newer version with the fix.
@Daniel: your program is nice and plays quite OK (I'm a 10x10 checkers player myself). However, it seems to be missing the "majority capture" rule. When you have the choice of multiple captures, you have to capture the most number of pieces (where pieces and queens count equally). If you could fix this, that would be great!
I think I have implemented that too. Only the longest captures are tried in the international 10x10 checkers version (the rest are dropped). You probably have an old version so I will upload a new one and let you know. But there are many variants of the rules to be sure.
@HGM
I am thinking that the alien mode could benefit from getting the legal moves from the engine. Winboard can use that to force the human player to make legal moves and also facilitate the move selection. An alien game can send any kind of move and it seems to me the only way to make sure legal moves are played is if winboard gets the list from the engine. I am experimenting with this with Nebiyu. When a user clicks one square, winboard reduces the move list to the subset which have that square, second click reduces it further ... until we are left with one move at which point winboard makes that move automatically.
