WinBoard 4.8.0 for Shogi - Tanuki USI Engine

[Norbert Raimund Leisner]

Hello HGM,

"nodchip" created Tanuki, an USI-compatible engine here:
https://github.com/nodchip/tanuki-/releases/tag/WCSC26

He said:
"Are you able to try tanuki-wcsc26-sse42-gcc-lazy-smp.exe in it? Could you install "Apery SDT3, the 3rd Denousen-tournament version" https://github.com/HiraokaTakuya/apery/ ... ig_sdt3.7z , and extract the tanuki- WCSC26 2016-09-10 binaries into the "bin" folder? Please make sure the "bin" folder contains "20151105" folder, and "20151105" contains "KPP_synthesized.bin", "KKP_synthesized.bin" and
"KK_synthesized.bin". Tanuki edition WCSC26 2016-09-10 reads those files on startup. But it takes long time if those files don't exist, and Shogidokoro will show "not an USI engine" because of timeout

So far-so good: Tanuki works without problems on Shogidokoro GUI 3.7.2 http://www.geocities.jp/shogidokoro/dow ... dokoro.zip for Japanese Chess.

But with WinBoard just after 3 moves Tanuki made an illegal move:
cf. these issues:
https://github.com/nodchip/tanuki-bin/issues/6
https://github.com/nodchip/tanuki-bin/issues/8

What be be done or improved? Such a different behaviour on two different GUIs by the same program seems to be very strange.

Why contains ShogiBoard package = WinBoard 20100211 no menu "load first engine / load second engine"? Do you still have plans to implement these features at a later moment ?

Best wishes,
Norbert

[hgm]

WinBoard 20100211 is a very old WinBoard version (as the number suggests it is from 2010), so it lacks many features that modern WinBoard has. I never updated the dedicated Shogi package, because it has become sort of superfluous. It was made in a time when WinBoard couldnot be configured torun both USI and UCCI engines, as these needed different adapters. So the standard WB package was not configured to run Shogi engines, and therefore I made a special Shogi package were this was the case. Alsoit was pretty cumbersome to switch the WinBoard display to a traditional oriental Shogi look,and the dedicated Shogi package also pre-configured that.

Nowadays UCI2WB can handle both UCCI and USI, and is configured to be the uxiAdapter in the standard install. So USI Shogi engines run just as easily in the standard install as UCI Chess engines and UCI or UCCI Xiangqi engines. Furthermore, WinBoard can now store and recall complete combinations of graphics settings as 'themes', and the standard install comes with pre-defined oriental Shogi and Xiangqi themes. That sort of removes the need for dedicated Shogi and Xiangqi packages, so that I never made newer versions of those.

I still do host dedicated packages for mini-Shogi and general Shogi variants, but the mini-Shogi package contains a lot of engines not normally included in the standard install (which would not be desirable, as almost no one would use them), and the Shogi-variants package uses a fork of WinBoard ('The Alien Edition') which can do some things the standard version can not.

I will try to run Tanuki with Apery evaluation, but I will first have to download Apery, and this might take an hour.

[hgm]

OK, after 3 attempts I finally succeeded downloading Apery.

When I put the tanuki executable in the Apery bin folder, start WinBoard with Bonanza, browse to the tanuki.exe with the Load Engine dialog, tick USI and Úse with this variant' and click OK, I can play 1min + 1sec/move games with only the usual TC troubles. No idea why you would get an illegal move. And impossible to figure out without more information. (E.g. what TC were you using?)

[Norbert Raimund Leisner]

Hello HGM and Evert,

nodchip said:
https://github.com/nodchip/tanuki-/comm ... 75b0e96f88

