Jim Ablett: Problem with Lime KM 62

[H.G.Muller]

I was running Lime KM 62 JA with time-odds factor 8 (and 40 moves / 8 min), and everthing worked fine. Except that the time odds was just a bit larger than Lime could handle. So I lowered the factor to 7, so that against an opponent with time-odds factor 4 Lime would get 4/7 * 8 min = 4:35.

But now Lime does not use any time at all, and always moves instantly. Is Lime unable to handle min:sec in the -tc parameter?

[H.G.Muller]

Below is a section from the debug file (where I edited out all communication with the second engine). Note that there also is a cosmetic bug in the variants and myname feature, that fail to print a newline, so that the following features are not recognized. (This could also be solved by leaving out the feature keyword in the myname and done features.)

From the time stamps it can be seen that Lime thinks only 125ms about its first move. This is a bit short for a 40/1:09 game. And it also does this when you give it 40/4:35. It uses only 5 sec or so for the entire game, no matter what.

Code: Select all

15561 >first : xboard
protover 2
15561 <first :
15561 <first : numelem = 666666
15561 <first : Hash size 16000 kB
15561 <first :
15561 <first : Lime by Richard Allbert
15561 <first : ------------
15561 <first : Version v62 JA
15561 <first : 14-06-08 Build
15561 <first : Lime Homepage:
15561 <first : http://www.geocities.com/taciturn_lemon/index.htm
15561 <first :
15577 <first : Knightmate variant version [Jim Ablett 14-06-08]
15577 <first :
15577 <first :
15577 <first : numelem set to 32
15577 <first : numelem = 1333333
15577 <first : Hash size 32000 kB
15624 <first :
15624 <first : received protover
15624 <first : feature usermove=1
15624 >first : accepted usermove
15624 <first : feature ping=1
15624 >first : accepted ping
15624 <first : feature setboard=1
15624 >first : accepted setboard
15639 <first : feature reuse=1
15639 >first : accepted reuse
15639 <first : feature colors=0
15639 >first : accepted colors
15639 <first : feature name=0
15639 >first : accepted name
15639 <first : feature variants="knightmate"feature myname="Lime v62 by Richard Allbert"feature done=1
15639 >first : accepted variants
15639 >first : rejected feature myname
15639 >first : rejected feature done
15639 <first : received accepted
15639 <first : received accepted
15639 <first : received accepted
15639 <first : received accepted
15639 <first : received accepted
15639 <first : received accepted
15639 <first : received accepted
15639 <first :
15639 <first : error rejected feature myname
15639 <first :
15639 <first : error rejected feature done
25577 >first : new
random
25577 >first : variant knightmate
25577 >first : level 40 1:08 0
25577 >first : post
25577 >first : hard
25577 >first : easy
25577 >first : ping 1
25577 >first : force
StartChildProcess (dir="C:\cygwin\home\fairyengs\mskcp14_ja") "ms[k]cp.exe"
....
26091 <first : received new
26091 <first : received random
26091 <first :
26091 <first : error variant knightmate
26091 <first : received level
26091 <first : movestogo = 40
26091 <first : received post
26091 <first : received hard
26091 <first : received easy
26091 <first : received ping
26091 <first : pong 1
26091 <first : received force
...
36091 >first : computer
36091 >second: computer
TC string = '+40/8'
mps=40 tc=480000 inc=0
TC string = '+40/8'
mps=40 tc=480000 inc=0
time odds: 7.000000 1.000000
36091 >first : time 6857
36091 >first : otim 6857
book hit = (NULL)
36091 >first : go
nps: w=-1, b=-1
36091 <first : received computer
36091 <first : received time
36091 <first : time 6857
36091 <first :
36091 <first : received otim
36091 <first : otim 6857
36091 <first :
36091 <first : received go
36091 <first :
36091 <first : allocated -9.46416e+007
36091 <first : 1 14 0 37 d2d4
36091 <first : 2 0 0 132 d2d4 d7d5
36091 <first : 3 36 0 309 d2d4 d7d5 c1f4
36091 <first : 4 0 0 1638 d2d4 d7d5 c1f4 c8f5
36107 <first : 5 16 1 10695 e2e4 e7e6 d2d4
36138 <first : 6 4 4 34920 d2d4 d7d5 e2e3 c8f5 f1d3 g7g6 d3f5 g6f5
36216 <first : 7 18 12 99364 d2d4 d7d5 e2e3 c8f5 f1e2 b8c8 c1d2
36216 <first :
36216 <first : move d2d4

[Jim Ablett]

Hi Harm,

I'll take a look and fix if I can.
Many thanks for running the Knightmate tournament.

Jim.

[H.G.Muller]

I had a peek at the sources, (xboard.cpp), and I can definitely confirm that Lime never makes an attempt to read the level command as "level %d %d:%d %d". So I guess it will ignore it altogether when it encounters one.

[H.G.Muller]

Jim, is there any chance you could make a fast Lime KM compile for me soon that does not have this problem? I guess all that needs to be done to fix it is add a second sscanf in the processing of the level command (xboard.cpp) that does

sscanf(line, "level %d %d:%d %d", &mps, &base, &base, &inc);

as "base" does not seem to be used at all (Lime apparently purely relies on the time and otim command). But the colon prevents the other sscanf from reading past it, and thus prevents assignment to inc, which is left with a random (and apparently negative) value. With both sscanfs there one of the two would always succeed to fill inc, and the other could not touch it, while they both put the same value in mps.

[Jim Ablett]

Jim, is there any chance you could make a fast Lime KM compile for me soon that does not have this problem? I guess all that needs to be done to fix it is add a second sscanf in the processing of the level command (xboard.cpp) that does

sscanf(line, "level %d %d:%d %d", &mps, &base, &base, &inc);

as "base" does not seem to be used at all (Lime apparently purely relies on the time and otim command). But the colon prevents the other sscanf from reading past it, and thus prevents assignment to inc, which is left with a random (and apparently negative) value. With both sscanfs there one of the two would always succeed to fill inc, and the other could not touch it, while they both put the same value in mps.

Lime KM v62.1 JA by Richard Allbert

Win32 Intel compiler 11 pgo compile.

what's new:
Incremental time fix (H.G Muller.)

Download:
http://www.mediafire.com/?zm5zmk210me

Jim.