Winboard Forum

Continuation of PM discussion:

Daniel Shawul wrote:Yesterday i removed sending variants 8x8+0_alien and such. Now it can play games perfectly under the standard winboard version. So i had a chance to play games against many variants in pulsar and shokidoki. I found many bugs in variants such as atomic, shogi etc... Nebiyu was basically playing itself in the past so these bugs don't show up. Can we completely remove sending of 8x8+0_alien etc in the winboard variant ?

To play under standard WinBoard reporting 'alien' in the variants feature is pointless anyway, as it does not know that variant. In WB-Alien it is usually not needed to to explicitly define a size override in WinBoard, as the engine will redefine the size through the setup command. You might want to do it if you want to play from a file of start positions, though. Then XBoard would not accept the FENs i the file unless it was set to the same board size first. So it could be necessary to start WinBoard with 3x4+3 size in -variant alien, and then it would check if the engine says it supports 3x4+3_alien, and it would not be satisfied with just variants="alien".

There already exists a solution for that, however: when you include "boardsize" as a pseudo-variant in the variants feature, WinBoard will assume any of the variants you mention can also be played with other board sizes. So feature variants="shogi,boardsize" would lead WinBoard to think the engine can play Shogi with any board/holdings size. This should really be improved by specifying a maximum, like feature variants="alien,15x15+7boardsize" would allow variant alien with any board size upto 15x15, and any holdings size upto 7. I think the specs even state this.

We could require that the engine should not overrule an explicitly requested board size. If WinBoard would just say variant alien, the engine would specify the size in a setup command, (as per its combobox) and WB would obey. If, however, WB would send variant 5x5+5_alien, it was probably set to 5x5 before starting the game for a reason (e.g. an externally loaded start pos), and not respecting it is a source of trouble. (WB will likely ignore the setup command in that case). Perhaps the engine should report the discrepancy in a tellusererror command. I can imagine that engines like Nebiyu would be capable of taking the rules of the variant they were set for per combobox (or which they recognize from the variant command), and use all its rules except for the board size, in which they would use what the GUI requested.

E.g. suppose I set WinBoard for 8x8 board, 7-holdings and select Shogi. It will send variant 8x8+7_shogi to the engine. Now the engine only knows 5x5+5, 6x6+6 and regular (9x9+7) shogi. So it picks 9x9 as being the closest, uses it rules, overrules the board size to 8x8, improvises a starting position in any way it wishes (could be empty board, anticipating that the GUI will provide it). For engines that supply arbitrary board size (as "boardsize" in the variants list suggets) this seems a good procedure. Engines that only specify specific board sizes would have to explicitly mention all of those as prefixed names.

As you said it is useless except for checking board size. One the variants are completely determined from the combo box for non supported variants. Second when some match those supported with winboard then it should send me 8x8+0_normal etc.. Winboard currently just say 5x5+5_alien and don't allow to play a game. If you remove that from the alien edition , Nebiyu can play in both alien and standard edition of winboard perfectly. In alien mode Nebiyu always sends setup.

For shogi, drops for pawns were allowed anywhere, now fixed it so that files with no pawns. That required a special flag in the ini with Shogi_pawn_rule.

Indeed, this is an annoying rule for an engine builder...

I still need to add the 'pawns can't be dropped to give checkmate' stuff.

There is another engine that ignores this rule, and from that I know that in mini-Shogi there is a lot of opportunity to violate it. As the side that will get checkmated usually sacrifices all his material to postpone it, the mating side will have a wide choice of material to drop. And often it drops a Pawn when plenty of other material could have been dropped in stead to deliver the mate as well. (S, G, and R are all upward-compatible to P.)

Note, however, that the problem game I sent you was not about dropping Pawns, but about dropping Rooks!

Right now i think what is left to fix are promotion piece chars Nebiyu only knows single char promotion lettters. So i use T , D etc for promotion letters. Even when two different pieces promote to goldgeneral different letters are used since it helps when making drops letter. I can still use T, D internally and send a +,= appended double letters but the problem is during promotions. I

The problem is not double letters. In Shogi one uses only a + to indicate promotions. (Very confusing for Chess players, who would think it means check!). Like a4a5+ (in mini-Shogi) in stead of a4a5g . So you would have to write the + in stead of the letter. And on input, replace the + by the ID letter for whatever piece you know the moved piece to promote to. And be sure to ignore a promotion character =, which can be added to stress there is no promotion when there could have been one.

I have now fixed most of the issues so it played some games against TJshogi. Btw shokidoki does not implement the rule of not droping pawns on the same file as other similar pawns. There are still some rare illegal move claims that i need to figure out. There are just too many exceptions to the general rule in shogi I will send you the files when it can play some long games of shogi/mini=shogi.

The problem is not double letters. In Shogi one uses only a + to indicate promotions. (Very confusing for Chess players, who would think it means check!). Like a4a5+ (in mini-Shogi) in stead of a4a5g . So you would have to write the + in stead of the letter. And on input, replace the + by the ID letter for whatever piece you know the moved piece to promote to. And be sure to ignore a promotion character =, which can be added to stress there is no promotion when there could have been one.

I have implemented the +,= stuff now so it can accept FENs and promotion moves. But i don't like this implicit way of specifying promotion moves. I had to do many shogi specific stuff to code it. The second issue of droping rooks is probably resolved now.

