WB Alien protocol

[H.G.Muller]

OK, very nice! I could play 20 games of mini-Shogi without any further problems, and it plays pretty well.

[H.G.Muller]

Against Shokidoki it seems to run fine, but against TJ I had another crash:

Code: Select all

[Event "Computer Chess Game"]
[Site "MAKRO-PC"]
[Date "2013.03.03"]
[Round "4"]
[White "TJshogi5x5 0.19"]
[Black "NebiyuAlien_1.43"]
[Result "1-0"]
[TimeControl "40/60"]
[Variant "shogi"]
[FEN "+b1sk1/1+b1rp/3G1/PS2R/K1G2[-] w 3 1"]
[SetUp "1"]

{--------------
+ . s k .
. + . r p
. . . G .
P S . . R
K . G . .
white to play
--------------}
1. Gc2 {-1.50/11} Sc4 {+11.85/20 1.4} 2. Gxd4 {+0.00/9 0.4} Kxd4
{+11.80/18 1.4} 3. Sa3 {-0.40/10 1.1} +Bc5 {+11.65/17 1.2} 4. Gd2
{-0.70/9 0.5} Ke5 {+12.90/17 1.4} 5. Kb1 {-2.30/10 0.9} +Bd4
{+12.95/17 1.3} 6. R@b2 {-4.50/10 1.9} G@c3 {+14.10/18 1.4} 7. Gxc3
{-6.30/11 1.6} Sxc3 {+19.30/19 1.4} 8. G@d1 {-7.40/11 1.7} e3
{+19.75/18 1.4} 9. Rec2 {-13.86/11 7} Sxc2 {+35.35/23 1.5} 10. Gxc2
{-15.20/11 2.4} R@e1 {+54.70/19 1.4} 11. S@c1 {-20.38/11 2.0} Rd1+
{+41.05/21 1.3} 12. Sb4 {-199.86/9 0.7} +Bxb4 {+299.86/23 1.5} 13. a3
{-199.90/9 2.7}

[H.G.Muller]

I had it play several hunder 40/min games, and it crashed 6 times. I uploaded a file with the crash games to http://hgm.nubati.net/Ncrash.pgn .

In addition it makes a false illegal-move claim on any deferred promotion of a Silver. This might be simply a protocol issue, that it does not understand the = sign that WinBoard appends as promo-suffix in such cases. (Either that, or it thinks promotion is mandatory.)

[Daniel Shawul]

Oh yeah. I have fixed that yesterday but forgot to tell you. Also i made changes to check extensions which i thought made it really stronger, but later found out it was a so so.
So just download again to avoid the crashes. Right now i feel there is something wrong with its search , because the amount of sudden losses from a good position is just too much. I have the checkmate rule and stalemate is win in place, but maybe still there is something missing..

[H.G.Muller]

Well, I don't know how you test, but at 40/min I see very few of those games. The score usually increases monotonously for one side or the other. (Scores smaller than 2 should not be taken seriously; that is just noise.)

[Daniel Shawul]

Well i don't know the game that well,but it seems timing of drops is very crucial. I see some game where one side is leading by +10 and then looses.
Does shokidoki have a perft embedded in it. I think at least for the 5x5 perft where lance and knight are absent i should get same results.
On 6x6 nebiyu can still drop the knight at the far rank and penultimatum rank so there are still problems.

[H.G.Muller]

Strange, I never saw Nebiyu lose after reporitng such a large advantage (on 5x5). TJshogi5x5 0.10 does that kind of thing, because it uses wrong piece values. But perhaps I should watch more games. I haven't tried any 6x6 yet.

None of my engines has perft. I never found that of much help in debugging the engine. Perft is just too different from how the search works, and almost all search bugs (failures to search certain branches) I encountered in my life were not due to bugs you would discover with perft. (They were mostly wrong sorting, losing the killers, etc.)

I still had a crash, with this new version:

Code: Select all

