Winboard and chess variant

[hgm]

Yeah, the highlight protocol is quite versatile in guiding the GUI what to do; it gives the engine complete control over what moves it wants to allow and which not, no matter how complex the rules. There are also colors for forcing a promotion popup (magenta) or an unconditional promotion (blue). Main disadvantage is that it cannot do anything for the generation of SAN. And it is a hassle to implement it in the engine, especially in combination with pondering.

The 'piece' commands cannot do nearly as much; they assume location-independent moves, and cannot force out-of-zone promotions, or other complex promotion rules (such as promotion on a sub-set of the moves of a piece only, or dependent on whether you capture or not). But they don't need consultation of the engine, and from the engine side just printing a fixed message in response to 'variant'. And they can be used to generate proper SAN.

I guess it should be made possible to have the best of both worlds. With legality testing on highlight commands are ignored, because the GUI is enforcing the rules and does the highlighting. When it is off, (or in a non-standard variant), 'piece' and 'highlight' commands are accepted, and then used to restrict what the user can enter. But I guess there is no harm in allowing those to be used both, having the highlight command overrule what would be implied by the piece commands at the start of the game. So that what you describe in the piece commands doesn't have to be fully correct in all cases, and the engine can intervene when it is not. E.g. define the Pawns with a backward step in the piece commands, but then send a color FEN only when a Pawn on your own board half gets selected to suppress that backward move. I am not sure WinBoard alreay does it like that, but it should be simple to implement. It is just a matter of the condition it uses to decide whether it should ignore the highlight command or not.

[edit] OK, from code inspection I can confirm that it (accidentally) already works this way. Piece commands are always accepted in engine-defined variants, and when a 'piece' command is received target squares of all moves will be highlighted according to their move description, or the built-in move for pieces for which no 'piece' command was received. This happens when a piece gets selected for moving, which also causes sending of the 'lift' command. The 'highlight' reply thus always comes later, and will always be accepted in engine-defined variants. It will then erase the previously applied highlights, and replace them by that specified by the 'highlight' command. So 'highlight' can always be used to overrule a default move specified by the 'piece' command.

[Ferdy]

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.

All right this one also works without cyan colorfen and without parsing those locust moves.

But it seems like I have to get back to locust moves/cyan in colorfen after all because in the long run I will be using a non-pawn id in piece to char table because there is a possibility that this piece and a pawn may exist on the board.

[hgm]

The Lance is also treated as a Pawn-like piece, in the sense that it promotes on last rank, resets the ply counter and generates e.p. rights when advancing more than one rank. At least in most variants. (In Spartan Chess it the generation of e.p. rights is suppressed, as this variant has no e.p. capture, and in Superchess it is used for the Amazon, and all special properties are suppressed. In Shogi the corner piece is really a Queen, (for historic reasons), but the Queen is displayed as a Lance there.)

So if the number of piece types that should be e.p.-capturable is limited to two, you can use Pawn + Lance. Any piece can be made to capture e.p. with the aid of the 'e' modality on one of its moves in a 'piece' command. There is no type-selective e.p. capture (or any other form of selective capture, for that matter): every e.p. capturerer will be able to e.p. capture any Pawn or Lance.

In the long run I will have to add a method for specifying creation of e.p.-rights in the XBetza notation, so that any piece can be endowed with this property. I am inclined now to do this by redefining the meaning of 'e' on non-final legs of a multi-leg move, to not mean the move captures e.p., but that it generates rights on the to-square of that (non-capturing) leg. Having e.p.-capture as a non-final leg doesn't really seem useful.The FIDE double-push would then become ifeafmW. Berolina Pawns would have ifeafmA, Omega Chess Pawns ifeafmWifeafeafmW (normal double push plus a triple push generating rights on two squares). The Pawns you have here would be ifeafmWifeafsmW.

This is currently hard to implement in WinBoard, because neither the fact that a move is an e.p. capture, nor that it generates rights, is currently indicated in the internal move representation. Without that, the implementation would have to examine the XBetza move descriptor (if the piece has any) in the ApplyMove() routine itself, for occurrences of 'e'. And then decode its meaning, and test if that applies to the move that the piece currently makes. This is awkward, but perhaps easier than extending the internal move representation. (At least it would be a localized patch, rather than requiring changes all over the place.)

[hgm]

I uploaded a new version of WinBoard-AA again. This implements the 'e' modifier in non-final legs as described above, so that it can now both used to generate e.p. rights as well as for cashing them. For now there is a restriction that there can only be a single e.p. square. (That is all WinBoard keeps track of in the game state, although there is a flag to indicate that the square in front of it is a second e.p. square. But that is not general enough to allow moves with arbitrary paths to specify 2 e.p. squares.)