There is another engine that ignores this rule, and from that I know that in mini-Shogi there is a lot of opportunity to violate it. As the side that will get checkmated usually sacrifices all his material to postpone it, the mating side will have a wide choice of material to drop. And often it drops a Pawn when plenty of other material could have been dropped in stead to deliver the mate as well. (S, G, and R are all upward-compatible to P.)
Note, however, that the problem game I sent you was not about dropping Pawns, but about dropping Rooks!

In that case i will make sure to implement it. By default i let kings be captured and test for legality by looking at previous move so it should be easy to add it.
I guess that will satisfy all the rules except those bugs i mentioned before.

To play under standard WinBoard reporting 'alien' in the variants feature is pointless anyway, as it does not know that variant. In WB-Alien it is usually not needed to to explicitly define a size override in WinBoard, as the engine will redefine the size through the setup command. You might want to do it if you want to play from a file of start positions, though. Then XBoard would not accept the FENs i the file unless it was set to the same board size first. So it could be necessary to start WinBoard with 3x4+3 size in -variant alien, and then it would check if the engine says it supports 3x4+3_alien, and it would not be satisfied with just variants="alien".

There already exists a solution for that, however: when you include "boardsize" as a pseudo-variant in the variants feature, WinBoard will assume any of the variants you mention can also be played with other board sizes. So feature variants="shogi,boardsize" would lead WinBoard to think the engine can play Shogi with any board/holdings size. This should really be improved by specifying a maximum, like feature variants="alien,15x15+7boardsize" would allow variant alien with any board size upto 15x15, and any holdings size upto 7. I think the specs even state this.

I think it is better to avoid it all in all because it made Nebiyu much simpler to work with both editions of winboard. For example winboard sending 8x8+0_alien meant standard chess. But this is very brittle since there may be tons of other variants of the same size. The winboard variants menu should not help at all for unknown variants and combo box should be solely used. That is what i use for my android gui and it works great. Alien is not mainstream so we can make radical changes. For the case where xboard gets FEN from file, winboard could have used a referee but it doesn't currently have that. But i feel it is better to remove sending alien strings , and find solutions for this problem.

There already exists a solution for that, however: when you include "boardsize" as a pseudo-variant in the variants feature, WinBoard will assume any of the variants you mention can also be played with other board sizes. So feature variants="shogi,boardsize" would lead WinBoard to think the engine can play Shogi with any board/holdings size. This should really be improved by specifying a maximum, like feature variants="alien,15x15+7boardsize" would allow variant alien with any board size upto 15x15, and any holdings size upto 7. I think the specs even state this.

Each dimension will require separate FEN string so currently ,i register them all as different variants. I think boardsize is for non-alien variants where winboard knows how to set it up. So if send variants="alien,15x15+7boardsize", it means the engine has all the required FENs. This is a shorthand specification but will not solve the problem i think.

We could require that the engine should not overrule an explicitly requested board size. If WinBoard would just say variant alien, the engine would specify the size in a setup command, (as per its combobox) and WB would obey. If, however, WB would send variant 5x5+5_alien, it was probably set to 5x5 before starting the game for a reason (e.g. an externally loaded start pos), and not respecting it is a source of trouble. (WB will likely ignore the setup command in that case). Perhaps the engine should report the discrepancy in a tellusererror command. I can imagine that engines like Nebiyu would be capable of taking the rules of the variant they were set for per combobox (or which they recognize from the variant command), and use all its rules except for the board size, in which they would use what the GUI requested.

We should remeber that the engine could have many variants with a shared board size. So WB can not help by sending only the dimensions. Ofcourse if sends 5x5+5_shogi the engine would accept it. But sending 5x5+5_alien will cause confusion to the engine as what variant to set. I think winboard should just reject setup command sent from the engine, if it didn't match its size. But don't send it to the engine because it is useless anyway.

It can play long games but you can see there is some rule missing. In the game below i just played it led by a lot of pawns but then
it lost it all and got checkmated in a silly way via a drop move.

[Event "Computer Chess Game"]
[Site "DANIEL-PC"]
[Date "2013.03.01"]
[Round "-"]
[White "TJshogi 0.10"]
[Black "NebiyuAlien_1.43"]
[Result "1-0"]
[TimeControl "40/60"]
[Variant "shogi"]
[Annotator "1. +0.00 1... +0.05"]

