hgm wrote:
I guess XBoard accepts only promotion suffixes if the move generator explicitly says the move is a promotion. Currently the Betza generator submits all moves to the callback as 'Normal'.
So I guess I would have to test for the piece being a Pawn, (i.e. represented by XBoard's Pawn image according to the pieceToCharTable) and in that case generate moves to last rank as White/BlackPromotionToQueen.
Wouldn't that potentially break Hoplites?
Of course it would be better if the Betza notation could tag the piece as promoting, so that you could have differently moving Pawns that each promote in one army. Like defining a Betza pseudo-atom '=' that means 'promotes on last rank', with a possibility to append a range for deeper zones (like "=3" in Grand Chess). Of course this could be extended with some notation for what it can promote to, but XBoard doesn't support that anyway, and always offers full choice on all (non-Shogi-style) promotions. (It is up to the engine to refuse an illegal choice.)
This would help, but of course in general the promotion zone isn't made up of the last N ranks: in Makruk it's the 6th rank, in Sittuyin (not a supported variant, I know) it would be the long diagonals on the opponent's side of the board.
I'm not sure what the best way to describe the promotion zone would be. Sjaak uses a bitmask and some logic to decide whether promotions are mandatory or optional (they're optional if the piece can still move, mandatory if it would have no legal moves on its new location).
It would indeed break Hoplites, which in XBoard's hard-coded move generator are treated in most variants as Pawns. (Except in Superchess, I think.) So I could use the same convention in the Betza generator.
As to promotions: For Makruk XBoard assumes a zone of 3 ranks. That there is no way to ever get deeper into the zone because promotion is mandatory makes that this is a moot point. If you play Makruk with drops, however, it would allow Pawns dropped on 6th or 7th rank to promote, which seems the more useful extension of the Makruk definition.
And yes, diagonal zones are a problem. I am inclined to group this with the the problem of position-dependent moves. Betza cannot handle that. The engine would have to inform the GUI that the move is apromotion, through the move notation (when it moves) or through the highlight command (when the user moves).
hgm wrote:It would indeed break Hoplites, which in XBoard's hard-coded move generator are treated in most variants as Pawns. (Except in Superchess, I think.) So I could use the same convention in the Betza generator.
I guess I could also just make it an option whether to send piece strings for pawns (default off for now). That would avoid the problem for now.
And yes, diagonal zones are a problem. I am inclined to group this with the the problem of position-dependent moves. Betza cannot handle that. The engine would have to inform the GUI that the move is apromotion, through the move notation (when it moves) or through the highlight command (when the user moves).
Will it accept promotion suffices on arbitrary moves though?
With legality testing off XBoard will accept promotion suffixes on arbitrary moves. So I guess even without engine highlight support you could always type the promotion moves when you want to make them as user. (Originally that was the only way to castle in FRC too.) Try typing g1f3r in -ncp mode.
hgm wrote:I pushed a patch that fixes the promotion problem: Pawns and Lances reaching last rank will now be assumed by the Betza generator to promote.
Other zone depths will have to wait for a next version of the Betza parser.
Ok, I'll upgrade to that, but keep 4.8 on the side for testing.
