gtp January 2004

gtp@lists.lysator.liu.se

6 participants
7 discussions

Time settings
by Olof Fridh 26 Jan '04

26 Jan '04

Hi. I have been running a gnugo bot on kgs thru the kgsGtp bridge for a while now and have noticed a few things. The problem lies in the fact that the gtp protocol only supports Canadian overtime while Japanese style byo-yomi happens to be the timesystem of choice for many kgs users. As how the kgsGtp bridge works now is to try to tell the engine how much total time it got left. But if the move is made within one time period the total time left will not became lower and this breaks the time control function in gnugo making it think it always made the last move on 0 sec, because of this it might not lower its level even then it should and ends up loosing on time. Also early in 19x19 games the total time reported (main time + period time * periods) might be so low that gnugo lowers its strength level way down to 0 while it might be able to play the whole game on level 10. I am not sure if this should be considered an error in the gtp specs for not including support for Japanese style byo-yomi or in the kgsGtp bridge for using the time system in the way it does or in gnugo's time control function (or in all of them) but as I know the people responsible for all 3 are reading this list I thought it would be correct place to post it. My personal opinion is that support for other time systems then Canadian overtime should be included in the gtp specs but until is does maybe kgs should use a private extension for this. TIA Olof Fridh

1 0

kgsGtp "ranked game rules" & new release
by William M. Shubert 08 Jan '04

08 Jan '04

A new beta (beta 3) of kgsGtp is at http://www.igoweb.org/~wms/upload/ as before. Unless bugs are found, this will be the final version. It fixes some bugs in beta2, and it also knows how to play rated games on the server and prevent people from cheating it. You cannot use this yet, though! The current KGS server does not know about GTP clients, so it will not allow them to play rated! If anybody wants to test ranked games, let me know. I'm especially interested in the kgs-genmove_cleanup command, since the engine that I have doesn't use that command I couldn't test it very well. I can set up a beta version of server 2.5.6, then we can arrange a time for to connect and test. The rules that I settled on for playing rated games are: 1. "Normal" accounts cannot play rated games via GTP, only via human players. 2. Admins can set an account to "Ranked Robot" authorization. With this authorization, the GTP engine can play ranked, and humans cannot. 3. A kgsGtp engine will refuse to start a new game with a player if there is already an unfinished rated games against that player. 4. To play rated games, an engine must support the final_game_status_list command. 5. The kgsGtp engine will refuse to play rated unless the rules of the game exactly match what is specified in the configuration file and/or command line. 6. If the engine and the human disagree on the status of living and dead stones at the end of the game, one of two things will happen: If the game uses non-Japanese rules and the engine supports the kgs-genmove_cleanup command, then the engine will recommend that the human press "undo", after which the engine will get kgs-genmove_cleanup commands until it passes. If the game uses Japanese rules or the engine does not support kgs-genmove_cleanup, then the engine will simply refuse to score the game unless the human agrees. 7. It is recommended that engines that play rated games support the kgs-genmove_cleanup command and play non-Japanese rules games. It is especially important that your engine support that command if it isn't so good at computing living/dead groups at the end of the game, otherwise you will get a lot of angry opponents left standing around in an unfinished game! Do these look reasonable? I was trying to stop cheating both for the sake of the engine (so it gets an accurate estimate of its own strength) and for the sake of the users (so that it isn't easy to use engines to fake a different strength than you have). -- William M. Shubert <wms(a)igoweb.org>

3 3

java.lang.NoClassDefFoundError: kgsGtp/jar
by Marco Baan 05 Jan '04

05 Jan '04

Hey there, I've been trying to get kgsGtp up and running and after tons of work to get java installed decently i get: [root@Fallen] kgsGtp/> /usr/local/jdk1.4.2/jre/bin/java kgsGtp.jar Exception in thread "main" java.lang.NoClassDefFoundError: kgsGtp/jar As you can see it's jdk 1.4.2, it runs on FreeBSD 5.1 and it doesnt have any issues with other programs. (browsers or other jar files.) Any clue as to what i am doing wrong or is buggy ? Greets, -- Marco Baan Talkers are no good doers. -- William Shakespeare, "Henry VI"

1 0

Resolving end of game issues
by William M. Shubert 04 Jan '04

04 Jan '04