[Event "Computer Chess Game"]
[Site "MAKRO-PC"]
[Date "2013.03.03"]
[Round "89"]
[White "Shokidoki UEC6+66h1"]
[Black "NebiyuAlien_1.43"]
[Result "1-0"]
[TimeControl "40/60"]
[Variant "shogi"]
[FEN "1r1gk/3sp/P4/1SG2/K3R[Bb] b 1 1"]
[SetUp "1"]

{--------------
. r . g k
. . . s p
P . . . .
. S G . .
K . . . R
black to play
--------------}
1... Rxb2 {+0.65/16 1.3} 2. Gxb2 {+0.60/10 0.9} B@c3 {+0.45/16 1.7} 3. Gxc3
{+0.84/9 0.6} Sxc3 {+0.45/17 1.4} 4. R@b5 {+0.08/9 4} G@b4 {+0.35/16 1.2}
5. B@d4 {+0.08/8 0.8} Sxd4 {+0.00/18 1.1} 6. Rxb4+ {+0.16/9 1.1} B@c3
{+1.40/18 1.8} 7. +Rxc3 {+0.72/10 0.8} Sxc3 {+0.95/16 1.2} 8. G@a2
{+0.80/9 1.1} R@b4 {+1.90/17 1.3} 9. B@b3 {+0.16/9 0.7} Gc4 {+2.40/17 2.1}
10. Rb1 {-4.12/10 3} Gxb3 {+9.90/18 1.3} 11. Gxb3 {-8.72/9 1.7} B@c2
{+12.95/17 1.4} 12. B@d4 {-8.56/8 0.6} Sxd4 {+13.55/17 1.2} 13. Gxb4
{-10.00/9 0.9} B@c3 {+13.50/18 1.4} 14. G@b2 {-11.28/10 1.0} Bxb1+
{+13.60/18 1.5} 15. Kxb1 {-11.32/1} Bxb4 {+13.70/15 1.4} 16. Ka2
{-9.48/8 0.8} R@e2 {+15.60/16 1.4} 17. B@c1 {-10.20/8 0.9} Re1+
{+17.00/15 1.4} 18. R@b5 {-11.20/8 1.1} S@c5 {+18.85/17 1.4} 19. Rxc5+
{-17.12/9 1.8} Sxc5 {+27.35/17 1.4} 20. Gb1 {-399.72/9 2.6} +Rxc1
{+299.84/17 1.5} 21. Gxc1 {-399.76/10 0.9} B@d5 {+299.86/17 1.4} 22. S@c4
{-399.80/10 0.2}
{White wins on time} 1-0


The only other problem is that it occasionally goes into a repeat loop as white, thinking this is a draw (while in fact it loses, by the rule unique to mini-Shogi).

[Daniel Shawul]

I am not getting a crush here so maybe i fixed it since then or it is something un reproducible. The pawn shogi rule had a bug and it was actually never activated where it was. When king captures are allowed i had to look at the move from 3 steps before is a pawn drop or not. I was checking only the previous move so that is fixed now. Try the new version.

Also i am trying to automatically determine piece values and piece square tables by counting the number of moves from each square for each piece. I get reasonable piece values for most variants that way. But jumpers tend to have a bit lower values, so i will have to give a little bonus for them. Maybe it si better to optimize by playing really fast games. In any case this seem to be the right way for the alien version.

Code: Select all

setboard 2sbk/1bS1p/P4/K4/2G2[Rrg] b 2 22
d

            a b c d e
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
          5 . . s b k * * * * * * * * * * * * * * * * * * * * * * * 5
          4 . b S . p * * * * * * * * * * * * * * * * * * * * * * * 4
          3 P . . . . * * * * * * * * * * * * * * * * * * * * * * * 3
          2 K . . . . * * * * * * * * * * * * * * * * * * * * * * * 2
          1 . . G . . * * * * * * * * * * * * * * * * * * * * * * * 1
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            a b c d e

                [Material: 6970 7990 ]