1. b4 {+0.00/10} b6 {+0.05/14 1.5} 2. c4 {-0.05/11 0.4} b5 {+0.00/16 1.0}
3. bxb5 {-0.20/11 0.4} Rxb5 {+0.55/16 1.1} 4. Gc2 {-0.20/11 0.8} Gfe8
{+0.00/14 1.5} 5. P@b3 {-0.20/9 0.5} Sd8 {+0.05/13 1.2} 6. a4
{-0.20/11 0.9} Sf8 {+0.10/14 1.4} 7. a5 {-0.15/11 0.8} P@b4 {+0.35/15 1.1}
8. bxb4 {+0.05/11 0.6} Rxb4 {+0.30/17 1.4} 9. Gc3 {+0.00/11 5} Rb6
{+0.25/16 1.2} 10. La4 {+0.00/9 0.7} c6 {+0.30/15 1.2} 11. d4 {+0.00/8 0.6}
Nc7 {+0.45/16 1.2} 12. Rd2 {+0.00/10 2.1} g6 {+0.55/15 1.2} 13. g4
{+0.00/9 0.6} a6 {+1.05/16 1.8} 14. axa6 {-0.10/9 0.4} Lxa6 {+0.75/15 1.5}
15. Lxa6 {-0.22/9 0.7} Rxa6 {+2.55/14 1.1} 16. P@a3 {-0.55/8 0.6} P@b4
{+4.25/16 1.4} 17. P@b3 {-1.24/8 0.6} bxb3+ {+6.55/17 1.5} 18. Gxb3
{-4.14/10 1.5} P@b4 {+6.05/17 1.3} 19. Gxb4 {-5.10/10 1.6} L@b6
{+6.05/17 1.2} 20. L@a4 {-3.36/10 1.3} Lxb4 {+6.05/17 1.3} 21. Lxa6
{-4.12/10 2.2} Lxb2+ {+6.10/16 1.5} 22. Sxb2 {-4.45/9 1.7} B@e5
{+6.25/14 1.5} 23. L@h5 {-5.10/9 4} Bxi1+ {+6.20/15 1.5} 24. Lxh7+
{-1.37/8 0.6} Bf6 {+9.05/14 1.7} 25. +Lg8 {-1.67/8 0.6} G@f9 {+6.20/13 9}
26. +Lxf9 {-0.83/8 1.7} Kxf9 {+5.55/15 1.8} 27. G@h2 {-1.97/9 5} L@e5
{+5.30/14 1.1} 28. e4 {-1.97/9 2.0} Lxe4 {+5.85/12 1.1} 29. P@e2
{-3.23/9 0.9} P@h4 {+6.65/10 1.0} 30. hxh4 {-2.80/8 1.0} P@h3
{+8.40/14 1.4} 31. Gxh3 {-4.32/9 1.3} +Bxh1 {+8.90/13 1.3} 32. Sg2
{-5.07/8 0.7} +Bi2 {+8.85/12 1.1} 33. La8+ {-5.35/8 0.8} L@h7
{+9.50/11 0.8} 34. Gg3 {-3.58/8 0.9} N@f5 {+10.05/12 1.1} 35. R@a9
{-5.75/9 1.7} Gde9 {+9.50/14 1.0} 36. Gf2 {-9.66/9 1.0} Nxg3+
{+12.40/11 1.0} 37. Gxg3 {-9.62/9 1.4} G@a2 {+13.40/12 1.0} 38. N@f2
{-10.13/9 1.4} Lxe2+ {+13.30/12 1.0} 39. Kxe2 {-10.29/10 2.4} Gxb1
{+13.85/12 1.4} 40. Rb9+ {-11.58/9 6} N@b5 {+14.05/11 1.2} 41. P@b6
{-10.70/8 1.8} Gxb2 {+17.05/13 1.2} 42. Rxb2 {-13.33/8 1.1} Bxd4
{+18.05/13 1.3} 43. Ra2 {-14.51/7 0.7} S@e3 {+20.35/13 1.4} 44. Kd1
{-17.43/8 1.6} Sxf2+ {+17.85/13 1.5} 45. G@d3 {-14.43/7 1.1} N@b4
{+22.85/14 1.3} 46. Rd2 {-22.60/8 0.9} Bc3+ {+26.40/12 1.5} 47. Rxf2
{-23.51/8 1.1} +Bxd3 {+28.55/10 1.5} 48. L@c1 {-29.98/8 4} G@c9
{+28.45/12 1.5} 49. +Ra9 {-20.51/8 0.7} Nxa3+ {+24.05/12 1.5} 50. b7+
{-19.50/8 0.8} Nb5 {+24.05/13 1.5} 51. P@b8 {-18.88/8 1.9} +Be3
{+22.35/13 1.2} 52. Re2 {-18.60/8 2.2} +Bxe2 {+22.00/14 1.3} 53. Kxe2
{-18.60/3 0.1} R@g1 {+20.80/12 1.5} 54. B@e3 {-14.26/7 0.8} +Bh2
{+14.65/13 1.2} 55. Bxg1 {-11.00/8 0.6} +Bxg1 {+14.45/13 1.5} 56. S@f2
{-10.90/8 2.3} +Bh2 {+12.45/12 1.2} 57. b9+ {-9.64/8 0.8} B@e5
{+12.45/14 1.6} 58. +Pxc9 {-8.74/7 0.6} Bxa9 {+13.90/13 1.5} 59. +Lxa9
{-5.24/7 1.5} R@e6 {+9.55/10 1.5} 60. P@e3 {-0.84/7 1.3} Kg8 {+5.45/12 3}
61. +Pcc8 {+2.40/7 0.8} +Nb3 {+4.05/11 1.2} 62. +Pxd8 {+3.37/7 1.4} G9xd8
{-0.50/14 1.5} 63. B@d4 {+6.47/6 1.1} Rf6 {-1.00/13 1.3} 64. R@c9
{+7.23/6 0.5} Ge9 {+0.70/11 1.2} 65. P@b2 {+8.15/7 1.0} +Nc2 {-1.15/13 3}
66. Lxc2 {+8.21/7 0.8} Nxc2+ {-0.65/12 1.2} 67. N@e4 {+8.85/7 1.8} Nc3+
{-6.85/10 1.5} 68. Nxf6 {+15.55/7 1.4} fxf6 {-8.10/12 2.5} 69. Bxf6
{+12.61/7 6} L@g7 {-7.10/9 1.1} 70. G@h3 {+14.81/6 1.2} +Bi2 {-7.90/11 1.3}
71. Rxc6+ {+15.57/7 1.4} P@h2 {-6.95/9 1.7} 72. +Pc7 {+16.44/7 1.4} Gde8
{-6.40/11 1.1} 73. Bxc3 {+21.77/7 0.5} +Nxc3 {-7.75/13 3} 74. N@f6
{+21.63/7 0.9} Kg9 {-7.70/13 1.6} 75. S@h8 {+23.47/7 1.2} Kf9
{-14.90/12 1.0} 76. Sxh9= {+24.14/7 1.4} B@d3 {-15.60/12 1.2} 77. Ke1
{+25.22/8 1.3} h1+ {-14.30/11 1.3} 78. Sg8+# {+199.99/1 0.1}
{Xboard adjudication: Checkmate} 1-0

Well, that is Shogi for you. It is never done until it is done, no matter how much you are ahead. From looking at the game, it seems Nebiyu is too eager to drop pieces. So although the white King is completely exposed, black never has enough pieces in hand to mate by a sequence of drop moves. With 3 or 4 pieces in hand it becomes extremely dangerous.

What Shokidoki version are you using? I have never seen it violate the 1-pawn/file rule. (There was a bug I only fixed recently, where it would drop a Pawn on last rank to block check.)

Here is idea that can save us the trouble with alien version. Remove the combo boxes from the engine BUT let winboard build the combo box and display it on its variants menu! Then instead of sending alien, it sends whatever is selected in combo box. This sounds a great idea I am excited to here what you think about it. Now winboard is in total control of the variant selection. I am going to add it in my androdi gui because setting the variant for participating engines was such a pain I was the only 'user' who could do it. Winboard can display what the first engine supports (like it does now) or just display the common variants by both engines. So you have variants known to winboard in bullets, and unknown to winboard in combo box. Then it sends the selected variant to both engines. With the Referee engine idea that i used , it would be the variants supported by the referee engine that would be displayed, but Winboard as it is can handle it. I think we can smoothly fit in the alien version to the standard this way. All it has to do is ingnore the setups sent when it knows the variant, but accept it when the variant is from came from combo selection.

Shokidoki version is the one that came with winboard 47, sdk09j. But I had to fix the winboard engine installation because it had a different name! You probably were testing with that version that may not have this problem.

Download current nebiyu here https://sites.google.com/site/dshawul/N ... edirects=0

If we remove the combo boxes from the engine, you don't have to worry about buffer overruns too.

Let me make sure I understand this correctly. What you propose is to send all choices that are sent now as combobox selections with the standard variants in the variants feature. And then let WinBoard create the combobox in the New Variant dialog, containing all the names it did not know. When you would pick one of those, it would send that name in a WB variant command to the engine, which would always know what it meant, as it defined the name itself.

This sure sounds like an improvement from the viewpoint of the user.

There are some sticky details, however. WinBoard always needs to be in a 'known' variant, even if this is only a 'catchall' like 'fairy' or 'alien', because many of the things it does depend on what variant it is in. In the Alien Edition this is not much of a problem, as you could make them all default to 'alien', in which basically everything is deferred to the engine, so that anything is possible. But in the regular version 'alien' does not exist, and the facilities it offers are not implemented. To make engines work in the regular version they have to rely on the GUI updating the board, knowing when to throw up promotion pop-ups, how to castle or e.p. capture, etc. For this it is important that non-standard variants are played as the standard variant that approaches them as closely as possible, and fulfills their essential needs. E.g. Crazyhouse960 would have to be played as FRC, because there is no other way to get the funny castling rule, while holdings can be slammed onto any variant. Capablanca with Berolina Pawns would have to be played as Berolina, because there is no other way to get the e.p. capture right, while changing board size and enabling Chancellor and Archbishop can be done by configuring through general parameters. The only way to get a Royal Knight is in knightmate, etc.

So it is important that the engine does indicate the 'parent variant' as which each non-standard variant should be played. This would be evident if it only said things like '5x5+5_shogi'. But that is awful for the user, who much rather would see 'mini-Shogi', or 'mini-Shogi (5x5)' in the combo-box. And it would not resolve the land-slide of '8x8+0_normal' variants that was thrown at it (Chancellor Chess, Archbishop Chess, Immobilizer Chess, Nightrider Chess...).

If WinBoard has to scan through the variants list anyway, to separate the known variants from the non-standard ones, we could put information in the order in which the variants are mentioned (which in the current protocol specs carries no meaning). All variants that have to be played as shogi could be mentioned immediately after shogi, before any other variant. So Fairy-Max, for instance, could say

feature variants="normal,capablanca,makruk,Cambodian,fairy,FIDE-Clobberers,FIDE-Nutters, Nutters-Clobberers,knightmate,Capablanca Knightmate,courier"

