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).
XBoard protocol: 'highlight' command
Moderator: Ras
-
hgm
- Posts: 28461
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: XBoard protocol: 'highlight' command
I've implemented this in SjaakII.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).
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.
-
hgm
- Posts: 28461
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: XBoard protocol: 'highlight' command
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.
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.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: XBoard protocol: 'highlight' command
Ah, true - I didn't think of that.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.
Hmm... yes, I should be able to do that. It'll take a bit more work though.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.
Good point about Grand Acedrex, I'll need to implement this in Postduif too.
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...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.
-
Evert
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: XBoard protocol: 'highlight' command
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.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.
-
hgm
- Posts: 28461
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: XBoard protocol: 'highlight' command
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.