WinBoard, exotic version

[hgm]

Well, note that in the latest version you can decouple panting the colored dots in the squares from marking them as legal. If you want to put dots on squares that are not legal to-squares of the current leg, use lower-case r and y. To mark a square as legal to-square of the current leg that you don't want a colored dot in, use T. The R and Y that were accepted before cause visible marking and indicate moving to them is legal.

So if you did mark all (and only) legal to-squares in the previous version, by whatever color, it should work in the current version immediately (but now with legality checking).

[Daniel Shawul]

I think it works. The old one said "Illegal move XXXX" which I think got from the engine. Legality testing was off. But with the new one I get "Only marked squares are legal" , which seems to have come from your new implementation. I will see if I can use the "T" marker in any of the games. So far it works with internation checkers, amazons and all the chess variants without a problem. For amazon I marked only moves of the queen, if I did the arrow throwing the whole board will usually be marked. Go and reversi don't need it. Reminder: complete alien mode still not working so i didn't test.
I will finish of the clikc command and upload for you to experiment with.

Edit: For checkers, double capture I highlighted all destination to squares by Red, and I tried to move to the last to square directly. It rejected it as "Illegal move" (coming from engine) which means it accepted it as "legal marked square" in the current implementation. So I think to avoid this, I should only mark Red only the destination of the current leg.

[hgm]

Indeed, that is the new mesage I added. Marking only Amazon moves is OK, as these are the legal to-squares of the first leg. You could mark the target squares for the spear on reception of the lift command for the second leg, though. (After you put down the Amazon, WinBoard will have cleared the markers for its moves.) If you don't send a highlight command, it will consider any to-square legal.

Note that Amazons can also be played with legality-testing on. (Hmm, I see it also marks captures with Amazons and arrows in that case, so this still requires a bit of fixing.)

Note the engine does not necessarily have to wait for the lift command to use highlight. It can send it at any time, and WB will accept it even when feature highlight=1 was not sent. So you could send a highlight immediately after you send the move to a human opponent in reversi, to highlight the squares where he is allowed to drop a piece.

I will look into variant alien. As I had to edit many patches by hand when applying them to the most recent WinBoard version, it is not surprising if I would have broken something.

[Daniel Shawul]

I have got perfect games for "G". All the weird captures in Ultima need some good coloring, it is difficult for human to see those. Also atomic chess etc.. But both are in the alien branch right now. Or I can modify the checkers capture in such a way T is used for to squares and a Red on the captured square maybe. It may require some work in international checkers due to long captures.

[Daniel Shawul]

click works for one leg captures but not with multi captures. I am not sure if the problem is with my possibly wrong coloring or not.

For single capture it worked.
>lift d4
click f6

For multi-captures with only one move I sent
>lift e3
click c5
click e7
> usermove e3c5
Illegal move : e3c5

It sent only one leg to the engine, which ofcourse the engine rejects.

[Daniel Shawul]

Here is a marking with both captial and small R & Y.
FEN: 8/6y1/5r2/Y3Y3/1r1r4/8/8/8
The first two yellow squares are captal (so we can move there) the last one is small. All red colors are small.

I do not support coloring after one leg move right now, since it is somewhat difficult to keep track. Actually once white captures the right pawn, click should finish it off but that doesn't work right now. Even if it did , I still have to implement coloring for multiple legs. Once a multiple leg move is started (and has two or more branches, otherwise click should finish it i think), I delete the rest of the moves. At least for checkers that will work, but for ultima the other moves need to be kept since I can combine them in.
Then the highligthing and click are done again and again until move becomes non-ambiguous.

Edit :
Now everything works I think. I kept a third copy of the board to be modified by a lift-put combination for multi leg moves. So when every leg is made the highlight_board is updated so it works there as well. It can even do finish intermediate moves now. It needs the comma after "put e5," to know a move is not finished
For the above example , if the user lifts and put c3e5, winboard does a click and finish of the move !!! That didn't work before though for non-ambiguous double captures. I think I now know why, I didn't put a comma after the first click! I will try again...

Edit 2:
Haha indeed it was the comma. Now I can make double captures just by lifting the piece. I don't think anything is left to do now for checkers.
For future implementers, I think retaining copies of board, handling pondering, not forgetting commas, clear explanation of the put_lift_hightlight commands need some explanatory notes I think.

Btw, there are many situations that click can help. I can say almost half of the moves in a checkers game are helped by the click command. If one square of a checker is blocked, a click would move it to the only other available square.

I will provide an exe tommorrow.

[Daniel Shawul]

All versions with highlighting are uploaded now. Some notes:

