[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Wishlist for playing programs on KGS
Hello list,
although beeing no active Go Progam developer,
just an occasional GNU Go operator on KGS,
here's my vote for both the ideas of
Chris Fant and Mike Bazynski.
The elegance of Mike's suggested new gtp command kgs-another_game
lies in the the fact that it hands the decision over on the engine, allowing for
a self-contained and simple design.
Re-Reading the config file between games, as Chris Fant suggest, on the
other hand would pave the way to any desired degree of responsiveness
and flexibility of the engine. Not only a gracious quit could be implemented
but also changing requested game params, opponent, gameNotes, talk etc.
Also a simple log-switching could be made possible by changing the logFile
parameter if kgsgtp would recognize the change and open another file.
To push the idea even further ... and adressing #5 plus the idea of some
talking "ELIZA-GO" AI-engine or kibitz program already mentioned on this list:
Imagine kgsgtp reading the file after each move and a new "speak" config
parameter that causes a sentence to be printed into the game log - et voilà.
Some possible problems should however be adressed beforehand
regarding the config file approach:
- At least on my WinXP system some version of kgsgtp seems to lock the config file,
making it impossible to overwrite it between games/moves. Is that something that
could be changed easily or is it inherent to a java app?
- The config parameters should be divided into a class that is interpreted only once
at kgsgtp startup ("Session Parameters"), a bunch of "Game Parameters" and
(if desired) the one or two commands that get interpreted between moves.
(E. g. I don't think it would be desirable nor even practical from a GTP point of view
to change the engine between moves ... changing the login between games would
imply a new session ... hopping around the rooms between games would be questionable
imho too ... at least for an engine ... Better to require a new session for that!)
- For a start, only very few commands would be needed in the "Game Parameters":
`open´, `opponent´ and perhaps `tournament´ would be sufficient. But imho a
new parameter `numGames´ would be more flexible and cleaner - because of the
already "overloaded" meaning of combinations of `open´ and `opponent´.
(Detailed proposal for numGames:
- numGames missing or =-1 would mean play as long as nothing else happens
(still re-reading the config file ...);
- numGames positive and not changed between games would cause to play n games and quit
- numGames positive and changed would mean just the same but reset game counter to new value
- numGames=0 would mean: no more games after the current one.
Note that kgsgtp would not attempt to write down the new game counter values into the config file;
it would rather log it in it's log file.)
- One last proposal - if WMS was to adopt the config file approach ...
Designing the whole "Game Parameter" thing as Optional could be simpler - concerning the locking issue -
and easier to understand:
Having a new parameter in the usual config file `gameOptFile´ that defaults to st. like `kgsgtp_game_opions´
This file would be probed (by default in the same directory kgsgtp found it's ordinary config file) between
games and parsed if present. All "Game Parameters" found there would override the ones in the ordinary
file. So it's simplest use would be not using it until one wants to stop the session by means of `numGames=0´.
happy Go - ing
Heiner Spies
> --- Ursprüngliche Nachricht ---
> Von: Chris Fant <chrisfant@xxxxxxxxxxxxxxxxx>
> An: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> Betreff: Re: [computer-go] Wishlist for playing programs on KGS
> Datum: Sun, 9 Oct 2005 00:52:55 -0400
>
> Why not just re-read the configuration file between each game? That
> would not require adding any new commands. Then we can just set
> open=f when we want to stop playing.
>
> On 10/7/05, William M. Shubert <wms@xxxxxxxxxxxxxxxxx> wrote:
> > #1 will be fixed in the next major realease of the server (all non-
> > private games will be viewable).
> >
> > #2 is indeed something that needs to be added to kgsGtp, but the problem
> > is, how to get that message in? kgsGtp currently talks to KGS via its
> > protocol, and to the engine via GTP streams, then it also writes its
> > logs to stderr. There is no other input. Where should the command to
> > exit after the end of the next game come from? Suggestions are welcome.
> > Chris' suggestion of refusing to support clear_board works, sure, but it
> > seems like a bit of a hack to me and if somebody has a better suggestion
> > I'd like to hear it.
> >
> > On Thu, 2005-10-06 at 00:54 -0400, Chris Fant wrote:
> > > #2 has a fairly easiy solution which I'm pretty sure I have mentioned
> > > on this list before. Here it is again:
> > >
> > > Don't support the clear_board command. Your program will terminate
> > > when the game is over. You then have full control over whether it
> > > restarts or not.
> > >
> > > In my setup, I can click on start.bat to start the engine and stop.bat
> > > to neglect to restart the engine after the game is over.
> > >
> > >
> > > On 10/5/05, Peter McKenzie <peter.mckenzie@xxxxxxxxxxxxxxxxx> wrote:
> > > > In general I've found KGS a good place to run my computer program.
> There is
> > > > a good range of opponents available and it is very easy to get up
> and
> > > > running with kgtGTP. And of course Nick's monthly tournaments are
> an added
> > > > bonus.
> > > >
> > > > There are a few things that are less than ideal though, so here is
> my
> > > > wishlist of things that I'd like changed/fixed (in rough order of
> priority).
> > > > Interested to see what others think.
> > > >
> > > > 1. Unable to examine unfinished games.
> > > >
> > > > This is a basic restriction of KGS that I find quite annoying. Say
> I leave
> > > > my program running on KGS overnight and go to check up on it in the
> morning.
> > > > I will usually see that it has one or more unfinished games in its
> history.
> > > > I have no way of viewing the unfinished games and therefore no way
> of
> > > > knowing why the games were unfinished. I suspect that the opponent
> has
> > > > usually escaped in a losing position but that is just speculation.
> It could
> > > > have been a scoring dispute for example.
> > > >
> > > > I realise that this 'feature' is designed to stop cheating but to me
> the
> > > > disadvantages seem to outweigh this factor. A determined person
> could still
> > > > cheat anyway. If it really is undesirable to let the escaper load
> and view
> > > > an unfinished game, then how about at least letting their opponent
> load the
> > > > game?
> > > >
> > > > 2. No easy way to tell kgsGTP to exit once the current game is
> finished.
> > > >
> > > > I tend to find myself sitting around waiting for my program to
> finish a game
> > > > before I disconnect it. The problem can be worse if my program is
> playing a
> > > > match vs another program, as they start another game practically
> > > > immediately.
> > > >
> > > > I'd like to be able to enter a command into kgsGTP (a simple text
> command)
> > > > that would tell kgsGTP to disconnect from KGS once the current game
> is
> > > > finished.
> >
> >
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/