WinBoard, exotic version

[hgm]

OK,I prepared a WinBoard binary. It can be downloaded from

http://hgm.nubati.net/WinBoard-Alien.zip

This is a bare winboard.exe, intended to replace the one in the WinBoard-4.5TM.exe install. It will need some thorough testing on the Alien stuff, as there were many conflicts in rebasing it on the master branch, due to changes in the latter since the point of the original forking, which I had to solve by hand (with plenty opportunity for error).

There are also some intentional changes. The most obvous one is in the user interface: if you now enter a partial move, the moved piece stays selected, like you already clicked it once for the next leg. To indicate this, I now don't leave both from- and to-square highlighted, but only the to-square. (I don't know if this is desirable; it was not necessary, so if it is more convenient to leave the from-square highights on, lease let me know.)

No things like lift / put / highlight implemented yet, but at least I am in a good position to do so, now. I guess this should be made subect to a featre, to be sure to not send any stuff to an engine that does not implement it, and might choke on it. How about

feature highlight=1

to indicate the engine wants to receive the

lift SQUARE
put SQUARE

commands, on every (left) up-click and down-click the user makes on the board. (Actually I think we have also to prepare for off-board up-clicks, as a down-click grabs all mouse events exclusively, and you could up-click on the clock or ambiguously on the grid lines anyway. How about a put without any SQUARE indication in that case? Or would it be better to send put @@?) How about down-clicks in the holdings, btw? Should the engine also get those? Normally I don't highight any squares when the user picks up a piece for dropping. So perhaps it should simply count as any off-board down-click, i.e. not be sent to the engine.

For the 'FEN' accompanying the highlight command (or would it be better to rename this a mark command, to not confuse it with the highlighting with arrow?), I want to propose the following letters:

R red
Y yellow
G green
C cyan
B blue
M magenta

In the initial implemantation, only the first two will work, btw, and produce the -premoveHighlightColor and -highlightColor, respectively.

[hgm]

Hmm, I already noticed a problem: when you walk the PV in checkers, and there is a multi-leg capture in it, it does only play the first leg of the move on the board, before continuing with later moves. I don't know if this is because of the way NebiyuCheckers (at least the old version I have) prints the PV: it prints things like "e6c4a2", without a comma in it ("e6c4,a2"), and I think this is non-compliant, and would prevent the WinBoard parser from realizing e6c4 is a patial move. (I guess it will actually parse it as e6c4=A, an invalid promotion...)

I am not saying it will work whe Nebiyu would print a compliant PV, but at least then there would be a chance to fix it.

[hgm]

I did implement the highlight feature as described above (now in the download). I made a special version of Fairy-Max that uses it to highlight some arbitrary squares when you pick up a piece, and it seems to work. I might still be a bit too liberal in sending the lift and put commands (some clicks WinBoard ignores,e.g. because it is not the users turn, will still be sent to the engine). I have to figure out a bit better at which points it is safe to send them.

The feature uses the same control mechanism as the GUI one: /showTargetSquares and /highlightDragging must be on for it to work. Note that in addition the feature is only used when legality testing is off; when it is on, WinBoard uses its own mechanism.

This solves the problem of providing optical cues to theuser to help him pick his move. The equivalent of one-click moving is a different issue, though. If we want to make it possible for the engine to finish a move for the user, before the user is fully done entering it, perhaps we should add an engine->GUI command click SQUARE, that would cause the same event in the GUI as when the user clicked the mentioned square. (That is, up-click + down-click; the command should only be sent, and will only be accepted when the user does not have the mouse button pressed at the time.)

[hgm]

I think the meaning of the highlight protocol needs a little adaptation. Simply sending the engine all clicks puts too much of a burdon on the engine, basically duplication the mouse-handler in the GUI. E.g. a down-click can select a to-square, but it can also cancel the from square (when you click a piece of the same color). You wouldn't want the engine to figure out the distinction.

So I am implementing the following use of these commands now:

lift SQUARE is sent when the user selects a piece. The engine is not necessarily informed when the user deselects the piece (by clicking it a second time, or by dragging the selected piece off board). So it must be prepared to get a second lift command after it, which informs it that the user cancelled the original selection, and selected a new piece in stead.