+1. Install WinBoard 4.8.0. The installation path is "C:\WinBoard-4.8.0".
+2. Download "apery_twig_sdt3.7z" from http://hiraokatakuya.github.io/apery/, and extract to "C:\WinBoard-4.8.0\apery_twig_sdt3".
+3. Download "tanuki-2016-09-10.7z" from https://github.com/nodchip/tanuki-/releases, and extract to "C:\WinBoard-4.8.0\apery_twig_sdt3\bin".
+4. Start "C:\WinBoard-4.8.0\WinBoard\winboard.exe".
+5. Check "Advanced options", and set -uxiAdapter {UCI2WB -%variant "%fcp" "%fd"). Please refer #8 (comment) about this step.
+6. Add "tanuki- WCSC26" with the following settings:
+ Engine (.exe or .jar): C:\WinBoard-4.8.0\apery_twig_sdt3\bin\tanuki-wcsc26-sse42-gcc-lazy-smp.exe
+ command-line parameters: empty
+ Special WinBoard options: empty
+ directory: empty
+ UCCI/USI [uses specified /uxiAdapter]: on
+7. Engine > Engine #1 Settings... > Set "Minimum_Thinking_Time" to "0".

I tried this, steps 1-6 are comprehensible for me - but how can be added the option - Set "Minimum_Thinking_Time" to "0"?

Can you please just configurate such an.ini-file for WinBoard with the purpose that Tanuki SSE42 x64 GCC-Lazy does executes moves? For example: 5 min-engine match (against Shokidoki WB), additional time = 0 seconds?

By the way: Would a direct USI interface for further WinBoard editions be a better solution than using the USI/UCCI-converter?

In my opinion, Shogidokoro http://www.geocities.jp/shogidokoro/dow ... dokoro.zip and ShogiGUI http://shogigui.siganus.com/shogigui/Sh ... .0.6.3.exe are pure "USI"-graphical interfaces.

Sjaak II 1.3.1a x64 runs as Shogi-WB-compatible engine well under WinBoard 4.8.0, but has problems to work via USI-protocol http://www.eglebbk.dds.nl/program/downl ... 1a-win.zip

What could the the reason for this behaviour?

Best wishes,
Norbert

[Evert]

By the way: Would a direct USI interface for further WinBoard editions be a better solution than using the USI/UCCI-converter?

Doubtful. It's the exact same functionality as when it would be compiled into the program rather than as a stand-alone program.

Sjaak II 1.3.1a x64 runs as Shogi-WB-compatible engine well under WinBoard 4.8.0, but has problems to work via USI-protocol http://www.eglebbk.dds.nl/program/downl ... 1a-win.zip

What could the the reason for this behaviour?

I don't know. I don't have UCCI2WB set up at the moment, I can try to look at it later this week. What I cannot do either way is explain how to get things to work on Windows, since I don't have Windows myself.

[hgm]

In a PM about that same subject Norbert had added about the last subject that the error message was

> variant shogi not supported by Sjaak 1.3.1a (x86_64) (UCCI2WB)

I don't know what prompts you to mention UCCI2WB in this context, but UCCI2WB only supports Xiangqi and UCCI protocol. So no surprise there that WinBoard refuses to let it play Shogi. The reason is that it is running with the wrong adapter, probably because the persistend WinBoard /uxiAdapter setting was configured to UCCI2WB rather than UCI2WB.

[Evert]

In a PM about that same subject Norbert had added about the last subject that the error message was

> variant shogi not supported by Sjaak 1.3.1a (x86_64) (UCCI2WB)

I don't know what prompts you to mention UCCI2WB in this context, but UCCI2WB only supports Xiangqi and UCCI protocol. So no surprise there that WinBoard refuses to let it play Shogi. The reason is that it is running with the wrong adapter, probably because the persistend WinBoard /uxiAdapter setting was configured to UCCI2WB rather than UCI2WB.

Sorry, I meant UCI2WB.

I just tried the following using UCI2WB, looks fine:

Code: Select all

