Winboard.debug file missing.

[George Tsavdaris]

I use the Winboard 4.9.191026 and as it seems i'm not able to create a Winboard.debug file!
I try to put -debug in engine options e.g
bihasa32.exe -debug /fd="C:\Program Files (x86)\WinBoard-AA\WinBoard\WinBoard\Bihasa32" /variant="gothic"

as also in "Additional Options" in the start with /debug as also tried /debugMode true as also in Winboard.ini and combinations of all the above, as also pressing CTRL+ALT+F12, but no Winboard.debug file is created anywhere. I'm looking at the places where Winboard.exe and bihasa32.exe is, but nothing!

Why?
So how i can generate a debug file?

[George Tsavdaris]

Oh and also why Stockfish does not use syzygy tablebases in Winboard with this command?
"stockfishx64-modern.exe" -fd "C:\Program Files (x86)\WinBoard-AA\WinBoard\WinBoard\Stockfish" -fUCI -firstOptions "SyzygyPath=E:\syzygy"

[Ferdy]

I use the Winboard 4.9.191026 and as it seems i'm not able to create a Winboard.debug file!
I try to put -debug in engine options e.g
bihasa32.exe -debug /fd="C:\Program Files (x86)\WinBoard-AA\WinBoard\WinBoard\Bihasa32" /variant="gothic"

as also in "Additional Options" in the start with /debug as also tried /debugMode true as also in Winboard.ini and combinations of all the above, as also pressing CTRL+ALT+F12, but no Winboard.debug file is created anywhere. I'm looking at the places where Winboard.exe and bihasa32.exe is, but nothing!

Why?
So how i can generate a debug file?

Try to run winboard with admin rights (right-click on winboard.exe, run as administrator).
This method works for me on winboard-aa 4.9.191113.

[hgm]

Like Ferdy says, you might not have permission to write in the WinBoard folder when running WinBoard. Sometimes attempts to write in a folder that WinBoard considers 'public' (like the Program Files sub-tree) are redirected to some user-specific 'roaming' folder instead. Then they are written, but very difficult to find back.

As to EGT: WInBoard (or its UCI adapters) does not consider the EGT options 'engine-defined' options, but (UCI) standard options, which have to be handled centrally by the GUI. So 'SyzygyPath' is not reported as an engine option to WinBoard, and will thus not be recognized for settin either. Instead the adpater will inform WinBoard that the engine supports the 'syzygy' flavor (possibly in addition to others) by sending 'feature egt="syzygy,..."'.

WinBoard will then look if a path for any of these flavors is defined through the WinBoard -egtFormats (persistent) option. E.g. with -egtFormats "syzygy:F:\egt\dtz50,nalimov:F:\egt\dtm" it would know the syzygy path is F:\egt\dtz50, and send the command

egtpath syzygy C:\egt\dtz50

to the engine (or in this case adapter) to give it the required info for finding the EGT. It is the responsibility of the adapter to translate this to UCI (i.e. send "setoption name SyzygyPath value C:\egt\dtz50" to the engine).

So all you have to do is configure WinBoard (once) to know where to find the various EGT through the -egtFormats option, which can also be done by typing the desired value for this option in the EGTB Path field of the Common Engine Settings dialog. Be sure the path is prefixed by the flavor name, (in this case "syzygy:"), thoug, or it would take the entered string as the Nalimov Path (for backward-compatibility reasons).

[George Tsavdaris]

....

Like Ferdy says, you might not have permission to write in the WinBoard folder when running WinBoard. Sometimes attempts to write in a folder that WinBoard considers 'public' (like the Program Files sub-tree) are redirected to some user-specific 'roaming' folder instead. Then they are written, but very difficult to find back.

So all you have to do is configure WinBoard (once) to know where to find the various EGT through the -egtFormats option, which can also be done by typing the desired value for this option in the EGTB Path field of the Common Engine Settings dialog. Be sure the path is prefixed by the flavor name, (in this case "syzygy:"), thoug, or it would take the entered string as the Nalimov Path (for backward-compatibility reasons).

Yes indeed, i had set all permissions to the folders to Winboard and yet i had to also run it with administrative rights as Ferdy said.
And for egtbs i did what you said and it worked with another issue though.
Also how i can set multiple folders for syzygy egtbs? Is syzygy:E:\syzygy;E:\syzygy2 gonna work?

