Uci "go" command without other parameters

[Ferdy]

An innocent user accidentally sends the command,

Code: Select all

go home

How does your engine replies to it.

Deuterium:

Code: Select all

go home
info string unknown command go home

[xr_a_y]

An innocent user accidentally sends the command,

Code: Select all

go home

How does your engine replies to it.

Deuterium:

Code: Select all

go home
info string unknown command go home

I love this one !

Here is Minic's answer

Code: Select all

[...]
uciok
go home
info string Info  2021-01-18 17:58:59-643: Received command : go home
info string Info  2021-01-18 17:58:59-643: uci received command go
info string Info  2021-01-18 17:58:59-643: received parameter home
info string home not implemented
info string Warn  2021-01-18 17:58:59-643: no parameters given for go command, going for a depth 10 search ...
[...]

[mvanthoor]

An innocent user accidentally sends the command,

Code: Select all

go home

How does your engine replies to it.

Deuterium:

Code: Select all

go home
info string unknown command go home

The specs say this:

* 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.

It's exactly what my engine does.

If you would type "go home", it will parse "go" (and then assume "infinite" as the search parameter), and because "home" is unknown, it'll just discard it. If you type any command the engine doesn't know, it'll just discard it too. The one exception is that I parse things such as "go depth 5" as "go", and "depth 5"; therefore, it knows the engine parsing "go", and when it sees "depth", it expects an integer. If it gets something different, it assumes "1". With some work I could change this, but I haven't seen any problems in practice.

Maybe I'll change it someday, to actually examine each token separately. That will only come down to not breaking on an illegal token when parsing. Now, when I find "depth", the engine looks for an int, and if there's none, it assumes 1 and breaks. I could also throw it away and not break, and keep parsing.

[Ferdy]

An innocent user accidentally sends the command,

Code: Select all

go home

How does your engine replies to it.

Deuterium:

Code: Select all

go home
info string unknown command go home

I love this one !

Here is Minic's answer

Code: Select all

[...]
uciok
go home
info string Info  2021-01-18 17:58:59-643: Received command : go home
info string Info  2021-01-18 17:58:59-643: uci received command go
info string Info  2021-01-18 17:58:59-643: received parameter home
info string home not implemented
info string Warn  2021-01-18 17:58:59-643: no parameters given for go command, going for a depth 10 search ...
[...]

Don't forget your engine is in uci protocol, it is not in CECP

[xr_a_y]

Using -xboard Minic will try to read anything unknown as a move so will say "go home" is a bad formatted move.

[hgm]

That is a risky implementation, which only works if you are sure that you do recognize every CECP command as valid. Otherwise you could get spurious Illegal move error messages when you receive a command you did not bother to implement. And that would wreck things, as the GUI would take back the latest move on reception of that error message, so that engine and GUI would be out of phase from that point on.

Saver is to consider only tokens of which the second character is a digit or @ sign as moves, and the rest as commands.

[Ras]

For "go home", my engine will just ignore the "home". The parser determines "home" to be a token without numeric parameters, and since the only known parameter of that class is "infinite", no code will be executed for "home". Reading continues with the next token, but since there is none, "go home" is handled the same way as "go", which means infinite search (but without waiting for "stop" if the maximum search depth is reached).

[xr_a_y]

That is a risky implementation, which only works if you are sure that you do recognize every CECP command as valid. Otherwise you could get spurious Illegal move error messages when you receive a command you did not bother to implement. And that would wreck things, as the GUI would take back the latest move on reception of that error message, so that engine and GUI would be out of phase from that point on.

Saver is to consider only tokens of which the second character is a digit or @ sign as moves, and the rest as commands.

Indeed, thanks for the warning, i'll try to make things safer.

[Ras]

Fun test: try putting "searchmoves" and its move list before other parameters like search depth. The UCI spec doesn't state that "searchmoves" has to be the last parameter, yet you'd be hard pressed to find UCI engines that can deal with this - not even Shredder itself.

[JimmyRustles]

Raven doesn't have any code to handle "go" without any parameters, so it defaults to doing a search with max move time (I think it's something like INT_MAX / 2), and max depth (128) which will result in it searching until it runs out of time (around 3 weeks) or hits depth 128.