Some more xboard alien/variant questions

[Evert]

In XBoard Alien edition, should I be able to select variant "alien" from the menu? It doesn't appear in the list, but it seems to be recognised when I pass it on the command line.
I think variant alien is the best (only) way to implement Burmese Chess because some of the moves have effects that XBoard is unaware of (the promotion zone is unconventional), but before I go there I'd like to know if I'm likely to run into issues with XBoard itself.

Another question: in variants where pawns move in unorthodox ways XBoard sometimes interprets a pawn move as an en-passant capture and removes an enemy pawn (note: there should be no en-passant square set because the removed pawn will not have moved from the second to the fourth rank in these variants, so maybe a check for that would be sufficient).
An obvious workaround would be to use a different piece-type but that has a drawback in that the piece then doesn't look pawn-ish. Is there a better way to handle this? Sjaak has feature "highlight" so in principle it can tell XBoard about en-passant captures when they happen, so there should be no reason for XBoard to implicitly implement them (although I'm not sure I'm handling this correctly at the moment).

Finally, a suggestion: IIRC there is an issue with legality testing in variants where XBoard doesn't know the rules and has to rely on the engines to tell it honestly what the state of the board looks like (through a setup command). Wouldn't it be possible to ask both engines what they think the board looks like and check whether they agree? Possibly only do this if the reported position has non-obvious changes (so anything other than the piece moving from one square to another).

[hgm]

Indeed, it would be better if all variants were selectable by the menu. I did not pay much attention to the menus yet. This, at least, can be easily fixed (by simply adding them to the table in xoptions.c).

Using variant alien just because of deviating castling or e.p. rules is a bit like firing a cannon at a mosquito... We really should find something better for this. I guess the heuristic used now in 'MakeMove' to implement e.p. capture could be 'disarmed' a little by adding the condition that it should _never_ remove anything that did not move on the move before. That is not fool-proof, however. And it does not help any to make it do non-standard e.p. captures. I am not even sure this works now in Berolina Chess.

I guess a good kludge would be to encode e.p. captures internally as having the to-square of the captured Pawn (in the same spirit as KxR encodes castling in FRC). This assumes sideway captures for Pawns are always illegal, which is probably reasonably safe. (Xiangqi can remain explicitly exempted, as it has no e.p.) MakeMove could intercept such lateral PxP captures (like it intercepts diagonal moves to empty squares now), and reconstruct the true to-square by averaging the from- and to-square of the previous move in that case. Or better yet, take the square one rank forward on the path of the previous move, to handle triple-pushes. That would catch both FIDE and Berolina Pawns. And, with legality testing off, where the engine pretty much directly writes the internal encoding, the engine could use this kludge to indicate a non-standard e.p. capture!

As to non-standard promotion zones: I think this is already supported in any variant. When legality testing is off, a promotion suffix to any move is taken seriously, and unconditionally obeyed. It does not even have to be a Pawn move. Nf3=Q gives you an instant Queen on f3, even in the standard edition of XBoard in variant normal! As long as the engine knows where to promote, you can still use any variant that is suitable for other reasons.

The 'referee structure'of XBoard is still open for debate. But XBoard seems to have been designed from the beginning for using the first engine as a plug-in for legality checking. Even in EditGame mode the first engine is kept in lockstep with the game, to check move legality. Later developments moved the legality checking to the GUI, but with the Alien Edition weagain move away from that.

It is a good question (and has indeed been proposed) whether we should equip XBoard with a 'referee plug-in' to do the legality testing and highlighting, next to the engines, so that not all engines have to implement this overhead. But IMO the required referee would not be significantly different from a normal engine, certainly not in its communiation needs. So it would be easiest to simply increase the number of engines to 3, keep the first engine responsible for legality-testing, highlighting, setting up the board, just like it is now, and add the possibility for the user or the third engine to play the second engine.

