Winboard and chess variant

[Ferdy]

I am working on a chess variant where the pawn can also move to west/east of the "to" square
from normal double step pawn push. See image 1.

Image 1:


That pawn at D7 can move to D5 (chess double step move) and C5 (variant move).

After d7c5, white can capture via E.P. (en passant). The E.P square is at D6.
Note this variant pawn can also move back to E4 once it reaches on 5th rank. See image 2.

Image2:


After making the E.P capture on the board, see Image 3.

Image3.


The pawn at C5 was not removed on the board.
Is there a way to remove that pawn at C5?

I can try the Winboard Alien Edition, but it seems like it does not support the target squares highlighting.
And perhaps it also does not support user defined images. But of course this is better than not able to remove that pawn at C5.

But I would prefer if latest winboard has a way to remove that typical C5 pawn after E.P capture.

Thanks.

[hgm]

To support such a thing would require some rethinking of the fundamentals. E.p. capture is a troublesome move, not only because it does a locust capture, but because it is dependent in a very specific way on the previous move. The solution I devised for indicating it in XBetza notation was to have moves with the 'in' modifier combination automatically generate rights on the square(s) they pass over. So that infmD can be used to describe the FIDE double push (and infmA for Berolina Chess). The modifier 'e' is then used for moves that 'consume' the created rights, by moving to their square, and capturing the previously moved piece in the process. This breathed some new life into the 'n' modifier, which in the original Betza notation was ill-defined, and in XBetza preferably should be replaced by a multi-leg description explicitly specifying the squares where the move can be blocked.

The problem is that in the 'in' combination the 'n' is just as poorly defined as on its own. This was not a problem as long as the e.p. capturable Pawns moved along primary rays (i.e. orthogonally or diagonally). In your case we are dealing with an oblique (hippogonal) move, though. The description infmN is therefore ambiguous. The 'non-jumping Knight' nN can be a Xiangqi Horse (Mao, mafsW) as well as a Moa (mafsF). Or perhaps blockable on both the W and the F squares, as a zig-zag 3-leg move. We can of course introduce an extra rule that singles out one of these cases as the official meaning, but then the other cases become un-encodable. It could be that XBoard accidentally already interprets nN as the Mao.

A better solution would therefore be to allow use of the 'n' in combination with a non-final leg of a multi-leg step atom (i.e. W or F, for which 'non-jumping' has no meaning anyway). It would then mean that the final square of that leg becomes an e.p. square. The infmafsmW would describe what you want, generating rights on the fW square of a fmN move.

I will try to implement this in WinBoard. Although the notation could specify multiple e.p. squares as the result of a single move, there will currently be no guarantee on how WinBoard will treat that. WinBoard's internal game-state representation did not allow encoding of more than one e.p. square, and to handle the case of triple-pushes I already had to resort to kludges. (Which, IIRC, only works if they are on the same ray.)

[Ferdy]

I tell winboad that this variant is fairy and am not using betza as this pawn changes its movement rule depending on the rank. I am just using colorfen to mark target squares depending on where the rank this pawn is located. Basically a pawn but with couple of moves added.

What you described is complicated for me, I will have to read more about betza.

In the meantime I will just try the winboard alien.

[hgm]

The recent versions of the WinBoard standard edition also support the highlight protocol. I prefer the reprogramming of the move generator through 'piece' commands at the start of the game, though. That leads to smoother operation of the interface, (no need to consult the engine during move entry), and can also be used for generating the proper SAN disambiguation. But the 'piece' commands do not support location-dependent moves (other than through the 'i' prefix for virgin-only moves). So I guess the highlight protocol is the only option here. And I believe this conflicts with the 'piece' commands, as the color FENs are only accepted when legality testing is off, while 'piece' commands overrule that by doing legality testing anyway.

It should be possible to specify general locust captures through the highlight protocol, however. The method is to initially highlight the capture victim in the color cyan (and forget about the target square). When you then receive a 'put' command for that square, the GUI knows the move entry is not finished yet, and the engine can/must send a new highlight command that highlights all squares where the second leg of the move can end. (In this case that is just the e.p. square.)

Once the user puts the Pawn on the e.p. square the GUI will now treat the move as a 2-leg move that makes a detour through the e.p. victim first to remove that. If an engine wants to play the move it should send it as a 2-leg move, which is done in 2 separate 'move' commands, the move in the first suffixed with a comma.

This will lead to somewhat ugly move notation in the PGN, like exc5-d6. And no e.p. square will be mentioned in the FEN of a position after an initial oblique Pawn push.

[Ferdy]

It should be possible to specify general locust captures through the highlight protocol, however. The method is to initially highlight the capture victim in the color cyan (and forget about the target square). When you then receive a 'put' command for that square, the GUI knows the move entry is not finished yet, and the engine can/must send a new highlight command that highlights all squares where the second leg of the move can end. (In this case that is just the e.p. square.)

Once the user puts the Pawn on the e.p. square the GUI will now treat the move as a 2-leg move that makes a detour through the e.p. victim first to remove that. If an engine wants to play the move it should send it as a 2-leg move, which is done in 2 separate 'move' commands, the move in the first suffixed with a comma.

This will lead to somewhat ugly move notation in the PGN, like exc5-d6. And no e.p. square will be mentioned in the FEN of a position after an initial oblique Pawn push.

That is nice I will try that.

[hgm]