2sbk/1bS1p/P4/K4/2G2[gRr] b - - 2 22

go
[search_time = 6175ms, max_time = 29250ms , moves_left 9, max_nodes 0]
2 2080 0 175  d5c4  a2b2  EBF=12.70
3 2420 0 600  d5c4  R@b3 b4e1+ EBF=8.07
4 2420 0 926  d5c4  a2b1  b4e1+ R@c2 EBF=5.23
5 2480 0 2219  d5c4  a2b1  b4e1+ R@c2 g@c3 EBF=4.44
5 2480 0 2238  d5c4  a2b1  b4e1+ R@c2 g@c3 EBF=4.44
6 2500 1 4534  d5c4  a2b1  b4e1+ R@d2 s@c3 d2d1  EBF=3.87
6 2500 1 5015  d5c4  a2b1  b4e1+ R@d2 s@c3 d2d1  EBF=3.94
7 2545 1 9999  d5c4  a2b1  g@a2 b1c2  r@e2 c2d1  b4e1+ EBF=3.56
7 2545 2 11208  d5c4  a2b1  g@a2 b1c2  r@e2 c2d1  b4e1+ EBF=3.62
8 2660 3 29865  d5c4  R@b3 b4e1+ c1c2  s@c3 c2c1  c4b3  a2b3  EBF=3.48
8 2660 3 30787  d5c4  R@b3 b4e1+ c1c2  s@c3 c2c1  c4b3  a2b3  EBF=3.49
9 2740 4 40985  d5c4  R@b3 b4e1+ a2b2  s@c3 b3c3  r@a2 b2b1  e1c3  EBF=3.12
9 2740 4 43125  d5c4  R@b3 b4e1+ a2b2  s@c3 b3c3  r@a2 b2b1  e1c3  EBF=3.14
10 2835 5 63509  d5c4  R@b3 b4e1+ c1b2  s@c3 b2c3  e1c3  S@a4 c4b3  a4b3  EBF=2.90
10 2835 6 72705  d5c4  R@b3 b4e1+ c1b2  s@c3 b2c3  e1c3  S@a4 c4b3  a4b3  EBF=2.94
11 2980 8 101673  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  r@b3 b2a2  c3c1+ a2b3  b4e1+ EBF=2.74
11 2980 9 109504  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  r@b3 b2a2  c3c1+ a2b3  b4e1+ EBF=2.76
12 29988 10 135505  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.57
12 29988 11 146166  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.59
13 29988 13 164959  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.42
13 29988 16 210524  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.47
14 29988 18 246228  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.33
14 29988 22 305282  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.37
15 29988 29 383774  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.27
15 29988 41 581852  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.33
16 29988 52 711576  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.24
16 29988 67 934070  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.28
17 29988 103 1417976  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.22
17 29988 131 1831646  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.26
18 29988 204 2823880  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.21
18 29988 253 3560385  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.24
19 29988 391 5559597  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.19
19 29988 472 6788748  d5c4  R@b3 c4b3  a2b3  r@c3 b3b2  g@b3 b2a1  s@a2 a1a2  b3a2  EBF=2.22
nodes = 6788748 <45 qnodes> time = 4725ms nps = 1436772
splits = 0 badsplits = 0
move d5c4


[H.G.Muller]

Normally I determine piece values by playing material-imbalance games. But mini-Shogi is so tactical that this did not work. Basically all moves are captures or drops, and the material turns over so fast that it cannot be considered a strategic concept. The number of pieces still is. (And loss of a piece always seem to mean loss of the game.) So I guess this is one of the games where you could tune by tuning the engine's piece values and seeing how it affects performance.

[Daniel Shawul]