The one issue I'd really like to fix for kgsGtp is how to solve problems when the game is over, and the human and the engine (or for that matter the two engines) disagree over which stones are dead. GnuGo on NNGS solves this problem by abandoning the game if there is a disagreement. Since GnuGo very rarely makes mistakes in judging life and death at the end of the game, this works well for it, since only once in a while must a human inspect the game record and resign a game that the engine was wrong in. It can still cause trouble though; on KGS, leaving too many rated games without finishing them gets you tagged as an escaper, so it could make people very angry if an engine sits there and won't finish a game, leaving the human with the choice of either accepting a score tha they think is wrong, or leaving the game and getting possibly tagged as an escaper. But, it seems that the problem is solvable in another way. If you are using non-Japanese rules, then you can always just resume the game and play it out to decide which stones are dead. If there was a genmove alternative, like "genmove_cleanup" or some such, that would not pass until all dead stones were removed from the board, then rated games would work well. Basically, if the human and the computer disagree on which stones are dead, just resume the game and start sending "genmove_cleanup" commands. Once "genmove_cleanup" passes, we know that there are no dead stones left on the board. If the human thinks that there are still dead stones left, then they can resume the game again and try to kill the stones. Eventually, a point will be reached where any reasonable person and engine will agree with each other and end the game. This seems nice, engines such as gnugo will then very rarely need "genmove_cleanup", but less mature engines can still play rated games, they just annoy the humans sometimes by requiring play until all the dead stones are gone to score correctly. Does this sound like a reasonable solution? If any engine author is willing to try it, I could add it as a kgsGtp-specific command. Engines that support this command would be able to play rated on KGS, with no issues about cheating. On the other hand, if none of the engine authors are interested, then there's not much point in me adding it. -- William M. Shubert <wms(a)igoweb.org>

4 4

My comments
by Don Dailey 03 Jan '04

03 Jan '04

Hi William, A few things, none of these are big deals but would be nice ... There is one thing that's a bit of a nuisance to me, there is no graceful exit strategy. The problem is that I sometimes want to bring the client down, but it is playing a game. Out of courtesy I like to let the game finish, but sometimes another game starts before I have a chance to kill the server. I also noticed that once in a while my process does not go away although that is a minor nuisance. (That could be because of the way I kill it.) If the client could respond to some signal that says, finish up the game you're playing and exit, that would be helpful but not a big deal. Is there a prefered way to stop the client? I have had a few players suggest that the program should make comments during the game, such as evaluation or something. Some chess programs do this on chess servers. GTP is not a very natural protocol for things (and it's not very important to me) but I would use it if you had it. The KSG client could prompt for comments after it moves. One thing I would really like to see is for the client to log any talking going on. Then I would ask players for useful comments during the game and I would study the comments. As far as game ending, I think what you seem to planning is good. I thought about suggesting tromp/talyor rules which have no ambiguities whatsoever at the end of the game. In tromp/taylor the game is scores after 2 consecutive passes, no matter what. Any dead stones are considered alive if you were foolish enough to pass before capturing them. I don't think this is a good protocol for a server where lots of humans play unless some kind of agreement protocol was worked out, and this is no better than what you are planning. By the way, my program supports undo, but I have disabled it on the server because my program takes some advantage of game history. If I allow undo or you simulate it, you cripple my program, so hopefully there will be an option to decline undo. Thanks, Don

1 0

Re: GTP client for KGS ready
by William M. Shubert 02 Jan '04

02 Jan '04

Thanks for your feedback Gunnar. I just put up a new release, "beta2", that corrects several of the issues that you pointed out. It's at the same http://www.igoweb.org/~wms/upload URL. Comments below, with one longer followup comment in another post. (PS - Apologies for sending my previous post as HTML mail, I know that it messes up archives and bundled messages). On Thu, 2004-01-01 at 03:00, gtp-request(a)lists.lysator.liu.se wrote: > | undo > | If your engine supports this command, you will get it as > | normal. If your engine does not list undo as a response to > | list_commands, then any undos that your opponents request will > | be denied, so this command is optional from kgsGtp's point of > | view. > > With some extra work undo can be simulated by clear_board + play > commands. On the other hand, allowing undo at all has potential > cheating problems. GNU Go on NNGS never accepts any undo, for good and > for bad. Even if the engine supports undo it would be good to have a > config option not to accept undos. Good point. I may get to this some time, but for now I'll just hope that most engine authors have "undo" implemented. I think it shoud be common, it is listed as one of the "required" commands; the only reason that I had the "no undo command, undos are declined" logic is to help people get started faster. > | final_status_list > | After the game enters scoring kgsGtp will send this command. If > | you return a list of dead stones, then kgsGtp will mark those > | on the board. If you return an error, then kgsGtp will not mark > | any stones dead and your opponent will have to do that instead. > > Do you ever ask for seki stones? I seem to recall that KGS tries to > identify such when Japanese rules are used. KGS never needs to ask for seki stones. Once you know which stones are alive and which are dead, finding seki eyes becomes quite simple, so the server does that automatically if it has to (that is, if you are using Japanese rules). > | clear_board > | Used after each game to start over. If you don't support this, > | then you will be limited to one game for each time you run > | kgsGtp. > > If you don't already do that, clear_board should be issued also at the > start of the first game. Although many engines will start with an > empty board that is not guaranteed. Thanks for pointing this out. The new version does a clear_board before each game (if clear_board is a supported command, otherwise it just hopes for the best then exits after one game). > | * Free games only. Right now it has no way to argue over dead stones > | at the end of the game, so if your opponent changes the stones > | that you mark dead, kgsGtp simply accepts the changes. This makes > | it very easy to cheat a kgsGtp player, so only free games are > | allowed right now. > > GNU Go on NNGS insists on adjourning the game if the opponent does not > agree on dead stones. The opponent is left with the options to a) > accept GNU Go's judgment, b) resign, or c) complain to me that GNU Go > gets it wrong (and then I either resign the game or fix the bug, or > both). The latter happens occasionally but we're talking of far less > than 1% of the games. > > This is probably not practical for kgsGTP and the understanding of > life and death status will of course vary significantly between > different engines. What could be interesting is an option to ask > another engine, e.g. GNU Go, for the final status. I don't much like the first solution because it won't work until the engine is mature enough to correctly spot dead stones. (I'm impressed with gnugo, it sometimes takes a long time to come up with the list of dead stones, but in the games I played it was right even in fairly tricky situations). As for using GNU go as the final arbiter, that's possible but still has the problem of what to do in the <1% of the time that GNU go is wrong, plus the "kludge factor" of requiring gnugo be packaged with kgsGtp even if you want to use a different engine! I've got an idea to try for this, but it's long, I'll put it in another post. > | * Engine cannot refuse game settings. If somebody sets up a game > | that is 9×9 and your engine only supports 19×19, all you can do is > | resign immediately. Eventually I hope to add a kgs-specific > | command that asks the engine if the settings are OK, then accepts > | the game only if it agrees. > > In the specific case of board size, kgsGTP should at least check > whether boardsize returns an error before accepting the game. Good idea. The new version will do exactly what you recommend. > | * No way to resume games. > > I assume there are no principal difficulties implementing this and > just a question of time. Well, the one issue was that I didn't yet code it up, the other was that a bug in the server made the most logical way for people to try to resume games, fail. The server does not let you resume a game if your opponent is already playing in another; a bug in the server also prevented you from resuming if your opponent is looking for a game! Since the kgsGtp client is *always* looking for a game when it's not playing, loading was difficult. The beta2 kgsGtp release can resume games, but until a new KGS server version is released it will still be difficult to use. -- William M. Shubert <wms(a)igoweb.org>

2 2

GTP client for KGS ready
by William M. Shubert 31 Dec '03

31 Dec '03

I just finished up a GTP client for KGS. With it, any GTP go engine can connect to KGS and play there. This has been a problem for KGS for a long time - one of the big advantages that IGS and NNGS have with their open protocol is of course that people could easily write a GTP (or any other kind of client for it). Now that I've finally written the GTP client for KGS, I wish I'd done it sooner - it was much easier than I'd expected. I've been using GnuGo to test with. About 20 games have been played in the past 24 hours, so it seems that the major bugs are gone. I have not tested with any other engine, so problems may show up due to small variations in the way that GTP is used. If you have a GTP go engine, please go to http://www.igoweb.org/~wms/upload/ and try downloading it. I'd be really interested in what people think of it. -- William M. Shubert <wms(a)igoweb.org>

3 2

2025

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 January 2004