WinBoard-AA beta release

[hgm]

So why waste time on specifying it? Because that is what you propose. That you would need to transfer keyboard focus to the second-engine field and erase it. To achieve something that can already be achieved now, namely selecting Stockfish also as second engine. (Which would also be a waste of time, if you are not going to use a second engine.)

If you are only interested in using Stockfish, it would be better to edit the Engine List (Engine -> Edit Engine List), and move Stockfish to first place. Then it would be automatically shown as default both in the first and second combobox, and you would never have to select anything, and could press 'OK' in the Startup Dialog right away.

BTW, to start up with 2x Stockfish the WinBoard-AA package contains a file StockfishV.xop, which you can drag on top of the winboard.exe icon to achieve that. If you associate the .xop file type with WinBoard (Open With -> Other -> Always use this program to open this file type), you can even simply double-click that .xop file to start WinBoard with Stockfish.

You can also set the -viewerOptions to start with Stockfish, instead of in -ncp mode, and associate the .pgn file type with WinBoard as well. Then WinBoard already starts with Stockfish if you double-click the PGN file:

-viewerOptions {-cp -fcp Stockfish.exe -fd ../Stockfish -fUCI -scp fmax -sd ../Fairy-Max}

There are already zillions of ways to customize WinBoard, and I really think that having people erase the second-engine field is in any way useful.

[lantonov]

So why waste time on specifying it?

For me, using 2 same engines playing against each other is a quick and lazy way to determine if a given position is won for white or black (or draw).
With Winboard, I have no problem doing this for the normal/FRC Stockfish. For the variant Stockfish, Winboard insists that the second engine doesn't play Fairy-Max, even though I have specified the second engine to play suicide/zh/losers/atomic, etc. This happens even with the newest dev version of Winboard (Jan 6)

[hgm]

Then you must do something wrong, because I don't have that problem at all. In the first place, 'Fairy-Max' is not a variant, but an engine, so I have no idea what you mean by "doesn't play Fairy-Max". In the second place, you don't specify that an engine plays something. An engine either plays a variant, or it doesn't. You can only instruct the GUI to switch to a certain variant, and if you then try to use an engine that doesn't know this, the GUI will detect your error and voice a complaint.

Since you mention Fairy-Max, it seems you did not select Stockfish at all as second engine, neither from the startup comboboxes, nor through the Load Engine dialogs. If both engines were really Stockfish, WinBoard would never have any reason (orpossibility) to refer to Fairy-max.

[lantonov]

I also suspect that the problem is in my settings. I have to check the exact message but as I remember it was the variant "Fairy" (not "Fairy-Max", my fault).
My settings for the first engine are:
"UCI2WB -var crazyhouse stockfish.exe C:\WinBoard\Stockfish" -fd "." -variant crazyhouse -firstOptions "UCI_Variant=crazyhouse"
for the second engine:
"UCI2WB -var crazyhouse stockfish.exe C:\WinBoard\Stockfish" -sd "." -variant crazyhouse -secondOptions "UCI_Variant=crazyhouse"
"crazyhouse" is only for the example. The same error comes up for the other variants, too.

I should also mention that your package Winboard-AA doesn't give this error.

[hgm]

Well, these are settings as they would be needed with a UCI2WB adapter version from before I made the WinBoard-AA package. In that package the use of UCI2WB is fully transparent, invoked by the single option -fUCI . It takes automatically care of reporting the supported variants, as announced by the engine, and selecting one of those through the WinBoard 'New Variant' menu. So the settings used in the WinBoard-AA package is

"stockfish.exe" -fd "../Stockfish" -fUCI

If you want WinBoard to automatically switch to Crazyhouse whenever you load the engine you could still add -variant crazyhouse , but that is not a necessity, and only done for saving you the trouble of opening the New Variant dialog to select it. (Which you would still have to do anyway if you then wanted to use that Stockfish for another variant that Crazyhouse, such as Horde or King of the Hill.)

[lantonov]

Thanks. I didn't know about these new setting and will adjust them accordingly.

[Guenther]

Well, these are settings as they would be needed with a UCI2WB adapter version from before I made the WinBoard-AA package. In that package the use of UCI2WB is fully transparent, invoked by the single option -fUCI . It takes automatically care of reporting the supported variants, as announced by the engine, and selecting one of those through the WinBoard 'New Variant' menu. So the settings used in the WinBoard-AA package is

"stockfish.exe" -fd "../Stockfish" -fUCI

...

That remembered me to change the workaround registering of the '/uxiAdapter' option back to normal.

[hgm]

In the WinBoard-AA package I configured

-adapterCommand {UCI2WB "%fcp" "%fd"}
-uxiAdapter {UCI2WB -%variant "%fcp" "%fd"}

This causes -fUCI and the UCI checkbox (which draws on the -adapterCommand) to indeed force UCI, while -fUCCI or -fUSI or UCCI/USI checkbox might also use UCI2WB in UCCI or USI mode, depending on the variant (for xiangqi and shogi, respectively). This because the protocol-selection option of UCI2WB only looks at the first letter after the dash, so that using the uxiAdapter for, say, variant seirawan would also select USI instead of UCI.

[Guenther]

In the WinBoard-AA package I configured

-adapterCommand {UCI2WB "%fcp" "%fd"}
-uxiAdapter {UCI2WB -%variant "%fcp" "%fd"}

This causes -fUCI and the UCI checkbox (which draws on the -adapterCommand) to indeed force UCI, while -fUCCI or -fUSI or UCCI/USI checkbox might also use UCI2WB in UCCI or USI mode, depending on the variant (for xiangqi and shogi, respectively). This because the protocol-selection option of UCI2WB only looks at the first letter after the dash, so that using the uxiAdapter for, say, variant seirawan would also select USI instead of UCI.

Does this mean ucci2wb, which I never had needed, is obsolete now
and combined in the uci2wb adapter?
(before, the uxiadapter was registered for ucci2wb)

[hgm]

Indeed. UCCI2WB is now obsolete. Originally it was a hacked version of UCCI2QH written by Huang Cheng (aka 'Morning Yellow'). It took me some time to incorporate its functionality in UCI2WB, because UCCI has the nasty property that the position-moves command must only send reversible moves, starting from a FEN of the position after the last irreversible move. As UCI2WB originally was completely game-state unaware, this was problematic. But now it keeps track of the board position, which at least is accurate for Xiangqi (which has no castling or e.p.), the only variant where it is needed.