Could anyone make me a Windows compile...?

[hgm]

If I make the board 12x10 and place the extra squares beside the board, I could fit everything in easily. Then I would need to remove the wizard squares from the slider move tables so the board effectively becomes 10x10 with two inactive borders, then hack the move tables so that say "Bd3-a1" becomes a legal move if b1 can be reached and is empty.
For leapers I would need to go over each of the wizard squares, remove it as a valid destination for any of the squares it thinks it can reach, shift the destinations by one rank and then mark the wizard square as a possible destination for all squares that can be reached from it.
The really tricky part might be to prevent things like b9xa10…

Might be fun, actually. However, I don't think I should be hacking in stuff like this in a "release candidate", so if I do something like this it'll be for post 1.0.

For this release a way to specify Shogi as parent variant is all I request!

But for later: I suppose you are doing rotated bitboards for >64 squares, as 128-square magics seem prohibitively expensive. Or are you doing single-ray magics?

In both cases I don't see any real problems. The mapping of squares to bits is arbitrary in both these techniques. You could just map the 10x10 board on bits 0-99, and use bits 100-103 for the wizzard squares. It means the long diagonals will have 12 squares, but if you are able to handle 12x10 boards, you have ten such rays for the ranks, so you must be able to handle that. Only squares on the long diagonals for generation of diagonal moves would not mask away all of the wizzard squares, but leave in two.

[hgm]

Actually it is quite important to have parent variant shogi, as several things do not work now:

* XBoard cannot parse Pawn drops on the first rank in variant fairy, even with legality checking off, which make it flag all machine moves that do so as 'invalid moves'. This should probably count as a bug in the XBoard move parser.

* Variant shogi causes a substitution of the piece images in the promoted series for various forms of the Gold General, while in variant fairy the promoted Pawn looks like a Cannon, etc.

If you don't want to introduce a keyword Parent: in the variant-description file, but use a heuristic to pick the best parent variant, good indicators that point to Shogi would be: '+' promotions, non-Pawn promotions, several promoted pieces that move the same, a promotion zone that spans more than a single rank, use of the no-pawn-drop-mate or one-pawn-per-file flag.

[Evert]

For this release a way to specify Shogi as parent variant is all I request!

Ah, good point: I see that I hadn't actually it on my TODO list. Added now.

But for later: I suppose you are doing rotated bitboards for >64 squares, as 128-square magics seem prohibitively expensive. Or are you doing single-ray magics?

The latter, what is called a "kindergarten" bitboard on the chess programming wiki. In particular, I use the same lookup table for horizontal and diagonal attacks, with appropriate bitmasks (https://chessprogramming.wikispaces.com ... +Bitboards).

In both cases I don't see any real problems. The mapping of squares to bits is arbitrary in both these techniques. You could just map the 10x10 board on bits 0-99, and use bits 100-103 for the wizzard squares. It means the long diagonals will have 12 squares, but if you are able to handle 12x10 boards, you have ten such rays for the ranks, so you must be able to handle that. Only squares on the long diagonals for generation of diagonal moves would not mask away all of the wizzard squares, but leave in two.

That was my initial idea too, but it occurred to me that it would be slightly more intuitive if I made the board 12x10 and then hack the movement tables to shift the wizard squares down or up one rank with respect to piece movement. This has the benefit that I can just use the tables from the 12x10 board for the sliders and only need to tweak the bitmasks for the diagonals. The leaper tables are also easy to change, using just a few shifts.

I actually have Sjaak play Omega Chess now, sortof. Its own output is distorted because it will output the 12x10 board it actually uses, but it cannot yet play through XBoard because I haven't relabelled the squares yet (so they don't agree on what squares are called). Still, so far was actually easier than I had thought.

[Evert]

Code: Select all

