WinBoard 4.8.0 for Shogi - Tanuki USI Engine

[Evert]

In fact this would be pretty easy. UCI2WB sets a string variable to "normal,xiangqi" or "shogi" as the protocol flag on its command line dictates, and a flag when it encounters UCI_Chess960. I could print both in a single printf when receiving 'uciok' rather than just the one requested by the frc flag. But all UCI 960 engines would then get the Xinagqi button in the New Variant dialog activated. There is unfortunately no way a UCI engine specifies it does NOT play Xiangqi, but having an option UCI_Chess960 is a very strong indication that it doesn't. Except for Sjaak...

Let me see if I understand this.
If UCI_Chess960 is set, you always send "normal,chess960".
In UCI or UCCI mode, you send "normal,xiangqi".
In USI mode you send "shogi,5x5+5_shogi".

I thought there were also Shogi engines that use UCI and so would need to have "shogi" listed under UCI? Or am I remembering this wrong?

Perhaps the logical solution would be to not print UCI_Chess960 (or to print USI_Chess960) when Sjaak is running in USI mode (i.e. afterreceiving the 'usi' command).

Yes, I guess that makes sense. I now don't print it unless in actual UCI mode.
As options go it's actually a rather silly one. The only real purpose of the option seems to be that its absence indicates that the engine doesn't play 960, and ticking it changes the move encoding from e1g1/e1c1 to KxR.
If you support more than one variant, listing them with checkboxes isn't exactly the best way to list them.

Well, in that case they're non-compliant* and should be fixed!

That would be the day... Unfortunately USI has almost become synonymous with non-compliant. And UCCI is not much better in that respect.

I recently made a change in Jazz so it disables the board and prompt if it detects that stdin is not a terminal; I could just plug that code into SjaakII as well and get rid of the problem that way. The only downside is that I don't know how to do that in Windows.

How does Sjaak work in Windows anyway? Does it use Windows API callslike PeekNamedPipe under an #ifdef?

Yes, it does. It has an "input_waiting()" function that has a UNIX and a Windows version under an #ifdef. Comments at the top suggest that I originally adapted it from Stockfish, but nearly identical versions exist in a couple of other programs.

You could print 'id name' in front of it; that wouldnot be very confusing to human readers.

