gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] time_settings


From: Gunnar Farneback
Subject: Re: [gnugo-devel] time_settings
Date: Wed, 21 May 2003 23:49:49 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Max wrote:
> Do the time_settings and time_left commands make anything with Gnugo 3.3.16
> ?

No.

> It seems to understand them since it sends a "=" output but it often
> runs out of time or play too much quickly according the -L
> parameter.

Yes, it does understand the commands. It just doesn't act on the
information. See the FIXMEs in interface/play_gtp.c for
gtp_time_settings() and gtp_time_left():

 * FIXME: This command stores the time settings but no one ever takes notice.

 * FIXME: This command does not take any action.

> Must the time_left command  be sent before or after the genmove command ?

The natural time to send a time_left command would be after the
genmove command has been answered and after making a move for the
opponent.

Evan wrote:
> I believe that the time settings only have an effect if you run gnugo with
> the --autolevel option.

No the --autolevel options and corresponding code is currently
unrelated to the gtp timing commands.

Below is a patch for TODO about this.

/Gunnar

Index: TODO
===================================================================
RCS file: /cvsroot/gnugo/gnugo/TODO,v
retrieving revision 1.10
diff -u -r1.10 TODO
--- TODO        30 Mar 2002 16:38:50 -0000      1.10
+++ TODO        21 May 2003 21:47:49 -0000
@@ -82,6 +82,12 @@
 
  * Support for constraints in the eye patterns.
 
+ * Implement handling of timing information through the GTP commands
+   time_settings and time_left for real. Currently the information is
+   received but then ignored. This may involve integration with the
+   current autolevel code in engine/clock.c or writing new level
+   adjustment code.
+
  * Create a paradigm for handling other types of ko (approach move ko,
    multi-step ko, etc) and then write code that handles them. 
    (Difficult!)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]