WB protocol and variant names

[Daniel Shawul]

Especially the latter was a bit tricky, because WinBoard has so many modes to enter promotion moves. With -sweepPromotions false you should get an old-fashioned promotion popup for any move to a purple square. This is not too convenient for engine-defined variants, however, as the standard popup does not contain all piece types, and might mention them by names not usual for the variant. (Like Chancellor for Champion and Archbishop for Wizzard.)

With -sweepPromotions true you can always do a click-click move to a purple square, in which case you can make a non-static click on the to-square to adjust the piece on the to-square to the desired type before you release the mouse button for the to-click. With a static click it should take a default piece, but this is sort of ill-defined in non-standard variants, as it has no idea what the most valuable piece is.

The most tricky to get working was the detour underpromotion, which is normally triggered when you grab a Pawn on 7th rank. Pulling it back before you move it to and release it on the promotion square then can be used to alter the type from the default promotion type. The problem with this mode is that it can only work if you know by the from-square alone that there is going to be a promotion. For standard Pawns on the 7th rank that is indeed the case. But this mode cannot be used for Shogi promotions of other pieces, which only have some promotion move but also many non-promoting moves.

I just tried this new mode of promotion and it works well specially for the standard promotion on the last rank. Pulling back or clicking the to-square, I can select the promotion piece. Pulling back also works during positions editing and it is a nice way of acceleration piece selection. As you said for shogi, it can be problematic since promotion may not be forced. There a piece can promote to exactly one type, so all that is needed is to figure out if a piece promotes or not. Since now you have various ways of handling promotions, you may also want to try out the 'movelist' method I mentioned before. If a promotion is not optional it is not clear what color to use for the square. Right now I color it purple anyway but promotion in shogi is optional. The movelist method avoids this problem and also offers better handling of multi-legged moves.

Btw, why do you send this transparency FEN. In Ultima you color the victims green, when one hovers above a to-square marked as a capture (in red). So it would be logical to color the promotion square green rather than transparent if you hover over it. Although for replacement capture it is not very useful to indicate the victim at all, as it should be clear to anyone that what was there must disappear (as we cannot stack pieces). Perhaps it would be better to have the engine not respond at all to a hover command for a move that only captures what is on the hover square (and certainly if it captures nothing at all, and the hover command was only sent because you hovered over an empty promotion square).

I guess that when the engine indicates capture victims in green when you hover above the to-square, the GUI could use this info when you release the piece there to perform all 'side-effect captures' even without receiving any board updates. When the engine moves, however, there would be no highlights, so this is probably of little value. And board updates would still be needed for side effects other than removal of pieces.

I will fix this. But I don't have alien version of winboard that allows me to play ultima with current Nebiyu. The last one I had is 4.5 and looks pretty old compared to the current version 4.8.

[hgm]

Indeed, the Alien Edition has not co-evolved with the standard edition. I could not easily rebase it on the master branch, because it was already too different, and I got lots of conflicts.

What exactly is it that prevents the latest Nebiyu from working on the Alien Edition? Is it just this variant naming, which is not implemented in the Alien Edition yet? I suppose you could temporarily replace "ultima" by "8x8+0_alien" in Nebiyu's Alien.ini file to work around that. Are there any other problems?

BTW, since some of the variants NebiyuAlien supports are multi-player variants, how do you encode positions for these games? What do you think of Don's proposal to encode sides separately, in another thread?

[Daniel Shawul]

Indeed, the Alien Edition has not co-evolved with the standard edition. I could not easily rebase it on the master branch, because it was already too different, and I got lots of conflicts.

What exactly is it that prevents the latest Nebiyu from working on the Alien Edition? Is it just this variant naming, which is not implemented in the Alien Edition yet? I suppose you could temporarily replace "ultima" by "8x8+0_alien" in Nebiyu's Alien.ini file to work around that. Are there any other problems?

It seems better to forget that all in all and import features. Changing the name and then putting ulima first in the game defintion worked but somehow the highlights are missing. What is the option name to turn that on/off ?

BTW, since some of the variants NebiyuAlien supports are multi-player variants, how do you encode positions for these games? What do you think of Don's proposal to encode sides separately, in another thread?

I thought about that scheme but decided to conform to current Winboard format and use a different letter for the 3rd/4th player. Rightnow it does not display them correctly because I forgot to change pieceToCharTable properly for triple/quadruple chess. Once you correct that you will see proper display of the board with the correct pieces for the third player. Ofcourse it would be better if each player's FEN are sent separately but didn't have much option at the time. With 4 or more players you would run out of chars, so the pawn shape I used for the third player looked like a horse! So definately the correct way to handle it is to send them separately, so it is better extend the FEN format while still having support for the old way. The FENs could be sent concatenated as one string and this will allow re-use of ASCIII characters, by coloring each player differently.

