xunker
commented
10 years ago I chose to skip the info line because, at the time, properly parsing out the info line in a usable form was a bigger challenge than I wanted to take on (especially when I realized that most of the engines have specific tweaks to the info line that would need to be handled individually). My use-case then was very limited and I didn't need it at the time so I chose to omit it.
I believe parsing could be added, but I don't know the best way to get it back to clients using the ruby gem since, given the async nature of the info line, I wouldn't be able to return the info data until after the engine has given me 'bestmove' and I have stopped waiting for data, and by then I don't know how useful the info data would be.
It may be possible to have the client pass a callback that I could call for each info line asynchronously, but that's just a spur-of-the-moment idea I would need to research first.
As for getting the board state from the engine, I would have liked to be able to get that too, but many of the UCI engines I tried just don't provide that capability. I don't remember specifically which ones do an don't because it's been so long, but I do remember that is why I have the gem keep an internal log of all moves and why I added the #board and #fenstring methods, because I couldn't rely on the engine giving that info to me.
As I understood it, the engine expects the calling code to handle the state of the board (though I could be wrong). That's why there is the #moves array, because every time I execute a new move I pass all the previous moves as well. I tested stockfish, rybka, robbolita and fruit, and found that they don't really keep a internal state, they just process the next move based on the previous string of moves.
Some engines, like stockfish, don't require the whole history of moves, but they do require info like "has white castled already?" or "has black done en passant?", so instead of keeping track of that separately it was easier just to feed the entire history in to the engine.
So, as for your last question, #fenstring will give you a "short" fenstring of the board state, and #board will give you an ascii-art representation of the current board. You can also parse the #moves array directly to see all the pervious moves and build a current board state.
ALSO ALSO ALO, it's really important to know that I honestly know very little about chess, so it's totally possible I've made glaring errors.
I do welcome any input on this gem though, especially from someone who actually plays chess!
atduskgreg
Thanks for this great library!
I'm looking to use it to automate the evaluation of a series of board positions. This means I need access to the engine's info output. According to the protocol the engine is supposed to send an info command that includes a score for the position with a series of different attributes. This is what I want. I noticed that in read_from_engine() you explicitly skip info strings. Why? Is it just to avoid their verbosity?
I also noticed that the protocol provides no way for the client to specifically request info for the current board position from the engine. Am I missing something there?
Is there a simple way to add that feature without having to add a persistent info log? What would be the best approach that you'd recommend?