and WB would know that Cambodian is to be played as makruk, FIDE-Clobberers etc. should be played as fairy, 'Capablanca Knightmate' as knightmate (so the Knight is the royal piece), etc. Once the variant gets selected (WB sending variant FIDE-Nutters), the engine will take care of setting pieceToCharTable, (implying Shogi-like promotions or Bughouse shadow pieces), board/holdings size and initial setup (possibly ignored when the user already had setup a board of that size in the requested variant).

I guess this would work pretty well...

Finally a win against TJshogi after fixing a problem with pawn drops. Fixed version at the same link. Right now pawn drops that attack the king are illegal. It is a bit complicated to implement the actual rule. I don't know if Nebiyu would reject the move when the opponent drops pawn infront of its king so i have to check for that.
I will think about your proposal in detail and let you know but it sounds we are on the right track...

[Event "Computer Chess Game"]
[Site "DANIEL-PC"]
[Date "2013.03.01"]
[Round "-"]
[White "TJshogi 0.10"]
[Black "NebiyuAlien_1.43"]
[Result "0-1"]
[TimeControl "40/60"]
[Variant "shogi"]
[Annotator "1. +0.00 1... +0.00"]

1. b4 {+0.00/10} Sf8 {+0.00/14 1.2} 2. h4 {+0.05/11 0.8} b6 {+0.15/15 1.4}
3. h5 {+0.00/11 0.5} b5 {+0.75/15 1.3} 4. h6 {-1.72/11 0.6} hxh6
{+4.50/17 1.3} 5. Rxh6 {-4.12/11 1.3} Gg8 {+5.00/17 1.3} 6. Rh5
{-5.62/10 0.8} bxb4 {+1.90/15 1.1} 7. P@h6 {-4.46/11 1.0} b3+
{+3.05/17 1.5} 8. h7+ {-5.00/11 1.8} Gxh7 {+3.00/16 1.1} 9. Rxh7+
{-5.00/10 0.9} Sg9 {+3.50/16 1.1} 10. +Rh2 {-5.20/10 2.0} P@h7
{+4.25/15 1.2} 11. c4 {-4.52/9 0.7} +Pxb2 {+4.65/17 1.4} 12. Sxb2
{-4.50/9 1.0} B@d5 {+4.80/15 1.2} 13. +Re2 {-4.60/9 1.9} Bxf3+
{+5.65/16 1.3} 14. +Rxf3 {-5.06/9 1.6} Rxb2+ {+7.35/13 1.1} 15. P@b8
{-5.24/8 2.8} Sxb8 {+6.25/14 1.2} 16. B@f5 {-6.44/7 0.9} S@e8
{+6.15/14 1.2} 17. Bxh7+ {-4.60/9 0.7} P@h2 {+4.35/15 1.6} 18. G@g8
{-1.64/8 1.1} hxh1+ {+6.05/15 1.3} 19. Gxh9 {-5.62/8 1.7} +Pxg1
{+7.20/14 1.5} 20. Gxg1 {-6.72/8 1.7} S@g6 {+7.85/14 1.4} 21. +Bxh8
{-6.26/8 1.0} Sxh8 {+10.35/13 1.3} 22. Gxh8 {-6.32/7 0.6} N@g5
{+10.25/11 1.6} 23. +Re2 {-8.88/7 2.2} +Rxb1 {+10.35/13 1.3} 24. B@e5
{-9.20/6 1.2} N@f3 {+10.15/14 1.6} 25. Kf2 {-15.47/8 1.8} Nxg1+
{+14.00/14 1.3} 26. Bxg7+ {-16.24/7 1.0} B@f8 {+9.90/14 1.6} 27. +Bxf8
{-15.06/7 1.1} Kxf8 {+10.40/13 1.7} 28. B@h6 {-16.46/7 2.6} P@g7
{+14.70/15 1.7} 29. S@g9 {-16.88/7 1.0} Kf9 {+15.40/15 1.7} 30. P@f8
{-18.10/7 1.2} Ke9 {+17.40/16 1.3} 31. Kxg1 {-20.89/8 3} B@f3
{+20.85/14 1.7} 32. f9+ {-23.96/7 0.4} Kxf9 {+19.15/15 1.7} 33. P@f8
{-24.78/7 1.4} Ke9 {+24.05/15 1.8} 34. f9+ {-28.73/8 3} Kd8 {+22.55/15 1.3}
35. N@c1 {-37.58/8 2.4} Bxe2+ {+27.30/14 1.7} 36. N@c6 {-57.08/7 2.0} cxc6
{+35.00/15 1.6} 37. Gxe2 {-199.90/7 1.9} +Rxc1 {+39.90/15 2.0} 38. B@f1
{-199.92/7 1.5} N@f3 {+42.25/15 1.6} 39. Gxf3 {-199.92/6 0.3} N@h3
{+46.85/15 2.2} 40. Kh2 {-199.92/7 0.6} +Rxf1 {+46.90/11 2.3} 41. N@e6
{-199.94/6 0.1} exe6 {+56.35/10 1.5} 42. Bxg5 {-199.94/6 0.2} Sxg5
{+61.20/13 1.1} 43. i4 {-199.96/4 0.1} R@g2 {+299.94/13 1.4} 44. Kxh3
{-199.98/3} G@h4# {+299.96/20 1.2}
{Xboard adjudication: Checkmate} 0-1