The pawn drop still has problems and i don't know if it is possible to solve it when king captures are allowed. In the following position the last move was a pawn drop at a3 by black. White's only move is to capture it, but it tries those two other moves where the bishop attacks the squares. Then when the king is lost and we check if pawn drop is made in the move 3 steps ago , we find that is is illegal checkmate! This doesn't work since there is a legal move that directly captures the pawn. Without the rule , all king captures are as scored as losses, but with the pawn drop rule added i set it as a win to indicate the opponent has made an illegal move. What do you think ?

Code: Select all


            a b c d e f
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
          6 . r . . . k * * * * * * * * * * * * * * * * * * * * * * 6
          5 n . . . b p * * * * * * * * * * * * * * * * * * * * * * 5
          4 . . . . O S * * * * * * * * * * * * * * * * * * * * * * 4
          3 p S . . . . * * * * * * * * * * * * * * * * * * * * * * 3
          2 K . . . . . * * * * * * * * * * * * * * * * * * * * * * 2
          1 . G . N . . * * * * * * * * * * * * * * * * * * * * * * 1
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * * * * * *
            a b c d e f

                [Material: 9260 6925 ]
1r3k/n3bp/4OS/pS4/K5/1G1N2[GB] w - - 1 21


[H.G.Muller]

I suppose Nebiyu scores King-capture in 1 different from King-capture in 2. I think you have to do the correction in the node where the best score is 'King-captured-in-1'. That is not the score in the displayed position, as as KxP is better. So the rule would not kick in. Had the Pawn been protected, (so that this would indeed have been a mate), your best score will remain 'K-captured-in-1', and the preceding move dropped a Pawn in front of the King, so the rule kicks in, and corrects the score to +INF.

The rules of Shogi are not clear about whether it is allowed to stalemate someone with a Pawn drop. I suppose this is allowed.

[Daniel Shawul]

Ok i have implemented it but i am not confident about it. If a pawn drop in front of king result in a mate <=3 it is counted as illegal.
In the previous example, if the pawn drop has already been made by the oppoent, there will not be a chance to change the score. Anyhow
not doing anything helps not to make those illegal moves. The previous way of doing it encouraged those moves.
I just noticed the 'machine match' mode in winboard which i haven't used before. So i will use that to run many games and make sure everything
works before the next update.

[H.G.Muller]

About the protocol: I went through WinBoard to make an inventory of all gameInfo.variant == Variant... conditions, and it is very murky how to replace that by flags with a clear meaning. As a temporary measure, couldn't we simply allow the engine to specify the 'parent variant' in the setup command? In the Alien protocol it can already specify the board size. We might as well let it write 5x5+5_shogi. So if an engine says feature variants="mini-Shogi (5x5)", this would appear in a combobox in the New Variant dialog. If the user chooses it WinBoard would send variant mini-Shogi (5x5), which the engine would of course recognize. It can then send a setup command to WinBoard specifying pieceToCharTable, initial position, board size and 'shogi'.