No, but it would annoy me.
I made it just not print even that if you start it in UxI mode (they're all the same internally).

* At least according to UCI protocol; it's surprisingly hard to find information on USI other than "Tord made it based on UCI" and of course I didn't bother to keep a link to his description handy. I'm sure I have it somewhere if I really need it.

It is much worse than that. Tord's website no longer exists. There still is a description at http://shogi.typepad.jp/brainstorm/2007 ... 1a0_1.html , which search machines usually does not find. But on the Shogidogoro website they posted a mutilated version of it in Japanese, ( http://www.geocities.jp/shogidokoro/usi.html ), ignoring anything Shogidogoro does not implement (like sending 'isready'...).[/quote]
Ok, that is indeed bad. It's a shame the website is no longer up, I remember it had some neat stuff. Fortunately I'm paranoid about websites disappearing and I should have downloaded copies somewhere.

Archive.org also has the USI stuff though, https://web.archive.org/web/20150326001 ... i/usi.html

[Norbert Raimund Leisner]

I have installed on device C:\ on my computer:
https://github.com/HiraokaTakuya/apery/ ... ig_sdt3.7z

C:\apery_twig_sdt3\bin\apery_twig_sdt3_sse41.exe

C:\WinBoard\UCI2WB.exe
(application WinBoard 32-bit GUI = symbol of black knight is situated in the same sub-directory like UCI2WB.exe)

All what I want is a practical example for ComputerChess Wikipedia how a right implementation via USI-works and WinBoard works:

Tell me please, is this the right configutation? If not, a correction would be useful.
engine (.jar or.exe) = UCI2WB.exe
command-line parameters =
-s apery_twig_sdt3_sse41.exe.exe -C:\apery_twig_sdt3\bin\apery_twig_sdt3sse41.exe -uxiAdapter {UCI2WB -%variant "%fcp" "%fd"}

What meaning has %variant "%fcp" "%fd" in that case?

WinBoard-options = Set "Minimum_Thinking_Time" to "0"

UCCI/USI option -uxiAdapter {UCI2WB -%variant "%fcp" "%fd"} disabled

The Apery download package is extremely time-consuming , you can use instead of this program TJshogi USI http://tonyjh.com/chess/TJshogi.zip instead

C:\TJshogi\TJshogi_USI.exe

(By the way: TJshogi WB.exe runs without problems, but for my purposes the right USI-configuration is here important)
Maybe you cand send me WinBoard 4.8.0 inchluding TJshogi USI as email-attachment.

Best wishes,
Norbert

By the way: ShogiGUI http://shogigui.siganus.com/shogigui/Sh ... .0.6.3.exe has the option Game/Analysis/Notation Analysis with USI engines.

Hiraoka <hiraoka64@gmail.com> , author of Apery said:

"I haven't used WinBoard, but I received information that Apery could work on WinBoard. If Apery can't work on WinBoard, maybe the reason is timeout of WinBoard's "usi" command.
Apery on GitHub sends "usiok" after loading evaluation
binaries(KPP_synthesized.bin, KKP_synthesized.bin, KK_synthesized.bin).
They are aboud 800MB. If HDD is very slow, "usiok" sent late.

If evaluation binaries are not found, Apery make evaluation binaries from base evaluation elements. It takes a few minutes.
Evalution making is another reason of timeout of "usiok".

If you use Apery, prepare evaluation binaries. and Apery can work. maybe.
If Apery cannot work due to other reasons, WinBoard is wrong. Fix WinBoard please.

[hgm]

Let me see if I understand this.
If UCI_Chess960 is set, you always send "normal,chess960".
In UCI or UCCI mode, you send "normal,xiangqi".
In USI mode you send "shogi,5x5+5_shogi".

Indeed, that's it. Except that the latter two can be overruled by a first command-line argument (after a possible 'debug') -var xxx. I needed that to be able to run the Seirawan versions of Fruit and Komodo (or Petit Shogi for Judkin's Shogi).

I thought there were also Shogi engines that use UCI and so would need to have "shogi" listed under UCI? Or am I remembering this wrong?

I don't know any such engine. I do know some UCI Xiangqi engines (in particular the commercial Cyclone), but these use a modified version of UCI (the 'Cyclone dialect'), which does not know the keyword 'startpos', and leaves out 'position' before 'fen'. UCI2WB uses that dialect in UCI mode when the variant is xiangqi.

As options go it's actually a rather silly one. The only real purpose of the option seems to be that its absence indicates that the engine doesn't play 960, and ticking it changes the move encoding from e1g1/e1c1 to KxR.

And the latter could also be triggered by the castling field of the FEN instead. So it is indeed abuse of options for the purpose of one-way engine-GUI communication (which logically should have been done with 'id' commands).

If you support more than one variant, listing them with checkboxes isn't exactly the best way to list them.

Agreed. The introduction of the UCI_Chess960 option was a quite short-sighted design choice. It would have been much better if it had been a combobox.

The only downside is that I don't know how to do that in Windows.

I found the following example (in BASIC, but it should do). In my engines I ignore the possibility that stdin might not be a pipe, and always usePeekNamedPipe when testing for input. The result is that pondering and analysis do not work from the console, but I can live with that. An alternative method might be to use PeekNamedPipe and test for the error return code.