Let me make sure I understand this correctly. What you propose is to send all choices that are sent now as combobox selections with the standard variants in the variants feature. And then let WinBoard create the combobox in the New Variant dialog, containing all the names it did not know. When you would pick one of those, it would send that name in a WB variant command to the engine, which would always know what it meant, as it defined the name itself.

Yes that is correct. So winboard activates bullets of known variants and put the rest in the combo. Maybe combo box is not appropriate since user could select known variant from the bullets, and unkown from the combo box. Also if parent variant have to be specified, then additional combo boxes would be required. But this is all a GUI issue, and i will let you figure out the best way to deal with it.

There are some sticky details, however. WinBoard always needs to be in a 'known' variant, even if this is only a 'catchall' like 'fairy' or 'alien', because many of the things it does depend on what variant it is in. In the Alien Edition this is not much of a problem, as you could make them all default to 'alien', in which basically everything is deferred to the engine, so that anything is possible. But in the regular version 'alien' does not exist, and the facilities it offers are not implemented. To make engines work in the regular version they have to rely on the GUI updating the board, knowing when to throw up promotion pop-ups, how to castle or e.p. capture, etc. For this it is important that non-standard variants are played as the standard variant that approaches them as closely as possible, and fulfills their essential needs. E.g. Crazyhouse960 would have to be played as FRC, because there is no other way to get the funny castling rule, while holdings can be slammed onto any variant. Capablanca with Berolina Pawns would have to be played as Berolina, because there is no other way to get the e.p. capture right, while changing board size and enabling Chancellor and Archbishop can be done by configuring through general parameters. The only way to get a Royal Knight is in knightmate, etc.

Ok so to use existing infrastructures from Winboard itself, we have to specify the parent variant so that it would take bits and pieces of rules, promotion popups etc... Later a referee engine that would take care of everything may be added so it is good we don't add new protocol commands to specify the parent variant. The order of the variants is a good idea. We should make the last variant to be 'alien' followed by its children like below:

feature variants="normal,capablanca,makruk,Cambodian,Go,Go99,Go1313,alien,jetan

Right now nebiyu can't do that as it reads its variants from ini but i will add a parent variant variable and then sort it. Even simpler would be to depend on the order in which the variants are defined. That is what i will do for now atleast.

and WB would know that Cambodian is to be played as makruk, FIDE-Clobberers etc. should be played as fairy, 'Capablanca Knightmate' as knightmate (so the Knight is the royal piece), etc. Once the variant gets selected (WB sending variant FIDE-Nutters), the engine will take care of setting pieceToCharTable, (implying Shogi-like promotions or Bughouse shadow pieces), board/holdings size and initial setup (possibly ignored when the user already had setup a board of that size in the requested variant).

The parent specification is required to let winboard help out. With a referee engine, which should be keps as a goal, it is possible to avoid winboard involvement even for promotion popups. That is what i did in AlienBoard and it works. But I do agree that it reuse existing winboard support is a good idea too, since many variants can be played with their parent's setup. Also many people write variant engines of that type so there is no compulsary need for the referee engine. So people who write something completely alien to winboard, we could have the referee engine or use one of the player engines which should be alien. Otherwise it has to specify the parent variant. This sounds alright so you should go on coding.

Daniel Shawul wrote:Finally a win against TJshogi after fixing a problem with pawn drops. Fixed version at the same link. Right now pawn drops that attack the king are illegal. It is a bit complicated to implement the actual rule.

It should not be hard; In WinBoard (which first did not know it too, but that became unbearable once there was an engine that regularly violated it), I could implement it very easily, doing the following concession:

I dropped the requirement that WB would flag it as an illegal move, an only implemented it as a correction on the result and result-comment. So when it detects mate with the old code, it adds the extra check whether the variant is Shogi, and whether in this case the preceding move was a Pawn drop. If it is, it inverts the result, and changes the comment to "Pawn-drop mate". I guess the same would work in an engine.

The down-side is that it declares a loss rather than an illegal move. Which in Shogi is actually custom, and in WB comp-comp play also the usual setting. So I did not care too much about it.

We should definitely strive for referee engines in the Alien Edition. But this is not really a simple change. And I am not sure I would ever want to do this in the regular version.

I am not happy with the way WB works internally anyway. The code now is littered with conditionals like if(gameInfo.variant == VariantShatranj || gameInfo.variant == VarianXiangqi || ...) ... to implement the rule modifiers that should be active during Shatranj & Xiangqi & ... It would have been much better to have a separate flag/variable for each rule modifier (like royalKnight, diagonalPawn, stalemateLoses, perpetualsLose, noDoublePush, promotionHoldings, promotionZoneDepth), and set those depending on the variant, and then only test those. This could do away with the concept of a 'parent variant', by allowing the engine's setup command to directly set the flags. That way it could even combine rule-modifiers that now are incompatible. (Like Royal Knight + Berolina Pawns.)

So basically I should cleanse the code completely from all tests on variant, and only test on generally applicable flags. I will make an inventory of how many such conditional rules are currently in WinBoard, to see which flags this would require. I am not sure how setting of flags could best be encoded in the setup command. Perhaps we should allow a number of keywos after some 'magic symbol', like $. Something like

