Implementing UCI Protocol
Implementing UCI Protocol
Hello All,
My friend and I are currently working on coding an engine from scratch. We have almost complete a very simplistic version but we are currently having trouble with implementing the UCI protocol. We have no idea how to create the PV and dump it to the GUI. Also, we have no idea how to make the engine accept the "stop" command from the GUI during the search. We have tried a few things but the search would get paused until the GUI sent a command which is not what we want.
Now before you say "look at an open source engine", we have already looked at a couple examples, TSCP and Gerbil, but we can't find what we are looking for.
My friend and I are currently working on coding an engine from scratch. We have almost complete a very simplistic version but we are currently having trouble with implementing the UCI protocol. We have no idea how to create the PV and dump it to the GUI. Also, we have no idea how to make the engine accept the "stop" command from the GUI during the search. We have tried a few things but the search would get paused until the GUI sent a command which is not what we want.
Now before you say "look at an open source engine", we have already looked at a couple examples, TSCP and Gerbil, but we can't find what we are looking for.
Re: Implementing UCI Protocol
I'm not sure this is really UCI-specific, but seems more pertinent to the engine. Does the engine have an array of moves/strings that represent the PV?We have no idea how to create the PV and dump it to the GUI.
Essentially you need to do some sort of non-blocking I/O. This should be in various open-source engines, though I agree it can be rather tricky (and OS dependent). I think Crafty, Fruit, IvanHoe, Stockfish, and others all have examples. See posix.cpp of Fruit, and the input_available() function.Also, we have no idea how to make the engine accept the "stop" command from the GUI during the search.
Re: Implementing UCI Protocol
Thank you very much. I believe that we figured out how to do this.Essentially you need to do some sort of non-blocking I/O. This should be in various open-source engines, though I agree it can be rather tricky (and OS dependent). I think Crafty, Fruit, IvanHoe, Stockfish, and others all have examples. See posix.cpp of Fruit, and the input_available() function.
However, this success seems short lived. When we tried to install the engine to Arena, Arena would begin to start up engine but after a short while it would shut the engine down and try to restart it. Our I/O looks the exact same as other engines. Is there another else that would force GUI's to shut down an engine?
Re: Implementing UCI Protocol
One possibility is that the GUI sends "isready" or "uci", and expects a response within a certain time limit.
Re: Implementing UCI Protocol
The engine sends its response instantly. Unless there is some command that I am missing? As far as I can tell the engine only needs to receive the engine name author name then send "uciok" and "readyok". Here is a link to download the a compile of the engine if you want to take a closer look. http://www.megaupload.com/?d=66LBEHTU
Thank you once again BB+. You are a very helpful individual.
Thank you once again BB+. You are a very helpful individual.
Re: Implementing UCI Protocol
The only other thing I can think of is maybe you are not flushing the output?
Re: Implementing UCI Protocol
What do you mean by "flushing the output"?
From what we found, "Forcing all buffered output to actually be printed is known as "flushing" the stream." Is that not the same as the engine using the printf or cout commands to print text in the command line?
From what we found, "Forcing all buffered output to actually be printed is known as "flushing" the stream." Is that not the same as the engine using the printf or cout commands to print text in the command line?
Re: Implementing UCI Protocol
Yes, printf only writes to a buffer. You need to do fflush(stdout); to flush the contents of this buffer, as else it will just sit there, and will not communicate to the GUI. This is a major difference between using a "console" (when the output appears anyway), and with inter-process communication via pipes. My recollection of how cout works in C++ is not that great, but it might be similar. EDIT: See http://support.microsoft.com/kb/94227 for C++ and cout. Note that endl flushes in C++, but a "\n" character does not in C.
Re: Implementing UCI Protocol
Ah. That was exactly the problem. I never realized that GUI would be unable to read directly from the command line.
However there is still a problem. Arena keeps saying that the engine is making an illegal move.
In the command line the text seems something like this.
User enters "go"
Engine sends depth, score, nodes
Engine completes search and sends "bestmove e2e4"
Also, how does the GUI communicate the moves that the other engine made is it a simple e2e4 command or does it send another position?
However there is still a problem. Arena keeps saying that the engine is making an illegal move.
In the command line the text seems something like this.
User enters "go"
Engine sends depth, score, nodes
Engine completes search and sends "bestmove e2e4"
Also, how does the GUI communicate the moves that the other engine made is it a simple e2e4 command or does it send another position?
Re: Implementing UCI Protocol
Under UCI, it always sends "position fen BLAH" -- in a game, many just do: "position startpos moves LIST". UCI is almost by definition "state-less", so it cannot assume that you know the previous position. So you would likely receive "position startpos moves e2e4 e7e6" and then "go wtime 65000 winc 3333 btime 54321 binc 3333" or something.
Flushing a pipe has stumped other GUI makers too: http://www.open-chess.org/viewtopic.php?f=5&t=597
Flushing a pipe has stumped other GUI makers too: http://www.open-chess.org/viewtopic.php?f=5&t=597