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