rofChade 3.0

[Krzysztof Grzelak]

A huge request to the author of the engine rofChade 3.0. Is it possible to ask you to improve the current version of the engine so that the basic functions of the engine are displayed correctly. I noticed that the program does not correctly display information in the GUI Shredder Classic 5.Thank you in advance for fulfilling my request.

Krzysztof.

[Ras]

Is it possible to ask you to improve the current version of the engine so that the basic functions of the engine are displayed correctly.

I guess it would be helpful to describe what exactly is not being displayed correctly. "Basic functions" doesn't mean anything. It could as well be the GUI's fault, in which case reviewing the engine code based on such a vague bug report would be a waste of time.

A quick glance at the UCI output of Rofchade showed no issues except the mate scores being off by one when losing:

Code: Select all

position fen 6nq/4pPpk/5bpp/7r/8/1B5P/5PP1/6K1 b - - 0 1
go depth 10
info score mate -2 depth 2 nodes 567 nps 70875 time 8 tbhits 0 pv h5b5 
bestmove h5b5

[Krzysztof Grzelak]

The engine does not show the best movement and the hash it uses when moving.

[Ras]

Best move and PV are there properly:

Code: Select all

position startpos
go movetime 2000
info score cp 56 depth 10 seldepth 15 nodes 25098 nps 678324 time 37 tbhits 0 pv e2e4 e7e5 g1f3 b8c6 d2d4 e5d4 f3d4 f8c5 d4c6 d7c6 
info score cp 46 depth 11 seldepth 19 nodes 75407 nps 628391 time 120 tbhits 0 pv e2e4 e7e5 g1f3 g8f6 b1c3 d7d6 d2d4 b8d7 f1c4 f8e7 d4e5 
info score cp 46 depth 12 seldepth 15 nodes 91107 nps 603357 time 151 tbhits 0 pv e2e4 e7e5 g1f3 g8f6 b1c3 
info score cp 35 depth 13 seldepth 18 nodes 214085 nps 543362 time 394 tbhits 0 pv e2e4 e7e6 d2d4 d7d5 b1c3 g8f6 c1g5 d5e4 c3e4 f8e7 e4f6 e7f6 g5f6 
info score cp 26 depth 14 seldepth 23 nodes 328172 nps 537106 time 611 tbhits 0 pv e2e4 e7e6 d2d4 d7d5 e4e5 c7c5 c2c3 b8c6 g1f3 a7a6 f1d3 g8e7 e1g1 e7g6 
info score cp 26 depth 15 seldepth 24 nodes 730582 nps 775564 time 942 tbhits 0 pv e2e4 e7e6 d2d4 d7d5 e4e5 
info score cp 31 depth 16 seldepth 26 nodes 1271085 nps 898928 time 1414 tbhits 0 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 g1f3 g8f6 b1c3 
info score cp 31 depth 17 seldepth 26 nodes 1603901 nps 934129 time 1717 tbhits 0 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 g1f3 g8f6 
info score cp 31 depth 18 seldepth 29 nodes 1886538 nps 939979 time 2007 tbhits 0 pv e2e4 e7e6 d2d4 d7d5 e4d5 e6d5 g1f3 
bestmove e2e4 ponder e7e6

What isn't there is UCI's optional hash table usage via hashfull as well as the current root move being examined. The latter would be via UCI's currmove and currmovenumber and could be either refreshed upon every root move search update, or (that's how I do it) only once per second because a faster update would not be human readable anyway, and then also update the hash table usage as well.

So the feature request is about implementing hashfull, currmove, and currmovenumber?

[Krzysztof Grzelak]

This can only be done by the engine programmer himself to make it work properly.

[Ras]

This can only be done by the engine programmer himself to make it work properly.

Ofc, but now he can at least see what the request is even about.