New engine releases & news 2021

[CMCanavessi]

Belofte 2.1.1 has been released on Win32/64, Mac32/64, Linux32/64 bit. I count on you for Apple sillicon, android , raspberry, solaris, ... binaries.
Strength improvement compared to 2.1.0: +100 +-50 elo. (In bullet +200 elo.) Estimated at 1250 elo.

Chess rules fixes:

• Make different draw claim based on FIDE rules.
  Only KK, KNK, KBK and KBKB with all bishops on the same color.
  Not KNNK, KBKN, KNKN and KBKB with unlike bishops;

• Bug fix: 50 moves counter is now cleared in case of capture with piece;

• Bug fix: 3 fold repetition more accurate, Hash collision less likely as now
  counting hash piece values instead of hash empty field values;

• Better time management in xboard protocol and after time control.

Search enhancements:

• Add Alpha-Beta Fail Soft, Alpha-Beta Fail Hard and make ABFS default.

• Sort moves before starting to search according to capture bonus and
  centerplay;

• Add partial Positional Board evaluation and make it default.

UI enhancements:

• Small improvement in output during search. Debug and log if set.

• Support for CECP and UCI. Perft.

• Documentation update.

Important open issues. Segmentation fault upon exit of Mac 64 bit version. (after quit command)

Nice improvement !!!

[Gabor Szots]

Hi Yves,

This seems a milestone version. I'm starting my tests this afternoon (using my 64-bit compile).

[Archimedes]

Belofte 2.1.1 has been released on Win32/64, Mac32/64, Linux32/64 bit. I count on you for Apple sillicon, android , raspberry, solaris, ... binaries.

Android version.
https://app.box.com/s/hkg2fu7lnm7ctktn9fl302p9hy6htbuj

[mvanthoor]

Belofte 2.1.1 has been released on Win32/64, Mac32/64, Linux32/64 bit. I count on you for Apple sillicon, android , raspberry, solaris, ... binaries.
Strength improvement compared to 2.1.0: +100 +-50 elo. (In bullet +200 elo.) Estimated at 1250 elo.

Very good I hope the feedback I gave you in the Rustic thread was useful.

[jshriver]

LC0 v0.27.0 is out now

https://github.com/LeelaChessZero/lc0/r ... ag/v0.27.0

[jshriver]

no start position and go w/o anything? (you can crash more programs that way)

Aye my bad, thought engines always defaulted to starting position at start. Played a few games and it's a fun engine to play. Congrats to niel!

[mvanthoor]

no start position and go w/o anything? (you can crash more programs that way)

Starting the engine and typing "go" should be possible without crashing the engine IMHO.

- Set up the start position when booting, contrary to the spec, which states to delay this to make the engine "start as fast as possible" (as if an engine takes 30 seconds to start and setup the start position on a system produced in the last 15 years....)
- Accept both "go" and "go infinite" as being "go infinite"
- Don't require ucinewgame to start the first game (the only thing ucinewgame does in my engine is set up the starting position and clear the hash table. With each "position startpos moves [...], the engine just replaces the internal board and plays the move without clearing the hash table. The GUI doesn't even need to send ucinewgame.)
- Just ignore unknown incoming commands. Sending a reply can crash some GUI's as THEY don't always ignore incoming commands.

I don't know if I'm completely there yet, but I'm trying to make my engine crash-free in this regard. For example, when receiving "position startpos {moves}", it doesn't change the position when the FEN is illegal, and it stops playing moves (with an "info string <error>") if it encounters an illegal move.

[mar]

Starting the engine and typing "go" should be possible without crashing the engine IMHO.

- Set up the start position when booting, contrary to the spec, which states to delay this to make the engine "start as fast as possible" (as if an engine takes 30 seconds to start and setup the start position on a system produced in the last 15 years....)
- Accept both "go" and "go infinite" as being "go infinite"
- Don't require ucinewgame to start the first game (the only thing ucinewgame does in my engine is set up the starting position and clear the hash table. With each "position startpos moves [...], the engine just replaces the internal board and plays the move without clearing the hash table. The GUI doesn't even need to send ucinewgame.)
- Just ignore unknown incoming commands. Sending a reply can crash some GUI's as THEY don't always ignore incoming commands.

I don't know if I'm completely there yet, but I'm trying to make my engine crash-free in this regard. For example, when receiving "position startpos {moves}", it doesn't change the position when the FEN is illegal, and it stops playing moves (with an "info string <error>") if it encounters an illegal move.

exactly what I do, at startup I prepare startpos, go = go infinite in my case
typicall however I fire up my engine from commandline and type something go depth 20
also - any command other than "xboard" coming first switches to UCI mode

I should probably report illegal moves via info string as well - for example I've recently removed Arena hacks related to Chess960; Arena doesn't honor UCI spec (sends castling as O-O-O instead of kxr in UCI notation) and doesn't even truly support Chess960 (doesn't allow legal castling in some cases)

[mvanthoor]

exactly what I do, at startup I prepare startpos, go = go infinite in my case
typicall however I fire up my engine from commandline and type something go depth 20
also - any command other than "xboard" coming first switches to UCI mode

My engine is basically UCI and XBoard on top of its own infrastructure; to switch protocols, I would need to unload the communication object and load a different one. It's possible to do, but I don't see an engine switching protocols mid-game. The default is UCI, because nowadays, that's the default for most GUI's. If you want xboard, the engine can be started with: "rustic -c xboard" (when I actually finish the protocol and merge it into master that is).

I should probably report illegal moves via info string as well - for example I've recently removed Arena hacks related to Chess960; Arena doesn't honor UCI spec (sends castling as O-O-O instead of kxr in UCI notation) and doesn't even truly support Chess960 (doesn't allow legal castling in some cases)

I didn't know what to do there. The spec says to try and keep parsing, discarding any illegal stuff. With moves that's not really possible, so I opted to the following:

- Try to set up the FEN. If that doesn't work, don't change the board and print an "info string".
- If the FEN setup works, start executing the moves. If a move is illegal (the engine actually executes them using its own make() function), it will be unmade, make() will return "false", and then the engine will print an "info string" with the illegal move in it and stop parsing there. The position will be the one just before the illegal move.

This will probably not be useful when the engine is loaded into a GUI, but I also sometimes want a quick analysis / test on the command line. It's very convenient when you put in an FEN, or a string of moves, and the engine can tell you exactly what is wrong at which point.

[mar]

My engine is basically UCI and XBoard on top of its own infrastructure; to switch protocols, I would need to unload the communication object and load a different one. It's possible to do, but I don't see an engine switching protocols mid-game. The default is UCI, because nowadays, that's the default for most GUI's. If you want xboard, the engine can be started with: "rustic -c xboard" (when I actually finish the protocol and merge it into master that is).

I didn't mean that I switch protocols on the fly midgame, I simply switch to xboard if first command from the GUI is xboard