XBoard protocol: 'highlight' command

Discussion of chess software programming and technical issues.

Moderator: Ras

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

XBoard protocol: 'highlight' command

Post by hgm »

I assigned a meaning to a marker color that so far did not have a special one: blue. This now means that a piece released there will be forced to promote on engine specification: XBoard will initially abort the entry of a move to such a square marked in blue, after it sent a 'put' command with the square coordinates to the engine. The engine is then supposed to reply to this 'put' command with a 'choice' command for specifying what the piece should promote to, (i,e, it should only specify a single option), and this would then complete the move entry by combining the coordinates of the aborted move entry with the received promotion choice.

This solves the problem of mandatory promotions that the GUI would not expect. When receiving such moves in text format (because an engine plays them, or they were read in a PGN file) they will have a promotion suffix on them, so these were already handled correctly.

Moves to squares marked by the engine in purple remain ordinary promotions, which trigger the usual GUI mechanism for selecting a promotion piece when the piece is released there. Here the engine has ample time to send an optional 'choice' command in response to a 'lift' or 'put' command from the GUI to tailor the offered choice away from the default (which would offer all participating piece types except Pawn and King).
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: XBoard protocol: 'highlight' command

Post by Evert »

hgm wrote:I assigned a meaning to a marker color that so far did not have a special one: blue. This now means that a piece released there will be forced to promote on engine specification: XBoard will initially abort the entry of a move to such a square marked in blue, after it sent a 'put' command with the square coordinates to the engine. The engine is then supposed to reply to this 'put' command with a 'choice' command for specifying what the piece should promote to, (i,e, it should only specify a single option), and this would then complete the move entry by combining the coordinates of the aborted move entry with the received promotion choice.

This solves the problem of mandatory promotions that the GUI would not expect. When receiving such moves in text format (because an engine plays them, or they were read in a PGN file) they will have a promotion suffix on them, so these were already handled correctly.

Moves to squares marked by the engine in purple remain ordinary promotions, which trigger the usual GUI mechanism for selecting a promotion piece when the piece is released there. Here the engine has ample time to send an optional 'choice' command in response to a 'lift' or 'put' command from the GUI to tailor the offered choice away from the default (which would offer all participating piece types except Pawn and King).
I've implemented this in SjaakII.
It now prints 'B' in the colour FEN if there is exactly one move to the target square, and it is a promotion move.
If the highlight/put move corresponds to a mandatory promotion, it will list all available promotion options in a "choice" command. No "choice" command is generated if the promotion is optional, or if the move is not a promotion.
User avatar
hgm
Posts: 28461
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: XBoard protocol: 'highlight' command

Post by hgm »

Great! I am trying it in HaChu, where some of this is needed for the contageous pieces of Maka Dai Dai Shogi. I guess I should use it for Mighty Lion and Werewolf Chess too.

Why would you not send 'choice' for optional promotions? An optional promotion just means that the original piece is amongst the electable pieces. For Shogi promotions (to a +L) this is actually the default (so that you would indeed not have to bother with those), but for Pawn promotions XBoard by default only presents non-Pawn, non-King choices.

One thing you could also do is that when all possible moves of a lifted piece are promotions (i.e. marked magenta), which all have the same choice, as would be usual in Pawn promotion (but not in Grant Acedrex), is already send the 'choice' in response to 'lift'. Then the restriction it specifies would already apply during detour underpromotion, rather than being selectable only on the to-square via click-click moving.

Note that for parent variant chu I made colors different from B or M deny promotion, even when the original rules for the variant would think it one (e.g. because the move touches the standard zone). Perhaps I should do that in all variants, but I was not sure whether I would break something by that.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: XBoard protocol: 'highlight' command

Post by Evert »

hgm wrote: Why would you not send 'choice' for optional promotions? An optional promotion just means that the original piece is amongst the electable pieces. For Shogi promotions (to a +L) this is actually the default (so that you would indeed not have to bother with those), but for Pawn promotions XBoard by default only presents non-Pawn, non-King choices.
Ah, true - I didn't think of that.
One thing you could also do is that when all possible moves of a lifted piece are promotions (i.e. marked magenta), which all have the same choice, as would be usual in Pawn promotion (but not in Grant Acedrex), is already send the 'choice' in response to 'lift'. Then the restriction it specifies would already apply during detour underpromotion, rather than being selectable only on the to-square via click-click moving.
Hmm... yes, I should be able to do that. It'll take a bit more work though.
Good point about Grand Acedrex, I'll need to implement this in Postduif too.
Note that for parent variant chu I made colors different from B or M deny promotion, even when the original rules for the variant would think it one (e.g. because the move touches the standard zone). Perhaps I should do that in all variants, but I was not sure whether I would break something by that.
I think I have set it up so "promotion" overrides "capture" if a move is both, so I don't think there should be any confusion. Of ourse I can't speak for everyone...
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: XBoard protocol: 'highlight' command

Post by Evert »

hgm wrote: One thing you could also do is that when all possible moves of a lifted piece are promotions (i.e. marked magenta), which all have the same choice, as would be usual in Pawn promotion (but not in Grant Acedrex), is already send the 'choice' in response to 'lift'. Then the restriction it specifies would already apply during detour underpromotion, rather than being selectable only on the to-square via click-click moving.
Is there a drawback to sending the union of all promotion options in response to "lift" (as for a pawn that can promote normally or through a capture in Grande Acedrex)? I would imagine that this would just restrict the offered choices in the sweep-underpromotion, in which case it would still be better than the default.
User avatar
hgm
Posts: 28461
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: XBoard protocol: 'highlight' command

Post by hgm »

There should not be any drawback to this. 'choice' commands simply overwrite each other; grabbing a new piece clears the restriction list. Down-click on a predictable promotion square (i.e. predictable by XBoard without help of any highlight command, so usually just 7th-rank Pawns) or on a purple to-square start the selection procedure with the restriction in force at that point, but a 'choice' command received while this selection is in progress will instantly replace the displayed piece, and further motion of the mouse will then only show pieces listed in the 'choice' command.