[Event "Computer Chess Game"]
[Site "vivaine.local"]
[Date "2015.02.05"]
[Round "-"]
[White "Sjaak II 210:220M"]
[Black "Sjaak II 210:220M"]
[Result "1/2-1/2"]
[TimeControl "40/10"]
[Variant "omega"]
[VariantMen "P:fmWfceFifmW3;N:N;B:B;R:R;Q:Q;C:WDA;W:CF;K:K"]
[FEN "w**********w/*crnbqkbnrc*/*pppppppppp*/*10*/*10*/*10*/*10*/*10*/*10*/*PPPPPPPPPP*/*CRNBQKBNRC*/W**********W 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 {+0.21/6} g7 {-0.45/5 0.1} 2. Qk7 {+0.33/6 0.4} Ci9 {+0.63/5 0.2} 3.
Qh7 {-0.44/6 0.2} Bf9 {+0.46/5 0.2} 4. Qh5 {-0.72/6 0.4} Qh9 {+0.74/5 0.3}
5. Ci4 {-0.24/5 0.2} Qxh5 {+0.92/5 0.3} 6. gxh5 {-0.77/6 0.2} Cd9
{+0.89/5 0.2} 7. Cd4 {-0.34/5 0.1} Cf7 {+0.37/5 0.4} 8. Wk4 {-0.40/5 0.2}
j7 {+0.42/4 0.2} 9. e6 {-0.32/6 0.3} Cf5 {+0.11/5 0.2} 10. Nh4
{+0.02/6 0.2} Cf6 {-0.23/5 0.2} 11. Cxf6 {+0.38/6 0.2} gxf6 {-0.31/5 0.2}
12. Cg6 {+0.21/6 0.3} e7 {-0.21/5 0.2} 13. Nf5 {+0.22/6 0.2} d8
{-0.17/5 0.2} 14. d6 {+0.62/5 0.1} h7 {-0.58/5 0.1} 15. Ch6 {+0.46/6 0.2}
Bc9 {-0.87/6 0.3} 16. Cf8 {+0.67/6 0.2} Cg9 {-0.97/5 0.2} 17. dxe7
{+0.60/4 0.2} dxe7 {-0.61/5 0.2} 18. Cxf9 {+0.57/6 0.2} Cxf9 {-0.66/7 0.2}
19. Nh6 {+0.59/6 0.2} Ch9 {-0.73/6 0.2} 20. j6 {+0.74/6 0.2} Wk11
{-0.88/5 0.1} 21. Rj4 {+0.94/6 0.2} Rj8 {-0.93/6 0.3} 22. Rg4+
{+0.94/5 0.1} Kf11 {-1.23/5 0.3} 23. Wb4 {+0.99/6 0.2} Wh10 {-0.99/5 0.1}
24. i5 {+1.03/6 0.3} b8 {-1.04/5 0.3} 25. Wc5 {+1.05/6 0.2} Ne9
{-0.91/5 0.3} 26. Wj5 {+1.20/5 0.2} Rf8 {-1.41/4 0.2} 27. Ni8 {+1.00/5 0.2}
Wi9 {-0.69/5 0.3} 28. Wb6 {+0.95/5 0.3} Bd8 {-0.45/6 0.3} 29. Wc5
{+0.00/5 0.2} Bc9 {+0.00/7 0.2} 30. Ng7 {+0.90/6 0.3} Ch8 {-0.59/5 0.3} 31.
Wi4 {+0.77/6 0.4} k8 {-1.40/5 0.3} 32. Bd3 {+0.98/6 0.3} h6 {-0.83/5 0.2}
33. h4 {+0.76/6 0.3} Nh9 {-0.60/5 0.2} 34. Bf5 {+0.58/4 0.3} Nxg7
{+0.28/6 0.2} 35. Rxg7 {+0.50/7 1.0} Wj8 {-0.42/6 0.3} 36. Rg3
{-0.48/6 0.2} hxi5 {-0.45/6 0.4} 37. hxi5 {-0.69/6 0.2} Wxi5 {+0.93/7 0.3}
38. k5 {-0.93/6 0.2} Wxh2 {+0.66/6 0.3} 39. Kxh2 {-0.88/6 0.2} b7
{+0.63/5 0.2} 40. Be4 {-0.78/6 0.3} Rb11 {+0.76/5 0.2} 41. b4 {-0.70/6 0.3}
b6 {+1.38/6 0.2} 42. Wf4 {-1.29/7 0.2} Bb8 {+1.29/6 0.2} 43. Rg4
{-1.46/6 0.2} Ch6 {+1.19/5 0.2} 44. Wg3 {-1.51/6 0.2} Cj4+ {+1.51/5 0.2}
45. Kg2 {-1.50/6 0.2} Cxi4+ {+1.50/6 0.2} 46. Rxi4 {-1.68/7 0.3} f5
{+1.43/6 0.2} 47. Bb7+ {-1.78/7 0.3} c8 {+2.68/6 0.3} 48. Bc6 {-2.19/7 0.4}
f4 {+2.08/6 0.3} 49. Wd4 {-0.65/6 0.2} Wb9 {+1.13/6 0.2} 50. Be4
{-0.45/6 0.2} We8 {+0.45/5 0.1} 51. Rxi10 {-0.22/6 0.2} Rg8+ {-0.53/5 0.2}
52. Kf2 {+0.50/6 0.2} Rb10 {-0.53/6 0.2} 53. Ri11+ {+0.70/6 0.1} Kg10
{-0.70/6 0.2} 54. Wxe7 {+0.76/7 0.3} Wf9 {-0.69/7 0.3} 55. Wxb8
{+0.85/7 0.2} Rxb8 {-0.82/7 0.2} 56. Bc6 {+0.54/7 0.2} Kh10 {-0.60/8 0.2}
57. Bxf9 {+0.60/9 0.1} Kxi11 {-0.63/10 0.2} 58. Bxg8 {+0.61/9 0.2} Nxg8
{-0.49/10 0.2} 59. c6 {+0.39/10 0.4} c7 {-0.27/10 0.2} 60. Ne4
{+0.32/9 0.2} Rf8 {-0.14/9 0.2} 61. Rd2 {+0.22/9 0.2} Rf5 {+0.61/9 0.2} 62.
Rd11+ {-0.10/8 0.2} Ki10 {+0.86/8 0.3} 63. Rg11 {-0.94/8 0.2} f9
{+0.91/9 0.2} 64. Rg10+ {-0.84/9 0.2} Kh11 {+0.91/8 0.2} 65. Rc10
{-0.86/10 0.2} Rxh5 {+0.86/9 0.2} 66. Kg2 {-1.08/9 0.4} Rxk5 {+1.82/9 0.2}
67. Rxc7 {-1.59/9 0.2} Rj5 {+1.66/10 0.5} 68. Rf7 {-1.63/9 0.2} Rj2+
{+1.69/9 0.3} 69. Kh3 {-2.99/2 0.1} Rxj6 {+1.66/9 0.2} 70. c7 {-1.71/8 0.2}
Rxe6 {+1.57/9 0.5} 71. Rxf4 {-1.57/8 0.2} Rh6+ {+1.48/8 0.3} 72. Ki3
{-1.35/7 0.3} Ri6+ {+1.42/8 0.3} 73. Kj4 {-1.15/7 0.2} Kg10 {+1.35/7 0.2}
74. Rf7 {-1.36/8 0.3} j6 {+1.39/7 0.2} 75. b5 {-1.36/8 0.2} Kg9
{+1.33/8 0.3} 76. c8 {-1.00/8 0.2} Ne9 {+1.52/10 0.4} 77. Rg7+
{-1.78/10 0.4} Kh8 {+1.78/9 0.3} 78. Rc7 {-1.20/10 0.3} Ri5 {+1.36/9 0.3}
79. Nd6 {-1.65/9 0.3} Rc5 {+1.74/9 0.4} 80. Rxc5 {-1.57/10 0.4} bxc5
{+1.94/13 0.5} 81. c9 {-1.56/11 0.2} Ki7 {+2.10/12 0.2} 82. b6
{-1.93/11 0.1} k7 {+2.23/12 0.2} 83. b7 {-2.20/12 0.2} Nc10 {+2.40/13 0.3}
84. Kj5 {-2.44/12 0.2} Kj7 {+2.37/12 0.1} 85. f6 {-2.58/11 0.2} k6+
{+2.06/12 0.2} 86. Kj4 {-2.26/11 0.2} f8 {+2.51/12 0.2} 87. Kk4
{-2.51/12 0.3} Ki7 {+2.88/11 0.2} 88. Kj4 {-2.16/11 0.2} Ki6 {+2.65/12 0.2}
89. f7 {-1.95/13 0.3} Kh6 {+2.51/11 0.2} 90. Ki4 {-2.51/11 0.1} k5
{+2.50/11 0.1} 91. Kj5 {-2.52/12 0.2} Ki7 {+2.08/13 0.2} 92. Nc4
{-1.53/14 0.3} Kj8 {+1.53/13 0.2} 93. Nd6 {-0.85/13 0.2} Kj7 {+1.90/14 0.2}
94. Nc4 {-1.79/14 0.2} Kk7 {+1.53/13 0.2} 95. Ne5 {-1.51/14 0.2} Nb8
{+0.79/15 0.2} 96. Nc4 {-1.22/15 0.3} Kk8 {+1.40/14 0.2} 97. Ne5
{-1.49/13 0.2} Kj7 {+1.81/14 0.2} 98. Nc4 {-1.12/13 0.3} Ki7 {+2.06/12 0.3}
99. Nd6 {-2.50/12 0.2} Kh6 {+1.31/12 0.2} 100. Nc4 {-1.55/13 0.2} Kg6
{+0.71/11 0.3} 101. Nd6 {-1.42/12 0.2} Kg7 {+1.74/13 0.2} 102. Kk4
{-1.74/12 0.2} Kh7 {+1.35/14 0.2} 103. Kj5 {-1.11/13 0.2} Kg6
{+1.70/15 0.3} 104. Kk4 {-2.50/14 0.4} Kg7 {+1.31/14 0.3} 105. Kj5
{-1.36/12 0.2} Nc10 {+1.80/13 0.3} 106. Kk4 {-2.23/11 0.2} Kh7
{+1.20/13 0.2} 107. Kj5 {-1.50/14 0.2} Kg6 {+1.81/13 0.2} 108. Kk4
{-1.51/14 0.3} Kg7 {+1.20/13 0.2} 109. Kj5 {-0.74/13 0.2} Kh6
{+0.66/12 0.2} 110. Nc4 {-0.66/14 0.3} Kg5 {+1.69/11 0.2} 111. Ne5
{-0.46/12 0.4} Kf5 {+1.70/13 0.6} 112. Nc4 {-3.24/11 0.2} Nb8
{+3.51/12 0.2} 113. Nd2 {-2.20/11 0.3} Kg6 {+2.22/12 0.3} 114. Kk4
{-2.51/13 0.2} Kxf7 {+3.37/14 0.3} 115. Ne4 {-3.17/14 0.2} c4
{+3.48/15 0.3} 116. Nd6+ {-3.48/14 0.3} Ke7 {+4.06/14 0.4} 117. Nxc4
{-3.11/14 0.3} Kd8 {+3.09/14 0.3} 118. Nd6 {-3.08/14 0.5} Nc10
{+3.08/12 0.3} 119. Nf7+ {-2.96/14 0.4} Kxc9 {+3.04/14 0.4} 120. Ng5
{-3.14/16 0.5} Kb8 {+3.20/17 0.5} 121. Nh7 {-2.90/16 0.2} f7 {+3.75/17 0.3}
122. Nxj6 {-3.41/16 0.2} f6 {+2.98/16 0.3} 123. Nh5 {-3.25/17 0.2} f5
{+0.00/15 0.2} 124. Kxk5 {-0.11/14 0.2} Nd8 {+0.11/14 0.2} 125. Ng3
{-0.10/14 0.2} f4 {+0.15/13 0.2} 126. Ne2 {-0.11/13 0.3} f3 {+0.15/12 0.3}
127. Nd4 {-0.11/9 0.3} f3f2=Q {+0.11/9 0.1} 128. Nc6+ {-0.08/8 0.2} Nxc6
{+0.15/6 0.2} 129. Kk6 {-0.08/7 0.2} Qf11+ {+0.11/6 0.1} 130. Kj6
{-0.19/7 0.3} Qf7 {+0.15/8 0.3} 131. Ki6 {-0.15/8 0.2} Kc7 {+0.31/7 0.3}
132. b8 {+0.00/7 0.2} Kd6 {+0.11/6 0.3} 133. b9 {+0.00/8 0.3} Ke5
{+0.00/7 0.2} 134. b10 {+0.00/7 0.2} Kf6 {+0.00/6 0.1} 135. b10b11=Q
{+0.00/9 0.3} Qxb11 {+0.00/7 0.2} 136. Kh6 {+0.00/8 0.2} Ne7 {+0.00/7 0.2}
137. Ki6 {+0.00/7 0.2} Qb5 {+0.00/7 0.3} 138. Kh6 {+0.00/8 0.3} Nc8
{+0.00/7 0.4} 139. Ki6 {+0.00/7 0.2} Kg7 {+0.00/7 0.3} 140. Kj7
{+0.00/8 0.3} Ne9 {+0.00/7 0.4} 141. Ki6 {+0.00/8 0.4} Kh8 {+0.00/7 0.4}
142. Kj6 {+0.00/8 0.2} Nc8 {+0.00/8 0.2} 143. Ki6 {+0.00/9 0.2} Ne9
{+0.00/7 0.2} 144. Kj6 {+0.00/60 0.2} Nc8 {+0.00/9 0.3} 145. Ki6
{+0.00/60 0.2} Ne9 {+0.00/8 0.3}
{3-fold repetition} 1/2-1/2

The only real issue (which occurs for Omicron Chess too) is that (as you can see) the detection of mate potential is badly broken. That's due to the function that determines mate potential not working correctly if the board has holes in it.
The SAN move parser also isn't working correctly for Omega Chess, but it's almost unplayable without a GUI anyway because of the mangled board.

I didn't bother implementing castling (I figured it would just confuse XBoard if it happened) and I'm not sure what would happen after, "long" en-passant capture (say 1. c3-c6 b5xc4 e.p. if we have a black pawn on a5 and white advances the c pawn three ranks).

Anyway, that's for later consideration.

[Evert]

If you don't want to introduce a keyword Parent: in the variant-description file, but use a heuristic to pick the best parent variant, good indicators that point to Shogi would be: '+' promotions, non-Pawn promotions, several promoted pieces that move the same, a promotion zone that spans more than a single rank, use of the no-pawn-drop-mate or one-pawn-per-file flag.

I actually ended up adding an "XBoard parent:" tag for a variant description.
It seems the safest (and easiest) way to do this: any of the heuristics could fail, but I could (in the future) adopt some of them to give a better default than "fairy".

To Sjaak it's just a meaningless string that gets passed through anyway, just like the piece-to-char table. I considered naming it something like "Game family" rather than "XBoard parent", but decided against it because this has a more obvious link to XBoard.

[hgm]

I actually ended up adding an "XBoard parent:" tag for a variant description.
It seems the safest (and easiest) way to do this: any of the heuristics could fail, but I could (in the future) adopt some of them to give a better default than "fairy".

OK, great.

As to Omega Chess: triple-push e.p. actually does work in the development version; it was one of the patches that distinguishes it from 4.8.0. (The variant that triggered these patches was an Omega-Chess derivative, http://www.chess.com/forum/view/chess96 ... mega-chess . I had to completely redesign XBoard's way of keeping e.p. rights for it.)

The current implementation of non-royal castling is not satisfactory: it is triggered by an O atom in the Betza string for the piece, but this implies use of the corner piece (minus dark squares), and thus is no good for Omega. The internal move format in XBoard 4.8 is (fromSqr, toSqr, killSqr), the latter to allow an extra 'e.p.' victim for the benefit of the Lion, and uses the kludge that a kill-own move resurrects the killed piece at the other side of the mover in MakeMove. The Betza format would allow definition of such a move explicitly, with the aid of a 'd' modifier for capture own, to hit a non-corner piece. It would not apply the virginity test on the castling partner in that case, though.

The latter could be solved by a small extension of XBetza, defining ci and di as modalities that can only capture and destroy virgin pieces. It remains an ugly kludge, however. Of course testing the virginity could simply be left to the engine. It is not really disastrous if XBoard would indicate a move target (namely KxR first leg) that is not actually legal, in the rare case that the castling partner would be in the right place, yet non-virgin, and have the engine reject it if the user enters that move.

Currently this kill-own auto-resurrection kludge is reserved for non-royal pieces. I see no good reason why it should not be used on King moves too, though. It is also restricted to pieces having an O in their Betza definition, which should be extended to a 'di' substring. Because XBetza is limited to using the same atom for every leg of a move, you would be forced to use a W atom, and 'spell out' the trajectory step by step. E.g. for Omega K-side castling it would be irmafmafdiabW (for the white King; for the black King it would be l in stead of r). And for Q-side castling it would even be worse: ilmafmafmafdiababaW. It would be nice if we had something better for that.

The kludge for the internal move notation currently leaks to the protocol world by specifying the kill-own move like it was real. This is undesirable: in the protocol moves with an extra victim are already transferred as full-blown two-leg moves, where the legs share the kill square ("ab,bc"). This for compatibility with the Alien Edition, which supports general multi-moving. So there is no need for any kludge here; Omega castling could simply be written as g2i2,j2h2. XBoard 4.8 should have a preproscessor code to translate such a move to g2i2;j2 , which is the kill-kludge format with j2 as kill square, like it now preprocesses incomming moves of the form ab,bc to make ac;b. And on printing moves make the reverse expansion.

So for the protocol castling with a non-corner partner should be fed to the engine as

usermove g2i2,j2h2

while the engine should print it in two lines

move g2i2,
move j2h2

[hgm]

One (somewhat ad-hoc) way to extend XBetza to more easily indicate Omega castling is to further abuse the 'j' modifier. Originally this meant 'must jump' on a leap of more than one square, but in XBetza I already used it in two other contexts as 'skips one square': on sliders like jR it means they completely ignore the first square on the Rook path, and slide from there. On drops j@ means you cannot drop on the first rank. So perhaps it would not be too crazy to interpret jO as a castling not with the corner piece, but with the piece one inward. That would make Omega castling isjO2.

All this is just 'convenience', to shorten notation for common movers that would be very long and cumbersome in the basic system. E.g. with the use of the spontaneous range-toggling modifier 'y' skipping a square like jR could have been written as gyafW, i.e. a W step to occupied or empty followed by Rook motion in the same direction. Even in original Betza jD could have been written as pR2. Using jO as notation for castling with the 'next-to-corner' piece is not general, but it is very unlikely you would ever need more.

[Evert]

As to Omega Chess: triple-push e.p. actually does work in the development version; it was one of the patches that distinguishes it from 4.8.0. (The variant that triggered these patches was an Omega-Chess derivative, http://www.chess.com/forum/view/chess96 ... mega-chess . I had to completely redesign XBoard's way of keeping e.p. rights for it.)

Interesting. It wouldn't be that hard to adapt Sjaak to play it (just more hacks in the vein of the ones I use for Omega itself), only the piece that is "iron except with respect to this one other piece" would require some changes in the "core" of the program.

The current implementation of non-royal castling is not satisfactory: it is triggered by an O atom in the Betza string for the piece, but this implies use of the corner piece (minus dark squares), and thus is no good for Omega. The internal move format in XBoard 4.8 is (fromSqr, toSqr, killSqr), the latter to allow an extra 'e.p.' victim for the benefit of the Lion, and uses the kludge that a kill-own move resurrects the killed piece at the other side of the mover in MakeMove. The Betza format would allow definition of such a move explicitly, with the aid of a 'd' modifier for capture own, to hit a non-corner piece. It would not apply the virginity test on the castling partner in that case, though.

The latter could be solved by a small extension of XBetza, defining ci and di as modalities that can only capture and destroy virgin pieces. It remains an ugly kludge, however. Of course testing the virginity could simply be left to the engine. It is not really disastrous if XBoard would indicate a move target (namely KxR first leg) that is not actually legal, in the rare case that the castling partner would be in the right place, yet non-virgin, and have the engine reject it if the user enters that move.

Currently this kill-own auto-resurrection kludge is reserved for non-royal pieces. I see no good reason why it should not be used on King moves too, though. It is also restricted to pieces having an O in their Betza definition, which should be extended to a 'di' substring. Because XBetza is limited to using the same atom for every leg of a move, you would be forced to use a W atom, and 'spell out' the trajectory step by step. E.g. for Omega K-side castling it would be irmafmafdiabW (for the white King; for the black King it would be l in stead of r). And for Q-side castling it would even be worse: ilmafmafmafdiababaW. It would be nice if we had something better for that.

I'm going to try to slip "ilmafmafmafdiababa" into casual conversation. In the mean time, an alternative would be good.

So for the protocol castling with a non-corner partner should be fed to the engine as

usermove g2i2,j2h2

while the engine should print it in two lines

move g2i2,
move j2h2

Ok, if that's the way to handle non-canonical castling (or guarding), I can handle that.
Is it correct to do this if either 1. neither piece is royal, or 2. neither piece is a corner piece? It seems like it should be.

[hgm]

Interesting. It wouldn't be that hard to adapt Sjaak to play it (just more hacks in the vein of the ones I use for Omega itself), only the piece that is "iron except with respect to this one other piece" would require some changes in the "core" of the program.

Indeed, this was a weird feature. The inventor was not interested in an engine, just in a means to play it over the internet. So it was only used with the p2p pseudo-engine, and the players just had to take care of this rule detail by themselves. (I modified p2p to print a file with setup + piece commands in response to the variant command.)

After I explained him how the piece commands worked to configure WinBoard, he seemed to lose interest in playing this variant, and instead got hooked to designing ever-more-complicated variants...

Ok, if that's the way to handle non-canonical castling (or guarding), I can handle that.
Is it correct to do this if either 1. neither piece is royal, or 2. neither piece is a corner piece? It seems like it should be.

Only (1):

In the XBoard patch I just pushed, this will be accepted for any piece that 'tramples' an own piece AND has an O atom in its Betza descriptor.

Although this would also work on a King, it should not be used when one is involved. This mainly for uniqueness of castling representation and backward compatibility. For Kings an oversized sideway step can be used to indicate castling, and it will castle with the first piece it sees in that direction. This does not have to be a corner piece, so there is no need to use the new format just because the partner is not in the corner. (You would have to if it is not on the same rank, though!)

XBoard is now not smart enough to recognize some notations are equivalent, so the Betza move generator will decide which notation is considered legal, and reject the other. For Kings it will use the oversized-step method, for other pieces the trample-friend method.

CAVEAT

The regular edition of XBoard is currently very limited in its understanding of multi-moves, as its internal encoding of moves consists of (from, to, trample) square triplets. (Which already is far more powerful as XBoard 4.7's (from, to) representation.) So even interpreting two fully independent moves is beyond it, and such moves are mapped onto (from, to, trample) as follows:

A-B, C-D gives (from=A, to=B, trample=C) if B and C are on different files
A-B, C-D gives (from=A, to=D, trample=C) if B and C are on the same file

The second case is supposed to be used only for hit-and-run captures. Since B=C there, only C had to be stored.
The first case, which I just added, is supposed to be used only for non-standard castling. The info on the 'resurrection square' D is now lost, but with the convention that friend-trampling indicates castling on Betza-O pieces, it is reconstructed as the square next to B on the opposite side. THIS HAD BETTER BE ON BOARD! Moves like e1a1,h1xx would currently lead to undefined behavior.

If the piece at A does not have O moves, C willstill be trampled, (whether friend or foe), but not resurrected, as a side effect of the move A-B.

[Evert]

Interesting. It wouldn't be that hard to adapt Sjaak to play it (just more hacks in the vein of the ones I use for Omega itself), only the piece that is "iron except with respect to this one other piece" would require some changes in the "core" of the program.

Indeed, this was a weird feature. The inventor was not interested in an engine, just in a means to play it over the internet.

True.
I guess someone somewhere has something interesting to say about the fact that when the one person he could play this game with moved far away, he sought a way to communicate with that person so they could continue to play, whereas back in the day when I wanted to play Xiangqi I decided to write a computer program to do that.

After I explained him how the piece commands worked to configure WinBoard, he seemed to lose interest in playing this variant, and instead got hooked to designing ever-more-complicated variants…

Well, as long as he has fun with it, that's cool.

Ok, if that's the way to handle non-canonical castling (or guarding), I can handle that.
Is it correct to do this if either 1. neither piece is royal, or 2. neither piece is a corner piece? It seems like it should be.

Only (1):

In the XBoard patch I just pushed, this will be accepted for any piece that 'tramples' an own piece AND has an O atom in its Betza descriptor.

Great!

Although this would also work on a King, it should not be used when one is involved. This mainly for uniqueness of castling representation and backward compatibility. For Kings an oversized sideway step can be used to indicate castling, and it will castle with the first piece it sees in that direction.

Ah, that is the obvious solution, of course: if the first piece it finds isn't the castle-partner, then no castling would be possible anyway.
Although, wouldn't this allow castling with Nb1 in ortho-chess?

This does not have to be a corner piece, so there is no need to use the new format just because the partner is not in the corner. (You would have to if it is not on the same rank, though!)

Has anyone ever done something like that?