put SQUARE is sent when the user had selected a piece (namely the one on the square mentioned in the last lift), and moved it to another square (mentioned in the put), i.e. when he completes a leg. (No distinction is made between drag-drop and click-click.) If the move is not yet complete (i.e. the user held the Ctrl key down), the put will be immediately followed by a lift on the same square. (Because WinBoard now always leaves the moved piece selected.) The user can then change the selection, if he wants, which will be reported by new lift commands.

The engine should only respond to lift commands with highlight instructions. In principle, after a put, the move is done, and when it sends a highlight in response to it, the markers might not be cleared by any subsequent event. Any markers put in response to a lift will be cleared by the GUI before the move entry is completed. (E.g. because the user releases the piece, clicks a to-square for it, selects a new piece.)

[hgm]

OK, I now also implemented the enginge->GUI command click SQUARE. It seems to work; I equiped Fairy-Max with an option that cause it to send

click e2
click e4

to the GUI, and when I press it, indeed WinBoard plays e2-e4, and black starts thinking. I made it such that the sending of lift and put commands is suppressed.

This should make it possible for the engine to finish moves for the user, as soon as they are unambiguously specified. (Not sure what would happen if you start sending click commands in response to the first lift command, as this would cause an (faked) down-click event before the user had the chance to up-click. I could not test that.)

I guess a highlight-like mechanism could also be used to let the GUI check legality (on user-entered moves, that is): the user lifts a piece, the GUI informs the engine, the engine sends back which squares should be highlighted, and now the GUI flags any release of the piece (or second click for a to-square) on a square that was not highlighted as illegal. This could perhaps be limited to red and yellow highlights, so that engines that feel the need to put markers on squares that are not legal move targets (like the capture victims in Checkers), could use other colors for those.

Would this be a good thing to have?

Anyway, new version is uploaded.

[hgm]

I have improved WinBoard's handling of the click command. That command can now be given at any time. If the user happens to have the left button down, WinBoard will be aware of it, and first generates an up-click event on the same square as the user's down-click, before starting to process the click the engine sent (as another up+down). This means the engine can now safely issue a click command in response to the first lift, to implement one-click moving. I tested it in a Fairy-Max that was modified to answer click h4 to lift h2, and it plays h2h4 flawlessly when you down-click on h2. The stray upclick that occurs when the user releases the button afterwards is simply ignored.

About the ILLEGALMOVE + go problem:

Is this really a problem? In user-engine games, when the machine has white, it is sent a go without first getting a move. And when it has black, it is already set to play black after new, and will not receive any go. Just a move.

[Rein Halbersma]

BTW, is it possible to remove the pop-window for promotion choices in checkers variants?

[hgm]

The new Alien versions should already have abandoned use of a promotion popup, provided that the options -sweepPromotions is set to true. (IIRC this option can be set in the General Options dialog as "(almost) always promote to Queen", but I am not sure, and I am on Linux now.) Anyway, it is a persistent option, so you would only have to set it once.

With this option on, promotion is to Queen by default, (the promoting piece changing into a Queen as soon as you pick it up), and if you want anything else, you can first pull the promoting piece backwards, which will make it cycle through all available pieces. (Which, in the case of Checkers, should be only Queen anyway, so you won't see anything even if you do pull back the piece first.)

[hgm]

Small fix:

When the engine 'clicks' on behalf of the user, it should also be able to control the Ctrl key. Likewise, when the user puts down a piece, the engine should be informed on the state of the Ctrl key, to know if it was the last leg of the move or not.

In both these cases, a comma suffix to the square will indicate that it concerns a to-click with Ctrl held down. (For lift the state of Ctrl is not relevant, so there never will be a comma suffix there.)

[Rein Halbersma]

Indeed the code for selecting the longest capture was effectively disabled while I was shuffling declartion of variables. Now it is fixed. In the following pos. it would have shown two captures before, but now only the longest capture is retained. thanks for the report.

New version with the fix is uploaded.

Thanks, the crash is now fixed. But the majority capture rule still does not work correctly!

1p1p1p1p1p/p1p1p1p1p1/1p1p1p1p1p/4p1p3/1p1p5p/2P1P5/3P1P1P1P/P3P1P1P1/1P1P1P1P1P/P1P1P1P1P1 w - - 0 4

And here Nebiyu 1.4 will happily allow the capture c4a6 rather than the mandatory e4c6,c6a4.