Open tissatussa opened 3 years ago
Hi @tissatussa, thank you very much for the log, that's perfect, I'll investigate the issue and release a fix.
This new 0.7 version was mostly to indicate that I changed the public library of the engine to use it inside the OS I'm writing, so it's good to know that the bug was already present in the 0.6 version.
i'm glad to help .. it's also nice you restarted working on this (old) engine ! What is your purpose ? Will LittleWing be v1.0 at last ? And are you really working on an Operating System (OS) ?
There will definitely be a version 1.0 at some point! But I don't know when as I work only infrequently on the engine, a few weeks at a time per year at most. I'll have to check my notes but one big thing on the todo list would be to improve my Lazy SMP code and also to make the move generation faster. The end goal I think is to have a solid implementation of all the basic algorithms.
In the meantime I'm improving the public API that I used to add a chess game to MOROS. Which is indeed an operating system I'm writing, but a very small one at the hobbyist level, loosely inspired by Unix and Plan9.
Regarding this Issue i just discovered something : LW only fails to play properly in UCI mode !
I tested in CuteChess (on Linux) and when i set LW to Xboard, LW plays OK. See these screenshots, LW played Black :
in UCI mode :
in Xboard mode :
These 2 games were played from the starting position, time control was 3 minutes for the whole game, without any increment or "milliseconds (ms) margin". You can see in UCI mode LW uses all 180 seconds for its first move and then it must finish the game in "no time", so it fails .. however, in Xboard mode LW nicely decides to spend about 3 sec per move : this way, after move 60 LW has no time (!?) left and it must finish the game with "no time per move" .. it did succeed but lost the game.
Here's the ZIPped PGN from CuteChess : LW_2_test_games.zip
Hi @tissatussa, sorry I didn't have the opportunity to really investigate the issue yet. I don't have much time for side projects at the moment and most of it is dedicated to MOROS.
Do you set a number of moves for the given time? I think on UCI that could explain why the engine stays the whole time on the first move. I tried to set a standard 40 moves per 5 minutes on CuteChess and didn't see anything wrong, but then I switched to 5 minutes without a finite number of moves and I could reproduce the issue.
I set the default number of moves to 1 if none is provided here: https://github.com/vinc/littlewing/blob/trunk/src/protocols/uci.rs#L77 and the code assume it's provided: https://github.com/vinc/littlewing/blob/trunk/src/clock.rs#L50). UCI support for the engine is still very basic.
According to the protocol if the engine get wtime
and btime
without movestogo
it should then enter a sudden death where every moves should be played during that time interval.
This time control is not supported by the engine, but a quick fix may be to set a high number of moves, although it'd be better to refactor the whole thing for a better support of the protocol.
Do you set a number of moves for the given time?
No, the time control was 3 minutes for the whole game, without any increment or "milliseconds (ms) margin". This was my CuteChess setting :
I like the UCI protocol - you should implement it ! Until then, maybe put in the README how basic UCI is in LW, by writing what it can and can't do (in current v0.7.0) .. because a user will not suspect that poor play or even errors are due to this basic UCI implementation .. Btw. i think testing in CuteChess is good : when an engine performs well, with all (..) options, it passes an important test.
Thanks for the suggestion I'll add some information on the README about what is best supported!
I don't use the GUI, but cutechess-cli is one of the most essential piece of my testing process, I use it to play hundreds of thousands of very short games (40 moves in 10+0.1s) against other engines with different starting positions between releases. And indeed it's my main benchmark to tell if an engine is stable or not.
Yes, keep it simple but complete.
I like GUIs but i can do bash / scripts also .. I think the UCI protocol is nice and clear, and has many (standard) options .. in CuteChess GUI developers can even create selectboxes and browse-for-file buttons .. it does auto-pinging to verify the engine responses .. for fun and curiousity i test many older / simple / weak engines and maybe correct their code to make them run in CuteChess .. or not .. [so i wrote you ] .. i learn a lot by this practice .. and it's fun .. i'm a simple programmer, and this way i also learn a bit of Rust -- i managed to compile your code into a Linux v0.7.0 : thanks for motivation !
Thanks for the suggestion I'll add some information on the README about what is best supported!
screenshots & examples do wonders : clear, simple and fast info !
this issue seems related to #39 and #53 .. while testing LittleWing v0.7.0 in CuteChess, it fails to play properly because it takes ALL time to calculate its first move and then continues on the plus-time i set (being 3 or 5 sec) .. and indeed, when setting no plus-time, LittleWing moves instantly but then crashes with an illegal move .. i also tested with v0.6.0 but same result .. i use Xubuntu 20.04 and my CuteChess runs OK with many other UCI engines .. i guess the log shows that some UCI commands do not set the remaining time correctly ..
littlewing_bug_notime.zip