WinBoard, exotic version

[Daniel Shawul]

Shogi promotions are giving me some trouble.
I think that in human vs engine mode, the promotion options for the human are not properly displayed. First even with the native shogi variant, winboard offers only king at the piece to promote to. Second in alien mode I think we might need some form of communication b/n winboard and engine to let it know, from which rank promotions start, what kind of pieces to offer to when a certain piece enters that region etc... I think we might have forgotten about this issue all along, or did I miss something?
When a bishop wanted to promote to a dragon horse by capturing a piece at rank 7, winboard doesn't even offer the option to promote. It just remained a bishop. I don't have a good idea how to fix this, maybe you do?

Neither shokidoki nor winboard seems to enforce move legality rule anyway. I can move a pawn 3 steps ahead and no illegal move message shows up..

[hgm]

Indeed Shokidoki does not enforce legality. (I wrote it in a hurry...) But WinBoard should. (Provided legality testing is on).

But I guess -sweepPromotions does not work for Shogi: it only triggers on forelast-rank Pawns. So you should set -sweepPromotions false in shogi, and in that case WinBoard should pop up a "Promote?" dialog with buttons YES and NO.

Btw, there is a command through which the engine can ask questions to the user (I think it was askuser). The engine could use this to create its own promotion popup. (But alas, while its clock is running...)

I will think some more about this.

[Daniel Shawul]

In native shogi, pawn drop moves seem to be rejected when they come from the engine. I made sure the P is capitalized but it still rejects it. I can make the drop move by hand though.
Try this:
l4g1nl/1r1k5/ppspp1gpp/2p2pp2/4B4/2P1N4/PP1PPP1PP/3K1GR2/L1S2G2L[NSpnbs] b 0 17

P@e6 in this position is rejected.

[st = 230ms, mt = 27305ms , moves_left 224]
3 230 0 12401 p@e6 e5f4 s@e5 EBF = 22.80
4 240 1 21360 p@e6 e5f4 s@e5 f4g3 EBF = 11.83
5 235 1 25935 p@e6 e5b2 n@d6 e4f6 d6c4 EBF = 7.42
5 235 1 27636 p@e6 e5b2 n@d6 e4f6 d6c4 EBF = 7.51
6 230 1 31525 p@e6 e5b2 n@d6 e4d6 c7d6 S@e4 EBF = 5.43
6 285 4 63256 n@g5 EBF = 6.13
6 230 4 81623 n@g5 S@g4 s@e6 e5g3 p@e5 N@b5 EBF = 6.40
6 235 7 121611 n@d6 e4d6 c7d6 e5c3 n@d5 c3d4 EBF = 6.86
6 235 7 126074 n@d6 e4d6 c7d6 e5c3 n@d5 c3d4 EBF = 6.90
7 245 10 158198 n@d6 e4d6 c7d6 e5c3 n@b6 S@b5 p@e5 EBF = 5.37
7 285 10 164866 p@e6 EBF = 5.40
7 335 12 195503 p@e6 e5c3 n@d5 c3a5 b@e5 S@h8 e5i1h h8h9U EBF = 5.54
7 335 15 220194 p@e6 e5c3 n@d5 c3a5 b@e5 S@h8 e5i1h h8h9U EBF = 5.64
8 385 18 280108 p@e6 EBF = 4.65
nodes = 280108 <82 qnodes> time = 188ms nps = 1489936
splits = 0 badsplits = 0
<000000009766> move P@e6
setup l4g1nl/1r1k5/ppspp1gpp/2p1ppp2/4B4/2P1N4/PP1PPP1PP/3K1GR2/L1S2G2L[SsbNn] w - - 0 18
<000000009766> result 1-0 {Xboard: Forfeit due to invalid move: P@e6 (_1_1) res=23}

[hgm]

OK, I did give it some thought.

As a general remark I want to point out that Shogi is a very complex games, with lots of exceptional rules you would find in no other variant. I had a hard time implementing it in WinBoard even when the latter could be aware of the exact rules. To make it work in a general variant like alien without any knowledge in the GUI might be raising the bar too high. And why go through the trouble if we can already play it as variant shogi, where WinBoard would do everything that is needed?

That being said, I have the following idea for promotion choice in variant alien. It uses the highlight mechanism. Just as we set one color apart to indicate captures, we could set another apart to indicate promotion choice (say magenta). This means we could make WinBoard popup a promotion dialog when a piece is released on it, rather than considering the move completed.

I don't like promotion dialogs, however, because they raise the problem what should be in it, in particular how the pieces should be called. This is why I thought the -sweepPromotions such a great idea; it just shows the piece symbols. WinBoard does now which pieces participate in the variant from the pieceToChar table, so it knows which pieces to show.

