WinBoard-AA beta release

[lantonov]

ddugovic made a patch on his variant Stockfish github with which he disabled the variant relay

[hgm]

Indeed, that was because I relayed your complaint to him.

[lantonov]

I was there first

https://github.com/ddugovic/Stockfish/issues/154

[JoshPettus]

If we nix polyglot, should we also remove the USI/UCCI checkbox since there would only be one adapter? (Or rather make the UCI one a UCI/UCCI/USI checkbox?)

[hgm]

I guess we should go for a single checkbox. OTOH, the traditional way of configuring UCI2WB as uxiAdapter used a -%variant optionon UCI2WB to select the protocol. This works for Xiangqi / UCCI and Shogi / USI, and for Chess and most other variants, since the protocol defaults to UCI. But it would fails for variants with a name starting with x or s. E.g. Seirawan Chess. For Xiangqi there is the problem that there are UCI as well as UCCI engines, and theUCIenginescouldnot be installed through the checkbox if Xiangqi implies UCCI.

With separate UCI and UCCI/USI checkboxes we could configure UCI2WB in forced UCI mode by not adding the -%variant option, I.e.

-adapterComand {uci2wb "%fcp" "%fd"}
-uxiAdapter {uci2wb =%variant "%fcp" "%fd"}

That would provide a reason for keeping a separate checkbox for UCI.

[styx]

Is it possible to output Algebraic Notation when using UCI2WB Adapter?

So for example "Nf3" instead of "g1f3" ?

[JoshPettus]

Isn't the whole point of an adapter is to take input from one protocol and output to another? That notation wouldn't be within the winboard protocol.

Xboard itself has all sorts of programing to make such assumptions for moves with little data, but most engines aren't really meant to be smart in that way. Remember UCI engines have no concept of positioning as they are stateless.

Could you explain why you need it as such?

[styx]

It's just easier to read for the human eye since you instantly know what kind of piece to move.

I just thought it is an adapter thing, since the polyglot output is in algebraic notation.

But you are right. Maybe it's the GUIs responsibility to format the notation.

It's not a big deal. I am happy if everything stays as it is. But if there is a way to do it, I'd do it!

[JoshPettus]

Unlike polyglot, the reason for UCI2WB is that it doesn't know anything about game rules, so it is far more malleable for chess variants. As such, is more inline of the goals xboard. Though not knowing about chess rules makes it difficult for chess algebraic notation. (Nf3? Which Knight?) We really should blame UCI for that though, not the adapter.

[hgm]

XBoard has options -fSAN, -sSAN, which will convert the engine PVs to SAN. So installing the engine with the additional option -fSAN should solve your problem. The downside from this option is that it would make everything that is not a move disappear from the PV the engine originally printed. This because it works by parsing the originalPV like it is PGN, and then only converts the detected moves back to SAN. But with UCI engines that would not be a problem, as they would never print anything but moves in their PV.

Another downside is that it makes the GUI eat more CPU time. XBoard's move parsing and SAN generation is not very efficient. So for hyper-bullet matches use of this option is not recommended. (But you would have no time to read the PVs anyway...)