WinBoard, exotic version

[Daniel Shawul]

He is showing only the top-right part of the board, so this position is from 10x10 international checkers which allows pawn capturing backwards. This positions is 'twisted'. The destination square for first leg (which was marked red) got overwritten by the last destination square. Easy to fix for me but hard to find this kind of bugs

Btw Rein, this is the kind of captures I don't resolve in my move generator.
In the above position, there are two paths (moves) ,
i5-h7-f9-d7-f5-h7
and
i5-h7-f5-d7-f9-h7

This was very hard for me to compare and discard one of them efficiently.

[Daniel Shawul]

This is a "cruel" example. It also uncovered another highlighting problem after fixing the previous problem. Now h7 is marked as Red. But after making the first leg move i5-h7, the highlighting is re-calculated with the pawn at h7. Doing that will include b5 and c6 into the mix.Because now h7 is not empty anymore and hence can not be a destination square. The other move was ignored previously because it resulted in shorter length capture when the pawn was at its original position. I still don't know what to do about this without rewriting the highlighting scheme I am using now i.e regenerating moves leg-by-leg.

[muxecoid]

What about Arimaa support?

[hgm]

I am not expert on Arimaa, but I don't think it would need any features that WinBoard does not support now. I guess it should be played as variant alien, because sometimes pieces disappear in a pit, and WB would not be aware of that unless the engine corrected the board position after the move. Otherwise it could have been played as variant multi.

Of course you would need an engine, but I would not call that 'support'.

Now we are talking about multi-move games: another, more Chess-like example of an interesting multi-move game is Chieftain Chess, where you can move up to 4 pieces per turn. (As many as you have Chieftains left.)

[Rein Halbersma]

Btw Rein, this is the kind of captures I don't resolve in my move generator.
In the above position, there are two paths (moves) ,
i5-h7-f9-d7-f5-h7
and
i5-h7-f5-d7-f9-h7

This was very hard for me to compare and discard one of them efficiently.

This is where bitboards are much more convenient. I simply compare the bitboards of captured pieces for equality. You would probably have to sort the captures, and then compare the lists. Not worth the trouble.

[hgm]

Actually, it seems you have more than a highlighting problem here. It seems there is a move-generator problem as well. Or do I misunderstand the rules?

1p1p1p1p1p/p1p1p5/1p3p1p2/2p5P1/3p1p1p1P/p7P1/1P8/P1P7/1P1P1P1P1P/P1P1P1P1P1 w - - 0 15

Nebiyu captures only 3 pieces here

(upper-right):
[d]1p1p1p1p/p1p5/3p1p2/p5P1/1p1p1p1P/6P1/8/P7 w - - 0 15

I think it should have captured 4.

[Daniel Shawul]

Ahh..that was what I was missing. Indeed with bitboards it becomes easier. Comparing with piece lists was damn expensive and it is not just one or two paths. Thanks.

[Daniel Shawul]

Yes this kind of circular 4-or-more capture lengths are not tested well. My perft doesn't match because of that and ofcourse duplicate move. I will fix it.

I am trying to play with NebiyuChess and NebiyuAlien and it works for the normal chess as it is. But I am having discrepancies when playing grandchess ,shogi etc mainly because of FEN. Currently I include ep,castling stauts etc for all games.. So it crashes when it get a shortened FEN. Should I not try to parse ep,castling etc when the game doesn't need it ?

Since I could have many alien games in alien.ini, the "feature variant..." list could be very long. You have to increase your buffer I think.
But I think the current scheme of nebiyu also works once I fix the FEN problems for those games. More later.

[Daniel Shawul]

for the first time my perft numbers for depth 9 match after fixing the bug you reported. I still didnt remove the duplicates (and probably never will) but it matches the number with duplicates.

perft 9
f4g5. 4158878
f4e5. 4340780
h4i5. 6360384
h4g5. 3660528
b4c5. 3688184
b4a5. 5649982
d4e5. 4156481
d4c5. 3631435
j4i5. 5375962
nodes 41022614
time 12.61 sec

[hgm]

What exactly crashes? WinBoard or Nebiyu? WinBoard should be pretty liberal in reading FEN. It does not recognize a castling field in games with no castling, but the worst thing that can happen is that it mistakes it for the e.p. square, and then fails to read the 50-move counter (so it wil be taken as 0).

In the other direction it sends no castling field in varants without castling, and no e.p. square in variants without e.p. But it is simple to make your FEN reader resistant to that, y taking '-' as default value, and not attempting to read them if the next chaacter is a digit.

Can the problem be that Nebiyu chokes on the holdings? All games you mention have holdings. E.g. when I paste the initial position of Shogi, the engine gets

setboard lnsgkgsnl/1r5b1/ppppppppp/9/9/9/PPPPPPPPP/1B5R1/LNSGKGSNL[-] w 0 1

Where [-] indicate empty holdings. Somewhere during a game a FEN can look like this:

l1r3p1l/2gsk1l+R1/2nppG3/p7p/4+b4/PPP1N3P/2NPPP3/2S1GG3/L3K4[PPPPPBSpns] b 0 47