hgm wrote:Evert wrote: Not sure what XBoard would do if Sjaak would try to castle (it didn't in the games I tested with).
I am pretty sure it would castle with the Champion. Which is already a big improvement: the previous version castled with the black square!
Now at least it skips black squares when looking for the corner piece.
Here it still crashes if I try to start with blacked out edges; not sure what version I'm on though, I could try out a more recent snapshot.
The problem is that non-corner-piece castling in Omega Chess is not Fischer castling, and although the KxR encoding is great for indicating which pieces you want to castle, but gives no information at all where you want those to end up…
Indeed. Perhaps that's something that can be done through some special Betza tokens? It's probably safe to assume that the "castle partner" ends up next to the "king" on the side opposite to where it just moved, so the only question is how many squares should the king move? So "O2" would mean "take a two-square step in the direction of the corner". I guess that wouldn't cover something like Janus Chess, which has asymmetric castling (the king always ends up next to the corner so it moves a different number of squares to the left than it does to the right).
There is a fundamental problem in XBoard that part of the information goes lost in the internal move encoding, (the implied side effects), and have to be reconstructed by the MakeMove routine through some heuristics.
That's extremely annoying. I guess it's not set up in a way that would make it easy to change this?
I originally wrote the move encoding in Sjaak based on a description of the move encoding in ChessV: a series of pickups and drops. You then have all the information you need right there (in fact, you have more than you need), including all side-effects. An en-passant capture is really no different from a regular capture, except the piece you "pick up" is not on the same square where you "drop" your own piece.
I changed it a bit for SjaakII in that I now also allow for "swaps", which are just two squares to indicate which piece should move where. This requires less information, which means I can now do castle+gate, which didn't fit in the old move encoding.
It really makes make-move and unmake-move very easy:
Code: Select all
1. Resolve all pickups
(Store the piece that was picked up in the undo stack, not needed if it is in the move encoding)
2. Perform all swaps
3. Resolve all drops
While for unmake:
Code: Select all
1. Reverse all drops
2. Perform all swaps
3. Reverse all pickups
(Retrieve the piece that was picked up from the undo stack, not needed if it is in the move encoding)
There are special markers to indicate that a piece should be placed in or taken from the holdings, but if those are encoded as off-board squares you wouldn't even need that: they'd just be extra drops/pickups.
More of a problem is how to tell the Betza move generator castling is with the Rook, and not the Champion, because there it really has to be decided whether the castling is legal. Since XBoard 4.8 understands hit-and-run capture in the multi-leg notation, the kludge is available to write castlings as KxR-dest, and make the fact that you captured an own piece with such a move imply that piece will reappear on the other side of the given 'dest'. (The capture already took care of their removal.) So I guess this would be a good extension of the KxR notation for the otherwise untreatable case where the King does not end up in the standard location.
That is indeed tricky. I thought adding the "castle" move to the rook, so that it knows to join up the king and the rook, would solve that, but if the queen also gets a "castle" move, it would also allow the king to castle with the queen (which doesn't sound as weird as it should)...
BTW, I tried to run your small-omaga definition, and although WinBoard does not crash, all moves are refused. Either by WinBoard, when legality checking is off (because Sjaak sends an empty color-FEN in the highlight command when I pick up a Pawn, so that WinBoard will not allow me to put down the Pawn anywhere),
Odd. It works here:
Code: Select all
757 >first : new
random
757 >first : variant omicron_chess
757 >first : level 40 0:10 0
757 >first : post
757 >first : hard
757 >first : easy
757 >first : ping 1
Impossible move , type = 0
920 <first : setup (PNBRQ..C........W....Kpnbrq..c........w....k) 12x10+0_fairy w10w/1crnbqkbnrc1/1pppppppppp1/12/12/12/12/1PPPPPPPPPP1/1CRNBQKBNRC1/W10W w KQkq -
recognized 'fairy' (-1) as variant omicron_chess
shuffleOpenings = 0
FEN castling rights: 11 12 90 11 12 90
1086 <first : piece N& N
1086 <first : piece C& WDA
1086 <first : piece W& CF
1086 <first : piece B& B
1086 <first : piece R& R
1086 <first : piece Q& Q
1086 <first : piece K& K
1086 <first : piece P& fmWfceFifmW2
1086 <first : pong 1
8519 >first : lift g2
8520 <first : highlight 12/12/12/12/12/6Y5/6Y5/12/12/12
9640 >first : put g4
(I changed the name to "Omicron" chess since "Small omega" sounds a bit off; I also disabled castling for the test). The game plays out normally, until Sjaak tries to promote a pawn:
Code: Select all
[Event "Computer Chess Game"]
[Site "vivaine.local"]
[Date "2015.02.04"]
[Round "-"]
[White "Sjaak II 210M"]
[Black "Sjaak II 210M"]
[Result "0-1"]
[TimeControl "40/10"]
[Variant "omicron_chess"]
[VariantMen "P:fmWfceFifmW2;N:N;B:B;R:R;Q:Q;C:WDA;W:CF;K:K"]
[FEN "w10w/1crnbqkbnrc1/1pppppppppp1/12/12/12/12/1PPPPPPPPPP1/1CRNBQKBNRC1/W10W w - - 0 1"]
[SetUp "1"]
{--------------
w . . . . . . . . . . w
. c r n b q k b n r c .
. p p p p p p p p p p .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. P P P P P P P P P P .
. C R N B Q K B N R C .
W . . . . . . . . . . W
white to play
--------------}
1. g4 f5 {-0.03/5 0.4} 2. Ne3 f4 {-0.40/5 0.4} 3. Neg2 Qf6 {+0.91/5 0.3} 4.
Nh3 Cd6 {+0.12/4 0.2} 5. e3 fxe3 {+0.29/4 0.2} 6. dxe3 Ci6 {+0.26/4 0.2} 7.
f4 Cxg4 {+0.68/4 0.2} 8. Ni3 {-1.01/4} Ch4 {+0.45/5} 9. Wi1 {-0.08/5 0.3}
Ci4 {+0.15/4 0.2} 10. Ng5 {+0.13/5 0.2} Cg6 {-0.13/4 0.2} 11. Qc4+
{+0.39/5 0.2} e6 {-0.39/4 0.2} 12. Ne4 {+0.55/6 0.4} Cxe4 {-1.12/6 0.4} 13.
Bxe4 {+1.12/5 0.2} g5 {-1.08/5 0.5} 14. Bc3 {+1.49/5 0.2} Qf7 {-1.55/5 0.3}
15. fxg5 {+1.84/5 0.2} Cc6 {-1.28/5 0.3} 16. Bxc6 {+1.60/6 0.3} Bxc3
{-1.95/5 0.3} 17. Bxb7 {+2.45/6 0.2} Nxb7 {-2.54/6 0.4} 18. Qxc3
{+2.63/6 0.3} Wb6 {-2.75/5 0.2} 19. Qf6 {+2.52/6 0.3} Wc5 {-2.15/6 0.3} 20.
Qxf7+ {+2.94/6 0.2} Kxf7 {-2.94/5 0.2} 21. Rf1+ {+2.83/7 0.4} Ke7
{-2.98/6 0.4} 22. Cd3 {+2.77/6 0.2} i5 {-3.14/6 0.4} 23. j4 {+3.04/6 0.2}
Bi4 {-3.24/6 0.3} 24. h3 {+3.82/7 0.2} Bg6 {-3.37/7 0.3} 25. jxi5
{+3.07/7 0.3} Bxd3 {-3.07/6 0.2} 26. cxd3 {+3.18/7 0.3} Wd2+ {-3.63/6 0.4}
27. Kh1 {+3.65/6 0.3} Wxe3 {-3.50/7 0.2} 28. Ng2 {+3.70/7 0.3} Wd4
{-3.37/7 0.2} 29. Wh4 {+3.60/7 0.4} j6 {-3.42/6 0.2} 30. Nf4 {+3.31/6 0.4}
Rk8 {-3.81/6 0.3} 31. Ci3 {+3.83/7 0.4} jxi5 {-3.83/6 0.2} 32. Cxi5
{+4.08/7 0.4} Kd6 {-3.82/5 0.2} 33. g6 {+4.36/7 0.3} hxg6 {-4.86/7 0.3} 34.
Nxg6 {+4.77/7 0.3} Nj6 {-4.76/7 0.3} 35. Ni7 {+4.66/7 0.4} Rke8
{-4.80/8 0.3} 36. Cxk7 {+5.32/7 0.5} Nh7 {-4.85/7 0.2} 37. k4 {+5.22/6 0.2}
Nc5 {-4.96/7 0.2} 38. Cj7 {+4.57/7 0.4} Wi8 {-4.13/7 0.3} 39. Rf3
{+4.13/6 0.2} Ng5 {-3.50/8 0.6} 40. Wxg5+ {+3.70/7 0.2} Wxg5 {-3.75/9 0.6}
41. b4 {+3.75/8 0.2} Nb7 {-3.75/9 0.3} 42. i4 {+3.69/8 0.2} c5
{-3.79/8 0.3} 43. b5 {+4.06/7 0.2} c4 {-4.04/7 0.1} 44. dxc4 {+4.11/7 0.2}
Rxc4 {-4.00/7 0.4} 45. Wd1 {+3.82/7 0.3} Rb4 {-3.77/6 0.1} 46. Wc2
{+3.58/6 0.1} Rc8 {-3.22/6 0.2} 47. Rd3+ {+3.22/6 0.2} Wd4 {-3.22/6 0.2}
48. Rd2 {+3.65/8 0.6} Rxc2 {-3.52/7 0.3} 49. Rxc2 {+3.81/9 0.2} Rb1+
{-4.57/8 0.2} 50. Ki2 {+4.35/9 0.2} Rxj1 {-4.35/9 0.2} 51. Kxj1
{+4.72/10 0.2} Wxj7 {-5.04/10 0.2} 52. k5 {+5.04/9 0.1} Wk4+ {-5.04/7 0.2}
53. Ki2 {+5.43/8 0.2} Nc5 {-5.52/8 0.4} 54. k6 {+5.52/8 0.2} Wg3
{-6.06/8 0.3} 55. Nh5 {+6.65/8 0.2} Wxh5+ {-7.28/9 0.2} 56. ixh5
{+6.93/9 0.2} Wh6 {-7.51/10 0.2} 57. h4 {+7.25/10 0.2} e5 {-7.13/11 0.3}
58. Kh3 {+7.21/10 0.2} e4 {-7.62/10 0.2} 59. Kg4 {+7.22/10 0.2} Kd5
{-7.86/10 0.2} 60. Kf5 {+7.81/10 0.2} Wk7 {-7.79/10 0.2} 61. Kg6
{+7.79/9 0.2} e3 {-7.63/10 0.2} 62. b6 {+7.27/10 0.2} d6 {-8.01/10 0.2} 63.
h6 {+8.13/11 0.3} Kc6 {-7.63/9 0.2} 64. Re2 {+7.93/11 0.3} d5
{-8.30/10 0.3} 65. Rxe3 {+9.97/10 0.4} Kxb6 {-10.39/10 0.2} 66. Re7
{+11.59/11 0.2} d4 {-11.30/11 0.3} 67. Rxk7 {+17.61/11 0.4} Ne6
{-16.34/10 0.2} 68. Rf7 {+19.71/11 0.5} d3 {-17.78/8 0.2} 69. k7
{+20.16/9 0.4} Nd8 {-20.47/8 0.3} 70. Rf6+ {+24.42/9 0.5} Nc6
{-23.49/7 0.2}
{Xboard: Forfeit due to invalid move: k7k8q (k7k8 via `/) res=24} 0-1
I suspect Sjaak does not start counting ranks at 0, causing disagreement on what the moves and lift commands mean.
It normally doesn't, but it should relabel everything if the board has 10 ranks and it's in XBoard mode. Does it work if you make it play Xiangqi (which works here, but so does Omicron Chess)?
I never noticed this, but I probably looked at the description of moves sent by the GUI.