Unfortunately there are some backward-compatibility problems here, because the way Fairy-Max specified the triple-push Pawns for Mexican Chess and Wildebeest Chess did not use the 'e' modifier for indicating e.p.-rights generation in its 'piece' commands for the Pawn move, but relied on WinBoard to do that automatically (for multiply pushed Pawns). To not break that, this WinBoard version also supports a 'legacy method' for specifying e.p.-rights generation:

When a Pawn type makes a purely orthogonal or diagonal, virgin-only, non-capture-only move that goes at least 2 ranks forward, and it is non-jumping (e.g. ifmnD or ifmW3), this will set the e.p. square at 1/3 (rounded to closest) on the path. This covers all existing cases in Fairy-Max.

This convention is now deprecated, and should not be used in new designs.

[Ferdy]

The Lance is also treated as a Pawn-like piece, in the sense that it promotes on last rank, resets the ply counter and generates e.p. rights when advancing more than one rank. At least in most variants. (In Spartan Chess it the generation of e.p. rights is suppressed, as this variant has no e.p. capture, and in Superchess it is used for the Amazon, and all special properties are suppressed. In Shogi the corner piece is really a Queen, (for historic reasons), but the Queen is displayed as a Lance there.)

Ahh ok Lance indeed works like a pawn, I thought before no other piece can do it.

[hgm]

Problem could be that it also triggers a promotion procedure (popup or detour under-promotion) when it reaches the last rank, which could be undesirable. (Detour under-promotion can be 'disguised', though, by having the engine send a 'choice' command in response to the 'lift' that only allows the Lance to promote to itself.)

BTW, I am having some second thoughts on the overloading of the XBetza 'e' modifier, as it is not totally inconceivable that one would want a piece to e.p.-capture with its non-final leg. (Think of an e.p.-capturing Checker, which would capture by jumping over the e.p. square.) So I will probably switch to using 'n' for indicating a non-final leg should generate e.p. rights on its target square if the move is a step (where the conventional meaning of 'non-jumping' is pointless).

The exact meaning of the modifiers would then be:
e: Move is only allowed when this leg goes to an e.p. square. (Which by definition is always empty.) The piece moved in the previous ply (which generated the rights) will be removed as a side effect of the move.
n: Move is allowed when this leg goes to an empty square. But as a side effect that square becomes an e.p. square for the next ply.

The full move description of the FIDE Pawn will then become fmWfceFifnafmW.

[Edit] OK, I uploaded a version that works this way now. It also handles the case where two e.p. squares are specified just in front of each other. (The only case that WinBoard currently can encode in the game state, but good enough for the most common case of triple pushes straight ahead.) Another limitation is that it only checks a move for creating e.p. rights when the piece itself can also perform e.p. capture. There could be variants where this is not the case.

[Ferdy]

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.

I did try this highlight and locust move.



So far so good, I can replay the moves.

However if I copy, press new game, paste the copied game and replay I got this.



The white pawn at F6 is missing. There is also semi colon after the move. The same thing happens if you load a game from a file.

I am using parent variant fairy with WinBoard 4.9.191113, test legality is off.

What could be the issue with locust move and winboard?

[Ferdy]

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.

I did try this highlight and locust move.



So far so good, I can replay the moves.

However if I copy, press new game, paste the copied game and replay I got this.



The white pawn at F6 is missing. There is also semi colon after the move. The same thing happens if you load a game from a file.

I am using parent variant fairy with WinBoard 4.9.191113, test legality is off.

What could be the issue with locust move and winboard?

All right I got a workaround, use lance instead of pawn in piece to char table.

[Ferdy]

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.

I did try this highlight and locust move.



So far so good, I can replay the moves.

However if I copy, press new game, paste the copied game and replay I got this.



The white pawn at F6 is missing. There is also semi colon after the move. The same thing happens if you load a game from a file.

I am using parent variant fairy with WinBoard 4.9.191113, test legality is off.

What could be the issue with locust move and winboard?

All right I got a workaround, use lance instead of pawn in piece to char table.

Ahh does not always work, the piece I am working can move one step back vertically. Note I did not specify the piece id after sending the setup, I just rely on colorfen and lance piece specified in piece to char table. If I replay the saved game, the locust move is fine (no semicolon after it), but winboard will complain that there is illegal move (not the locust move).

Now if I specify the piece id and its movement, the saved game cannot be fully replayed, it will stop on locust move probably because there is a semicolon after the locust move in winboard notation even if there is no semicolon in move notation in the actual saved pgn file.