[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Wishlist for playing programs on KGS
I've read your proposal, and all the responses so far
and I like your suggestion.
I would be perfectly happy if you implemented it as is.
You are not actually providing a game end function however.
This is fine with me, because I like that you are providing
a nice way to communicate with an engine WHILE it's running
and even for the engine to respond with a text message.
The game end procedure can be implemented without any of
the changes you propose, just by the engine author providing
a private way to communicate to his engine to stop the game
after clear board. So Pete's point is well taken. But
I like that you are providing a general mechanism to handle
this, so I don't have to create my own mechanism.
On Wednesday 12 October 2005 7:54 pm, William M. Shubert wrote:
> On Thu, 2005-10-13 at 10:55 +1300, Peter McKenzie wrote:
> > 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.
> > cheers,
> > Peter
> I think you maybe only want a way to stop the engine after a game. But I
> have gotten many requests from other users for a way to query the engine
> of information while it is running. The way I see it, this solves two
> problems at once. Yes, it would be some more work for the engine authors
> who only want to be able to shut their engine down at the end of a game,
> but I have trouble believing much more (how much? one line to detect a
> shutdown request; one to set a flag; one to check the flag after a game
> ends - three lines of code maybe?) So in the end, it just seems to make
> sense to push all such decisions down into the engine, where people can
> do whatever they like.
> computer-go mailing list
computer-go mailing list