Hi,
I would like to propose a new optional command subset for graphical user interfaces.
The main problem it tries to access is the excessive number of play and undo commands when navigating in games, which slow down GUIs and are not very human-readable.
Here are the proposed new commands:
play_sequence <color> <move> [<color> <move> [...]]
Example: play_sequence b c3 w g7 b g3
Like the play command, but can take a sequence of moves. The development version of GoGui already uses this command, if supported by the engine. This command requires that the engine has no limit on the command length, because the argument length can become large.
undo_multiple <int>
Example: undo_multiple 3
Like the undo command, but with an argument that tells the number of moves to undo. GoGui presently uses the GNU Go gg-undo extension command, if supported by the engine. The command should have a different name from the simple undo command to avoid problems with engines that support only simple undo and don't check if the command has an argument.
setup <color>|empty <point> [<point> [...]]
Example: setup b c3 g7
Setup stones. GoGui presently sends setup stones as play commands. This has two big disadvantages. First, a play command will kill blocks with no liberties, a setup stone does not. Second, the engine does not know, that the setup stones are not regular moves. For example, if the engine has a command to save SGF traces of a search (like GNU Go and Explorer have), and the search is done in a setup position, then the setup stones show up as moves in the SGF trace and it is difficult to find the actual start position. Color empty means removing a stone. If the engine supports the setup command, then undo should undo the last play or setup command.
- Markus
Markus wrote:
play_sequence <color> <move> [<color> <move> [...]]
Example: play_sequence b c3 w g7 b g3
Like the play command, but can take a sequence of moves. The development version of GoGui already uses this command, if supported by the engine. This command requires that the engine has no limit on the command length, because the argument length can become large.
How does your implementation handle errors? If there's an illegal move, does it try to tell which move was illegal? Does it restore the board state to before the command or does it leave the successful moves played?
Like the undo command, but with an argument that tells the number of moves to undo. GoGui presently uses the GNU Go gg-undo extension command, if supported by the engine.
Notice that gg-undo, as implemented in GNU Go, does not try to restore the board state on failure.
The command should have a different name from the simple undo command to avoid problems with engines that support only simple undo and don't check if the command has an argument.
Agreed.
setup <color>|empty <point> [<point> [...]]
Example: setup b c3 g7
Setup stones. GoGui presently sends setup stones as play commands. This has two big disadvantages. First, a play command will kill blocks with no liberties, a setup stone does not.
I've always found this ugly in the sgf specification, as it allows creating an invalid position.
Second, the engine does not know, that the setup stones are not regular moves. For example, if the engine has a command to save SGF traces of a search (like GNU Go and Explorer have), and the search is done in a setup position, then the setup stones show up as moves in the SGF trace and it is difficult to find the actual start position.
This is a good point.
Color empty means removing a stone. If the engine supports the setup command, then undo should undo the last play or setup command.
Ouch, I find undoing anything other than regular moves very ugly, which is why handicap stones (or clear_board) can't be undone. Is there any good use case for this, other than to be able to faithfully navigate an arbitrary sgf file?
/Gunnar
On Wednesday 01 March 2006 14:19, Gunnar Farneb�ck wrote:
How does your implementation handle errors? If there's an illegal move, does it try to tell which move was illegal? Does it restore the board state to before the command or does it leave the successful moves played?
I implemented play_sequence only in the Explorer program so far. If the sequence contains an illegal move, the error response gives information about the illegal move and move number. If the command fails, the original board state is restored. This is easy to implement and avoids that the GUI is out of sync with the program.
Notice that gg-undo, as implemented in GNU Go, does not try to restore the board state on failure.
GoGui never requests more moves to undo than there were actually played. I don't think there is any reason why a Go program that implements gg-undo should fail to undo a valid number of moves.
Ouch, I find undoing anything other than regular moves very ugly, which is why handicap stones (or clear_board) can't be undone. Is there any good use case for this, other than to be able to faithfully navigate an arbitrary sgf file?
No other reason. I found it ugly too, this is why GoGui originally only supported setup stones in the root node. But the fact is that SGF files exist that contain setup stones after moves were played (e.g. problem collections) and I want to be able to load these files and synchronize the Go program with any position in the file. At present, GoGui just assumes, that setup stones don't kill anything when transmitted as play commands, but this is not a good solution and could cause undetected error, which is even more ugly.
- Markus
It would be nice to be able to have opponent information communicated to the engine via GTP. For instance when looking through my log files or saving a game, it would be a great convenience if the PROGRAM knew who it was playing.
This would be a nice compliment to the "name" command. After a controller gets both names from the programs, it could transmit them to the opponent.
So we could have: "opponent_name"
We could also have "opponent_rank" if the controller has access to this information.
I will probably add these commands for CGOS. I guess they will become private extensions with "cgos-" as a prefix. If you were to adapt these into the standard I could change things over.
- Don
On Wed, 2006-03-01 at 22:19 +0100, Gunnar Farnebäck wrote:
Markus wrote:
play_sequence <color> <move> [<color> <move> [...]]
Example: play_sequence b c3 w g7 b g3
Like the play command, but can take a sequence of moves. The development version of GoGui already uses this command, if supported by the engine. This command requires that the engine has no limit on the command length, because the argument length can become large.
How does your implementation handle errors? If there's an illegal move, does it try to tell which move was illegal? Does it restore the board state to before the command or does it leave the successful moves played?
Like the undo command, but with an argument that tells the number of moves to undo. GoGui presently uses the GNU Go gg-undo extension command, if supported by the engine.
Notice that gg-undo, as implemented in GNU Go, does not try to restore the board state on failure.
The command should have a different name from the simple undo command to avoid problems with engines that support only simple undo and don't check if the command has an argument.
Agreed.
setup <color>|empty <point> [<point> [...]]
Example: setup b c3 g7
Setup stones. GoGui presently sends setup stones as play commands. This has two big disadvantages. First, a play command will kill blocks with no liberties, a setup stone does not.
I've always found this ugly in the sgf specification, as it allows creating an invalid position.
Second, the engine does not know, that the setup stones are not regular moves. For example, if the engine has a command to save SGF traces of a search (like GNU Go and Explorer have), and the search is done in a setup position, then the setup stones show up as moves in the SGF trace and it is difficult to find the actual start position.
This is a good point.
Color empty means removing a stone. If the engine supports the setup command, then undo should undo the last play or setup command.
Ouch, I find undoing anything other than regular moves very ugly, which is why handicap stones (or clear_board) can't be undone. Is there any good use case for this, other than to be able to faithfully navigate an arbitrary sgf file?
/Gunnar _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
Markus Enzenberger wrote:
I would like to propose a new optional command subset for graphical user interfaces.
The main problem it tries to access is the excessive number of play and undo commands when navigating in games, which slow down GUIs and are not very human-readable.
Why does it slow down GUIs? I understand the readability part, but not the GUI one. (Quarry uses sequences to resume games only, though, so my experience here is limited.)
Here are the proposed new commands:
play_sequence <color> <move> [<color> <move> [...]]
Example: play_sequence b c3 w g7 b g3
As Gunnar has already pointed out, there are potential problems WRT to state after an error in the middle.
undo_multiple <int>
Example: undo_multiple 3
Like the undo command, but with an argument that tells the number of moves to undo. GoGui presently uses the GNU Go gg-undo extension command, if supported by the engine. The command should have a different name from the simple undo command to avoid problems with engines that support only simple undo and don't check if the command has an argument.
Likewise, we need to think about the behavior on failure. GNU Go's behavior is certainly not something to follow as the final state is undefined if an error occurs...
setup <color>|empty <point> [<point> [...]]
Example: setup b c3 g7
Setup stones. [...]
If this command is added, we _must_ stress that the clients must never expect that an engine will accept an invalid position. I'm sure most engines have no use for invalid positions permitted by SGF (I understand why SGF permits them, they are useful for e.g. explaining game rules, but for a game-playing program there is no reason to support such positions.)
There is also command `setup_board' used in at least two programs (not generally available.) It is probably not so nice for Go as it is for smaller-board games. It has single argument with run-together values of all board squares (sth. `-' for empty, `x' for black, `o' for white) listed left-to-right, top-to-bottom. Unfortunately, for Go this normally means 361 characters long argument, which is not quite as nice as 100 or even 64 characters for Amazons and Arimaa.
In general, this discussion is kind of meaningless unless GTP 2 is released or a fork (doh...) is made. As some of you may know, there are also ideas (already implemented) of expanding GTP to other games as the protocol seems really useful.
Paul
-
Don Dailey -
Gunnar Farneb�ck -
Markus Enzenberger -
Paul Pogonyshev