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