@HG: auto moveing and lift,put,drag

[hgm]

WinBoard + Polyglot was faster than most GUIs that natively implement UCI. Only cutechess-cli was some 20% faster, IIRC. This could only be measured with sub-msec timing.

[hgm]

The MESSAGE can contain \n escapes, and it is upto the GUI implementation to make sure that works. (A nice GUI would respond to mouse clicks in this dialog, e.g. by pretending the user typed the clivked line.) For Shogi variants, there only has to be a 'promote? (y/n)'. The referee will finish the move (sendin it with the appropriate promo char).

In SAN double capitals would not be ambiguous. For FEN I was thinking about surrounding any multi-char piece name by commas. In protovol format it can just be everything upto the linefeed, after the coords. More than 25 board files is a bigger problem.

[Daniel Shawul]

The MESSAGE can contain \n escapes, and it is upto the GUI implementation to make sure that works. (A nice GUI would respond to mouse clicks in this dialog, e.g. by pretending the user typed the clivked line.) For Shogi variants, there only has to be a 'promote? (y/n)'. The referee will finish the move (sendin it with the appropriate promo char).

Ok but it is a bit awkward to send only the piece promotion character so why not the whole move. I can send him back the move again when I recieve the message with that tag. Anyway after implementing this I realized, we may not need the double click for promotions. If I do some work to see the only moves left are promotions then I can automatically send him the 'askuser' command. I suppose I can do that even in the case of long vs short versions of move but in the latte case the list could be long, however for promo we know for sure it is short.Btw the long vs short version happens also in checkers variants where one does not have to capture all pieces offered on his way.

In SAN double capitals would not be ambiguous. For FEN I was thinking about surrounding any multi-char piece name by commas. In protovol format it can just be everything upto the linefeed, after the coords. More than 25 board files is a bigger problem.

How about a {} instead of comma. Commas are often used as delimeters elsewhere. Don not parse anything in there as I may choose to include a number in like {q2} to mean queen for the 2nd player. Right now I use different letters to represent pieces in a 4-player chess. As to the files, many would prefer row-column format (both numbers) but we are used to the column being an alphabet. If we attach number to it then there would be difficulty to tell the file from the raw number in the move string. A hack could be using captial letters to extend file range to 52, but that requires a case sensitive more parser...

Two unrelated questions that I need help with:
a) If a user changes options of an engine like (pawn_value = 87), and then wants to use that engine in a tournament, does the engine has to be saved as a new one? Note the engine is restarted after each game so the change evaporates. Is the gui responsible for saving changes in options. Right now I am populating them with default values when the engine sends a feature option list at start up.

b) Similar to (a) but this concerns 'variant' option. Again to play a different variant should I send the "variant 10x10+0_checkers" at the start of each game from the gui-to-engines , or let it be handled same way as (a)

[hgm]

Anyway after implementing this I realized, we may not need the double click for promotions. If I do some work to see the only moves left are promotions then I can automatically send him the 'askuser' command.

Indeed, this is how I imagined it would work. As soon as the referee has seen all the square information from user clicks it can expect, if it needs additional info to uniquely specify the move (like a promotion choice), it can use askuser to start a dialog requesting that info.

Note that this is very much a referee issue: there are many ways a referee engine could work, leading to different behavior of the system towards the user, without the GUI ever realizing it. E.g. I could build an Amazons referee that requires the user to first click its own piece (ignoring any click on an opponent or empty square), highlights the possible destinations of that 'Amazon' on the board, then sends an 'Illegal move' response on any clicks not on one of the highlighted squares, and switches the highlights to the possible 'Arrow' desitinations after you specified a valid Amazon to-square, and finally wait for a click on those. Or I could make a referee that allows you to click the three involved squares in any order, and already play the move when there is enough info to unambiguously specify the move (e.g. after clicking an empty square that could only be reached from one square reachable by only a single Amazon). This is the choice of the referee author; he decides how he wants to use the protocol to define a user interface to his liking.

I suppose I can do that even in the case of long vs short versions of move but in the latte case the list could be long, however for promo we know for sure it is short.Btw the long vs short version happens also in checkers variants where one does not have to capture all pieces offered on his way.

Well, I guess the essence is that the referee sends the move to the GUI, and should do it in such a way that it achieves the desired effect on the displayed position, based on its knowledge of how the GUI reacts to moves. This could be variant dependent. E.g. in 'variant checkers' WB empties any square jumped over. If that is not what you want, you either should not implement the game as variant checkers, or (if only in exceptional cases it is not wanted), you could specify a multi-leg detour over the wrong-color squares, so you don't jump over anything, yet reach the desied to-square. An alternative would be to implement it as 'variant multi', and let the referee specify a capture by first jumping on the victim, and then to the to-square. (This is actually how my dumb ChessLive! viewer implements e.p. capture in Chess.) In the worst case you could use 'variant alien', and send the complete board update after every move.

