Problems with UCI protocol

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Problems with UCI protocol

Postby Wolfgang Gralke » 19 Jan 2005, 17:25

Hello everybody,
I'm writing an engine with UCI- and Winboard-Interface. In this moments I'm trying to establish comunication with Arena 1.1, ChessAssistent 7.0 and Fritz8.

The Winboard-part is going fine, but with the UCI-protocol I have problems.

I receive correctly the "uci"-command and answer with id's and a "uciok", but from there on the problems are beginning...

Arena sends a "position startpos e2e4" and a "go btime 30000".
The others start to play some moves (my engine has no brain, so the moves are made by some ghost) and send a "position startpos e2e4 e7e6 d2d4 d7d5" and a "go movetime 8000".

Now I have tried to answer with a "bestmove h7h6", but the board doesn?t react. As well I have tried to force a "stop"-command (pressing the spacebar) and answer after this with the bestmove, but still without reaction. After a "quit" my engine stops ejecution corectly.

Any idea what I'm doing wrong?

Many thanks in advance,
Wolfgang
Wolfgang Gralke
 

Re: Problems with UCI protocol

Postby Dann Corbit » 19 Jan 2005, 20:17

Wolfgang Gralke wrote:Hello everybody,
I'm writing an engine with UCI- and Winboard-Interface. In this moments I'm trying to establish comunication with Arena 1.1, ChessAssistent 7.0 and Fritz8.

The Winboard-part is going fine, but with the UCI-protocol I have problems.

I receive correctly the "uci"-command and answer with id's and a "uciok", but from there on the problems are beginning...

Arena sends a "position startpos e2e4" and a "go btime 30000".
The others start to play some moves (my engine has no brain, so the moves are made by some ghost) and send a "position startpos e2e4 e7e6 d2d4 d7d5" and a "go movetime 8000".

Now I have tried to answer with a "bestmove h7h6", but the board doesn?t react. As well I have tried to force a "stop"-command (pressing the spacebar) and answer after this with the bestmove, but still without reaction. After a "quit" my engine stops ejecution corectly.

Any idea what I'm doing wrong?

Many thanks in advance,
Wolfgang


Can you post the code you use to handle UCI input and output?
Dann Corbit
 

Problems with UCI protocol

Postby Wolfgang Gralke » 19 Jan 2005, 22:27

Hello, first many thanks for your reply.

The part of the source which answers to the go and stop-command is the following:

printf("bestmove ");
printf("%s",move->data);
printf("\n");


where move->data is an unsigned char *

Regards, WOlfgang
Wolfgang Gralke
 

Problems with UCI protocol

Postby Wolfgang Gralke » 19 Jan 2005, 22:52

Oh, I forgot, here are the part of incoming commands:

Code: Select all
void sendcommand (bstring bcommand){
   switch (UCI_MODE)
      {case 1:
         if(bstrncmp(bcommand, cstr2bstr("go"), 2)==0)
            UCI_Go(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("isready"), 7)==0)
            UCI_IsReady(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("stop"), 4)==0)
            UCI_Stop(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("position"), 8)==0)
            UCI_Position(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("quit"), 4)==0)
            UCI_Quit(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("ucinewgame"), 10)==0)
            UCI_Newgame(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("debug"), 5)==0)
            UCI_Debug(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("setoption"), 9)==0)
            UCI_SetOption(bcommand);
         if(bstrncmp(bcommand, cstr2bstr("ponderhit"), 9)==0)
            UCI_PonderHit(bcommand);
         break;
       case 2:
         if(bstrncmp(bcommand, cstr2bstr("go"), 2)==0)
         {
            WB_Go(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("ping"), 4)==0){
            bsetstr(bcommand, 1, cstr2bstr("o"), ' ');
            printf("%s\n",bcommand->data);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("usermove"), 8)==0)
         {
            WB_Usermove(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("protover"), 8)==0){
            WB_Protover(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("level"), 5)==0){
            WB_Level(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("new"), 3)==0){
            WB_New(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("force"), 5)==0){
            WB_Force(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("post"), 4)==0){
            WB_Post(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("nopost"), 6)==0){
            WB_NoPost(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("easy"), 4)==0){
            WB_Easy(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("hard"), 4)==0){
            WB_Hard(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("time"), 4)==0){
            WB_Time(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("otim"), 4)==0){
            WB_Otim(bcommand);
            break;
         }
         if(bstrncmp(bcommand, cstr2bstr("?"), 1)==0){
            WB_Interrogante(bcommand);
            break;
         }
         else WB_Move(bcommand);
         break;
       default:
         WB_Quit(bcommand);
      }
}
Wolfgang Gralke
 

