Winboard and chess variant

Discussion of anything and everything relating to chess playing software and machines.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 23772
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Winboard and chess variant

Post by hgm » Tue Nov 12, 2019 4:42 pm

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
Posts: 4111
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Winboard and chess variant

Post by Ferdy » Wed Nov 13, 2019 9:06 am

hgm wrote:
Mon Nov 11, 2019 5:07 pm
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.

User avatar
hgm
Posts: 23772
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Winboard and chess variant

Post by hgm » Wed Nov 13, 2019 10:02 am

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.)

User avatar
hgm
Posts: 23772
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Winboard and chess variant

Post by hgm » Wed Nov 13, 2019 9:59 pm

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
Posts: 4111
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Winboard and chess variant

Post by Ferdy » Thu Nov 14, 2019 9:41 am

hgm wrote:
Wed Nov 13, 2019 10:02 am
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.

User avatar
hgm
Posts: 23772
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Winboard and chess variant

Post by hgm » Thu Nov 14, 2019 12:04 pm

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.

Post Reply