a) If a multi-capture is non-ambigous just click on the piece and winboard automatically finishes it. But if the first leg is ambigous but not the rest, do a Cntrl + click on the first to square and winboard will finish it. If you just clicked without Cntrl, it won't work. Maybe that is something to think about ?

b) Colring right now works only on R & Y. I wanted to paint some to squares of a multi-capture with green but it didn't work. Y & y have a different meaning , so I wanted to differentiate by color too using small g instead of y.

c) For checkers click moving it is now an essential component for the human to play quikly. It also helps in normal chess especially when being in check. Btw does winboard have click moving for normal chess before ?

b) I changed the PV into standard form but it didn't fix winboard's problem. I think there is a bug in winboard not related to how the pv is displayed. Also my pv has other stuff at the end which could be the problem. Is the PV standardized now anyway ? I am sending some random stuff when using montecarlo search, so maybe I should precede those with "#" not to break things.

[hgm]

a) If a multi-capture is non-ambigous just click on the piece and winboard automatically finishes it. But if the first leg is ambigous but not the rest, do a Ctrl + click on the first to square and winboard will finish it. If you just clicked without Cntrl, it won't work. Maybe that is something to think about ?

I am not sure what can be done without losing generality. Without game knowledge the GUI cannot know that the first leg does not complete the move, and if it does, it has to send usermove in response to it (because nothing else that could act as a trigger will be happening after that). The engine, receiving the illegal usermove might be able to realize that the user meant the multi-leg extensionof the entered move, and could, after sending 'Illegal move' to have the GUI take it back, send a number of click commands to enter the correct move. This is likely to cause annoying visual side effects, though,and can cause move+go hardship.

How about this: the engine informs the GUI in advance which of the legal to-squares are only legal if another leg follows, so that it can force Ctrl with a user click on that square, even when the user did not press it. Not sure how I would have to enode that in the highlight command, though. There are only two cases (upper and lower), and I already use those to indicate legality irrespective of the need for a follow-up leg. Perhaps I should allow a color-indicator in the color-FEN of the highlight command, to be suffixed by a comma, to indicate that it is a 'semi-legal' to-square, i.e. legal not by itself, but only with a follow-up leg. (Similar to ~ suffixing in bFENs to indicate that a piece is really a promoted Pawn.)

I am not sure if this is a good way to go, though. I would like the highlighting and one-click moving to be optional. (In future versions I definitely want to make acceptance of the click command also subject to the setting of the GUI one-click move option.) I don't want to force engines to have them, because that would force an almost impossible burdon on protocol adpters for engines using protocols that do not support anything like this. And I think it would be bad to train the user to expect that a non-Ctrl click might do the job, where other engines might require pressing the Ctrl key.

b) Colring right now works only on R & Y. I wanted to paint some to squares of a multi-capture with green but it didn't work. Y & y have a different meaning , so I wanted to differentiate by color too using small g instead of y.

Indeed, only the two colors that were implemented before for the native /moveTargetSquares currently work. (And I stole those from highlight and premoveHighlight of square borders.) For more colors I would have to change the front-end, to create graphics consoles and all that crap to define new colors, which must be done separately for XBoard and WinBoard. At some point I will probably do that, but not before we are sure that we like the basic highlighting mechanism enough to keep it.

Highlighting capture victims in Ultima or Atomic might be problematic, though. The lifted piece could have different captures. E.g., in Atomic, lifting Qe4 with opponent Pawns on e5, and d5, provides two legal captures, each with their own 'blast zone', but the blast zones overlap. So if there are Nc6, Bd6 and Rf6 next to the Pawns, now with what color would you want to mark each of the mentioned pieces when Qe4 is lifted?

Perhaps highlighting in this case will cause more confusion than it will solve. Perhaps it would be better to mark the target square of the capture(s) R when he lifts the piece, and only indicate the 'collateral damage' when the user actually hovers the lifted piece above the target square. This would require a new command in addition to lift and put, namely hover SQ. (Note that the corresponding event already exists in WinBoard: Highlight Dragging causes highlight borders to be drawn around the square where the dragged piece is going to land. So I can easily implement this. But it will cause a flood of output. Perhaps the GUI should only send it when you hover above a square highlighted in (legal) red, so the engine could respond with a highlight command indicating collateral damage (if there is any). The GUI then would automatically clear the collateral damage as soon as you hover off the square.

c) For checkers click moving it is now an essential component for the human to play quikly. It also helps in normal chess especially when being in check. Btw does winboard have click moving for normal chess before ?

Yes, with legality testing on, you can swicth on one-click moving in the General Options dialog. And it is even more elaborate than we can do now with the lift/click protocol: apart from moving your own clicked piece that only has a single legal move, it will move a piece to a clicked empty square or opponent piece if only a single move can legally go there. (From-clicks on an empty square are not transmitted to the engine now, so this can not yet be emulated.) And double-clicking on an own piece willmake it do the only legal capture it has.

