gtp

gtp@lists.lysator.liu.se

164 discussions

GtpEngine 1.4
by Markus Enzenberger 08 Mar '07

08 Mar '07

GtpEngine version 1.4 has been released. GtpEngine is a C++ implementation of the Go Text Protocol released under the LGPL. The major new feature is support for interrupting commands. The source code is available from: http://www.cs.ualberta.ca/~emarkus/amigogtp/ - Markus

2 6

GtpEngine 1.1
by Markus Enzenberger 09 Jan '07

09 Jan '07

I updated the C++ GTP implementation GtpEngine to version 1.1, which includes support for pondering (thinking during the opponent's time). The source code is available here: http://www.cs.ualberta.ca/~emarkus/amigogtp/ - Markus

1 0

GtpEngine and AmiGoGtp
by Markus Enzenberger 06 Jan '07

06 Jan '07

The GTP C++ implementation of the Explorer Go program has been released unter the Lesser GNU General Public License with friendly permission of Martin Mueller. It is available here: http://www.cs.ualberta.ca/~emarkus/amigogtp/ There is also a new GTP wrapper for the AmiGo Go program. - Markus

1 0

2 questions about kgsGtp
by Patrick van der Wal 28 Nov '06

28 Nov '06

Hi, I'm new on this list so I don't know if I'm asking these questions at the right place. I've been working to get my own bot to work on KGS. So far things are going well but I've been having 2 problems. The first one is about the connection of my engine to kgsGtp. At the moment I'm doing this through the stdin/stdout method and kgsGtp starts up my exe. However, this is not how I want it to work. I want to communicate over a tcp/ip port to kgsGtp using the "engine.port=<port#>" command in the ini file. When I try this, I get the following messages in my log file: 18-nov-2006 20:27:00 org.igoweb.kgs.client.gtp.GtpClient main FINER: Waiting for a connection on port 4000 18-nov-2006 20:28:22 org.igoweb.kgs.client.gtp.GtpClient main FINER: Got connection. Closing server socket. So it seems to get a connection but right after that kgsGtp disconnects. Anybody has an idea why? The second issue is about resigning a game. When I'm playing against my bot on KGS I want to resign the game at some point. So I press the 'Resign' button and the game is ended on my side. However, I see no message being sent to my engine about the resignation. My engine just keeps on thinking until the opponent's time runs out. Shouldn't kgsGtp send a "play <color> resign" statement? Any help is welcome. Thanks in advance, Patrick.

2 1

Version 2 release?
by Evan Daniel 10 Aug '06

10 Aug '06

Any idea when version 2 will be finalized? Evan

2 1

Re: [gtp] Play command
by Markus Enzenberger 07 Apr '06

07 Apr '06

On Thursday 06 April 2006 20:24, William M. Shubert wrote: > On Thu, 2006-04-06 at 18:17 -0600, Markus Enzenberger wrote: > > I think it would be good enough, if the specification mentions, that a Go > > engine does not necessarily have to be able to play moves by the same > > color in a row, to keep GTP controllers from making this assumption > > without real necessity. Most tasks, like playing games, do not need > > support for non-alternating play. > > How do you handle free placement of handicap stones? NeuroGo can initialize its data structures from a position, which is good enough for setup positions (if no moves are played yet) and fixed handicap. I had no special code for free handicap placement, I always considered free handicap to be the same as the opponent answering your moves with a pass for a certain number of times in the beginning of the game.

1 0

Re: [gtp] Play command
by Markus Enzenberger 07 Apr '06

07 Apr '06

On Wednesday 05 April 2006 18:45, Evan Daniel wrote: > I would like to suggest that GTP version 3 have some way of allowing > engines to support only alternating play. > > I could fake the support by inserting a pass move in such cases, but > that seems inelegant. Similarly, I'd rather not add a function that > plays illegal moves. I faced the same problem: old versions of NeuroGo did not support non-alternating play. There are a few things that you can do a bit more efficiently if you make this assumption. I think it would be good enough, if the specification mentions, that a Go engine does not necessarily have to be able to play moves by the same color in a row, to keep GTP controllers from making this assumption without real necessity. Most tasks, like playing games, do not need support for non-alternating play. - Markus

1 0

Play command
by Evan Daniel 06 Apr '06

06 Apr '06

I'm in the process of rewriting GoFigure, and currently my board library implements a very strict Tromp-Taylor ruleset. Among other things, this means it requires alternating play. It would be possible to extend the library to support non-alternating play, but I'm not yet sure what the right way to do that is. I would like to suggest that GTP version 3 have some way of allowing engines to support only alternating play. I could fake the support by inserting a pass move in such cases, but that seems inelegant. Similarly, I'd rather not add a function that plays illegal moves. Evan Daniel

1 0

Finalizing GTP version 2?
by Gunnar Farneb�ck 02 Apr '06

02 Apr '06

Recently there has been an increasing interest in adding more official commands to GTP. Considering that the current draft specification has been stable (to choose a positive word) for a very long time now I don't think it's a good idea to make those changes to GTP version 2. Some people may wonder why it's still a draft and with the risk of embarrassing myself I can reveal that mainly it has been stalled on me wanting to track down information for the Credits section but not finding enough inspiration to actually do that. To get things moving again I propose finalizing the version 2 specification by the radical approach of simply removing the empty Examples and Credits sections from the draft, then opening up development of version 3. Does anybody see a problem with this plan? Is there any fatal flaw in the specification draft that has to be fixed first? In an attempt to help development of version 3 along I've set up a Wiki at http://trac.gnugo.org/gtp. It's currently bare but you can help filling it with relevant information yourselves. /Gunnar

3 4

Re: [computer-go] More GTP questions
by Gunnar Farneb�ck 31 Mar '06

31 Mar '06

[Moved from computer-go.] Mark Boon wrote: > At the moment only category 2 is of interest now, the other two > categories I could deal with myself. I'll list them below. Most of > them are related to the state of the game. Although the GTP > definition explicitly states a certain amount of state is expected to > be kept by the engine (like the number of stones captured, history > etc.), it doesnt provide commands to query this state. Although it is > not strictly necessary to provide means to extract this information, > it can be very convenient. After all, for an engine to work > meaningfully, it needs to implement a minimal administration of the > game and knowledge about legal moves. By exposing this knowledge, a > front-end could trust the engine to provide this information > correctly, thereby reducing the complexity of the front-end. This is what I also thought once. In fact there's an entire outcommented section "Introspective Commands" in the LaTeX source for the second draft, containing the commands all_legal, is_legal, captures, color, countlib, findlib, get_handicap, get_komi, list_stones, query_boardsize. Today I'm more doubtful. The idea of a thin front-end doesn't seem all that attractive. I'd rather add board logic to a front-end than increasing the minimum requirements on the engines to interface to it. Still some commands of this kind may be worth standardizing. New people to the GTP list should be aware that the plan is to finalize GTP version 2 as is so this discussion applies to version 3. > # set_rules > arguments rules (string) > effects the engine will return moves and score according to these > rules. > output none > fails when rules are not supported by the engine > comments The engine needs to know by which rules the game is played, > it seems strange this command is missing. There are two reasons why this is missing. The first one is that it's not clear how to best design this and how to specify the different rules. The second one is that it's reasonable to assume that rules are relatively fixed, so that it's feasible to set them by other means, e.g. command line options or GUI settings, for a whole session. (This reasoning obviously didn't take the multiple rulesets of KGS into account.) Anyway, I consider this a priority item for GTP version 3 but I don't think the right approach is to enumerate a number of rulesets by name. Rather I'd like to have the rules defined by their properties, e.g. suicide allowed or disallowed, type of ko rule, territory or area scoring, points for seki or not, and so on. > # captured_by_black > arguments none > effects none > output number of stones captured by the black player (int) > fails never > > # captured_by_white > arguments none > effects none > output number of stones captured by the white player (int) > fails never GNU Go has the (private) command captures which takes a color as argument. I'm somewhat doubtful about the usefulness of this. > # is_legal > arguments vertex color > effects none > output whether a move played by color would be a legal move (boolean) > fails never This is also available in GNU Go but as has already been pointed out it takes a "move" which is "color vertex" as argument. I think this is worth standardizing. > # next_move_nr > arguments none > effects none > output number of the next move to be played (int) > fails never I think the front-end is better suited to keep track of this than the engine. Nobody has even bothered implementing a command of this kind in GNU Go, which is some kind of sign. (There are 136 commands in GNU Go, asking the engine for all sorts of things.) > # color_to_move > arguments none > effects none > output color of the next move to be played (b|w) > fails never As pointed out before the engine is not expected to have an opinion about who plays when and in any case this is mostly redundant with the following command (with the possible exception of the first move). > # last_move > arguments none > effects none > output vertex color (b|w) of the move that was last played > fails never Implemented in GNU Go (but with a "move" as output). I'm somewhat doubtful about the value of standardizing this. For GNU Go it's mostly used in conjunction with loadsgf. > # nr_passes > arguments none > effects none > output number of consecutive passes played (int) > fails never This is trivial for the controller to keep track of. > # adjust_status > arguments vertex* status (alive,seki or dead) > effects the next call to final_score will return the score with the > status adjusted at the list of points passed > output none > fails never I'm negative. If the controller wants to do fancy stuff with scoring it can count the score itself. > # thinking > arguments none > effects none > output whether the engine is currently thinking about its next move > (boolean) > fails never > comment this can be very useful to prevent undesirable re-entry of > the engine This absolutely doesn't fit with the GTP communication model. As commands must be responded to in order, this can't be answered in time to be useful. Rather if a genmove command has been issued but has not had a response the engine is thinking on a move, otherwise not. /Gunnar

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp