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@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.
Bill wrote:
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;
Where do you find it listed as required? The draft spec has this to say about required command:
| 6.1 Required Commands | All implementations are required to support the following commands: | | protocol_version | name | version | known_command | list_commands | quit | boardsize | clear_board | komi | play | genmove
the only reason that I had the "no undo command, undos are declined" logic is to help people get started faster.
That's fine with me, but I still think there should be a way to decline all undos even if it's implemented by the engine.
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).
Ok, then that's not much of an issue. I thought I had read somewhere that KGS could use a bit of hinting from the players regarding sekis, but maybe I misunderstood or misremembered.
(On a side not I don't quite agree that identifying sekis given knowledge of which groups are dead is easy. It's easy in common situations or when the dame are completely filled, but for more obscure positions it may require relatively sophisticated connection analysis. Or maybe you have come up with a smarter algorithm than I did some years ago. Are the details of the KGS algorithm published somewhere?)
I don't much like the first solution because it won't work until the engine is mature enough to correctly spot dead stones.
That's certainly true.
(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).
Well, I've put a lot of work into that.
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,
It should be noted that GNU Go can be expected to do somewhat worse on games where it's not one of the players. Not a big difference though.
plus the "kludge factor" of requiring gnugo be packaged with kgsGtp even if you want to use a different engine!
No, that would not be required. You could have a config variable "scoring_engine" similar to the existing "engine" and let the user provide it.
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.
Ah, if it's only internal KGS difficulties I'm confident you'll resolve them. :-)
/Gunnar
On Thu, 2004-01-01 at 10:50, Gunnar Farnebäck wrote:
Bill wrote:
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;
Where do you find it listed as required? The draft spec has this to say about required command:
Sorry, my mistake. I saw undo was in the "core play commands" section, and got that confused with "required". kgsGtp beta 3 will do undos by clearing the board if undo is unsupported or if an "undo" command fails.
That's fine with me, but I still think there should be a way to decline all undos even if it's implemented by the engine.
When rated games are added, all undos will be declined for rated games only. For free games, it seems not so important. I may add a "decline all undos" option at some point though.
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).
Ok, then that's not much of an issue. I thought I had read somewhere that KGS could use a bit of hinting from the players regarding sekis, but maybe I misunderstood or misremembered.
(On a side not I don't quite agree that identifying sekis given knowledge of which groups are dead is easy. It's easy in common situations or when the dame are completely filled, but for more obscure positions it may require relatively sophisticated connection analysis. Or maybe you have come up with a smarter algorithm than I did some years ago. Are the details of the KGS algorithm published somewhere?)
You *sometimes* have to fill dame, but not usually. The algorithm is described at http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=30F01D32... (it's an old rec.games.go post). An example of when filling dame is required is also present. A few people have said that this algorithm can't possibly work, but so far nobody has come up with a position that it judges incorrectly. CGoban 1 and CGoban 2 both use the same algorithm also, so to test it, just start up cgoban2, created a new SGF file, set up a position, and hit the "scoring tool". By the way that territory is marked, you will be able to see what it thinks is/is not a seki. You must mark dead stones correctly though - if there is a mistake there, it will often be confused about sekis. (You can also use cgoban 1, but I think I remember fixing a bug in the algorithm that would make the it go into an infinite loop after I stopped supporting cgoban 1).