uci2wb -s ./sjaakii 
xboard
protover 2
feature variants="shogi,5x5+5_shogi" setboard=1 usermove=1 debug=1 ping=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
feature option="UCI2WB debug output -check 0"
feature myname="Sjaak II 633 (x86_64) (USI2WB)"
feature option="UCI_Variant -combo chess /// chess960 /// seirawan /// shatar /// makruk /// shatranj /// sittuyin /// crazyhouse /// chessgi /// asean /// ai-wok /// super /// spartan /// pocketknight /// kingofthehill /// knightmate /// berolina /// losalamos /// micro /// capablanca /// gothic /// embassy /// greatshatranj /// courier /// grand /// opulent /// omega /// minishogi /// shoshogi /// shogi /// torishogi /// xiangqi"
feature variants="normal,fischerandom" oocastle=0
feature smp=1 memory=1 done=1
new
variant shogi
sd 10
go
move c3c4=

The only peculiarities I see are the sending of two "feature variants" lines (the latter is probably prompted by SjaakII sending UCI_Chess960) and the redundant deferral after the opening move.

In USI mode, by hand, I have

Code: Select all

./sjaakii
Sjaak II version 633 (x86_64)
Type 'help' for a list of commands and help topics
 8r n b q k b n r 
 7p p p p p p p p 
 6                
 5                
 4                
 3                
 2P P P P P P P P 
 1R N B Q K B N R *
  a b c d e f g h 
#[Chess] 0w>usi

id name Sjaak II 633 (x86_64)
id author Evert Glebbeek
option name Hash type spin default 48 min 1 max 4096
option name Ponder type check default true
option name UCI_Chess960 type check default true
option name UCI_Variant type combo default shogi var chess var chess960 var seirawan var shatar var makruk var shatranj var sittuyin var crazyhouse var chessgi var asean var ai-wok var super var spartan var pocketknight var kingofthehill var knightmate var berolina var losalamos var micro var capablanca var gothic var embassy var greatshatranj var courier var grand var opulent var omega var minishogi var shoshogi var shogi var torishogi var xiangqi
usiok
go depth 10
info depth 2 score cp -48 nodes 123 time 1 hashfull 0 pv 7g7f 3c3d
info depth 3 score cp -27 nodes 311 time 2 hashfull 0 pv 7g7f 3c3d 7f7e 2b8h+ 7i8h
info depth 4 score cp -41 nodes 2314 time 17 hashfull 0 pv 7g7f 3c3d 7f7e 9c9d
info depth 5 score cp -27 nodes 5913 time 32 hashfull 0 pv 7g7f 3c3d 7f7e 2b8h+ 7i8h
info depth 6 score cp -39 nodes 15994 time 68 hashfull 0 pv 7g7f 5a6b 2h7h 3c3d 7f7e 4a4b
info depth 7 score cp -22 nodes 32131 time 131 hashfull 0 pv 7g7f 8b3b 7f7e 3c3d 2h7h 2b4d 8h6f 4d6f 6g6f
info depth 8 score cp -16 nodes 83422 time 364 hashfull 0 pv 7g7f 3c3d 7f7e 8c8d 8h2b+ 3a2b B@6e 5a4b
info depth 9 score cp -22 nodes 98931 time 418 hashfull 0 pv 7g7f 3c3d 7f7e 8c8d 8h2b+ 3a2b B@6f B@4d 2h7h 4d6f 6g6f
info depth 10 score cp -25 nodes 184794 time 779 hashfull 1 pv 7g7f 3c3d 8h2b+ 3a2b B@4e B@4d 7i8h 4a5b 4e3d 5a6b
bestmove 7g7f ponder 3c3d

which seems likewise fine...

So to the limit of what I can test right now, it "should work."

[hgm]

Actually the two variants features are a problem, as XBoard would only remember the last feature of every kind (except for option features, which accumulate). So the "normal, ficherandom" (which is indeed triggered by the UCI option mentioning chess960) would overrule the possibility to play Shogi and Xiangqi. I added this to have UCI2WB also support the Arena dialect of UCI for Chess960. I guess I should suppress this if an explicit protocol flag -s or -x was given (Chess960 would probably not work in UCCI or USI mode anyway).

