[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Wishlist for playing programs on KGS
My feeling is that we are getting carried away with all this flexibility.
Top priority should be a simple way of exiting after the current game. I believe that the idea of sending a command, via chat text, is a solution that will satisfy this requirement for most people.
This functionality should reside in kgsGTP for two reasons:
1) It is the natural place for it. Most (all?) other logic regarding dis/connecting to the server and selecting games to play currently resides in kgsGTP.
2) If the option of forwarding the command to the engine is used, then the engine author would have to implement the logic to:
a) parse the command
b) somehow authenticate the command (i.e. check the user)
c) update some internal "last game" state to indicate that it should exit after the current game
d) exit when a clear_board command is received and the engine is in a "last game" state (see (c))
This logic would end up being implemented in the vast majority of engines. To my way of thinking it is less than ideal that all engine authors have to do this, when it could have been simply solved once in kgsGTP.
If a command is added which allows direct communicaiton with the engine then that is great too. But I think it is of secondary importance.
On 10/13/05, William M. Shubert <wms@xxxxxxxxxxxxxxxxx> wrote:
On Wed, 2005-10-12 at 09:43 -0400, Chris Fant wrote:
> Won't people who are watching the game and the commands being sent ot
> the engine quickly learn the syntax and start toying with the engine
> on thier own? One way around this is to specify a command user in the
> config file. Only commands from that particular user will be send to
> the engine.
You didn't read carefully enough! The user is sent as the first part of
the message. So the engine is free to choose which users to ignore, and
which to pay attention to...or perhaps have privileged users that can
send any command, other users can do only a limited subset...whatever.
If kgsGtp does the filtering then this flexibility is lost.
> On 10/12/05, Michał Bażyński <bazik@xxxxxxxxxxxxxxxxx
> > >-----Original Message-----
> > >From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> > >[mailto:
computer-go-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of
> > >William M. Shubert
> > >
> > >My solution:
> > > 3. When a game ends, the engine will get a clear board request.
> > > Since clear boards never appear in-game (as long as
> > >you support
> > > the undo command that is!), an engine can treat this
> > >command as
> > > a "the game is over" signal. When the engine exits,
> > >kgsGtp logs
> > > out, so if an engine decides though chat or any other
> > >mechanism
> > > that it should log out when the game ends, it can simply exit
> > > when it gets the next clear board request (or exit
> > >right now if
> > > the last request that it received was a clear board).
> > > * Adding an extra GTP command to query the engine "should we do
> > > another game?" also lacks flexibility, and doesn't seem to
> > > simplify engine programming any over the chatting proposal.
> > > Really instead of this, the engine could simply exit when it
> > > gets a request to clear the board, that would do
> > >about the same
> > > thing.
> > i love being able to hear user text, and being able to answer, but as far as
> > logging off problem is concerned this has a feeling of a dirty hack added
> > last minute under time pressure then a real fix. instead of adding a new
> > command for this purpose we try to use the fact that there's a command, used
> > for something else, that for some users can be used for telling the game has
> > ended. i do not allow undo's so for me it is not a fix at all.
> > additionally, the mechanism assumes i have a java computer with
> > windows/xwindows ready, and that i want to stop playing now, and not some
> > time in the future. all in all i do not see how can this be claimed to be
> > more flexible then a specialized command. (in fact the chatting mechanism
> > has nothing to do with game-end problem - i can tell my program i want to
> > stop playing in any number of ways, without the chatting thing. the proposed
> > fix to end playing problem is 'stop disallowing undos, log-off when you get
> > clear_board [or simply wait for time_settings, or board_size, or
> > game_rules]).
> > so in one word chatting mechnism is cool and would be great to have, but my
> > feeling is that the problem of logging off is not proposed to be solved at
> > all.
> > regards
> > mike bazynski
> > _______________________________________________
> > computer-go mailing list
> > http://www.computer-go.org/mailman/listinfo/computer-go/
> computer-go mailing list
computer-go mailing list
computer-go mailing list