I just tried ifmnN in a piece command, but it does not have the desired effect. For one, it always assigns the left-most intermediate square as e.p. square (so c6 after c7-d5, but b6 after c7-b5), and highlights that when you select a suitable Pawn (b5 or c5, respectively) as capture on the next move. But when you then play it, it does not remove the victim Pawn. The latter can probably be fixed by changing the general algorithm for e.p. in WinBoard's ApplyMove(), to always remove the previously moved piece (when it is known), rather than to make assumptions where that must be based on the move itself. (It now removes the wrong Pawn, directly in front of the e.p. square, if there is one.)

The only way to have the backward move with piece commands it to allow it always, and then let the engine reject it when the user actually plays it in locations where it is not allowed. This would lead to spurious highligting and possibly unnecessary disambiguation of other Pawn moves in the latter case, however.

[edit] Inspecting the ApplyMove() code revealed that WinBoard manages the e.p. rights completely independent from any move description in the 'piece' commands; these descriptions are only used to generate the moves, but the move representation has no means or saying the move creates rights. So the code just assumes that any Pawn move that goes more than 1 rank forward generates such rights, on the square that is halfway between the from- and to-square ((from + to)/2), which rounds towards the a-file and 1st rank when the difference is odd. To handle these cases in a useful way, I could take the point at 1/3 of the way instead, rounding to closest ((2*from + to + 1)/3). This would then always point to the 1st square of a triple step, (or even a quad step). While lateral movement of one file would keep the e.p. square on the original file.

In a later stage I could use the locust square of the move representation (normally set to invalid) also for indicating that the move generates e.p. rights, namely when the indicated square is empty. The default move generation code would then have to set the locust square when it generates Pawn double pushes. The XBetza-based move generator would then set it based on the 'n' modifiers in multi-leg descriptions, as discussed before.

[hgm]

Turns out that the WinBoard beta version (unlike 4.8) at least already always removed the correct Pawn (the one that last moved). I now uploaded (to http://hgm.nubati.net/WinBoard-AA.zip ) a version that calculates the e.p. square after a Pawn multi-push in a more sensible way (so that for a move to the adjacent file it is on the from-file, and it only gets on the neighboring file for a lateral move of two or three files). This is hard-coded; there is no way yet to define generation of e.p. rights by other pieces through the XBetza move spec in a 'piece' command.

The specification of e.p. capture in the move spec through an 'e' modifier is still very flakey. (But necessary if you don't use the default Pawn move, as pieces with a redefined move without 'e' would not be able to e.p. capture at all.) It turned out that any move of a piece that had an 'e' somewhere in its XBetza move spec would do e.p. capture through ALL its moves that go to the e.p. square, and not just the moves of the type that had the 'e' on it. So a normal Pawn would also be able to e.p. capture with its forward push, even though the 'e' was only specified for the diagonal moves. This did not hurt before, because with normal Pawns it is geometrically impossible to do that. But when a double-push can follow a Knight path, with the e.p. square directly in front of it, both normal Pawn captures and non-captures can reach that e.p. square. The latest version tries to fix this through a kludge: it only does e.p. capture with a move that stays on the same file if the 'e' was on an orthogonal move, and on other moves to the e.p. capture if it was on a non-orthogonal move. (Assuming only a single move type can perform e.p.; a second 'e' in the move spec is ignored.)

What is really needed is to make it explicit in the internal move representation that a move is an e.p. capture, as not every move to the e.p. square is automatically an e.p. capture, and it is very difficult to figure out which are afterwards. The current move representation evolve from the 'coordinate notation' used in engine communication, a concatenation of from-square, to-square and (optional) promotion character. This was extended for handling locust captures by allowing one or two squares to follow the 'promotion character' if the latter is a semi-colon, like e4g5;f4, to indicate where locust captures take place (f4). We could use a similar kludge for encoding e.p. squares, e.g. using an ampersand as promotion character. This requires a lot of changes, as all 'consumers' of internal moves should be made aware of this convention, and take the appropriate action when they detect it.

[Ferdy]

After user presses E5


After user presses C5 (magenta)

Correction, not magenta but cyan.

[hgm]

So far so good. And then you press d6 (red) to complete the move. This should then perform the 2-leg move e5xc5-d6. WinBoard does not have 'auto-complete' that executes a move when only a single target square is left for the currently selected piece.

[Ferdy]

So far so good. And then you press d6 (red) to complete the move. This should then perform the 2-leg move e5xc5-d6. WinBoard does not have 'auto-complete' that executes a move when only a single target square is left for the currently selected piece.

Yes after pressing the red D6, the piece at C5 was removed.



With this I need to parse the locust move and some codes for colorfen for that cyan color. But it worked.

It starts with d7c5

Code: Select all

16761 >first : lift d7
16768 <first : # Received lift d7
16768 <first : highlight 8/8/3Y4/2YY4/8/8/8/8
17479 >first : put c5
17480 >first : d7c5
17617 <first : # Received put c5
18448 >first : lift e5
18455 <first : # Received lift e5
18456 <first : highlight 8/8/8/2C5/4Y3/8/8/8
19542 >first : put c5
19543 >first : lift c5
19549 <first : # Received put c5
19550 <first : # Received lift c5
19550 <first : highlight 8/8/3R4/8/8/8/8/8
22119 >first : put d6
22120 >first : e5c5,c5d6
22323 <first : # Received put d6
22324 <first : # Received locust move e5c5,c5d6

It is cool.

Next I will try your latest compile.