setup (P..R.FE...M.........K.p..r.fe...m.........k.) rmekfemr/pppppppp/8/8/8/8/PPPPPPPP/RMEKFEMR $ !stalemate royalknight !doublePush explode !perps

for a Knightmate version of Atomic Shatranj where perpetual checking is not allowed.

I can't unzip the Nebiyu file at the link. The archive seems to be damaged.

It should not be hard; In WinBoard (which first did not know it too, but that became unbearable once there was an engine that regularly violated it), I could implement it very easily, doing the following concession:

I dropped the requirement that WB would flag it as an illegal move, an only implemented it as a correction on the result and result-comment. So when it detects mate with the old code, it adds the extra check whether the variant is Shogi, and whether in this case the preceding move was a Pawn drop. If it is, it inverts the result, and changes the comment to "Pawn-drop mate". I guess the same would work in an engine.

The down-side is that it declares a loss rather than an illegal move. Which in Shogi is actually custom, and in WB comp-comp play also the usual setting. So I did not care too much about it.

Ok I was flagging pawn drops in front of king as illegal, but that caused problems when TJshogi did so. Now i moved the code to the checkmate section, so it will not declare it as illegal but knows not to play along that line. I have replaced the corrupted zip file now.

I get correct Perft results for crazyhouse is correct but not for shogi. From ply 5 onwards the numbers are wrong. There are some missing rules such as droping a lance or knight at the far rank is illegal because they can't make moves from there. Nebiyu probably never does this as it adds absolutely nothing but block an attack. Will winboard flag this as illegal if it occured? Also the way pawn drops are handled will modify the perft numbers. Does shokidoki have a divide perft ?

H.G.Muller wrote:We should definitely strive for referee engines in the Alien Edition. But this is not really a simple change. And I am not sure I would ever want to do this in the regular version.

Yes we should try to only integrate supported variants from alien engines to be played in the standard edition while still having the option to play them in the alien edition.

I am not happy with the way WB works internally anyway. The code now is littered with conditionals like if(gameInfo.variant == VariantShatranj || gameInfo.variant == VarianXiangqi || ...) ... to implement the rule modifiers that should be active during Shatranj & Xiangqi & ... It would have been much better to have a separate flag/variable for each rule modifier (like royalKnight, diagonalPawn, stalemateLoses, perpetualsLose, noDoublePush, promotionHoldings, promotionZoneDepth), and set those depending on the variant, and then only test those. This could do away with the concept of a 'parent variant', by allowing the engine's setup command to directly set the flags. That way it could even combine rule-modifiers that now are incompatible. (Like Royal Knight + Berolina Pawns.)

You should see Nebiyu's code! NebiyuChess has too many tests of variant == shatranj type etc it is so ugly. The alien version allievated this problem by having rules as you suggested: stalemate_is_win,has_holding,two_pass_end etc, shogi_pawn_rule. That removed the variant==X dependence, but still code is spaghetti. I guess that is the best we can hope for. My search is also a mess because of three player games, two or more kings, checkmate/stalemate rules etc..

So basically I should cleanse the code completely from all tests on variant, and only test on generally applicable flags. I will make an inventory of how many such conditional rules are currently in WinBoard, to see which flags this would require. I am not sure how setting of flags could best be encoded in the setup command. Perhaps we should allow a number of keywos after some 'magic symbol', like $. Something like

setup (P..R.FE...M.........K.p..r.fe...m.........k.) rmekfemr/pppppppp/8/8/8/8/PPPPPPPP/RMEKFEMR $ !stalemate royalknight !doublePush explode !perps

for a Knightmate version of Atomic Shatranj where perpetual checking is not allowed.

If you are comfortable with winboard code right now, then we don't have to pass long strings but just flags as i do in nebiyu.
# // HAS_ENPASSANT = 1,
# // STALEMATE_IS_WIN = 2,
# // REPEAT_DRAW = 4,
# // FIFTY_DRAW = 8,
# // TWO_PASS_END = 16
# // HAS_MATING = 32
# // HAS_HOLDINGS = 64
# // SHOGI_PAWN_RULE = 128

OK, now I can play NebiyuAlien against Shokidoki. It still refuses moves, though:

Code: Select all

[Event "Computer Chess Game"]
[Site "MAKRO-PC"]
[Date "2013.03.02"]
[Round "-"]
[White "Shokidoki UEC6+66h1"]
[Black "NebiyuAlien_1.43"]
[Result "0-1"]
[TimeControl "40/60"]
[Variant "shogi"]
[FEN "rbsgk/4p/5/P4/KGSBR[-] w 0 1"]
[SetUp "1"]