b) I changed the PV into standard form but it didn't fix winboard's problem. I think there is a bug in winboard not related to how the pv is displayed. Also my pv has other stuff at the end which could be the problem. Is the PV standardized now anyway ? I am sending some random stuff when using montecarlo search, so maybe I should precede those with "#" not to break things.

In WB protocol the PV is just free-format text. But for things like PV-walking to work, the PV must be recognizable, of course. I run WinBoard's PGN parser on it, which is pretty clever in recognizing moves of any notation, automatically skips over move numbers and a lot of other chatter, and I let it skip over things that parse as comment as well. It parses what the engine sent until it runs into something it cannot parse, or an illegal move, and the PV can only be walked upto that point. So sending 'nonsense' should never be fatal; it just means you cannot walk through it.

[Daniel Shawul]

I am not sure if this is a good way to go, though. I would like the highlighting and one-click moving to be optional. (In future versions I definitely want to make acceptance of the click command also subject to the setting of the GUI one-click move option.) I don't want to force engines to have them, because that would force an almost impossible burdon on protocol adpters for engines using protocols that do not support anything like this. And I think it would be bad to train the user to expect that a non-Ctrl click might do the job, where other engines might require pressing the Ctrl key.

Yes it sounds awkward so I think we should leave it as it is. Also this happens very very rarely.
Most multi-captures are usually the kind that are finished automatically by clicks the engine sends.
So the first lift finishes it off already. I have to manually set up that postion I posted before to
check if it works or not.

Perhaps highlighting in this case will cause more confusion than it will solve. Perhaps it would be better to mark the target square of the capture(s) R when he lifts the piece, and only indicate the 'collateral damage' when the user actually hovers the lifted piece above the target square. This would require a new command in addition to lift and put, namely hover SQ. (Note that the corresponding event already exists in WinBoard: Highlight Dragging causes highlight borders to be drawn around the square where the dragged piece is going to land. So I can easily implement this. But it will cause a flood of output. Perhaps the GUI should only send it when you hover above a square highlighted in (legal) red, so the engine could respond with a highlight command indicating collateral damage (if there is any). The GUI then would automatically clear the collateral damage as soon as you hover off the square.

For Ultima & other alein games, if the move captures anything its destination square are reddened, non-captures
yellowed. If I want to show all those weird captures, the hover SQ is definately needed. The problem with a flood of
output could be allievated if winboard sends the command only when the hover square changes! Maybe that is what it already
does. But if I get a command for the slightest mouse move , pondering would be severly hampered.
I currently do not have information on captured pieces during move genration (I do that only when the move is actually being made),
so it may require me some work. But you can go ahead and add the hover command. Make sure I get it only when the hovered
square changes though.

Yes, with legality testing on, you can swicth on one-click moving in the General Options dialog. And it is even more elaborate than we can do now with the lift/click protocol: apart from moving your own clicked piece that only has a single legal move, it will move a piece to a clicked empty square or opponent piece if only a single move can legally go there. (From-clicks on an empty square are not transmitted to the engine now, so this can not yet be emulated.)

I have thought about making a single move automatically, but I think KISS as we agreed before is better for now.
There are other ways to hasten the move selection process like f.i clicking any of the to squares which disambiguates
from multiple possible moves can trigger immediate clicks.
For instance e4! does need the lift of the pawn at e2, just clicking the target square can make the only available move.

And double-clicking on an own piece willmake it do the only legal capture it has.

Currently we do this with single click btw.

In WB protocol the PV is just free-format text. But for things like PV-walking to work, the PV must be recognizable, of course. I run WinBoard's PGN parser on it, which is pretty clever in recognizing moves of any notation, automatically skips over move numbers and a lot of other chatter, and I let it skip over things that parse as comment as well. It parses what the engine sent until it runs into something it cannot parse, or an illegal move, and the PV can only be walked upto that point. So sending 'nonsense' should never be fatal; it just means you cannot walk through it.

Ok I will switch to the standard form then. I wanted to use shorter form to make the pvs shorter and also because
it requires synchronization between the board and the move being played. So to print the pv, I have to make_move each
of the moves and construct its representation (much like SAN is done). But the real reason I am doing it was the former
so I will change it.

[hgm]

Currently we do this with single click btw.

Not if the piece also has legal non-captures. (Which in Checkers of course never can be the case, but in Chess is quite normal. Siders often have 10-15 non-captures plus one capture of a distant target. Double-clicking can then save time compared to dragging it to the distant target, when clicking the target wouldnot work because there are other attakers.)