| blob | 7b6e6970624f2265e3191e01a7a212af825bb986 |
1 \r
2 \r
3 Description of the universal chess interface (UCI) April 2006\r
4 =================================================================\r
5 \r
6 * The specification is independent of the operating system. For Windows,\r
7 the engine is a normal exe file, either a console or "real" windows application.\r
8 \r
9 * all communication is done via standard input and output with text commands,\r
10 \r
11 * The engine should boot and wait for input from the GUI,\r
12 the engine should wait for the "isready" or "setoption" command to set up its internal parameters\r
13 as the boot process should be as quick as possible.\r
14 \r
15 * the engine must always be able to process input from stdin, even while thinking.\r
16 \r
17 * all command strings the engine receives will end with '\n',\r
18 also all commands the GUI receives should end with '\n',\r
19 Note: '\n' can be 0x0d or 0x0a0d or any combination depending on your OS.\r
20 If you use Engine and GUI in the same OS this should be no problem if you communicate in text mode,\r
21 but be aware of this when for example running a Linux engine in a Windows GUI.\r
22 \r
23 * arbitrary white space between tokens is allowed\r
24 Example: "debug on\n" and " debug on \n" and "\t debug \t \t\ton\t \n"\r
25 all set the debug mode of the engine on.\r
26 \r
27 * The engine will always be in forced mode which means it should never start calculating\r
28 or pondering without receiving a "go" command first.\r
29 \r
30 * Before the engine is asked to search on a position, there will always be a position command\r
31 to tell the engine about the current position.\r
32 \r
33 * by default all the opening book handling is done by the GUI,\r
34 but there is an option for the engine to use its own book ("OwnBook" option, see below)\r
35 \r
36 * if the engine or the GUI receives an unknown command or token it should just ignore it and try to\r
37 parse the rest of the string in this line.\r
38 Examples: "joho debug on\n" should switch the debug mode on given that joho is not defined,\r
39 "debug joho on\n" will be undefined however.\r
40 \r
41 * if the engine receives a command which is not supposed to come, for example "stop" when the engine is\r
42 not calculating, it should also just ignore it.\r
43 \r
44 \r
45 Move format:\r
46 ------------\r
47 \r
48 The move format is in long algebraic notation.\r
49 A nullmove from the Engine to the GUI should be sent as 0000.\r
50 Examples: e2e4, e7e5, e1g1 (white short castling), e7e8q (for promotion)\r
51 \r
52 \r
53 \r
54 GUI to engine:\r
55 --------------\r
56 \r
57 These are all the command the engine gets from the interface.\r
58 \r
59 * uci\r
60 tell engine to use the uci (universal chess interface),\r
61 this will be sent once as a first command after program boot\r
62 to tell the engine to switch to uci mode.\r
63 After receiving the uci command the engine must identify itself with the "id" command\r
64 and send the "option" commands to tell the GUI which engine settings the engine supports if any.\r
65 After that the engine should send "uciok" to acknowledge the uci mode.\r
66 If no uciok is sent within a certain time period, the engine task will be killed by the GUI.\r
67 \r
68 * debug [ on | off ]\r
69 switch the debug mode of the engine on and off.\r
70 In debug mode the engine should send additional infos to the GUI, e.g. with the "info string" command,\r
71 to help debugging, e.g. the commands that the engine has received etc.\r
72 This mode should be switched off by default and this command can be sent\r
73 any time, also when the engine is thinking.\r
74 \r
75 * isready\r
76 this is used to synchronize the engine with the GUI. When the GUI has sent a command or\r
77 multiple commands that can take some time to complete,\r
78 this command can be used to wait for the engine to be ready again or\r
79 to ping the engine to find out if it is still alive.\r
80 E.g. this should be sent after setting the path to the tablebases as this can take some time.\r
81 This command is also required once before the engine is asked to do any search\r
82 to wait for the engine to finish initializing.\r
83 This command must always be answered with "readyok" and can be sent also when the engine is calculating\r
84 in which case the engine should also immediately answer with "readyok" without stopping the search.\r
85 \r
86 * setoption name <id> [value <x>]\r
87 this is sent to the engine when the user wants to change the internal parameters\r
88 of the engine. For the "button" type no value is needed.\r
89 One string will be sent for each parameter and this will only be sent when the engine is waiting.\r
90 The name and value of the option in <id> should not be case sensitive and can inlude spaces.\r
91 The substrings "value" and "name" should be avoided in <id> and <x> to allow unambiguous parsing,\r
92 for example do not use <name> = "draw value".\r
93 Here are some strings for the example below:\r
94 "setoption name Nullmove value true\n"\r
95 "setoption name Selectivity value 3\n"\r
96 "setoption name Style value Risky\n"\r
97 "setoption name Clear Hash\n"\r
98 "setoption name NalimovPath value c:\chess\tb\4;c:\chess\tb\5\n"\r
99 \r
100 * register\r
101 this is the command to try to register an engine or to tell the engine that registration\r
102 will be done later. This command should always be sent if the engine has sent "registration error"\r
103 at program startup.\r
104 The following tokens are allowed:\r
105 * later\r
106 the user doesn't want to register the engine now.\r
107 * name <x>\r
108 the engine should be registered with the name <x>\r
109 * code <y>\r
110 the engine should be registered with the code <y>\r
111 Example:\r
112 "register later"\r
113 "register name Stefan MK code 4359874324"\r
114 \r
115 * ucinewgame\r
116 this is sent to the engine when the next search (started with "position" and "go") will be from\r
117 a different game. This can be a new game the engine should play or a new game it should analyse but\r
118 also the next position from a testsuite with positions only.\r
119 If the GUI hasn't sent a "ucinewgame" before the first "position" command, the engine shouldn't\r
120 expect any further ucinewgame commands as the GUI is probably not supporting the ucinewgame command.\r
121 So the engine should not rely on this command even though all new GUIs should support it.\r
122 As the engine's reaction to "ucinewgame" can take some time the GUI should always send "isready"\r
123 after "ucinewgame" to wait for the engine to finish its operation.\r
124 \r
125 * position [fen <fenstring> | startpos ] moves <move1> .... <movei>\r
126 set up the position described in fenstring on the internal board and\r
127 play the moves on the internal chess board.\r
128 if the game was played from the start position the string "startpos" will be sent\r
129 Note: no "new" command is needed. However, if this position is from a different game than\r
130 the last position sent to the engine, the GUI should have sent a "ucinewgame" inbetween.\r
131 \r
132 * go\r
133 start calculating on the current position set up with the "position" command.\r
134 There are a number of commands that can follow this command, all will be sent in the same string.\r
135 If one command is not sent its value should be interpreted as it would not influence the search.\r
136 * searchmoves <move1> .... <movei>\r
137 restrict search to this moves only\r
138 Example: After "position startpos" and "go infinite searchmoves e2e4 d2d4"\r
139 the engine should only search the two moves e2e4 and d2d4 in the initial position.\r
140 * ponder\r
141 start searching in pondering mode.\r
142 Do not exit the search in ponder mode, even if it's mate!\r
143 This means that the last move sent in in the position string is the ponder move.\r
144 The engine can do what it wants to do, but after a "ponderhit" command\r
145 it should execute the suggested move to ponder on. This means that the ponder move sent by\r
146 the GUI can be interpreted as a recommendation about which move to ponder. However, if the\r
147 engine decides to ponder on a different move, it should not display any mainlines as they are\r
148 likely to be misinterpreted by the GUI because the GUI expects the engine to ponder\r
149 on the suggested move.\r
150 * wtime <x>\r
151 white has x msec left on the clock\r
152 * btime <x>\r
153 black has x msec left on the clock\r
154 * winc <x>\r
155 white increment per move in mseconds if x > 0\r
156 * binc <x>\r
157 black increment per move in mseconds if x > 0\r
158 * movestogo <x>\r
159 there are x moves to the next time control,\r
160 this will only be sent if x > 0,\r
161 if you don't get this and get the wtime and btime it's sudden death\r
162 * depth <x>\r
163 search x plies only.\r
164 * nodes <x>\r
165 search x nodes only,\r
166 * mate <x>\r
167 search for a mate in x moves\r
168 * movetime <x>\r
169 search exactly x mseconds\r
170 * infinite\r
171 search until the "stop" command. Do not exit the search without being told so in this mode!\r
172 \r
173 * stop\r
174 stop calculating as soon as possible,\r
175 don't forget the "bestmove" and possibly the "ponder" token when finishing the search\r
176 \r
177 * ponderhit\r
178 the user has played the expected move. This will be sent if the engine was told to ponder on the same move\r
179 the user has played. The engine should continue searching but switch from pondering to normal search.\r
180 \r
181 * quit\r
182 quit the program as soon as possible\r
183 \r
184 \r
185 Engine to GUI:\r
186 --------------\r
187 \r
188 * id\r
189 * name <x>\r
190 this must be sent after receiving the "uci" command to identify the engine,\r
191 e.g. "id name Shredder X.Y\n"\r
192 * author <x>\r
193 this must be sent after receiving the "uci" command to identify the engine,\r
194 e.g. "id author Stefan MK\n"\r
195 \r
196 * uciok\r
197 Must be sent after the id and optional options to tell the GUI that the engine\r
198 has sent all infos and is ready in uci mode.\r
199 \r
200 * readyok\r
201 This must be sent when the engine has received an "isready" command and has\r
202 processed all input and is ready to accept new commands now.\r
203 It is usually sent after a command that can take some time to be able to wait for the engine,\r
204 but it can be used anytime, even when the engine is searching,\r
205 and must always be answered with "isready".\r
206 \r
207 * bestmove <move1> [ ponder <move2> ]\r
208 the engine has stopped searching and found the move <move> best in this position.\r
209 the engine can send the move it likes to ponder on. The engine must not start pondering automatically.\r
210 this command must always be sent if the engine stops searching, also in pondering mode if there is a\r
211 "stop" command, so for every "go" command a "bestmove" command is needed!\r
212 Directly before that the engine should send a final "info" command with the final search information,\r
213 the the GUI has the complete statistics about the last search.\r
214 \r
215 * copyprotection\r
216 this is needed for copyprotected engines. After the uciok command the engine can tell the GUI,\r
217 that it will check the copy protection now. This is done by "copyprotection checking".\r
218 If the check is ok the engine should send "copyprotection ok", otherwise "copyprotection error".\r
219 If there is an error the engine should not function properly but should not quit alone.\r
220 If the engine reports "copyprotection error" the GUI should not use this engine\r
221 and display an error message instead!\r
222 The code in the engine can look like this\r
223 TellGUI("copyprotection checking\n");\r
224 // ... check the copy protection here ...\r
225 if(ok)\r
226 TellGUI("copyprotection ok\n");\r
227 else\r
228 TellGUI("copyprotection error\n");\r
229 \r
230 * registration\r
231 this is needed for engines that need a username and/or a code to function with all features.\r
232 Analog to the "copyprotection" command the engine can send "registration checking"\r
233 after the uciok command followed by either "registration ok" or "registration error".\r
234 Also after every attempt to register the engine it should answer with "registration checking"\r
235 and then either "registration ok" or "registration error".\r
236 In contrast to the "copyprotection" command, the GUI can use the engine after the engine has\r
237 reported an error, but should inform the user that the engine is not properly registered\r
238 and might not use all its features.\r
239 In addition the GUI should offer to open a dialog to\r
240 enable registration of the engine. To try to register an engine the GUI can send\r
241 the "register" command.\r
242 The GUI has to always answer with the "register" command if the engine sends "registration error"\r
243 at engine startup (this can also be done with "register later")\r
244 and tell the user somehow that the engine is not registered.\r
245 This way the engine knows that the GUI can deal with the registration procedure and the user\r
246 will be informed that the engine is not properly registered.\r
247 \r
248 * info\r
249 the engine wants to send information to the GUI. This should be done whenever one of the info has changed.\r
250 The engine can send only selected infos or multiple infos with one info command,\r
251 e.g. "info currmove e2e4 currmovenumber 1" or\r
252 "info depth 12 nodes 123456 nps 100000".\r
253 Also all infos belonging to the pv should be sent together\r
254 e.g. "info depth 2 score cp 214 time 1242 nodes 2124 nps 34928 pv e2e4 e7e5 g1f3"\r
255 I suggest to start sending "currmove", "currmovenumber", "currline" and "refutation" only after one second\r
256 to avoid too much traffic.\r
257 Additional info:\r
258 * depth <x>\r
259 search depth in plies\r
260 * seldepth <x>\r
261 selective search depth in plies,\r
262 if the engine sends seldepth there must also be a "depth" present in the same string.\r
263 * time <x>\r
264 the time searched in ms, this should be sent together with the pv.\r
265 * nodes <x>\r
266 x nodes searched, the engine should send this info regularly\r
267 * pv <move1> ... <movei>\r
268 the best line found\r
269 * multipv <num>\r
270 this for the multi pv mode.\r
271 for the best move/pv add "multipv 1" in the string when you send the pv.\r
272 in k-best mode always send all k variants in k strings together.\r
273 * score\r
274 * cp <x>\r
275 the score from the engine's point of view in centipawns.\r
276 * mate <y>\r
277 mate in y moves, not plies.\r
278 If the engine is getting mated use negative values for y.\r
279 * lowerbound\r
280 the score is just a lower bound.\r
281 * upperbound\r
282 the score is just an upper bound.\r
283 * currmove <move>\r
284 currently searching this move\r
285 * currmovenumber <x>\r
286 currently searching move number x, for the first move x should be 1 not 0.\r
287 * hashfull <x>\r
288 the hash is x permill full, the engine should send this info regularly\r
289 * nps <x>\r
290 x nodes per second searched, the engine should send this info regularly\r
291 * tbhits <x>\r
292 x positions where found in the endgame table bases\r
293 * sbhits <x>\r
294 x positions where found in the shredder endgame databases\r
295 * cpuload <x>\r
296 the cpu usage of the engine is x permill.\r
297 * string <str>\r
298 any string str which will be displayed be the engine,\r
299 if there is a string command the rest of the line will be interpreted as <str>.\r
300 * refutation <move1> <move2> ... <movei>\r
301 move <move1> is refuted by the line <move2> ... <movei>, i can be any number >= 1.\r
302 Example: after move d1h5 is searched, the engine can send\r
303 "info refutation d1h5 g6h5"\r
304 if g6h5 is the best answer after d1h5 or if g6h5 refutes the move d1h5.\r
305 if there is no refutation for d1h5 found, the engine should just send\r
306 "info refutation d1h5"\r
307 The engine should only send this if the option "UCI_ShowRefutations" is set to true.\r
308 * currline <cpunr> <move1> ... <movei>\r
309 this is the current line the engine is calculating. <cpunr> is the number of the cpu if\r
310 the engine is running on more than one cpu. <cpunr> = 1,2,3....\r
311 if the engine is just using one cpu, <cpunr> can be omitted.\r
312 If <cpunr> is greater than 1, always send all k lines in k strings together.\r
313 The engine should only send this if the option "UCI_ShowCurrLine" is set to true.\r
314 \r
315 \r
316 * option\r
317 This command tells the GUI which parameters can be changed in the engine.\r
318 This should be sent once at engine startup after the "uci" and the "id" commands\r
319 if any parameter can be changed in the engine.\r
320 The GUI should parse this and build a dialog for the user to change the settings.\r
321 Note that not every option needs to appear in this dialog as some options like\r
322 "Ponder", "UCI_AnalyseMode", etc. are better handled elsewhere or are set automatically.\r
323 If the user wants to change some settings, the GUI will send a "setoption" command to the engine.\r
324 Note that the GUI need not send the setoption command when starting the engine for every option if\r
325 it doesn't want to change the default value.\r
326 For all allowed combinations see the examples below,\r
327 as some combinations of this tokens don't make sense.\r
328 One string will be sent for each parameter.\r
329 * name <id>\r
330 The option has the name id.\r
331 Certain options have a fixed value for <id>, which means that the semantics of this option is fixed.\r
332 Usually those options should not be displayed in the normal engine options window of the GUI but\r
333 get a special treatment. "Pondering" for example should be set automatically when pondering is\r
334 enabled or disabled in the GUI options. The same for "UCI_AnalyseMode" which should also be set\r
335 automatically by the GUI. All those certain options have the prefix "UCI_" except for the\r
336 first 6 options below. If the GUI gets an unknown Option with the prefix "UCI_", it should just\r
337 ignore it and not display it in the engine's options dialog.\r
338 * <id> = Hash, type is spin\r
339 the value in MB for memory for hash tables can be changed,\r
340 this should be answered with the first "setoptions" command at program boot\r
341 if the engine has sent the appropriate "option name Hash" command,\r
342 which should be supported by all engines!\r
343 So the engine should use a very small hash first as default.\r
344 * <id> = NalimovPath, type string\r
345 this is the path on the hard disk to the Nalimov compressed format.\r
346 Multiple directories can be concatenated with ";"\r
347 * <id> = NalimovCache, type spin\r
348 this is the size in MB for the cache for the nalimov table bases\r
349 These last two options should also be present in the initial options exchange dialog\r
350 when the engine is booted if the engine supports it\r
351 * <id> = Ponder, type check\r
352 this means that the engine is able to ponder.\r
353 The GUI will send this whenever pondering is possible or not.\r
354 Note: The engine should not start pondering on its own if this is enabled, this option is only\r
355 needed because the engine might change its time management algorithm when pondering is allowed.\r
356 * <id> = OwnBook, type check\r
357 this means that the engine has its own book which is accessed by the engine itself.\r
358 if this is set, the engine takes care of the opening book and the GUI will never\r
359 execute a move out of its book for the engine. If this is set to false by the GUI,\r
360 the engine should not access its own book.\r
361 * <id> = MultiPV, type spin\r
362 the engine supports multi best line or k-best mode. the default value is 1\r
363 * <id> = UCI_ShowCurrLine, type check, should be false by default,\r
364 the engine can show the current line it is calculating. see "info currline" above.\r
365 * <id> = UCI_ShowRefutations, type check, should be false by default,\r
366 the engine can show a move and its refutation in a line. see "info refutations" above.\r
367 * <id> = UCI_LimitStrength, type check, should be false by default,\r
368 The engine is able to limit its strength to a specific Elo number,\r
369 This should always be implemented together with "UCI_Elo".\r
370 * <id> = UCI_Elo, type spin\r
371 The engine can limit its strength in Elo within this interval.\r
372 If UCI_LimitStrength is set to false, this value should be ignored.\r
373 If UCI_LimitStrength is set to true, the engine should play with this specific strength.\r
374 This should always be implemented together with "UCI_LimitStrength".\r
375 * <id> = UCI_AnalyseMode, type check\r
376 The engine wants to behave differently when analysing or playing a game.\r
377 For example when playing it can use some kind of learning.\r
378 This is set to false if the engine is playing a game, otherwise it is true.\r
379 * <id> = UCI_Opponent, type string\r
380 With this command the GUI can send the name, title, elo and if the engine is playing a human\r
381 or computer to the engine.\r
382 The format of the string has to be [GM|IM|FM|WGM|WIM|none] [<elo>|none] [computer|human] <name>\r
383 Examples:\r
384 "setoption name UCI_Opponent value GM 2800 human Gary Kasparov"\r
385 "setoption name UCI_Opponent value none none computer Shredder"\r
386 * <id> = UCI_EngineAbout, type string\r
387 With this command, the engine tells the GUI information about itself, for example a license text,\r
388 usually it doesn't make sense that the GUI changes this text with the setoption command.\r
389 Example:\r
390 "option name UCI_EngineAbout type string default Shredder by Stefan Meyer-Kahlen, see www.shredderchess.com"\r
391 * <id> = UCI_ShredderbasesPath, type string\r
392 this is either the path to the folder on the hard disk containing the Shredder endgame databases or\r
393 the path and filename of one Shredder endgame datbase.\r
394 * <id> = UCI_SetPositionValue, type string\r
395 the GUI can send this to the engine to tell the engine to use a certain value in centipawns from white's\r
396 point of view if evaluating this specifix position. \r
397 The string can have the formats:\r
398 <value> + <fen> | clear + <fen> | clearall\r
399 \r
400 * type <t>\r
401 The option has type t.\r
402 There are 5 different types of options the engine can send\r
403 * check\r
404 a checkbox that can either be true or false\r
405 * spin\r
406 a spin wheel that can be an integer in a certain range\r
407 * combo\r
408 a combo box that can have different predefined strings as a value\r
409 * button\r
410 a button that can be pressed to send a command to the engine\r
411 * string\r
412 a text field that has a string as a value,\r
413 an empty string has the value "<empty>"\r
414 * default <x>\r
415 the default value of this parameter is x\r
416 * min <x>\r
417 the minimum value of this parameter is x\r
418 * max <x>\r
419 the maximum value of this parameter is x\r
420 * var <x>\r
421 a predefined value of this parameter is x\r
422 Examples:\r
423 Here are 5 strings for each of the 5 possible types of options\r
424 "option name Nullmove type check default true\n"\r
425 "option name Selectivity type spin default 2 min 0 max 4\n"\r
426 "option name Style type combo default Normal var Solid var Normal var Risky\n"\r
427 "option name NalimovPath type string default c:\\n"\r
428 "option name Clear Hash type button\n"\r
429 \r
430 \r
431 \r
432 Examples:\r
433 ---------\r
434 \r
435 This is how the communication when the engine boots can look like:\r
436 \r
437 GUI engine\r
438 \r
439 // tell the engine to switch to UCI mode\r
440 uci\r
441 \r
442 // engine identify \r
443 id name Shredder\r
444 id author Stefan MK\r
445 \r
446 // engine sends the options it can change\r
447 // the engine can change the hash size from 1 to 128 MB\r
448 option name Hash type spin default 1 min 1 max 128\r
449 \r
450 // the engine supports Nalimov endgame tablebases\r
451 option name NalimovPath type string default <empty>\r
452 option name NalimovCache type spin default 1 min 1 max 32\r
453 \r
454 // the engine can switch off Nullmove and set the playing style\r
455 option name Nullmove type check default true\r
456 option name Style type combo default Normal var Solid var Normal var Risky\r
457 \r
458 // the engine has sent all parameters and is ready\r
459 uciok\r
460 \r
461 // Note: here the GUI can already send a "quit" command if it just wants to find out\r
462 // details about the engine, so the engine should not initialize its internal\r
463 // parameters before here.\r
464 // now the GUI sets some values in the engine\r
465 // set hash to 32 MB\r
466 setoption name Hash value 32\r
467 \r
468 // init tbs\r
469 setoption name NalimovCache value 1\r
470 setoption name NalimovPath value d:\tb;c\tb\r
471 \r
472 // waiting for the engine to finish initializing\r
473 // this command and the answer is required here!\r
474 isready\r
475 \r
476 // engine has finished setting up the internal values\r
477 readyok\r
478 \r
479 // now we are ready to go\r
480 \r
481 // if the GUI is supporting it, tell the engine that is is\r
482 // searching on a game that it hasn't searched on before\r
483 ucinewgame\r
484 \r
485 // if the engine supports the "UCI_AnalyseMode" option and the next search is supposed to\r
486 // be an analysis, the GUI should set "UCI_AnalyseMode" to true if it is currently\r
487 // set to false with this engine\r
488 setoption name UCI_AnalyseMode value true\r
489 \r
490 // tell the engine to search infinite from the start position after 1.e4 e5\r
491 position startpos moves e2e4 e7e5\r
492 go infinite\r
493 \r
494 // the engine starts sending infos about the search to the GUI\r
495 // (only some examples are given)\r
496 \r
497 \r
498 info depth 1 seldepth 0\r
499 info score cp 13 depth 1 nodes 13 time 15 pv f1b5 \r
500 info depth 2 seldepth 2\r
501 info nps 15937\r
502 info score cp 14 depth 2 nodes 255 time 15 pv f1c4 f8c5 \r
503 info depth 2 seldepth 7 nodes 255\r
504 info depth 3 seldepth 7\r
505 info nps 26437\r
506 info score cp 20 depth 3 nodes 423 time 15 pv f1c4 g8f6 b1c3 \r
507 info nps 41562\r
508 ....\r
509 \r
510 \r
511 // here the user has seen enough and asks to stop the searching\r
512 stop\r
513 \r
514 // the engine has finished searching and is sending the bestmove command\r
515 // which is needed for every "go" command sent to tell the GUI\r
516 // that the engine is ready again\r
517 bestmove g1f3 ponder d8f6\r
518 \r
519 \r
520 \r
521 Chess960\r
522 ========\r
523 \r
524 UCI could easily be extended to support Chess960 (also known as Fischer Random Chess).\r
525 \r
526 The engine has to tell the GUI that it is capable of playing Chess960 and the GUI has to tell\r
527 the engine that is should play according to the Chess960 rules.\r
528 This is done by the special engine option UCI_Chess960. If the engine knows about Chess960\r
529 it should send the command 'option name UCI_Chess960 type check default false'\r
530 to the GUI at program startup.\r
531 Whenever a Chess960 game is played, the GUI should set this engine option to 'true'.\r
532 \r
533 Castling is different in Chess960 and the white king move when castling short is not always e1g1.\r
534 A king move could both be the castling king move or just a normal king move.\r
535 This is why castling moves are sent in the form king "takes" his own rook.\r
536 Example: e1h1 for the white short castle move in the normal chess start position.\r
537 \r
538 In EPD and FEN position strings specifying the castle rights with w and q is not enough as\r
539 there could be more than one rook on the right or left side of the king.\r
540 This is why the castle rights are specified with the letter of the castle rook's line.\r
541 Upper case letters for white's and lower case letters for black's castling rights.\r
542 Example: The normal chess position would be:\r
543 rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w AHah -\r
544 \r