A more complex change would be to make the New Variant dialog similar to the Load Engine or Themes dialogs, with a listbox listing all the variants, and a set of checkboxes, spins and text-edits to specify the individual rule modifiers. The user could then define his own combination of rule modifications, (which in the current New Variant dialog he can do for board size), and give a name to it, just like he now can define themes. This requires there to be a command-line option for every individual rule modifier. (But even in the current situation, the options -variant, -boardWidth, -boardHeight, -holdingsSize, -pieceToCharTable could be made setable in that dialog, and together with a new string option -startPos (which could be set by ticking a checkbox 'Use current board position as initial one') this would get you a long way defining your own variants.

[Daniel Shawul]

About the protocol: I went through WinBoard to make an inventory of all gameInfo.variant == Variant... conditions, and it is very murky how to replace that by flags with a clear meaning. As a temporary measure, couldn't we simply allow the engine to specify the 'parent variant' in the setup command? In the Alien protocol it can already specify the board size. We might as well let it write 5x5+5_shogi. So if an engine says feature variants="mini-Shogi (5x5)", this would appear in a combobox in the New Variant dialog. If the user chooses it WinBoard would send variant mini-Shogi (5x5), which the engine would of course recognize. It can then send a setup command to WinBoard specifying pieceToCharTable, initial position, board size and 'shogi'.

Yes that is simple enough. I will change my setup as shown below which is sent anytime i want to update the board.
This also means we can use better names for the child variant which is to be specified in the 'feature variants= minishogi'.
I guess now we don't need to order the variants to specify the parent variant.

Code: Select all

void setup() {
   print("setup (%s) %dx%d+%d_%s %s\n",setup_str,BOARDX,BOARDY,HOLDINGS,PARENT,start_fen);
}


A more complex change would be to make the New Variant dialog similar to the Load Engine or Themes dialogs, with a listbox listing all the variants, and a set of checkboxes, spins and text-edits to specify the individual rule modifiers. The user could then define his own combination of rule modifications, (which in the current New Variant dialog he can do for board size), and give a name to it, just like he now can define themes. This requires there to be a command-line option for every individual rule modifier. (But even in the current situation, the options -variant, -boardWidth, -boardHeight, -holdingsSize, -pieceToCharTable could be made setable in that dialog, and together with a new string option -startPos (which could be set by ticking a checkbox 'Use current board position as initial one') this would get you a long way defining your own variants.

Ok all new additions can be sent through the setup. But when you say setable, it means winboard has to send the current configuration back to the engine. What if the engine doesn't support the specific board size that is just set, or other rule that is modified? Right now winboard can only display the selected variant configuration.

[H.G.Muller]

Indeed, perhaps this idea makes no sense. It is simpler, and sufficient, if the engine would set all these things through the setup command. ThenGUI and engine will automatically use the same settings always.

About the format, we should be a bit careful. WinBoard 4.7.0 does not allow board-size to be specified in the setup command, and would only understand it if there is only a FEN, or optionally, a string between parentheses between 'setup' and FEN (which is then used as pieceToCharTable). This unfortunately is an incompatibility between the Alien Edition and regular WinBoard. Of course I could change that in the future, but that would not help engines using 'setup' run in existing regular WinBoard versions.

So make sure this format is only sent when the GUI somehow indicates it understands this format. I guess an indication for that would be that it does send you a non-standard variant name in the variant command. If it would send something like 5x5+5_shogi (which the engine must continue to report if you want it to be able to play in WinBoard 4.7.0, for instance), in stead of minishogi.

If the GUI puts the engine in a standard variant, (i.e. one supported by regular WB), there is no reason to send board size or parent variant in the setup (or, indeed, hardly ever any need to send setup at all). If the GUI sends variant 5x5+5_shogi there also is no need to mention board size or variant in the setup command; the GUI obviously knew these already. So in those cases, send a setup command without this info. Only when the engine is set to a non-standard variant, e.g. variant minishogi, it should use the board-size, parent variant field in its setup command.

[Daniel Shawul]

Sorry that was sent only when receiving the 'variant' command. The one that is sent after every move contains only FEN setup FEN. Apparently this works
for winboard47 because that is what i have been using so far! Check that sending the setup command with board size , only when getting variant command, doesn't break anything. If so i guess we can keep using it since it works. Also figuring out if winboard understands the variant is difficult for the engine.

Once the parent specification is done, how much work will it be to port the alien into standard. The chess,checkers,go,amazons will all be parents where variants could be derived from.

[H.G.Muller]

It probably 'works' because it is ignored. When I run Nebiyu in WB 4.7.0, and select 5x5+5_shogi through the New Variant menu I get an empty board (even with legality testing off). So I suppose you test with an external file for the start position, which would make WB ignore the FEN part of the setup command in any case.

But what we really want is that in human-engine mode Nebiyu would be able to set up the position, also in WB 4.7.0.

It will be a fair amount of work to port all features of the Alien Edition into the main branch. But what is worse, the Alien Edition was an experiment, and I am not entirely happy with it. The implementation of multi-leg moves is really awful and bug-prone, leaving the stack of boards in a state which is inconsistent, and has undefined effects when the user starts stepping through the game before the move entry is completed. In addition loading games in variant alien that need board update is still not possible even in the Alien edition. Having to use the Ctrl key for multi-leg move entry is horrible. In addition there is the XBoard problem; the Alien patch never worked in XBoard.

Some features of the Alien Edition are harmless and simple to implement, though. I especially like the highlight feature, and the way the engine can use it to 'program' the GUI to ask for promotion piece. I think we should also use that for multi-leg entry, by having a separate color for moves that are not necessarily terminating legs. Like the Chu Lion could get all King steps marked in blue, for instance, and releasing it on a blue square would then let the engine mark all King steps from that square in yellow/red, including the square ittself. (Which you could now click to terminate the move on that square, so the first leg becomes the only leg.) Multi-leg moves are already sent to the engine in one usermove command, so WB can afford to wait sendiing the first leg until it knows wheher a second will follow.

So I will probably port the highlight feature, and the way it will activate promotion choice soon. I am not so sure about the multi-move. I would like to offer Chu Shogi in WB as a standard variant, but this would require multi-move. But there are many other problems as well (such as number of piece types), so I am not sure if this is realistic.

[Daniel Shawul]

Yes i was using the the minishogi package which loads the fen from an external file. But i think the solution is to let winboard
accept the first setup with board size and everything for a child variant. If the variant is a paren it knows how to setup, but for derived variants it has to accept
the the initial setup. Shogi is the parent, which is why minishogi needed the fen setup. Doing it from an EPD file is ok for now, but for complex setups involving other rule changes it has to to accept the first setup with piecechars. It can ignore the setups setups sent after the move, because winboard should be able to update board for a child variant. That one is accepted only when the parent is alien.

[H.G.Muller]

In the future anything is possible, but 4.7.0 is what it is. And in principle it can do what is needed, (setting up the position), but only when leaving out the board-size / variant part. I think it would be very bad form not to respect backward compatibility, if it is easy to do it.

It should not be that difficult to refrain from sending the 5x5+5_shogi part if that exactly matched the variant requested by the GUI?

[Daniel Shawul]

In the future anything is possible, but 4.7.0 is what it is. And in principle it can do what is needed, (setting up the position), but only when leaving out the board-size / variant part. I think it would be very bad form not to respect backward compatibility, if it is easy to do it.

It should not be that difficult to refrain from sending the 5x5+5_shogi part if that exactly matched the variant requested by the GUI?

Sure now I can send comfortable and standard names that winboard and other engines use such as minishogi,judkins_shogi. This should be standardized since all engines get the same variant name.

It will be a fair amount of work to port all features of the Alien Edition into the main branch. But what is worse, the Alien Edition was an experiment, and I am not entirely happy with it. The implementation of multi-leg moves is really awful and bug-prone, leaving the stack of boards in a state which is inconsistent, and has undefined effects when the user starts stepping through the game before the move entry is completed. In addition loading games in variant alien that need board update is still not possible even in the Alien edition. Having to use the Ctrl key for multi-leg move entry is horrible. In addition there is the XBoard problem; the Alien patch never worked in XBoard.

The good thing about all this is that you can import variants you deem important anytime you want to,until then it will be offloaded to the parent 'alien' which would require a referee engine. If multi-legs are messy right now,checkers/chu-shogi can be played via alien mode where those moves are displayed by popups. In that mode the move is just a string to winboard. It doesn't understand it, parse it or try to help input the move in anyway since referee will handle via clicks sent to it. I think i may have already implemented all necessary features for promotion popus as well. Once we are done with the 'setup' and highlight features we can discuss about that later. Also since now winboard can load/unload engine through menu, using referee engine is in the horizon (forgive my obsession with this referee thing). I believe we can integrate alien to standard in the near future without importing all the complications with multi-legs/clicks or other messy stuff.