Greg Strong wrote:Also, I've rolled in all the command line/winboard support code written by H. G. as a separate build option. Thanks for doing this, H. G.!
I tried to arrange it in such a way that, when called without a command-line argument, ChessV would behave in exactly the same way as before. (I.e. not startup the input thread that looks at its stdin, and suppress the print statements to stdout.)
When run with an argument it seems to have a little quirk, though: when it s terminated from the WB interface through a
quit command, it uses exit() to kill the entire app. But when you try to kill it by clicking the close button on the GUI (which you should not do when you run it under WinBoard, but you could do it by mistake), it kills the GUI thread, but not the console I/O thread.
The thing that is still sadly missing from WB protocol is the edit-position command (either
setboard <FEN> or
edit). This because it seemed ChessV did not support setting up a position, and it would require intricate knowledge of its internal game representaton to write one from scratch.
The most wrecking thing for its playing strength is currently that it does not see promotions coming; I hope you can fix that.
A practical problem is the naming of pieces, and how to indicate them in WB-protocol promotion moves. I currently use the moveInfo.promotion->GetFullName() method to understand the ChessV promotion moves, where I use the algorithm that a piece called "Knight" will be represented by 'n', and any other piece by its (decapitalized) initial character. This works for Capablanca, but there is in general no guarantee that no two pieces will start with the same character. And it causes problems when trying to run, (say) Schoolbook Chess as WB variant capablanca, because a Chancellor in Schoolbook Chess is caled a Marshall. Now the piece letters in WB can be configured as well, and the defaults actually are, on a per-variant basis, but unfortunately not on a per-engine basis. So configuring the R+N piece in WB as 'M' would solve the problem for
ChessV "Schoolbook Chess", but then the opponent engine will likely not understand the promotion moves, unless it is also configurable in this respect (such as Fairy-Max). I guess the ultimate solution here is that I should allow the pieceToCharTable of WB to be set differently for each engine (as well as for PGN/FEN), which is not a ChessV problem. But a possible ambiguity of the letter-to-piece assignment should be solved in ChessV. Is there a beter way to obtain a suitable promotion character for a piece that is guaranteed to be unique within that variant?
One other minor issue: When I was adding printing of the WB RESULT command (1-0, 0-1 or 1/2-1/2) I got the impression that one of the popups you have ChessV show in native mode was the wrong way around. (Mentioning the same player as winner for a score-wise opposite case.) This code in ChessV is a bit messy, no doubt because it accumulated over time as you added more variants with non-standard winning conditions (I had the same problem in WB, when I wanted to make it determine that game result). Perhaps it would be good to replace it by a single end-of-game-test routine (that could be called both before and after the computer starts thinking, and after entering of a user move). You could independently determine a result (WhiteWins, BlackWins, Draw) and a reason string (checkmate, stalemate, king destroyed, bare king, check, insufficient mating material), that would then be used to print a WB result or format a message popup. It would then be much easier to keep the WinBoard patch localized; now I had to scatter printf calls all over the place in Board.cpp, and I am still not sure that I did it everywhere correctly.
You said my code might be backwards on one of them. It certainly could be; I'll double check them!