The problem will always remain that Sjaak then cannot be loaded to play both Shogi and Chess960, as its initial declaration of supported variants would depend on XBoard's variant setting at the time of first loading.

Now Sjaak II is of course pretty unique, in the sense that it can play both Chess960 and Shogi/Xiangqi. And it does support WB protocol, so there is never any reason to use it under UCI2WB. So I can live with the idea that Sjaak II will not be able to run under XBoard+UCI2WB as USI or UCCI engine...

As to the bare USI output:
Sjaak does print some non-compliant stuff at startup, and it cannot be excluded that some USI interfaces would choke on that. You might consider slightly delaying that printing, so that the interface gets a chance to send "usi" first, and you can suppress the printing if it does. I suppose that you already have a routine to test for pending input, and you could start with that after a 100msec usleep to decide if you are going to read or print.

[Evert]

Actually the two variants features are a problem, as XBoard would only remember the last feature of every kind (except for option features, which accumulate). So the "normal, ficherandom" (which is indeed triggered by the UCI option mentioning chess960) would overrule the possibility to play Shogi and Xiangqi. I added this to have UCI2WB also support the Arena dialect of UCI for Chess960. I guess I should suppress this if an explicit protocol flag -s or -x was given (Chess960 would probably not work in UCCI or USI mode anyway).

Can't you merge the list of supported variants?

I'm pretty sure that you can make SjaakII play Chess960 through USI or UCCI if you abuse the options. I'm sure the end result will be a spectacular failure on many levels.

The problem will always remain that Sjaak then cannot be loaded to play both Shogi and Chess960, as its initial declaration of supported variants would depend on XBoard's variant setting at the time of first loading.

Now Sjaak II is of course pretty unique, in the sense that it can play both Chess960 and Shogi/Xiangqi. And it does support WB protocol, so there is never any reason to use it under UCI2WB. So I can live with the idea that Sjaak II will not be able to run under XBoard+UCI2WB as USI or UCCI engine...

I'm not losing any sleep over it (if you want to do anything other than Chess960, the sensible thing to do is use CECP, IMO), but XBoard+UCI2WB is my testing environment for U*I, so it is a little annoying. Then again, I can always hack the source for UCI2WB on my end, so it's not a big issue.

As to the bare USI output:
Sjaak does print some non-compliant stuff at startup, and it cannot be excluded that some USI interfaces would choke on that.

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

You might consider slightly delaying that printing, so that the interface gets a chance to send "usi" first, and you can suppress the printing if it does. I suppose that you already have a routine to test for pending input, and you could start with that after a 100msec usleep to decide if you are going to read or print.

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.

Having said that, you can actually start SjaakII directly in USI mode using "sjaakii -usi" (there are also -xboard, -uci and -ucci options; I should add -cecp and deprecate -xboard). That will disable the board and prompt, but it won't get rid of the greeter ("Sjaak II version <whatever> (x86_64)
Type 'help' for a list of commands and help topics"). It may still ameliorate the problem.

* 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.

[hgm]

Can't you merge the list of supported variants?

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...

I'm pretty sure that you can make SjaakII play Chess960 through USI or UCCI if you abuse the options. I'm sure the end result will be a spectacular failure on many levels.

I'm not losing any sleep over it (if you want to do anything other than Chess960, the sensible thing to do is use CECP, IMO), but XBoard+UCI2WB is my testing environment for U*I, so it is a little annoying. Then again, I can always hack the source for UCI2WB on my end, so it's not a big issue.

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).

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?

but it won't get rid of the greeter ("Sjaak II version <whatever> (x86_64)
Type 'help' for a list of commands and help topics"). It may still ameliorate the problem.

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

* 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'...).