BTW, I am sensitive to the argument that requiring every engine to do the highlighting leads to unnecessary duplication of effort, but I cannot see a clear reason why XBoard should consult both players in an engine-engine match for board upates. Cheating by one of the engines would be caught by the other quickly enough, as it would flag moves that are illegal according to its own internal board. XBoard does not force the board updates it receives upon the other engine.

[Evert]

Indeed, it would be better if all variants were selectable by the menu. I did not pay much attention to the menus yet. This, at least, can be easily fixed (by simply adding them to the table in xoptions.c).

Ok.
Just wondering.

Using variant alien just because of deviating castling or e.p. rules is a bit like firing a cannon at a mosquito... We really should find something better for this.

Yes. It's difficult to see how though... unless there's a way to do a multi-move with a "lift"? Then a non-standard en-passant capture could just be a move+lift (of the captured pawn).

I guess the heuristic used now in 'MakeMove' to implement e.p. capture could be 'disarmed' a little by adding the condition that it should _never_ remove anything that did not move on the move before. That is not fool-proof, however. And it does not help any to make it do non-standard e.p. captures. I am not even sure this works now in Berolina Chess.

Berolina is at least a recognised variant, so if en-passant doesn't work there it can be filed as a bug and fixed. But it's more difficult for fairy variants where there is no obviously correct en-passant rule...

I guess a good kludge would be to encode e.p. captures internally as having the to-square of the captured Pawn (in the same spirit as KxR encodes castling in FRC). This assumes sideway captures for Pawns are always illegal, which is probably reasonably safe.

Well, actually... the variants where I'm running into issues have the pawns move one step along a diagonal (say white pawns move NE) and capture straight (either N or E), so they're like normal pawns but rotated over 45 degrees. They're not really like Berolina pawns either.

(Xiangqi can remain explicitly exempted, as it has no e.p.)

True, but there can be variants with normal pieces and Xiangqi pawns (just for fun, I had the Xiangqi array play against the FIDE array, without palace or river restrictions. The result was entirely what you expect, but it was still amusing).

And, with legality testing off, where the engine pretty much directly writes the internal encoding, the engine could use this kludge to indicate a non-standard e.p. capture!

I'm all for it, as long as I can also say (explicitly) that a move is not in fact an en-passant capture.

As to non-standard promotion zones: I think this is already supported in any variant. When legality testing is off, a promotion suffix to any move is taken seriously, and unconditionally obeyed. It does not even have to be a Pawn move. Nf3=Q gives you an instant Queen on f3, even in the standard edition of XBoard in variant normal! As long as the engine knows where to promote, you can still use any variant that is suitable for other reasons.

You're right, I'm not sure why I thought variant "alien" would be the most appropriate. It was probably late when I thought of it.
In fact the problem with promotion moves is not so much how the engine specifies them (that works) but how the user should specify them.

It is a good question (and has indeed been proposed) whether we should equip XBoard with a 'referee plug-in' to do the legality testing and highlighting, next to the engines, so that not all engines have to implement this overhead. But IMO the required referee would not be significantly different from a normal engine, certainly not in its communiation needs. So it would be easiest to simply increase the number of engines to 3, keep the first engine responsible for legality-testing, highlighting, setting up the board, just like it is now, and add the possibility for the user or the third engine to play the second engine.

Sounds good, although I would personally keep "first" and "second" engine as is and have a third explicit "referee" engine, that defaults to the first engine. That's probably mostly semantics.
I agree that the referee is just another engine.

BTW, I am sensitive to the argument that requiring every engine to do the highlighting leads to unnecessary duplication of effort,