Re: Problems with UCI protocol

Postby Fabien Letouzey » 20 Jan 2005, 10:02

[quote="Wolfgang Gralke"]Hello, first many thanks for your reply.

The part of the source which answers to the go and stop-command is the following:

printf("bestmove ");
printf("%s",move->data);
printf("\n");


where move->data is an unsigned char *

Regards, WOlfgang[/quote]

Make sure stdout is not buffered at all. Line buffering is supposed to work but does not on Windows for me (I don't want to know why).

Use only one printf per line where possible (as in your extract). Again your code is fine but better make things more simple.

If it still does not work, post a UCI-transaction log.

Good luck,

Fabien.
Fabien Letouzey
 
Posts: 110
Joined: 03 Dec 2004, 10:17
Location: France

Problems with UCI protocol

Postby Wolfgang Gralke » 20 Jan 2005, 12:05

Hello,

yes, I thought that buffering will give problems, so one of the first
instructions is:

setbuf(stdout, NULL);
setbuf(stdin, NULL);

setvbuf(stdout, NULL, _IONBF, 0);
setvbuf(stdin, NULL, _IONBF, 0);

And the three printf's are only the result of a try, after seeing that
the GUI was not showing reaction on my first

printf("bestmove %s\n",move->data);

So it seems the problem comes from another point.

Regards, Wolfgang
Wolfgang Gralke
 

Re: Problems with UCI protocol

Postby Jim Ablett » 20 Jan 2005, 15:22

Hi Wolfgang,
I don't see from your code that the engine is sending a 'readyok' after receiving an 'isready' command.
This must be sent when the engine has received an "isready" command .

Jim.
___________________________
http://jimablett.net63.net/
Jim Ablett
 
Posts: 721
Joined: 27 Sep 2004, 10:39
Location: Essex, England

Problems with UCI protocol

Postby Wolfgang Gralke » 20 Jan 2005, 16:50

Hello Jim,
yes I do so in the UCI_IsReady function:

int UCI_IsReady(bstring bcommand)
{
//this is used to synchronize the engine with the GUI. When the GUI has sent a
//command or multiple commands that can take some time to complete, this command
//can be used to wait for the engine to be ready again or to ping the engine to
//find out if it is still alive. E.g. this should be sent after setting the path
//to the tablebases as this can take some time. This command is also required once
//before the engine is asked to do any search to wait for the engine to finish
//initializing. This command must always be answered with "readyok" and can be sent
//also when the engine is calculating in which case the engine should also immediately
//answer with "readyok" without stopping the search.

printf("readyok\n");
return 1;
}

Because I'm writing in this moment only dummy-functions, there is nothing more to do then answering directly to the isready-command.

Later on there have to be a control that everything is initialized before sending it.

Regards, Wolfgang
Wolfgang Gralke
 

Debug-Output

Postby Wolfgang Gralke » 20 Jan 2005, 16:56

Hello everybody,
maybe it would help me if anybody could send me a logfile of a working engine in UCI-mode with any GUI with all in- and output.

The best would be of a game human-engine of some 5-10 moves.

Maybe so I can see better in which way I have to answer to the first inputs.

Thanks, Wolfgang
Wolfgang Gralke
 

Re: Problems with UCI protocol

Postby Anonymous » 20 Jan 2005, 20:07

You got already some answers. Make sure, you don't have strings without "\n" hanging around in stdout. My suggestion - write a logging printf, that will do the normal printf and also write it to a file, and show it here. It also has the advantage, that you can easily add an fflush(stdout) there (at *one* place). You can easily write such a function with the help of stdarg.h, vfprintf and vprintf.

Don't use setbuf and setvbuf together (but this is not your problem). In my experience, setting stdin to unbuffered mode did not help under Windows (when using single threaded polling input method). When polling input, one has to check stdin->_cnt anyway (of course this is system specific code). Out of curiosity - is your code C or C++? What is bstring?
When I'd see "if(bstrncmp(bcommand, cstr2bstr("ucinewgame"), 10)==0)", I'd get a bit nervous. What is cstr2bstr returning? In a static buffer? How long is the static buffer? Is it always long enough? Will I always count correct? (the compiler would be better at counting the 10)
And some minor nit picking about

...
printf("%s",move->data);
...
where move->data is an unsigned char *

move->data should be a char * and not an unsigned char * (it might be the same on some compilers/environments and it might be different on others).

Regards,
Dieter
Anonymous
 

Re: Problems with UCI protocol

Postby Wolfgang Gralke » 20 Jan 2005, 23:14

Hello Dieter,
many thanks for your advices. Today I'm in trouble, but tomorrow I will start to check the source on your tips.

Regards, Wolfgang
Wolfgang Gralke
 

Re: Problems with UCI protocol

Postby Wolfgang Gralke » 21 Jan 2005, 11:19

Hello,
it seems that really there was only one nasty printf without "\n".....
Now Arena responses and above is the output of the debug-window:

7871>1:uci
7921<1:id name ChessLobo 1.0
7921<1:id author Wolfgang Gralke
7921<1:option name Hash type spin default 8 min 1 max 128
7921<1:uciok
8121>1:setoption name Hash value 12
8121>1:isready
8642<1:readyok
9083*1*Start calc, move no: 1
9083>1:ucinewgame
9083>1:isready
9103<1:readyok
9193>1:position startpos moves e2e4
9193>1:go movetime 8000
9203<1:info depth 1 nodes 0
9203<1:bestmove h7h6
9203*1*Found move:h7-h6

Many thanks to all helpers.

Future troubles will be posted... :wink:

Wolfgang
Wolfgang Gralke
 

Difference in WB-protocol between Arena and Chess Assistant

Postby Wolfgang Gralke » 23 Jan 2005, 13:54

Hello again,
apart that Arena uses the protover 2, there seems to be another difference with Chess Assistant 7.0.

Above I send a protocol in both GUI's and Arena accepts my move e7e5 after the "?"-command, but Chess Assistant interrupts with the following information:
"Internal program error in chess engine ChessLobo: Move is not done"

Any suggestion?

Thanks, Wolfgang

ARENA 1.1:

> xboard
> protover 2
< feature ping=1 myname=ChessLobo 1.0 usermove=0 done=1
> accepted ping
> accepted myname
> accepted usermove
> ccepted done
> new
> random
> st 8
> post
> hard
> ping 1
< pong 1
> st 8
> new
> random
> st 8
> post
> hard
> ping 2
< pong 2
> e2e4
> ?
< move e7e5
> c2c3
> quit

Chess Assistant 7.0:

> xboard
> easy
> post
> new
> post
> level 0 5 0
> new
> post
> level 0 5 0
> time 29990
> otim 30000
> e2e4
> time 29447
> otim 30000
> ?
< move e7e5
> quit
Wolfgang Gralke
 

Re: Problems with UCI protocol

Postby Anonymous » 23 Jan 2005, 14:04

I don't see the problem with CA from your log. I am wondering one thing, however - doesn't Arena send time/otim?

You might want to try to send a (fake) PV. I believe some GUIs do/did need it.

Regards,
Dieter
Anonymous
 

Re: Problems with UCI protocol

Postby Wolfgang Gralke » 23 Jan 2005, 16:09

Hello,
the only time-command from Arena is "st 8".

After sending what you call a (fake) PV

printf("9 156 1084 48000 Nf3 Nc6 Nc3 Nf6\n");
printf("move e7e5\n");

Arena still accepts the move and shows the PV.

But Chess Assistant gives the same error-message as before.

Regards, Wolfgang
Wolfgang Gralke
 


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 21 guests