Preface

Here I would to announce some problematic characteristics of UCI engines that might be of interest to some users.

Personally, I mostly use the latest version of Stockfish, so there shouldn't be any problems with that engine.

About good things and bad things

The UCI standard is a good thing, but not a perfect one. For example, there is no definition of how engines should deal with a stalemate position. And so the engines react very differently. In order for the GUI to be able to cope with each (new) engine, the GUI must therefore be able to recognize and deal with stalemates itself, and therefore doing the engine's work.

Some engine programmers think what applies to stalemate also applies to mate. So they treat mates their own way, even though the UCI standard has a definition for that (maybe an incomplete definition as one may argue).

But there is more. There are a few crystal clear rules that an UCI engine has to follow. But some engines deliberately ignore these rules, and then it looks like the stupid GUI is to blame.

This week a few rule breakings by engine programmers stole a lot of my time again. That's why I started this page.

Rule: For every "go" command a "bestmove" command is needed!

There are several go commands the GUI can send to the engine to start an evaluation. The end of an evaluation is announced by the engine with a bestmove command, which contains the best move. But what happens if there is no best move, for example in a stalemate? Well, some engines exemplarily send "bestmove <none>". Not so Hermann 2.8. If you use this engine with the Chess Suite, you should therefore avoid stalemates at all costs!

Rule: The debug mode should be switched off by default.

In debug mode the engine should send additional infos to the GUI, but only then. The Berserk 10 engine sends a lot of debug information and there is no way to switch this off!

One free version of Komodo sends one line of debug information, when tablebases are used. This is probably more of a programming error than a breach of the rule.

Rule: Deal with any allowed order of commands.

The standard says little about the order of commands, and therefore the engine should be able to deal with any allowed order until an evaluation is started with a "go" command. Stockfish 11, however, can be corrupted by sending a position first, and only then the Chess960 command (both commands are send before the evaluation is started).

I had a rather unpleasant experience telling this in the SF forum, and I was way to polite, when I was treated like an idiot by some nitwit. I left an analysis of the SF code(!) there, but I don't know if the bug has since been fixed.

(Only loosely related to: Many engines can never recover from an incorrect position information, e.g. nine white pawns. What would you say if you had to restart your chess GUI if you did something wrong? Just saying.)

To be continued.

Bugs

Apart from breaking the rules, there are of course also software errors, so called bugs. The Chess Suite is a large software package and certainly has many of them. Therefore, it should be said here that I do not mention the following engine issues to denounce them. It is only a list of known bugs.

1. Ethereal 11.25 (POPCNT)

This engine can be become unresponsive for some positions. One example: 6k1/3QK3/8/8/p7/P7/1P5q/8 b - - 0 1. Without Syzygy tablebases, the engine stopped sending results after a depth of 12, 15 or 17 plies, depending on the  runtime conditions. With Syzygy support, it runs fine for this position.

To be continued.