Problems arise if you want to use the move sent by the referee also for notation purposes (when the user saves PGN). In variant alien, where the move is always overruled by the board update, so you could send any move you want, as the board update does not affect the move notation.

How about a {} instead of comma. Commas are often used as delimeters elsewhere.

Well, If most of the pieces are double character, I would like to avoid having two separator characters between them. Which is what you would get whith the braces: {ST}{AB}{VO}{FD}. But I guess you cannot mix single and double char names that way. So it could be better to just use a colon as an escape to announce a two-letter name follows. E.g. if you want a piece called Baron, abbreviated as BN, to replace the Queen in the FIDE setup you could write rnb:bnkbnr. With long stretches of two-letter names you would then see them separated by colons, like :ST:AB:VO:FD.

Don not parse anything in there as I may choose to include a number in like {q2} to mean queen for the 2nd player. Right now I use different letters to represent pieces in a 4-player chess. As to the files, many would prefer row-column format (both numbers) but we are used to the column being an alphabet. If we attach number to it then there would be difficulty to tell the file from the raw number in the move string. A hack could be using captial letters to extend file range to 52, but that requires a case sensitive more parser...

Yes, and it would cause ambiguity with the piece name in SAN. The problem is disambiguation. With single-letter files, in a move like Ngf3 the g must be a disambiguator. Double digits are no problem, even as disambiguator, because in N13g11 the 13 must a disambiguator: numeric coordinates will never be next to each other. But using double-letter file IDs like the letters are digits (i.e. continue with aa, ab, ac after z) would cause such ambiguities. Unless all file names have the same number of letters. But that is bad for backward compatibility.

Two unrelated questions that I need help with:
a) If a user changes options of an engine like (pawn_value = 87), and then wants to use that engine in a tournament, does the engine has to be saved as a new one? Note the engine is restarted after each game so the change evaporates. Is the gui responsible for saving changes in options. Right now I am populating them with default values when the engine sends a feature option list at start up.

Unfortunately this does not work yet as it should, and the GUI is completely oblivious of option changes. This has grown historically because only UCI engines had options, and they were saved in the polyglot.ini files. Ideally it should be possible to save the settings in the engine list (in the winboard.ini file), by inclusing a /firstOption="..." command with the engine. Currently you would have to edit that option by hand into the list, like /firstOptions="pawn_value=87".

b) Similar to (a) but this concerns 'variant' option. Again to play a different variant should I send the "variant 10x10+0_checkers" at the start of each game from the gui-to-engines , or let it be handled same way as (a)

The preferred way of selecting a variant is to let the GUI be aware of the variant, and order the engine to play it (i.e. send 10x10+0_checkers). The method where the engine has a private option that selects what is truly played (e.g. Cambodian Chess when you set it to variant makruk), and then forces the corresponding board size upon the GUI through the setup command is really a kludge. The GUI would put the wrong variant name in the PGN, for example. (If it is only the board size that is different, this is not an issue, though, as the GUI would eventually become aware of that.) This might impact how the user has to select the variant, though (e.g. set nr of ranks and files in the New Variant dialog to 10 when he chooses Checkers there, rather than use the Engine Settings dialog).

