[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] gnugo / gGo interaction badness
From: |
Peter Strempel |
Subject: |
Re: [gnugo-devel] gnugo / gGo interaction badness |
Date: |
Thu, 23 Jan 2003 22:18:13 +0100 |
User-agent: |
Mutt/1.4i |
On Thu, Jan 23, 2003 at 10:04:12PM +0100, Gunnar Farneback wrote:
> > 1) Difficulties with boardsize.
> This is gGo's fault. It shouldn't ignore the error message from the
> engine. (It may be possible to increase GNU Go's upper limit by
> modifying the MAX_BOARD value in engine/gnugo.h and recompile. This
> has not been tested, however. Higher value than 31 definitely won't
> work but I'm unsure whether there are further limitations.)
Indeed, gGo ignores any error after telling GTP the board size. I will fix
this for the next release. Actually, I never got the idea to play anything
except 19x19, 13x13 or 9x9 myself yet. Why do you try such odd stuff? :)
> > 2) Timing Issues
In my eyes it makes not so much sense to play fast games with GNU Go. I
prefer to give the AI some time to calculate and enjoy a better game. If I
want to play fast games, I play a human opponent. So I did not implement
very much of reasonable time control in the gGo interface. If time runs out,
the game ends. Thats basically all of the time support gGo implements. But
I really don't see the requirement to add more sophisticated support.
I know about the --autolevel option. Users can configure this in the GNU Go
parameters in the gGo configuration, so it is possible to use. I just dont
want to use it as default setting.
About the other issues and GTP 2, I am following the GTP mailing list. Once
a new GNU Go release is available wich uses GTP 2, I will adjust gGo where
it is required. But as long the latest stable release of GNU Go is not yet
using GTP 2, I won't change anything. Most users are not interested in
development versions, and I want to provide a working interface for the
stable GNU Go release.
Peter