XBoard alpha with PV display

[hgm]

I managed to port the most recent WinBoard enhancements to XBoard. A binary Debian package of the alpha version can be downloaded from:

http://hgm.nubati.net/xboard_4.devel~hgm-6_i386.deb

Be welcome to test it!

The two major new features are:

Show PV

Display of positions in the PV, under control of the right mouse button, in modes that involve an engine. To activate this, you have to right-click the board. This will then show the position at the end of the most recent PV the engine produced in its Thinking Output. (In Two-Machines mode that of the engine on move.)

Moving the mouse vertically while keeping the right button pressed, will then step through this PV move by move, so that you can see how the engine thinks this position will be reached from the current game position.

Releasing the right mouse button, or the thinking engine doing a move, will leave this mode and put the latest game position back in the display.

In old XBoard versions, right-clicking the board in some variants (e.g. bughouse) would bring up the piece-drop menu. This now has been officially deprecated, so the PV display can work even in those variants. Only in Edit-Position mode right-clicking the board will still bring up a menu. To restore the old behavior, a new option is provided; xboard -dropMenu true will disable PV display and uses the right mouse button for drop menus. (Default setting: false.)

This feature currently only works with engines that produce a plain PV without frills: I feed the PV to the WinBoard parser that is also used to read PGN files, and anything that does not parse as a legal move or a comment will be considered termination of the PV. (The first move can be in parentheses, as many engines do while pondering.)

Show Move Target Squares

XBoard can now indicate the squares a piece can move to, with a colored circle, as soon as you 'pick up' the piece. (See picture below, for a Xiangqi example.)


picking up the Rook shows you where it can move to

This might not be very interesting for normal Chess, but it can be helpful for people playing variants. In variants like suicide, it highlights all captures, even those with pieces that you did not pick up, which might be helpful in case you overlooked a capture.

This feature is under control of the option -showMoveTargets true|false (default: false), but is only active when -testLegality and -highlightDragging are also switched on. The latter can be switched from the Option menu, and thus is a convenient way to control it interactively, when you permanently have -showMoveTargets on. (Especially since the true highlighting of dragging never worked under XBoard.)

[Michel]

I have the impression that the show PV feature does not yet work in analysis. Is this true?

[hgm]

You are absolutely right. I simply forgot that this is also a mode where an engine is active. When fixing it, it turned out that stat01 lines cleared the PV all the time, so that there was nothing to display when I activated the new code in Analysis mode. I fixed that too, now.

I put a fixed version at the same link as above. Now it should really work in all engine modes. I will fix it in WinBoard tomorrow.

[Dirt]

I simply forgot that this is also a mode where an engine is active.

Funny, I never though of trying to use it anywhere other than analysis mode. I just figured it didn't work at all on my system.

[hgm]

OK, there were some problems with the announced version when displaying the PV when the engine had already done the move, and pondering was off. Those should be fixed now.

So when the engine is thinking or analyzing, you should see the most recent PV it is thinking about. When the engine is pondering, you see what it is pondering about. When two engines play, you will see the PV of the engine that is thinking. If pondering is off, and the single engine is idle, you will get to see the last PV it printed before doing its move. (Hopefully this will start with the same move as it actually played, otherwise what will be displayed will have no reality value.)

The fixed version can be downloaded at the same link.

Please let me know if there are problems with specific engines. I am sure there will be many, when the engine dresses up its PV in a fanciful way (e.g. using smilies). If we have a good impression what kind of interjections most frequently spoil the parsing of the PV to the end, I could try to adapt the parser to ecognize these as 'comments'.

[michiguel]

OK, there were some problems with the announced version when displaying the PV when the engine had already done the move, and pondering was off. Those should be fixed now.

So when the engine is thinking or analyzing, you should see the most recent PV it is thinking about. When the engine is pondering, you see what it is pondering about. When two engines play, you will see the PV of the engine that is thinking. If pondering is off, and the single engine is idle, you will get to see the last PV it printed before doing its move. (Hopefully this will start with the same move as it actually played, otherwise what will be displayed will have no reality value.)

The fixed version can be downloaded at the same link.

Please let me know if there are problems with specific engines. I am sure there will be many, when the engine dresses up its PV in a fanciful way (e.g. using smilies). If we have a good impression what kind of interjections most frequently spoil the parsing of the PV to the end, I could try to adapt the parser to ecognize these as 'comments'.

I downloaded a test in a pgn format and started analyze mode. One of the positions worked, but the others just showed only the move that was in the pgn file (the move that was supposed to be the best move), regardless of what the engine (Gaviota) was thinking.

In th initial position, it does not work. Is that because Gaviota once in a while has a smiley in the PV?

Miguel

[hgm]

This is very possible. I don't know how the XBoard parser reacts to smilies. The way I programmed it is that it skips everything that parses as a comment, but smilies probably are not recognized as comments.

I guess the parsing is not as robust as it could be, because I haven't figured out yet how to make the parser tell me what was parsed and what wasn't. So when I sucesfully parse something (comment or legal move), I skip to the next space for parsing the next item. This works fine on normal PVs that are just moves separated by spaces. But it would fail if there is something that is simply ignored by the parser, and is separated by spaces from the following move. The parser then probably just skips over it and returns the move, but for the next move I will then skip to the space, and parse the same move agan (which of course will always be illegal). Another case where it would fail is something that parses as a comment, but is not separated by a space from the next move.

Move numbers are ignored by the parser (except number 1), which is no problem if they are not separated by a space from the move (like 13.Nf6), which they usually aren't.

I am not sure how it could show the move that is in the file. Does the engine echo that move somehow, in it Tinking Output? It should only act on what it gets from the engine, and be oblivious of any file.