I guess ideally we should do away with predefined variant names, and let the GUI reshape its New Variant dialog to whatever the engine said in its variants feature. Even if this contains unknown names. Then the engine could simply print feature variants="international_draughts", and the GUI would make it appear in the menu, and send variant international_draughts to the engine when the user selects it. Problem is that it would have no idea that this is a sub-variant of checkers. Either the engine should specify that as additional parameter in the setup command (i.e. where it says 10x10 now for board size it should say 10x10_checkers), or it should already specify it in the variants feature (introducing the concept of sub-variant, like feature variants="spartan,checkers:intl_draughts,gothic,makruk:cambodian,...". The advantage of that could be that the GUI can use the info to format its New Variant dialog.

[Daniel Shawul]

Indeed, this is how I imagined it would work. As soon as the referee has seen all the square information from user clicks it can expect, if it needs additional info to uniquely specify the move (like a promotion choice), it can use askuser to start a dialog requesting that info.

Note that this is very much a referee issue: there are many ways a referee engine could work, leading to different behavior of the system towards the user, without the GUI ever realizing it. E.g. I could build an Amazons referee that requires the user to first click its own piece (ignoring any click on an opponent or empty square), highlights the possible destinations of that 'Amazon' on the board, then sends an 'Illegal move' response on any clicks not on one of the highlighted squares, and switches the highlights to the possible 'Arrow' desitinations after you specified a valid Amazon to-square, and finally wait for a click on those. Or I could make a referee that allows you to click the three involved squares in any order, and already play the move when there is enough info to unambiguously specify the move (e.g. after clicking an empty square that could only be reached from one square reachable by only a single Amazon). This is the choice of the referee author; he decides how he wants to use the protocol to define a user interface to his liking.

That is a whole new perspective I haven't thought of. Indeed one can customize referees for the game as required. Thus we don't need to worry about making referee-gui communication the same for every game.

Well, I guess the essence is that the referee sends the move to the GUI, and should do it in such a way that it achieves the desired effect on the displayed position, based on its knowledge of how the GUI reacts to moves. This could be variant dependent. E.g. in 'variant checkers' WB empties any square jumped over. If that is not what you want, you either should not implement the game as variant checkers, or (if only in exceptional cases it is not wanted), you could specify a multi-leg detour over the wrong-color squares, so you don't jump over anything, yet reach the desied to-square. An alternative would be to implement it as 'variant multi', and let the referee specify a capture by first jumping on the victim, and then to the to-square. (This is actually how my dumb ChessLive! viewer implements e.p. capture in Chess.) In the worst case you could use 'variant alien', and send the complete board update after every move.

Problems arise if you want to use the move sent by the referee also for notation purposes (when the user saves PGN). In variant alien, where the move is always overruled by the board update, so you could send any move you want, as the board update does not affect the move notation.

I think if a beautiful move representation is required (SAN) it can be added to the "setup" command with the last move made. Style 12 of ICS sends the move in different formats , and I use the SAN style when recording games in PGN. But I very much prefer coordinate notation for other communications.

Well, If most of the pieces are double character, I would like to avoid having two separator characters between them. Which is what you would get whith the braces: {ST}{AB}{VO}{FD}. But I guess you cannot mix single and double char names that way. So it could be better to just use a colon as an escape to announce a two-letter name follows. E.g. if you want a piece called Baron, abbreviated as BN, to replace the Queen in the FIDE setup you could write rnb:bnkbnr. With long stretches of two-letter names you would then see them separated by colons, like :ST:AB:VO:FD.

Agreed. Comma is the delimeter for a popular database format (CSV), which I happen to have EPD collections with it. Colon is a good choice and redundunt closing-opening delimeter should be avoided .

Yes, and it would cause ambiguity with the piece name in SAN. The problem is disambiguation. With single-letter files, in a move like Ngf3 the g must be a disambiguator. Double digits are no problem, even as disambiguator, because in N13g11 the 13 must a disambiguator: numeric coordinates will never be next to each other. But using double-letter file IDs like the letters are digits (i.e. continue with aa, ab, ac after z) would cause such ambiguities. Unless all file names have the same number of letters. But that is bad for backward compatibility.

I know SAN is the "standard" move notation for chess, but I could care less about it in other games. It is so game specific and convoluted that it should be dropped specially when you consider the alien protocol. What is suitable is a either e2e4 or row-column format. But I understand we have to keep backward compatibility.

Unfortunately this does not work yet as it should, and the GUI is completely oblivious of option changes. This has grown historically because only UCI engines had options, and they were saved in the polyglot.ini files. Ideally it should be possible to save the settings in the engine list (in the winboard.ini file), by inclusing a /firstOption="..." command with the engine. Currently you would have to edit that option by hand into the list, like /firstOptions="pawn_value=87".

Too bad. Isn't there a better place to store settings file for an application (windows registry ??). Android has a whole new take on this and each app is endowed with a set of preferences that are kept by the OS ,and displayed in a nice "common for all" user interface that greatly speeds up developement.
So I could pretty much get it done if the convention is for the GUI to store engine option changes rather than loading default values.

The preferred way of selecting a variant is to let the GUI be aware of the variant, and order the engine to play it (i.e. send 10x10+0_checkers). The method where the engine has a private option that selects what is truly played (e.g. Cambodian Chess when you set it to variant makruk), and then forces the corresponding board size upon the GUI through the setup command is really a kludge. The GUI would put the wrong variant name in the PGN, for example. (If it is only the board size that is different, this is not an issue, though, as the GUI would eventually become aware of that.) This might impact how the user has to select the variant, though (e.g. set nr of ranks and files in the New Variant dialog to 10 when he chooses Checkers there, rather than use the Engine Settings dialog).

I guess ideally we should do away with predefined variant names, and let the GUI reshape its New Variant dialog to whatever the engine said in its variants feature. Even if this contains unknown names. Then the engine could simply print feature variants="international_draughts", and the GUI would make it appear in the menu, and send variant international_draughts to the engine when the user selects it. Problem is that it would have no idea that this is a sub-variant of checkers. Either the engine should specify that as additional parameter in the setup command (i.e. where it says 10x10 now for board size it should say 10x10_checkers), or it should already specify it in the variants feature (introducing the concept of sub-variant, like feature variants="spartan,checkers:intl_draughts,gothic,makruk:cambodian,...". The advantage of that could be that the GUI can use the info to format its New Variant dialog.

I prefer that way too because then user would not have to change the variant manually for each participant engine. The user (i.e GUI) sets the referees variant options then that variant will be sent automatically to the currenlty loaded engines either by the Referee or the GUI. I am not sure of the details but I agree this should be the prefered method.