+++ /dev/null
-/* With friendly permission, to public this document,
- * of Stefan-Mayer Kahlen
- * For more information or newer versions of the
- * UCI protcol please visit
- * http://www.shredderchess.de/download.html
- */
-
-Description of the universal chess interface (UCI) April 2004
-================================================================
-
-* The specification is independent of the operating system. For Windows,
- the engine is a normal exe file, either a console or "real" windows application.
-
-* all communication is done via standard input and output with text commands,
-
-* The engine should boot and wait for input from the GUI,
- the engine should wait for the "isready" or "setoption" command to set up its internal parameters
- as the boot process should be as quick as possible.
-
-* the engine must always be able to process input from stdin, even while thinking.
-
-* all command strings the engine receives will end with '\n',
- also all commands the GUI receives should end with '\n',
- Note: '\n' can be 0x0c or 0x0a0c or any combination depending on your OS.
- If you use Engine und GUI in the same OS this should be no problem if you cummunicate in text mode,
- but be aware of this when for example running a Linux engine in a Windows GUI.
-
-* The engine will always be in forced mode which means it should never start calculating
- or pondering without receiving a "go" command first.
-
-* Before the engine is asked to search on a position, there will always be a position command
- to tell the engine about the current position.
-
-* by default all the opening book handling is done by the GUI,
- but there is an option for the engine to use its own book ("OwnBook" option, see below)
-
-* if the engine or the GUI receives an unknown command or token it should just ignore it and try to
- parse the rest of the string.
-
-* if the engine receives a command which is not supposed to come, for example "stop" when the engine is
- not calculating, it should also just ignore it.
-
-
-Move format:
-------------
-
-The move format is in long algebraic notation.
-A nullmove from the Engine to the GUI should be send as 0000.
-Examples: e2e4, e7e5, e1g1 (white short castling), e7e8q (for promotion)
-
-
-
-GUI to engine:
---------------
-
-These are all the command the engine gets from the interface.
-
-* uci
- tell engine to use the uci (universal chess interface),
- this will be send once as a first command after program boot
- to tell the engine to switch to uci mode.
- After receiving the uci command the engine must identify itself with the "id" command
- and sent the "option" commands to tell the GUI which engine settings the engine supports if any.
- After that the engine should sent "uciok" to acknowledge the uci mode.
- If no uciok is sent within a certain time period, the engine task will be killed by the GUI.
-
-* debug [ on | off ]
- switch the debug mode of the engine on and off.
- In debug mode the engine should sent additional infos to the GUI, e.g. with the "info string" command,
- to help debugging, e.g. the commands that the engine has received etc.
- This mode should be switched off by default and this command can be sent
- any time, also when the engine is thinking.
-
-* isready
- 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.
-
-* setoption name <id> [value <x>]
- this is sent to the engine when the user wants to change the internal parameters
- of the engine. For the "button" type no value is needed.
- One string will be sent for each parameter and this will only be sent when the engine is waiting.
- The name of the option in <id> should not be case sensitive and can inludes spaces like also the value.
- The substrings "value" and "name" should be avoided in <id> and <x> to allow unambiguous parsing,
- for example do not use <name> = "draw value".
- Here are some strings for the example below:
- "setoption name Nullmove value true\n"
- "setoption name Selectivity value 3\n"
- "setoption name Style value Risky\n"
- "setoption name Clear Hash\n"
- "setoption name NalimovPath value c:\chess\tb\4;c:\chess\tb\5\n"
-
-* register
- this is the command to try to register an engine or to tell the engine that registration
- will be done later. This command should always be sent if the engine has send "registration error"
- at program startup.
- The following tokens are allowed:
- * later
- the user doesn't want to register the engine now.
- * name <x>
- the engine should be registered with the name <x>
- * code <y>
- the engine should be registered with the code <y>
- Example:
- "register later"
- "register name Stefan MK code 4359874324"
-
-* ucinewgame
- this is sent to the engine when the next search (started with "position" and "go") will be from
- a different game. This can be a new game the engine should play or a new game it should analyse but
- also the next position from a testsuite with positions only.
- If the GUI hasn't sent a "ucinewgame" before the first "position" command, the engine shouldn't
- expect any further ucinewgame commands as the GUI is probably not supporting the ucinewgame command.
- So the engine should not rely on this command even though all new GUIs should support it.
- As the engine's reaction to "ucinewgame" can take some time the GUI should always send "isready"
- after "ucinewgame" to wait for the engine to finish its operation.
-
-* position [fen <fenstring> | startpos ] moves <move1> .... <movei>
- set up the position described in fenstring on the internal board and
- play the moves on the internal chess board.
- if the game was played from the start position the string "startpos" will be sent
- Note: no "new" command is needed. However, if this position is from a different game than
- the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.
-
-* go
- start calculating on the current position set up with the "position" command.
- There are a number of commands that can follow this command, all will be sent in the same string.
- If one command is not send its value should be interpreted as it would not influence the search.
- * searchmoves <move1> .... <movei>
- restrict search to this moves only
- Example: After "position startpos" and "go infinite searchmoves e2e4 d2d4"
- the engine should only search the two moves e2e4 and d2d4 in the initial position.
- * ponder
- start searching in pondering mode.
- Do not exit the search in ponder mode, even if it's mate!
- This means that the last move sent in in the position string is the ponder move.
- The engine can do what it wants to do, but after a "ponderhit" command
- it should execute the suggested move to ponder on. This means that the ponder move sent by
- the GUI can be interpreted as a recommendation about which move to ponder. However, if the
- engine decides to ponder on a different move, it should not display any mainlines as they are
- likely to be misinterpreted by the GUI because the GUI expects the engine to ponder
- on the suggested move.
- * wtime <x>
- white has x msec left on the clock
- * btime <x>
- black has x msec left on the clock
- * winc <x>
- white increment per move in mseconds if x > 0
- * binc <x>
- black increment per move in mseconds if x > 0
- * movestogo <x>
- there are x moves to the next time control,
- this will only be sent if x > 0,
- if you don't get this and get the wtime and btime it's sudden death
- * depth <x>
- search x plies only.
- * nodes <x>
- search x nodes only,
- * mate <x>
- search for a mate in x moves
- * movetime <x>
- search exactly x mseconds
- * infinite
- search until the "stop" command. Do not exit the search without being told so in this mode!
-
-* stop
- stop calculating as soon as possible,
- don't forget the "bestmove" and possibly the "ponder" token when finishing the search
-
-* ponderhit
- the user has played the expected move. This will be sent if the engine was told to ponder on the same move
- the user has played. The engine should continue searching but switch from pondering to normal search.
-
-* quit
- quit the program as soon as possible
-
-
-Engine to GUI:
---------------
-
-* id
- * name <x>
- this must be sent after receiving the "uci" command to identify the engine,
- e.g. "id name Shredder X.Y\n"
- * author <x>
- this must be sent after receiving the "uci" command to identify the engine,
- e.g. "id author Stefan MK\n"
-
-* uciok
- Must be sent after the id and optional options to tell the GUI that the engine
- has sent all infos and is ready in uci mode.
-
-* readyok
- This must be sent when the engine has received an "isready" command and has
- processed all input and is ready to accept new commands now.
- It is usually sent after a command that can take some time to be able to wait for the engine,
- but it can be used anytime, even when the engine is searching,
- and must always be answered with "isready".
-
-* bestmove <move1> [ ponder <move2> ]
- the engine has stopped searching and found the move <move> best in this position.
- the engine can send the move it likes to ponder on. The engine must not start pondering automatically.
- this command must always be sent if the engine stops searching, also in pondering mode if there is a
- "stop" command, so for every "go" command a "bestmove" command is needed!
- Directly before that the engine should send a final "info" command with the final search information,
- the the GUI has the complete statistics about the last search.
-
-* copyprotection
- this is needed for copyprotected engines. After the uciok command the engine can tell the GUI,
- that it will check the copy protection now. This is done by "copyprotection checking".
- If the check is ok the engine should sent "copyprotection ok", otherwise "copyprotection error".
- If there is an error the engine should not function properly but should not quit alone.
- If the engine reports "copyprotection error" the GUI should not use this engine
- and display an error message instead!
- The code in the engine can look like this
- TellGUI("copyprotection checking\n");
- // ... check the copy protection here ...
- if(ok)
- TellGUI("copyprotection ok\n");
- else
- TellGUI("copyprotection error\n");
-
-* registration
- this is needed for engines that need a username and/or a code to function with all features.
- Analog to the "copyprotection" command the engine can send "registration checking"
- after the uciok command followed by either "registration ok" or "registration error".
- Also after every attempt to register the engine it should answer with "registration checking"
- and then either "registration ok" or "registration error".
- In contrast to the "copyprotection" command, the GUI can use the engine after the engine has
- reported an error, but should inform the user that the engine is not properly registered
- and might not use all its features.
- In addition the GUI should offer to open a dialog to
- enable registration of the engine. To try to register an engine the GUI can send
- the "register" command.
- The GUI has to always answer with the "register" command if the engine sends "registration error"
- at engine startup (this can also be done with "register later")
- and tell the user somehow that the engine is not registered.
- This way the engine knows that the GUI can deal with the registration procedure and the user
- will be informed that the engine is not properly registered.
-
-* info
- the engine wants to send infos to the GUI. This should be done whenever one of the info has changed.
- The engine can send only selected infos and multiple infos can be send with one info command,
- e.g. "info currmove e2e4 currmovenumber 1" or
- "info depth 12 nodes 123456 nps 100000".
- Also all infos belonging to the pv should be sent together
- e.g. "info depth 2 score cp 214 time 1242 nodes 2124 nps 34928 pv e2e4 e7e5 g1f3"
- I suggest to start sending "currmove", "currmovenumber", "currline" and "refutation" only after one second
- to avoid too much traffic.
- Additional info:
- * depth <x>
- search depth in plies
- * seldepth <x>
- selective search depth in plies,
- if the engine sends seldepth there must also a "depth" be present in the same string.
- * time <x>
- the time searched in ms, this should be sent together with the pv.
- * nodes <x>
- x nodes searched, the engine should send this info regularly
- * pv <move1> ... <movei>
- the best line found
- * multipv <num>
- this for the multi pv mode.
- for the best move/pv add "multipv 1" in the string when you send the pv.
- in k-best mode always send all k variants in k strings together.
- * score
- * cp <x>
- the score from the engine's point of view in centipawns.
- * mate <y>
- mate in y moves, not plies.
- If the engine is getting mated use negativ values for y.
- * lowerbound
- the score is just a lower bound.
- * upperbound
- the score is just an upper bound.
- * currmove <move>
- currently searching this move
- * currmovenumber <x>
- currently searching move number x, for the first move x should be 1 not 0.
- * hashfull <x>
- the hash is x permill full, the engine should send this info regularly
- * nps <x>
- x nodes per second searched, the engine should send this info regularly
- * tbhits <x>
- x positions where found in the endgame table bases
- * cpuload <x>
- the cpu usage of the engine is x permill.
- * string <str>
- any string str which will be displayed be the engine,
- if there is a string command the rest of the line will be interpreted as <str>.
- * refutation <move1> <move2> ... <movei>
- move <move1> is refuted by the line <move2> ... <movei>, i can be any number >= 1.
- Example: after move d1h5 is searched, the engine can send
- "info refutation d1h5 g6h5"
- if g6h5 is the best answer after d1h5 or if g6h5 refutes the move d1h5.
- if there is norefutation for d1h5 found, the engine should just send
- "info refutation d1h5"
- The engine should only send this if the option "UCI_ShowRefutations" is set to true.
- * currline <cpunr> <move1> ... <movei>
- this is the current line the engine is calculating. <cpunr> is the number of the cpu if
- the engine is running on more than one cpu. <cpunr> = 1,2,3....
- if the engine is just using one cpu, <cpunr> can be omitted.
- If <cpunr> is greater than 1, always send all k lines in k strings together.
- The engine should only send this if the option "UCI_ShowCurrLine" is set to true.
-
-
-* option
- This command tells the GUI which parameters can be changed in the engine.
- This should be sent once at engine startup after the "uci" and the "id" commands
- if any parameter can be changed in the engine.
- The GUI should parse this and build a dialog for the user to change the settings.
- Note that not every option needs to appear in this dialog as some options like
- "Ponder", "UCI_AnalyseMode", etc. are better handled elsewhere or are set automatically.
- If the user wants to change some settings, the GUI will send a "setoption" command to the engine.
- Note that the GUI need not send the setoption command when starting the engine for every option if
- it doesn't want to change the default value.
- For all allowed combinations see the example below,
- as some combinations of this tokens don't make sense.
- One string will be sent for each parameter.
- * name <id>
- The option has the name id.
- Certain options have a fixed value for <id>, which means that the semantics of this option is fixed.
- Usually those options should not be displayed in the normal engine options window of the GUI but
- get a special treatment. "Pondering" for example should be set automatically when pondering is
- enabled or disabled in the GUI options. The same for "UCI_AnalyseMode" which should also be set
- automatically by the GUI. All those certain options have the prefix "UCI_" except for the
- first 6 options below. If the GUI get an unknown Option with the prefix "UCI_", it should just
- ignore it and not display it in the engine's options dialog.
- * <id> = Hash, type is spin
- the value in MB for memory for hash tables can be changed,
- this should be answered with the first "setoptions" command at program boot
- if the engine has sent the appropriate "option name Hash" command,
- which should be supported by all engines!
- So the engine should use a very small hash first as default.
- * <id> = NalimovPath, type string
- this is the path on the hard disk to the Nalimov compressed format.
- Multiple directories can be concatenated with ";"
- * <id> = NalimovCache, type spin
- this is the size in MB for the cache for the nalimov table bases
- These last two options should also be present in the initial options exchange dialog
- when the engine is booted if the engine supports it
- * <id> = Ponder, type check
- this means that the engine is able to ponder.
- The GUI will send this whenever pondering is possible or not.
- Note: The engine should not start pondering on its own if this is enabled, this option is only
- needed because the engine might change its time management algorithm when pondering is allowed.
- * <id> = OwnBook, type check
- this means that the engine has its own book which is accessed by the engine itself.
- if this is set, the engine takes care of the opening book and the GUI will never
- execute a move out of its book for the engine. If this is set to false by the GUI,
- the engine should not access its own book.
- * <id> = MultiPV, type spin
- the engine supports multi best line or k-best mode. the default value is 1
- * <id> = UCI_ShowCurrLine, type check, should be false by default,
- the engine can show the current line it is calculating. see "info currline" above.
- * <id> = UCI_ShowRefutations, type check, should be false by default,
- the engine can show a move and its refutation in a line. see "info refutations" above.
- * <id> = UCI_LimitStrength, type check, should be false by default,
- The engine is able to limit its strength to a specific Elo number,
- This should always be implemented together with "UCI_Elo".
- * <id> = UCI_Elo, type spin
- The engine can limit its strength in Elo within this interval.
- If UCI_LimitStrength is set to false, this value should be ignored.
- If UCI_LimitStrength is set to true, the engine should play with this specific strength.
- This should always be implemented together with "UCI_LimitStrength".
- * <id> = UCI_AnalyseMode, type check
- The engine wants to behave differently when analysing or playing a game.
- For example when playing it can use some kind of learning.
- This is set to false if the engine is playing a game, otherwise it is true.
- * <id> = UCI_Opponent, type string
- With this command the GUI can send the name, title, elo and if the engine is playing a human
- or computer to the engine.
- The format of the string has to be [GM|IM|FM|WGM|WIM|none] [<elo>|none] [computer|human] <name>
- Example:
- "setoption name UCI_Opponent value GM 2800 human Gary Kasparow"
- "setoption name UCI_Opponent value none none computer Shredder"
-
-
- * type <t>
- The option has type t.
- There are 5 different types of options the engine can send
- * check
- a checkbox that can either be true or false
- * spin
- a spin wheel that can be an integer in a certain range
- * combo
- a combo box that can have different predefined strings as a value
- * button
- a button that can be pressed to send a command to the engine
- * string
- a text field that has a string as a value,
- an empty string has the value "<empty>"
- * default <x>
- the default value of this parameter is x
- * min <x>
- the minimum value of this parameter is x
- * max <x>
- the maximum value of this parameter is x
- * var <x>
- a predefined value of this parameter is x
- Example:
- Here are 5 strings for each of the 5 possible types of options
- "option name Nullmove type check default true\n"
- "option name Selectivity type spin default 2 min 0 max 4\n"
- "option name Style type combo default Normal var Solid var Normal var Risky\n"
- "option name NalimovPath type string default c:\\n"
- "option name Clear Hash type button\n"
-
-
-
-Example:
---------
-
-This is how the communication when the engine boots can look like:
-
-GUI engine
-
-// tell the engine to switch to UCI mode
-uci
-
-// engine identify
- id name Shredder
- id author Stefan MK
-
-// engine sends the options it can change
-// the engine can change the hash size from 1 to 128 MB
- option name Hash type spin default 1 min 1 max 128
-
-// the engine supports Nalimov endgame tablebases
- option name NalimovPath type string default <empty>
- option name NalimovCache type spin default 1 min 1 max 32
-
-// the engine can switch off Nullmove and set the playing style
- option name Nullmove type check default true
- option name Style type combo default Normal var Solid var Normal var Risky
-
-// the engine has sent all parameters and is ready
- uciok
-
-// Note: here the GUI can already send a "quit" command if it just wants to find out
-// details about the engine, so the engine should not initialize its internal
-// parameters before here.
-// now the GUI sets some values in the engine
-// set hash to 32 MB
-setoption name Hash value 32
-
-// init tbs
-setoption name NalimovCache value 1
-setoption name NalimovPath value d:\tb;c\tb
-
-// waiting for the engine to finish initializing
-// this command and the answer is required here!
-isready
-
-// engine has finished setting up the internal values
- readyok
-
-// now we are ready to go
-
-// if the GUI is supporting it, tell the engine that is is
-// searching on a game that is hasn't searched on before
-ucinewgame
-
-// if the engine supports the "UCI_AnalyseMode" option and the next search is supposted to
-// be an analysis, the GUI should set "UCI_AnalyseMode" to true if it is currently
-// set to false with this engine
-setoption name UCI_AnalyseMode value true
-
-// tell the engine to search infinite from the start position after 1.e4 e5
-position startpos moves e2e4 e7e5
-go infinite
-
-// the engine starts sending infos about the search to the GUI
-// (only some examples are given)
-
-
- info depth 1 seldepth 0
- info score cp 13 depth 1 nodes 13 time 15 pv f1b5
- info depth 2 seldepth 2
- info nps 15937
- info score cp 14 depth 2 nodes 255 time 15 pv f1c4 f8c5
- info depth 2 seldepth 7 nodes 255
- info depth 3 seldepth 7
- info nps 26437
- info score cp 20 depth 3 nodes 423 time 15 pv f1c4 g8f6 b1c3
- info nps 41562
- ....
-
-
-// here the user has seen enough and asks to stop the searching
-stop
-
-// the engine has finished searching and is sending the bestmove command
-// which is needed for every "go" command sent to tell the GUI
-// that the engine is ready again
- bestmove g1f3 ponder d8f6
projects / xboard.git / blobdiff