Page 1 of 1
Problems with UCI protocol
Posted:
19 Jan 2005, 17:25
by Wolfgang Gralke
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
Re: Problems with UCI protocol
Posted:
19 Jan 2005, 20:17
by Dann Corbit
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?
Problems with UCI protocol
Posted:
19 Jan 2005, 22:27
by 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
Problems with UCI protocol
Posted:
19 Jan 2005, 22:52
by Wolfgang Gralke
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);
}
}
Re: Problems with UCI protocol
Posted:
20 Jan 2005, 10:02
by Fabien Letouzey
[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.
Problems with UCI protocol
Posted:
20 Jan 2005, 12:05
by Wolfgang Gralke
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
Re: Problems with UCI protocol
Posted:
20 Jan 2005, 15:22
by Jim Ablett
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.
Problems with UCI protocol
Posted:
20 Jan 2005, 16:50
by Wolfgang Gralke
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
Debug-Output
Posted:
20 Jan 2005, 16:56
by Wolfgang Gralke
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
Re: Problems with UCI protocol
Posted:
20 Jan 2005, 20:07
by Anonymous
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
Re: Problems with UCI protocol
Posted:
20 Jan 2005, 23:14
by Wolfgang Gralke
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
Re: Problems with UCI protocol
Posted:
21 Jan 2005, 11:19
by Wolfgang Gralke
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...
Wolfgang
Difference in WB-protocol between Arena and Chess Assistant
Posted:
23 Jan 2005, 13:54
by Wolfgang Gralke
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
Re: Problems with UCI protocol
Posted:
23 Jan 2005, 14:04
by Anonymous
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
Re: Problems with UCI protocol
Posted:
23 Jan 2005, 16:09
by Wolfgang Gralke
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