[Daniel Shawul]

This is what I send back to winboard on getting clicks.

• No move => Illegal move
• One move => Send that only move
• Clicked on Same square => Send move list
• Else => Highlight Fen

So if the user clicks on the same square as previous, it will be shown a move list with a popup from which to select from. He can do this when anytime it gets tired of clicking squares and want to just select from the available move lists. It occurs to me you can implement this in your current pull back scheme for promotion. Just send two clicks and it will get you the available promotion moves. For pawn at e7, two 'click e7' s will get you a movelist.

Code: Select all

if(count == 0) {
		print("Illegal move\n");
		clicks_recieved = 0;
	} else if(count == 1) {
		MOV_STR(only_move,mv_str);
		print(mv_str);
		clicks_recieved = 0;
	} else if(clicked_again) {
		print("movelist %d %s\n",count,movelist);
		clicks_recieved = 0;
	} else {
		char fen[MAX_STR];
		construct_color_fen(fen,colorfen);
		print("highlight %s\n",fen);
	}

[hgm]

It seems better to forget that all in all and import features. Changing the name and then putting ulima first in the game defintion worked but somehow the highlights are missing. What is the option name to turn that on/off ?

There are several options that affect highlighting. For one, legality checking has to be off, or WinBoard will trust its own move generator. You have to check 'Highlight dragging' in the General Options dialog, and there is a persistent option -showTargetSquares true that also has to be set (or Highlight Dragging would do something else).

[hgm]

It seems better to forget that all in all and import features. Changing the name and then putting ulima first in the game defintion worked but somehow the highlights are missing. What is the option name to turn that on/off ?

There are several options that affect highlighting. For one, legality checking has to be off, or WinBoard will trust its own move generator. You have to check 'Highlight dragging' in the General Options dialog, and there is a persistent option -showTargetSquares true that also has to be set (or Highlight Dragging would do something else).

[hgm]

Daniel, can you check your PMs?

[Daniel Shawul]

One problem I had was that the purple square is no longer purple at that point. WinBoard also sends hover command to the engine when the mouse pointer enters a purple square (as I did not define separate colors for promotions with and without capture), and as a matter of fact I did test this on a promotion that was also a capture. Nebiyu then sent a highlight command which did color the to-square 'transparent' (T). And of course it still is in that state when you release the mouse button to put the piece on that square, as you must do that before you leave the square again. So I had to introduce a flag that forces promotion without testing the square color, set at the point where it became clear all moves would be promotions (which is needed to trigger this mode in the first place).

Btw, why do you send this transparency FEN. In Ultima you color the victims green, when one hovers above a to-square marked as a capture (in red). So it would be logical to color the promotion square green rather than transparent if you hover over it. Although for replacement capture it is not very useful to indicate the victim at all, as it should be clear to anyone that what was there must disappear (as we cannot stack pieces). Perhaps it would be better to have the engine not respond at all to a hover command for a move that only captures what is on the hover square (and certainly if it captures nothing at all, and the hover command was only sent because you hovered over an empty promotion square).

I rember you told me to mark the to-square with 'transparent' for legality checking. When I did not do that , the hover overwrites the red-square and has to be colored by some color (transpernt) to allow the move. Anyway I have fixed it such that it ignores the hover command when there are no victims as in ultima/atomic. Unless there is a promotion with a side effect now everything should work as expected. Also I noticed that highlight with coordinator-type moves were not working correctly so I fixed that as well.

[hgm]

I rember you told me to mark the to-square with 'transparent' for legality checking. When I did not do that , the hover overwrites the red-square and has to be colored by some color (transpernt) to allow the move.

Yes, that is true, but this was a problem only if you wanted to send a highlight command to mark some other squares. If there is nothing at all that needs to be marked, there is no need to send a highlight command in the first place, and then you would also not disturb the red marker.

Responding to lift / put / hover commands is not mandatory. WinBoard does not even check if such a command is outstanding when it receives a highlight command; it just processes the command. So in a sense the lift/put/hover and highlight commands are completely independent, and one can be used without the other. Engines can also mark squares spontaneously, at any time they want. (They could for example use this to highlight the move on which they are pondering or analyzing, but you could also imagine a 'teaching engine' that explains stuff by directly accessing the sound card, or displaying text in the engine-output window, and uses highlight commands to back up the explanation with board markers.) Or they could use put/lift for the purpose of implementing one-click moving or implied side effects (e.g. non-standard castling) with 'click' commands, and refrain from highlighting.