XBoard problem: disappearing piece

[Evert]

I was just watching a game of Amazon chess (ortho Queen replaced by Amazon) when I noticed that black's Amazon disappeared after Ad3xb1. XBoard subsequently forfeited the engine when it tried to play Ab1-c3.

The problem is likely that the Amazon uses the same slot as the Lance/Berolina/Hoplite, and XBoard treated the move as a promotion to nothing. The log-file suggests this is indeed the case, since the move it sent to the other engine is "d3b1." rather than "d3b1".

Not sure what fixing this would break.

EDIT: some further elaboration: I can't reproduce the problem if I do this "by hand", which is annoying. The variant selected in the New Variant dialog box was actually "fairy" (I was testing Sjaak's variant alias feature) rather than "amazon" (which is listed because Sjaak defines that variant). The setup command was "setup (PNBR..............AKpnbr..............ak) 8x8+0_fairy rnbakbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBAKBNR w KQkq - 0 1"

[hgm]

Indeed, the Lance is considered an alternate Pawn symbol in most variants. There is an explicit exception for Superchess (variant super). I am not sure if chosing that as a parent variant will cause other problems, though. (It is a sort of shuffle game, and has 'promotion-to-captured-only' rules.)

I guess for now the only solution is to not use the Lance for non-pawn pieces. Which is a pity, because I really would not know which of XBoard's symbols would represent an Amazon better than that.

The problem that causes the disappearance is that XBoard does expect a promotion suffix on a move of a pawn to the last rank, and when none is given makes it default to the pieceToChar for a Queen. But the Queen is not defined in this variant. So I guess it should better select something that is defined. Which would of course not really solve the problem, but it would make it look less buggy.

I guess in the future piece-type-dependent decisions such as promotion and creation of e.p. rights should be derived purely from Betza notation, when a piece is redefined. So a piece that promotes on last rank should have an '=1' in its move definition, and pieces that don't have it should never promote. Having a default promotion to Queen for moves that don't specify a promotion choice is of course a bad idea in itself, but I am afraid it would break many engines if I abandon that policy. But perhaps it should be abandoned on pieces that are redefined. They could just stay themselves. This still would not mean you could use the Lance for a non-pawn, however, as XBoard would still trigger the promotion procedure when the user moves it to the last rank, and not allow it to stay a Lance.

[Evert]

I guess for now the only solution is to not use the Lance for non-pawn pieces. Which is a pity, because I really would not know which of XBoard's symbols would represent an Amazon better than that.

I guess the obvious choice would be the Queen.

The problem that causes the disappearance is that XBoard does expect a promotion suffix on a move of a pawn to the last rank, and when none is given makes it default to the pieceToChar for a Queen. But the Queen is not defined in this variant. So I guess it should better select something that is defined. Which would of course not really solve the problem, but it would make it look less buggy.

If it would promote the piece to itself in that case, that would solve the problem, and I don't think it would break anything.

I guess in the future piece-type-dependent decisions such as promotion and creation of e.p. rights should be derived purely from Betza notation, when a piece is redefined. So a piece that promotes on last rank should have an '=1' in its move definition, and pieces that don't have it should never promote. Having a default promotion to Queen for moves that don't specify a promotion choice is of course a bad idea in itself, but I am afraid it would break many engines if I abandon that policy. But perhaps it should be abandoned on pieces that are redefined. They could just stay themselves. This still would not mean you could use the Lance for a non-pawn, however, as XBoard would still trigger the promotion procedure when the user moves it to the last rank, and not allow it to stay a Lance.

Hmm… ok, not that problem probably. However, I don't get any sort of promotion options when I move the piece there "by hand".

That reminds me: is it possible to disable the "drag to select piece" option (either for board editing or for promotion) in favour of a popup dialog? It's pretty inconvenient in combination with a touchpad.

[hgm]

That reminds me: is it possible to disable the "drag to select piece" option (either for board editing or for promotion) in favour of a popup dialog? It's pretty inconvenient in combination with a touchpad.

For promotion there is the option -sweepPromotions true|false. When set to false this would give you the old promotion popup with buttons. But unfortunately this only has buttons for the orthodox Chess pieces + ArchBishop and Chancellor. Except in Spartan Chess, where I made another dialog, and in Shogi, where it is a simple yes/no.

For setting up a position there is the option -pieceMenu true|false. Pop-up menus are not yet implemented in the GTK version, though, so if you set it to true there, nothing would happen when you right-click. Even in the Xaw version the piece menu is not very convenient, though. For one, Xaw menus don't stay up, but have to be selected from with the up-click, which in itself seems already more touch-pad unfriendly than the sweep selection. To create a white piece you need the middle button (or shift + right). And the only pieces directly obtainable from the menu are the orthodox pieces, Archbishop, Chancelor, Elephant and Cannon (where in XQ K and Q are 'corrected' to Wazir and Ferz, respectively). Others can be obtained through clicking an existing piece, and 'promoting' or 'demoting' it.

I admit that a touchpad is not really very ergonomic, but the detour promotion should not really be more difficult to make than any other move. Or do you enter moves as click-click rather than drag-drop? Even with click-click moving there is an opportunity to select the promotion piece in the to-click, similar to in Edit Position mode (but with the left button). This was needed for Shogi, where detour under-promotion does not work, because you cannot predict yet whether a grabbed piece will be able to promote, like you can for a Pawn.