Code: Select all

    lType = GetFileType(hStdIn)
    If lType = FILE_TYPE_PIPE Then
        If PeekNamedPipe(hStdIn, ByVal 0, 0, 0, lAvailChars, 0) = 0 Then
            Exit Function
        End If
    End If
    If lType = FILE_TYPE_DISK Or lAvailChars > 0 Then
        sBuffer = Space(IIf(lAvailChars > 0, lAvailChars, 512))
        Call ReadFile(hStdIn, ByVal sBuffer, Len(sBuffer), lChars, 0)
        ConsoleReadAvailable = Left$(sBuffer, lChars)
    End If
    If GetConsoleMode(hStdIn, lMode) <> 0 Then
        Call SetConsoleMode(hStdIn, 0)
        Do While PeekConsoleInput(hStdIn, baBuffer(0), 1, lEvents) <> 0
            If lEvents = 0 Then
                Exit Do
            End If
            If baBuffer(0) = KEY_EVENT And baBuffer(4) <> 0 Then ' baBuffer(4) = INPUT_RECORD.bKeyDown
                sBuffer = Space(1)
                Call ReadFile(hStdIn, ByVal sBuffer, Len(sBuffer), lChars, 0)
                ConsoleReadAvailable = ConsoleReadAvailable & Left$(sBuffer, lChars)
            Else
                Call ReadConsoleInput(hStdIn, baBuffer(0), 1, lEvents)
            End If
        Loop
        Call SetConsoleMode(hStdIn, lMode)
    End If

Archive.org also has the USI stuff though, https://web.archive.org/web/20150326001 ... i/usi.html

Thanks for that link. I will copy these specs, and post them on my own website.

[hgm]

All what I want is a practical example for ComputerChess Wikipedia how a right implementation via USI-works and WinBoard works:

Tell me please, is this the right configutation? If not, a correction would be useful.
engine (.jar or.exe) = UCI2WB.exe
command-line parameters =
-s apery_twig_sdt3_sse41.exe.exe -C:\apery_twig_sdt3\bin\apery_twig_sdt3sse41.exe -uxiAdapter {UCI2WB -%variant "%fcp" "%fd"}

No. One problem that would certainly make it fail is that there is a spurious minus sign prefixed to the directory path ("-C:\...").

What meaning has %variant "%fcp" "%fd" in that case?

It is one of the things that makes it wrong. -uxiAdapter is not a UCI2WB option, it is a WinBoard option. The command-line parameters given in this dialog are for the command line of the engine start command (the UCI2WB adapter, in this case). So putting -uxiAdapter there only serves to confuse UCI2WB.

This whole method of installing engines (namely explicitly referring to the adapter) is not recommended, however. The intended method for embedding USI engines is tick the USI/UCCI checkbox. Future WinBoard releases will certainly be configured to make sure this works. Unfortunately due to an oversight WinBoard 4.8 is still distributed with a configuration that makes this checkbox only work for UCCI engines, using the (now obsolete) UCCI2WB adapter.

Rather than advertizing a deprecated method of engine embedding, any 'How To' should specify how to cure that, and configure WinBoard properly. It could do this by saying

To cofigure WinBoard for running USI or UCCI engines, one needs to run it once with "Additional options" (in the Startup Dialog) specified as

/uxiAdapter={UCI2WB -%variant "%fcp" "%fd"}

This will cause WinBoard to invoke the UCI2WB adapter in the proper mode, in response to ticking the USI/UCCI checkbox or specifying the -fUSI / -sUSI / -fUCCI / -sUCCI options. This step will be required for WinBoard versions 4.8 and older, or installs that might have inerited settings from such an older version, as otherwise the less-capable UCCI2WB adapter would be used.

The the specific example for Apery becomes:

engine (.jar or.exe) = C:\apery_twig_sdt3\bin\apery_twig_sdt3_sse41.exe.exe

All other text input fields left empty.
Tick USI/UCCI checkbox

Toprevent forfeit by flagging at fast time controls you will need to change the engine's minimum time setting in its Egine Settings dialog:

Set "Minimum_Thinking_Time" to "0"


The other issue can be ignored; WinBoard+UCI2WB will never timeout onloading USI egines.