The issue i have is that variant Stockfish from https://github.com/ddugovic/Stockfish works perfectly fine for CHESS with normal Chess 3-6 syzygy TBs, loads them fine etc etc.
But when i turn it to Atomic Chess 3-5 syzygy TBs, it doesn't load them at all. I pinged here niklasf in case he can help with this.

Debug shows something very strange is happening with Stockfish in Atomic and TBs.
It loads them fine initially but then immediately reports again 0 TBs. Why?

5670 <first : # setoption name UCI_Variant value atomic
5670 <first : ucinewgame
5670 <first : isready
5830 <first : # engine said: info string Found 0 tablebases
5831 <first : 0 0 0 0 Found 0 tablebases
5831 <first : # engine said: info string variant atomic startpos rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
6196 <first : # engine said: info string Found 145 tablebases
6197 <first : 0 0 0 0 Found 145 tablebases
6354 <first : # engine said: info string Found 0 tablebases
6354 <first : 0 0 0 0 Found 0 tablebases
6355 <first : # engine said: readyok

[hgm]

Also how i can set multiple folders for syzygy egtbs? Is syzygy:E:\syzygy;E:\syzygy2 gonna work?

It would work if it would work for the engine's SyzygyPath option. WinBoard doesn't care what string you specify for the various EGT flavors; it just splits the entire -egtFormats string at the commas, and consider every part a <flavor>:<value> pair by splitting at the first colon. This is then sent to an engine / UCI adapter that supports the flavor as

egtpath <flavor> <value>

The UCI adapter should then pass it to the engine as

setoption name <relevant UCI option> value <value>

So the <value> is never interpreted or modified. The only restriction is that it cannot contain commas.

The other thing seems to be a Stockfish problem; it first sees 145 EGT, but then it has second thoughts and reports it sees none. Could be that one is for the first path you give, and the other for the second.

Note that the entire system of handling the EGT is not really tailored for having any variant dependence of the path names; WinBoard sends egtpath commands to the engine before every game, even before it switches the engine to the desired variant. Presumably the names of the individual EGT files should identify the variant they are for, or they should be in a variant-dependent subdirectory of the given path (e.g. F:\egt\syzygy\atomic\* when the path is given as F:\egt\syzygy). This is for the flavor to define and handle; WinBoard does not meddle in this.

[George Tsavdaris]

The other thing seems to be a Stockfish problem; it first sees 145 EGT, but then it has second thoughts and reports it sees none. Could be that one is for the first path you give, and the other for the second.

Not really as i gave just one path.
I just asked for how to handle 2 or more without using them for being safe.

That same Stockfish that gave the above strange behavior in Atomic with Winboard is working fine on cmd:
setoption name UCI_Variant value atomic
info string variant atomic startpos rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
setoption name SyzygyPath value E:\syzygyatomic
info string Found 145 tablebases
position fen 3k4/3b4/8/8/8/8/1B3K2/1R6 w - - 0 1
go nodes 1000000
info depth 1 seldepth 1 multipv 1 score cp 15322 nodes 3 nps 1000 tbhits 24 time 3 pv b1d1


But not on Winboard as it can't recognize TBs

I run again in Winboard with above Stockfish and the same thing again. It recognizes and then drops it

17755 <first : # command egtpath
17755 <first : # setoption name syzygyPath value E:\syzygyatomic
17755 <first : # queue 'cores', searching=0
17755 <first : # command cores
17755 <first : # setoption name Threads value 8
17755 <first : # queue 'new', searching=0
17755 <first : # command new
17755 <first : # queue 'variant', searching=0
17771 <first : # command variant
17771 <first : # setoption name UCI_Variant value atomic
17771 <first : ucinewgame
17771 <first : isready
17771 <first : # queue 'level', searching=0
17771 <first : # queue 'option', searching=0
17771 <first : # queue 'option', searching=0
17771 <first : # queue 'ping', searching=0
17771 <first : # queue 'force', searching=0
17771 <first : # queue 'setboard', searching=0
17786 <first : # engine said: info string Found 145 tablebases
17786 <first : 0 0 0 0 Found 145 tablebases
18287 <first : # engine said: info string variant atomic startpos rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
18302 <first : # engine said: info string Found 145 tablebases
18318 <first : 0 0 0 0 Found 145 tablebases
18427 <first : # engine said: info string Found 0 tablebases
18427 <first : 0 0 0 0 Found 0 tablebases
18427 <first : # engine said: readyok
18427 <first : # command level
18427 <first : # command option
18427 <first : # setoption name Ponder value true
18427 <first : # command option
18427 <first : # setoption name Ponder value false
18427 <first : # command ping
18427 <first : pong 3
21954 <first : # engine said: info depth 1 seldepth 2 multipv 1 score cp 871 nodes 195 nps 97500 tbhits 0 time 2 pv b2f6 d8c8 b1b8 c8c7