{--------------
r b s g k
. . . . p
. . . . .
P . . . .
K G S B R
white to play
--------------}
1. Bc2 {+0.08/11} Gd4 {+0.00/20 1.2} 2. Sb2 {+0.44/11 1.2} Sb4
{+2.15/18 1.3} 3. Sb3 {-0.24/11 2.1} Sc3 {+2.10/18 1.1} 4. Gc1
{-0.64/11 1.3} e3 {+0.40/20 5} 5. Rd1 {+0.12/11 0.9} Be2 {+4.25/20 1.4} 6.
Rxd4 {+0.96/11 1.3} Kxd4 {+5.20/20 1.3} 7. G@d2 {+1.16/10 1.6} Sxc2
{+5.50/17 1.4} 8. Sxc2 {+2.24/7 0.7} B@e5 {+5.45/16 1.2} 9. Gc3 {+2.80/9 8}
Kd5 {+3.85/21 1.4} 10. S@d4 {+2.56/10 2.7} Bxd4 {+0.00/22 4} 11. Gxd4
{+2.88/11 2.1} Kxd4 {+0.00/19 1.1} 12. B@c3 {+2.92/11 6} Ke4 {+0.00/17 1.3}
{Black wins on time} 0-1


Here it refuses Bxa5+ (e3a5+).

About the modifier notation: I think it is in general better to keep the protocol somewhat readable to humans. So I think I would (lightly) prefer long names over just a hex code. It seems less bug prone. No one would accidentallly write doublepush when he means royalknight. Many people would write CD3 when they really meant CB3. Many engines might not be multi-variant, but dedicated to one variant, so that they don't use internal modifier flags they could derive the code from, but would write it as a programmer-defined text string.

Perhaps others can also comment on this, to see if there is some concensus.

It is a problem in the game specification in alien.ini. The promotion zone for the 5x5 shogi variant is the last rank so.

Replace
18 6 6 8
with
18 5 5 8

OK, this works better. I could play a number of games now. Nebiyu crashed (exited) in this game, though:

Code: Select all

[Event "Computer Chess Game"]
[Site "MAKRO-PC"]
[Date "2013.03.02"]
[Round "9"]
[White "Shokidoki UEC6+66h1"]
[Black "NebiyuAlien_1.43"]
[Result "1-0"]
[TimeControl "40/60"]
[Variant "shogi"]
[FEN "+br2k/2rsp/P4/1G3/KGS+B1[-] w 3 1"]
[SetUp "1"]

{--------------
+ r . . k
. . r s p
P . . . .
. G . . .
K G S + .
white to play
--------------}
1. Gb3 {+0.32/10} Rxb3 {+0.00/18 1.4} 2. +Bxb3 {+0.32/11 1.5} +Bb5
{+0.00/18 1.4} 3. Sc2 {+1.16/10 0.9} Rc5 {+0.00/18 1.3} 4. +Ba2
{+0.64/10 1.1} e3 {+0.00/17 1.1} 5. +Bb2 {+0.24/10 1.9} G@c4 {+0.00/18 1.5}
6. R@d1 {+0.56/10 1.0} Rd5 {-0.40/18 1.2} 7. Rxd4 {+1.72/11 0.8} Gxd4
{-1.15/19 1.2} 8. S@d3 {+2.92/11 1.2} R@b4 {-0.10/20 1.3} 9. Sxd4
{+2.76/10 0.7} Rdxd4 {+0.00/20 1.5} 10. Sc3 {+2.36/10 0.8} Rxb2
{+0.20/20 1.4} 11. Sxd4 {+2.40/9 0.9} Kxd4 {-1.15/20 2.0} 12. Gxb2
{+3.56/9 4} S@b4 {-1.45/18 1.5} 13. R@d1 {+3.32/7 0.9} S@d3 {-1.25/20 1.3}
14. G@c2 {+2.20/8 1.6} B@e2 {-2.15/20 1.3} 15. Rc1 {+1.60/8 1.1} Sxc2
{+2.15/19 1.2} 16. Rxc2 {-0.04/9 1.8} G@c3 {+2.25/19 1.5} 17. Gxc3
{+3.92/8 0.8} Sxc3 {+2.50/19 1.5} 18. Rxc3 {+3.28/8 0.8} Kxc3
{+1.80/21 2.6} 19. S@b2 {+399.72/8 0.7}
{White wins on time} 1-0


There is something wrong with allowing king captures. And it also plays very week due to heavy lmr of drop moves.
I got it to beat shokidoki in minishogi when disabling both. So turn off allow_king_capture and lmr in nebiyu when you play games for now atleast.
I only tested at 9x9 shogi so far so there could be more problems. I will investigate the crash but probably due to allowing king
captures which made it really weak too.

I have now re-ordered drops to be tried before non-captures, and also reduced the piece values for bishops and rook
for 5x5 and 6x6 shogi. This has improved strength significantly. You don't have to turn off lmr now or allow_king_captures.
Just use the default values and download at the same link before.
Do you have a link for learning game strategy and powers of pieces ?
I want to make some educated guesses for the pieces and rather than pick some random values.
Edit In most games it plays it leads by a huge margin and then looses to a flood of drops.
I don't know if this is a problem with allow_king_captures or just part of the game. Anyway i think
it is a good opponent for you now.

Again the archive seems damaged, and cannot be unzipped.

Arg..i think my the default windows compression tool is broken. I have uploaded a working zip file now.
Edit
I see now why setting off allow_king_capture results in much better play! Check extensions (actually absences of reductions for checks) are never triggered
when using that. I will try to find a way to allow check extensions while still getting the benefit of 2x nps.

For the alien version i am going to use a method of automatically determining piece values and piece square tables. The idea is to count number of moves the piece can go to at every square on an empty board. So that will be the rough evaluation of Piece + PST which should work in most cases. That will simplify the game specification a lot.