I think highlighting should be entirely optional (actually, I always disable it because I find it annoying, but that's personal preference of course).

but I cannot see a clear reason why XBoard should consult both players in an engine-engine match for board upates. Cheating by one of the engines would be caught by the other quickly enough, as it would flag moves that are illegal according to its own internal board.

But you don't know who the cheater is since you can't be sure that it's the engine that supposedly made the invalid move. Of course, if there's a referee, then there's no issue; presumably xboard would also consult the referee for board updates.

XBoard does not force the board updates it receives upon the other engine.

Ok.

[hgm]

Yes. It's difficult to see how though... unless there's a way to do a multi-move with a "lift"? Then a non-standard en-passant capture could just be a move+lift (of the captured pawn).

Well, adding a new command to specify an extra square (such as captured Pawn in e.p. or Rook to-square in free castling) would be possible, but it would easily lead to something so similar to entering another move, that we might as well use the general multi-move capability already designed for the Alien Edition. In this case the test now flagging partial moves as illegal even with legality testing off in most variants could be relaxed a bit in case of castlings or PxP moves that capture a Pawn moved on the previous move. (Or perhaps the e.p. captures should be denoted as P x (own)K?). So a comma suffix on a move that parses as castling could be re-defined to indicate only the King step, without the normally implied Rook move, so that the Rook move could be specified in a second leg. For e.p. capture we would send a plain capture of the victim Pawn as first leg, and a move from capture- to true to-square as second leg.

But these demands are so Chess-specific that it would be really nice they could also work in the standard edition, without general multi-move capability. But I guess there it could be implemented in a more ad-hoc way, not treating a move command with a partial move as move command at all, but just making it set some flags that would affect processing of the next move command.

Berolina is at least a recognised variant, so if en-passant doesn't work there it can be filed as a bug and fixed. But it's more difficult for fairy variants where there is no obviously correct en-passant rule...

True. Berolina is currently only partially supported (it still needs legality testing off), and I should do something about that one of these days.

You're right, I'm not sure why I thought variant "alien" would be the most appropriate. It was probably late when I thought of it.
In fact the problem with promotion moves is not so much how the engine specifies them (that works) but how the user should specify them.

Ah, yes. Of course the user could always type it, but this is a bit of a poor-man's solution. I guess the highlight mechanism could be used similar to how it is now used for letting the GUI check move legality. A certain color marking could be reserved for promotions, and when a user releases the piece on a thus marked square, he would get the promotion popup. Or even better, when promotions are amongst the highlighted squares, it could activate the "detour under-promotion", immediately changing the picked-up piece to the default choice. In the unusual case that promotions and non-promotions are possible at the same time, it can always automatically revert to Pawn when you land on a non-promo square.

Of course this solution is again specific to the Alien Edition. But perhaps the highlighting mechanism should be incorporated in the official protocol, and ported tot he standard version in any case. Even if only as a protocol addition to facilitate implementing referee engines.

Similar problems of course occur with non-standard e.p. and castlings.

Sounds good, although I would personally keep "first" and "second" engine as is and have a third explicit "referee" engine, that defaults to the first engine. That's probably mostly semantics.

Well, it could be a bit more than semantics, because when you have only a single engine connected, it would automatically have to be the referee, and it would be a bit counter-intuitive to call it 'third engine' in that case.

I think highlighting should be entirely optional (actually, I always disable it because I find it annoying, but that's personal preference of course).

Oh, yes, it is entirely optional, but when the engine (or referee) implements it, the markers would not have to be visible in order be used as a guide for legality checking, promotion guiding or (perhaps) capture indication. Actual display of them could be controlled by a GUI option the engine doesn't have to know about. If side effects of a move are merely disappearance of pieces in unexpected places, such as with e.p. capture or in Ultima, a full board update (as in variant Alien) could be over-kill, and the second-level highlight command sent in response to hovering over a to-square for a capture could be used by the GUI to empty the indicated squares when the piece is released there. It would lead to the same sort of problems when loading a PGN file, though.

But you don't know who the cheater is since you can't be sure that it's the engine that supposedly made the invalid move. Of course, if there's a referee, then there's no issue; presumably xboard would also consult the referee for board updates.

If there is a referee, it would _only_ accept the board updates from the referee. But even without referee, I think this is not really a problem of much practical importance. It would be known quickly enough which engines are buggy, and which can be trusted. And you could simply check the PGN to see which engine is right. Buggy engines are not attractive as testing opponents for your own, and when your own engine is at fault you would want to analyze the game anyway, to see what the bug was.