For setting up a position starting from the 'piece pallette' should be the most convenient method in XBoard 4.8. There you just have to just move the pieces (click-click or drag-drop, whatever you prefer), using the Ctrl key if you want to duplicate them (which you can do with your other hand).

Actually pressing the right button with my right-hand thumb, and sweeping my index finger over the touch pad (down for white pieces, up for black) works quite efficiently for me. Except perhaps in Chu Shogi.

[Evert]

I admit that a touchpad is not really very ergonomic, but the detour promotion should not really be more difficult to make than any other move. Or do you enter moves as click-click rather than drag-drop?

No, I drag-drop, but I don't normally need to change direction after the initial shift.

For most "normal" operations I actually find the touchpad to be far superior to a mouse.

For setting up a position starting from the 'piece pallette' should be the most convenient method in XBoard 4.8. There you just have to just move the pieces (click-click or drag-drop, whatever you prefer), using the Ctrl key if you want to duplicate them (which you can do with your other hand).

I'll give that a shot, thanks!

Actually pressing the right button with my right-hand thumb, and sweeping my index finger over the touch pad (down for white pieces, up for black) works quite efficiently for me. Except perhaps in Chu Shogi.

Ah, detail I forgot to mention: I have a Mac, so the touchpad is really one big button (but it does detect if I click it on the left side or on the right side). That possibly doesn't make things easier in this case.

[hgm]

Ah, detail I forgot to mention: I have a Mac, so the touchpad is really one big button (but it does detect if I click it on the left side or on the right side). That possibly doesn't make things easier in this case.

Oh, I was not aware of that. Perhaps we should find another mode for the OS X App that better suits the hardware.

What would be easy to do? I am used to touch pads where tapping twice (without pressing any mechanical switch) simulates a left-click. The second tap can then be used to drag. Is that the same on Mac? I guess Android touch screens also don't have a right button. (And what is worse, no Shift or Ctrl keys to play with.)

What about using the left click both for dragging and dropping pieces, depending on whether you click on a piece (drag it) or empty square (drop something on it). Would that make it easier for you to make the sweep selection? (That shouldn't be more difficult than moving a piece.) Dragging empty squares is not really needed, although it is usually the quickest way to delete a piece. (There almost always is an empty square nearby that you can drag on top of it, while dragging the piece off board might require you to drag over a much larger distance. OTOH, the palette board has all pieces at the edge, usually.) In the development version I now have made it that dragging an empty square off board removes it from the board, but I guess an alternative can be found for that. (And perhaps it is not something we should want to allow anyway.)

Double-click (triple-tap) could be made to emulate the Crtl key; this is already done for move exclusion during analysis (where both double-click and pressing Ctrl while grabbing the piece would signify exclusion rather than moving). So it would be logical do do it during EditPosition too, and let it signify 'copy' instead of 'move'.

The Shift key is currently used for selecting black or white. Basically it is a general signal for swapping the function of right- and middle-button. With the XBoard piece menu that was essential, as the menus have only one color in it, and it would not be possible to drop white pieces if you have no access to the middle button. With sweep selection you loop through both colors, and starting to move up immediately brings you to black, so the Shift key isn't really essential there. (Although still convenient when you want to drop black Pawns without middle button.)

Of course the sweep selection itself could also be streamlined. Now it always starts with a white Pawn, under the assumption that you need those most often, and would similarly use a static click with the middle button for black Pawns. Whether the default is white or black could be made dependent on history, though. E.g. when you previously dropped a black piece, start with a black Pawn rather than a white.

[Evert]

Oh, I was not aware of that. Perhaps we should find another mode for the OS X App that better suits the hardware.

To be fair, older macs are different: they have a tracking surface and a button (singular).

What would be easy to do? I am used to touch pads where tapping twice (without pressing any mechanical switch) simulates a left-click. The second tap can then be used to drag. Is that the same on Mac?

Yes, there's an option "tap to click". I think it's even the default (I disabled it because it would randomly detect clicks whenever I brushed against the trackpad).

I guess Android touch screens also don't have a right button. (And what is worse, no Shift or Ctrl keys to play with.)

The trackpad on a Mac is basically like a touch-input device (it recognises the same type of gestures you can make on an iphone or ipad), so a solution that works for those should work there too.

What about using the left click both for dragging and dropping pieces, depending on whether you click on a piece (drag it) or empty square (drop something on it). Would that make it easier for you to make the sweep selection?

I think so. I'd have to try it out to be certain.

[hgm]

I pushed a version in the master branch of hgm.nubati.net that has the new (persistent) Boolean option -monoMouse. When set, a left-click on an empty-square during Edit Position mode will be interpreted as a right-click.

Please let me know if that is of any help.

Yet another method could be to replace the entire board by the 'pallette board' on a static right click, as a kind of graphical menu, from which you can then select the required piece by clicking it. (After which the board would switch back to the original position with the extra piece.) I tried this once (also with the selectable pieces grouped close to the clicked square), but experienced it as very confusing/distracting.