Now the problem is that -sweepPromotions do not work in Shogi, because (in general) you only know that the piece has the right to promote when the user releases it. With Pawns, you know it already when the user picks them up (from 7th rank).

Perhaps -sweepPromotions could be extended to Shogi in the following way: when the piece enters a (potential) promotion square during dragging it changes to the (primary) promoted form. Leaving the promotion square would give it back its original form, but dragging it around within the promotion square would cycle it through alternatives. (Which in Shogi would make it toggle between promoted and unpromoted form.)

[hgm]

Try this:
l4g1nl/1r1k5/ppspp1gpp/2p2pp2/4B4/2P1N4/PP1PPP1PP/3K1GR2/L1S2G2L[NSpnbs] b 0 17

P@e6 in this position is rejected.

Well, this is because dropping a Pawn on e6 in this position is illegal. Shogi does not allow you to have two Pawns in the same file.

If WB accepts it when you do it by hand, it can only be because you switched legality testing off...

[Daniel Shawul]

Well, this is because dropping a Pawn on e6 in this position is illegal. Shogi does not allow you to have two Pawns in the same file.

If WB accepts it when you do it by hand, it can only be because you switched legality testing off...

Ah! Shogi indeed has too many rules. That was one of the reasons why I postponed finishing the game. Another weird promotion rule was that a piece could promote when it gets out of the promotion zone, or anytime while it is in it... I couldn't implement all those in NebiyuAlien and I thought about using scripting language, which I probably will someday.

OK, I did give it some thought.

As a general remark I want to point out that Shogi is a very complex games, with lots of exceptional rules you would find in no other variant. I had a hard time implementing it in WinBoard even when the latter could be aware of the exact rules. To make it work in a general variant like alien without any knowledge in the GUI might be raising the bar too high. And why go through the trouble if we can already play it as variant shogi, where WinBoard would do everything that is needed?

That being said, I have the following idea for promotion choice in variant alien. It uses the highlight mechanism. Just as we set one color apart to indicate captures, we could set another apart to indicate promotion choice (say magenta). This means we could make WinBoard popup a promotion dialog when a piece is released on it, rather than considering the move completed.

It sounds good. It is better to use an open door than open another one.
So If I understand correctly , I just color detination squares with possible promotion moves by a different color Magenta. I think winboard shouldnot be doing the job from this point onward. On a put, the engine can send list of promotion pieces for that particular piece the user put.
Winboard can display all the promotion pieces from the piceToCharTable but shogi has exactly one piece to promote to. So always it is either blank (option not to promote) or that promotion piece.

I don't like promotion dialogs, however, because they raise the problem what should be in it, in particular how the pieces should be called. This is why I thought the -sweepPromotions such a great idea; it just shows the piece symbols. WinBoard does now which pieces participate in the variant from the pieceToChar table, so it knows which pieces to show.

Now the problem is that -sweepPromotions do not work in Shogi, because (in general) you only know that the piece has the right to promote when the user releases it. With Pawns, you know it already when the user picks them up (from 7th rank).

Yes but the engine can let it know it has promotion chances. A promotion keyword like lift and put can be used.

Perhaps -sweepPromotions could be extended to Shogi in the following way: when the piece enters a (potential) promotion square during dragging it changes to the (primary) promoted form. Leaving the promotion square would give it back its original form, but dragging it around within the promotion square would cycle it through alternatives. (Which in Shogi would make it toggle between promoted and unpromoted form.)

Yes but the piece still has the option not to promote. Some pieces are better kept unpromoted. We could probably solve the shogi problem without dialogs, but I am for extending highlight and displaying a dialog.

[hgm]

Well, one way to solve it would be to have WinBoard treat release of a piece on a magenta-colored square as a partial move, as if Ctrl was held down. And then accept a click on the piece as finishing the move. (Currently clicking on that same piece again would deselect it, as the moved piece always stays selected after a partial move. But this is not really useful; you either would click a new to-square for that same piece, or grab another in a true multi-move game. Actually deselecting the piece, so that no piece is selected anymore is a very natural method for saying you want to consider the move finished.)

Now between the release and the deselection click, the engine could use the askuser command to present a promotion dialog, receive the answer, send the deselection click itself, and use the answer in its board update. Problem is that the PGN would not be aware of the promotion choice in that case.

How about this: after releasing the piece on a (potential) promotion square, the move is accepted as a partial one, WB already making the default promotion. In this state only, a right click on the piece would adjust the promotion choice to the next available piece. A left-click would finish the move by confirming the current choice. A message would appear above the board: "left-click piece to confirm, right-click to alter".