[hgm]

The difference seems to be that when working from the command line you set the SyzygyPath option after the UCI_Variant, while under WinBoard this happens in reverse. Perhaps changing UCI_Variant interferes with the setting of the SyzygyPath, and makes it reload the EGT.

Another difference is that UCI2WB does not capitalize syzygyPath when it tries to set it, but according to the UCI specs this should not matter, as option names are supposed to be case insensitive.

[George Tsavdaris]

Another difference is that UCI2WB does not capitalize syzygyPath when it tries to set it, but according to the UCI specs this should not matter, as option names are supposed to be case insensitive.

I tried this in cmd mode and does not matter it still accepts it so this is not the problem.

The difference seems to be that when working from the command line you set the SyzygyPath option after the UCI_Variant, while under WinBoard this happens in reverse. Perhaps changing UCI_Variant interferes with the setting of the SyzygyPath, and makes it reload the EGT.

But here you indeed found the problem.
In cmd again when loading Stockfish(the Ddugovic variant one) and trying first to load Atomic TBs before declaring the variant Atomic:
uci
setoption name SyzygyPath value E:\syzygyatomic
info string Found 0 tablebases

So then after loading the variant has 0 loaded TBs.
Any workaround to make this Stockfish work with Winboard and support Atomic TBs?

(I think when you write first the syzygypath it looks for Chess TBs and since my E:\syzygyatomic has only Atomic Chess TBs it recognizes 0 TBs. So you have first to declare the variant Atomic Chess in order to recognize the atomic TBs. )

Btw when i put first the Chess TBS:
uci
setoption name SyzygyPath value E:\syzygy
info string Found 988 tablebases

So it finds Chess TBs but not Atomic Chess ones when you put syzygypath first.
So you have to set the Atomic variant first in order to recognize Atomic TBs.

[hgm]

Well, in engine-engine games WinBoard would sent a "computer" command to both players (after the variant and level commands) to inform them their opponent is an engine, and this is a configurable command, which could be altered though the -computerString option (e.g. to send a hard-coded egtpath command again). For human-engine I cannot imagine a work-around. (Perhaps WinBoard should support a special -workAround option for such purposes, where you can define a stringthat should be sent to the engine at game start after everything else, both in homan and engine games.)

I think this should really be fixed in Stockfish. The most sensible implementation seems to be that it loads the EGT on reception of the 'ucinewgame' command, at which time both the variant and the egtPath should be known. It would also work when it loads EGT on both the setting of EGT Path and UCI_Variant, according to the most recent values of those, but this could lead to a lot of wasted loading (as under WinBoard the only way to start a new variant game is to first swicth back to normal chess with a 'new' command, after which you cannot rely on a 'variant' command to follow it, as for normal chess this would not come). And the loading might be slow. But I guess not all interfaces do send 'ucinewgame' (it was introduced in UCI only later), and to not break Stockfish for those interfaces it must load normal chess EGT on setting of the EGT Path. Or it should make a check each time it receives a 'position' or 'isready' command to see if the proper EGT are loaded, and if not, load them before proceeding.

It is also bad that you / the GUI would have to change the EGT Path when you want to do another variant. That would require the user to somehow define a new path for each variant. There really should be only a single SyzygyPath, and the engine should be able to use that for finding the Syzygy EGT for all variants. E.g. by adopting the convention that variant EGTs are in a sub-folder of the given path named after the variant.