WinBoard, exotic version

[hgm]

OK, I have a new version, that implements a hover SQUAREcommand. It only sends it when the piece you drag enters a square marked before as 'R' in response to a lift command.

It was a bit tricky to implement, because when you leave the square again, it should restore the markings there were after the lift, and it is not so obvious which highlight command is in response to a lift, and and whh in response to a hover command. I do it such now that the marker state when you first leave the from-square with the piece is taken as the base markings. But I think it should work now.

[Daniel Shawul]

Ok for checkers I have small 'r' so it was not applicable there. For chess I used R and it seems to work. I am getting hover e5 for a knight capturing a pawn at e5. It sent it twice when I moved out and moved in to the square again.
So I will send a highlight with different colors (other than R & Y) when I get the hover right? Both atomic and ultima are in alien branch, so I will just send some coloring ; 8 yellows around the target square to see if it works as intended.

[hgm]

Yes, for now only red and yellow work. Most logical would probably be to mark the pieces that will disappear red.

Be careful not to disturb the legality markings from the original lift command, as I make no effort to save and restore those. So a color-FEN sent in response to a hover command should mark the same squares as legal to-square that belong to the current from square (as indicated by the last lift).

[Daniel Shawul]

It works just as expected. When I hovered upon e5 all the surrounding squares are highlighted with yellow. The previous highlighting is overwritten. And then when I moved out it goes back to the previous highlighting even though I didn't put the piece back to its original square. This is what you told me before and it works.
But when I hovered back (still without putting it), I am not getting another hover. I think what I said before about getting a second hover is wrong. It must be two consecutive hover-lifts that I saw in the log file. I am not getting it. I tried a positon with two RED marks hoping moving to another red square generates a hover but it didn't. So we got a problem there.
Other than that everything works.

Edit :

Be careful not to disturb the legality markings from the original lift command, as I make no effort to save and restore those. So a color-FEN sent in response to a hover command should mark the same squares as legal to-square that belong to the current from square (as indicated by the last lift).

But it sounds like you saved the original highlights. Because when I hovered and get out, it automatically reverts back to that one. The highlight I sent when getting a hover consisted of only those 8 surrounding squares. But second time hovering on the same square or a different red square doesn't work. I have to first put down the piece, hence getting a new lift and repreating the process...

[Rein Halbersma]

[quote="Daniel Shawul"]Hello Rein
I have fixed it now and is uploaded. It was still a problem with declaration of variables . I am sure v1.0 had all of this working correctly since I had matching perft numbers. Anyway thanks for the report. I appreciate it.[/quote]

Hi Daniel, thanks for the fix! It would be nice if you could add minor version numbers for such changes (i.e. 1.4.1 for the current one) because it's easier to notice them when browsing your site.

In any case, it's also very interesting to see the very active development of alien Winboard the last week or so. It would be nice -when you guys have settled on the new features- if you and/or HGM somehow/somewhere can summarize the protocol changes wrt regular WinBoard. That would make it a bit easier for aspiring engine programmers (like me!) to make their own engines also use WinBoard for non-chess games.

Rein

[hgm]

Have you seen http://hgm.nubati.net/alien.html ?

The hover command is not yet described in there, but I try to keep it reasonably up to date, so if we decide it is satisfactory in its current form, I will add that soon as well.

[Rein Halbersma]

[quote="hgm"]Have you seen http://hgm.nubati.net/alien.html ?

The [b]hover[/b] command is not yet described in there, but I try to keep it reasonably up to date, so if we decide it is satisfactory in its current form, I will add that soon as well.[/quote]

OK, thanks, I knew your site of course, just hadn't really read it very carefully.

My draughts engine is a bitboard program, and it generates the moves as a set of 3 bitboards describing the changes in the black, white and king pieces. For updating the position, this is all you need, but for displaying the capture path, it is not enough! I guess I will have to write an adapter to my move generator to get this information before I can test the WinBoard alien edition.

Rein

[hgm]

But it sounds like you saved the original highlights. Because when I hovered and get out, it automatically reverts back to that one. The highlight I sent when getting a hover consisted of only those 8 surrounding squares. But second time hovering on the same square or a different red square doesn't work. I have to first put down the piece, hence getting a new lift and repreating the process...

Internally to WinBoard, the color-FEN received in a highlight command is split into legality and color-marker info, which go into separate arrays. The current version does save the color array when you first leave the from-square, but not the legality. A hover is only sent when you hover over a square that is red AND legal. So to get a second hover event, it is essential to not destroy the legality info of the square you hover over. If you highlighted it with lower-case color, it would have destroyed the legality. I used a much more primitive test than you, but I could get multiple hover events for the same lift.

I guess this is very error prone, so I will change WinBoard such that it also saves and restore the legality info.

Another question:
Do you currently use the comma suffix in put commands (indicating Ctrl is down)? I think it is a bit redundant, and consider dropping it from the protocol. When Ctrl was down during the put, the engine will be sent an immediate lift of the same square, rather than a usermove, and can easily conclude from it that another leg is going to follow.

The comma in the click command in the other direction must stay, of course.

[hgm]

OK, I uploaded a version that saves the legality array after lift, and restores it whenever you hover over a new square.

But it will still remain essential that the color-FEN used for putting the markers on the victims of the capture move you currently hover over will mark the to-Square as legal. Because that is where you are going to release the piece, while the markers are still present.

About variant alien:
What exactly is wrong with it? For me it seems to work fine, with some old version of NebiyuAlien I still had installed here. When I start it up, I see the Ultima setup. I can then use the Engine Settings menu to switch to Grand Chess, and the board nicely changes to 10x10+holdings with the Grand-Chess setup, when I click New Game. No problems at all.

[Daniel Shawul]

Internally to WinBoard, the color-FEN received in a highlight command is split into legality and color-marker info, which go into separate arrays. The current version does save the color array when you first leave the from-square, but not the legality. A hover is only sent when you hover over a square that is red AND legal. So to get a second hover event, it is essential to not destroy the legality info of the square you hover over. If you highlighted it with lower-case color, it would have destroyed the legality. I used a much more primitive test than you, but I could get multiple hover events for the same lift.

On recieving a hover, I construct a move from the sq and the lift_sq and make it on the highlight_board, then I determine which pieces need to go off board thereby constructing the highlight FEN, then I undo the move immediately. Are you saiying I should merge the two FENs for the highlighting when reciveing a hover ?

I guess this is very error prone, so I will change WinBoard such that it also saves and restore the legality info.

Agreed.

Another question:
Do you currently use the comma suffix in put commands (indicating Ctrl is down)? I think it is a bit redundant, and consider dropping it from the protocol. When Ctrl was down during the put, the engine will be sent an immediate lift of the same square, rather than a usermove, and can easily conclude from it that another leg is going to follow.

I handle the multi-leg moves same way I do the hover. I make the moves when receiving a put. I use the comma after the put square to check if the move is finished or not. When a move is finished, I prepare for a new lift command by copying the root board otherwise the next leg of the move will go from the old board i.e where the first leg left off... I think if the lift command had commas too, I can directly use that. Is there a comma after lifts ?

The comma in the click command in the other direction must stay, of course.