Note that WB has a default idea of what promotions are allowed, based on pieceToCharTable, so the engine would not have to tell it that. Pawns promote to any piece of that color present in the pieceToChar, including Pawns only if the promotion square is not on last rank. (That you can select King is only a minor problem; we can have the engine reject it as illegal afterwards.) If it is a non-Pawn, the pieces have a single natural counterpart. To this end the 22 piece types supported by WB are divided in two groups, the first 11 the base types, the second 11 the promoted types. When a promoted type gets assigned + in the pieceToCharTable, WB will demote it to its partner before putting it in the holdings, when it was assigned a ~, it will be demoted to Pawn. So when a piece promotes, and its natural partner is indicated by +, WB will know that this natural partner is the only alternative to keeping the piece unchanged (i.e. it is dealing with a Shogi-style promotion).

So basically the only thing the engine has to do is mark the square magenta. WB can then in response take care of the piece-type adjustment as programmed through the pieceToCharTable, and will thus be fully aware of the promotion choice (so it can generate correct PGN).

[Rein Halbersma]

Could the current multi-leg feature of WinBoard also encompass Russian draughts? This game has a "promotion en-passant" capture rule. If a man during a capture passes the promotion line, he will instantly promote to a king and continue the capture as a king.

[hgm]

In the protocol this would be no prolem. You can simply write the leg as a promotion. e.g. a2c0q,c0e2. In fact I worry more about the opposite rule, because WinBoard automatically promotes Pawns that reaches the last rank to Queen when no promo-character is given. Perhaps I should suppress this in behavior in a partial move, if it is not standard.

1p1p1p3p/p3p1p3/1p1p1p1p1p/p3p1p1p1/7p2/p3P1P3/1P3P1P1P/P3P3P1/1P1P1P1P1P/P1P3P1P1 b - - 0 11

In the above position, this causes an error:

261005 >first : lift a4
261096 <first : highlight 10/10/10/10/10/8c1/1g5g2/2R3c3/3g1g4/4c5
261166 <first : click c2,
261546 <first : click e0,
261787 <first : click g2,
262007 <first : click i4
262007 >first : usermove 262007 >first : a4c2,c2e0q,e0g2,g2i4
262207 <first : Illegal move: a4c2,c2e0q,e0g2,g2i4

Nebiyu nicely finishes the muli-capture after the user touches a4, but the leg c2e0 defaults to a promotion, both in the display and in the move sent. So the latter is naturally refused by Nebiyu. I guess correct operation would be to send

262007 >first : usermove 262007 >first : a4c2,c2e0p,e0g2p,g2i4

Note that both 2nd and 3rd leg are considered promotions by WinBoard, and thus need a promotion suffix, because it uses the Shogi rule to identify promotion moves, which is a generalization of the Chess rule: a move is a promotion if the to-square or the from-square are in the promotion zone. In Chess the latter can never happen if the former is not true, so the generalization is harmless. But here it makes that e0g2 woud also be seen as a promotion, and a missing promoChar on it would default to q. So you need the p promochar to suppress that.

Nebiyu does not seem to understand this, though. When I entered the legs by typing c2e0=P etc., WB causes aprotocol violation by sending the promoChar as capital (I got to fix that), and Nebiyu rejects it:

912512 >first : usermove 912512 >first : a4c2,c2e0P,e0g2P,g2i4
912682 <first : Illegal move: a4c2,c2e0P,e0g2P,g2i4

But when I type them as c2e0=p, WB sends the correct move, and Nebiyu still rejects it.

1032435 >first : usermove 1032435 >first : a4c2,c2e0p,e0g2p,g2i4
1032575 <first : Illegal move: a4c2,c2e0p,e0g2p,g2i4

[hgm]

I might have a better idea for how to extend the method of -sweepPromotions to Shogi. In normal Chess, this method requires a drag-drop move; with a click-click move you currently always promote to Queen. But, as explained earlier, the problem in Shogi is that it is not apparent that there is a potential promotion before the piece is released on the to-square, in drag-drop.

But in click-click moves this is different! There the to-square becomes apparent when you down-click on the to-square. In current operation this down-click finishes the move entry, the corresponding up-click having no function and being ignored. But in case of a potential promotion I could change this. In stead of finishing the move, the down-click on the to-square could grab the auto-promoted piece there for dragging (deleting the selected piece from its from-square), the completion of move entry being deferred to the up-click. Then, between up-click and down-click you would have the opportunity to drag the piece backwards to change its identity, if you wanted to under-promote.

This method for promotion-piece selection during click-click moves could be made standard as part of the -sweepPromotions feature, so that it would work in any variant. But in Shogi it would be the only method that worked. So drag-drop would auto-promote (as this is usually what you want, similar to -alwaysPromoteToQueen in Chess), but with a click-click move you would be able to switch back the piece type to the unpromoted form during the second click.

This way there would be no need to involve the right mouse button in any way.