Stockfish: No use from Stockfish of Atomic Chess endgame tablebases in Winboard.

[GeorgeMJ23]

This multivariant Stockfish cannot use Atomic Chess endgame tablebases in Winboard.
It can use them pefrectly fine while running in cmd , but not in Winboard.

The reason is Winboard sends the SyzygyPath command to Stockfish before the UCI_Variant command so when Stockfish sees:

setoption name SyzygyPath value E:\syzygyatomic

where E:syzygyatomic contains Atomic Chess TBs, it reports:
info string Found 0 tablebases

and then when Winboard sends the UCI_Variant=atomic command Stockfish has 0 Atomic TBs loaded.
As it does not recognize the Atomic Chess EGTBs before you set the variant atomic.
And you need first to load the variant and then to send the SyzygyPath command.
But Winboard does the opposite. First it sends syzygy path and then UCI_Variant to declare the variant.
So i can't run Stockfish Atomic Chess analysis on Winboard with tablebases. :(

Harm Geert Muller though, says it's unreasonable what Stockfish does and it should be changed.

HGM explains it well here:
http://www.talkchess.com/forum3/viewtopic.php?f=2&t=72546&sid=a6d5136793a50d1c86bbb77bbfdcc40d#p822066

So any chance for a change in order Stockfish to be able to use TBs for Atomic Chess(and i guess for Suicide Chess also) in Winboard?

[HGMuller]

Some explanation:
I think it is undesirable that the value of the EGT path option should depend on the variant, as this would either force the user to change that option every time he switches variant, or require the existence of a separate EGT path option for each variant, which the user would then all have to configure.
A much better design would be to let the single EGT path option indicate the 'base directory' of the indicated EGT flavor, (which for backward compatibility then contains the EGT files for normal Chess), and have a sub-directory in there with the variant name for the EGT of each variant. With such a design the EGT path can be given once and for all, independent of the variant that will be chosen.
But in all cases it should be up to the engine to make sure the required EGT are loaded at the start of a game, according to the current setting of the EGT path and UCI_Variant.

[HGMuller]

Perhaps formulated more succinctly: I think it is wrong (contrary to the spirit of UCI) to require a new setoption command for the SyzygyPath in order for the EGT residing there to be loaded, when that option already has the desired value.

[ddugovic]

In principle I think I agree with that succinct formulation. At the moment #566 has my complete attention but I will consider this next.

[GeorgeMJ23]

In principle I think I agree with that succinct formulation. At the moment #566 has my complete attention but I will consider this next.

Thanks as Winboard is the ONLY GUI that one can analyze with Stockfish variants, so analyzing with tablebases is essential.
Of course one can analyze with cmd directly but that is infinitely more painful than with the luxury of all Winboard's features and easiness and its graphical board.

[gbtami]

@GeorgeMJ23 You can give https://github.com/pychess/pychess a try also.

[niklasf]

There's no need to hardcode subdirectories for each variant. Simply specify multiple paths, seperated by ; (Windows) or : (Unix) and Stockfish should load the relevant files by name and extension.

If this doesn't work, as described by OP, that's a bug.

[HGMuller]

Well, basically it is up to of the EGT flavor to define how it interprets the Path option and how it distinguishes the tables for different variants; WinBoard does nothing but pass the string the user enters for this.
It doesn't seem a very good design, however, to require the engine to search all directories in the string to see if there happen to be data files that are suitable (recognized by name or content) for the variant it is going to play. Or to require the user to enter multiple paths where a single path could have sufficed.

[ianfab]

To search a list of colon-separated paths in the SyzygyPath option is in line with the UCI specification, where this behavior is defined for the NalimovPath option:

*  = NalimovPath, type string
    this is the path on the hard disk to the Nalimov compressed format.
    Multiple directories can be concatenated with ";"

Anyhow, this issue simply is a bug, no problem with the design, although some double initializations could maybe be avoided. I will open a PR with the fix soon.

[HGMuller]

The UCI specification does not account for any variants, so whatever it says should be taken to apply to Chess(960) only. That users can organize their EGT data by distributing them over several directories (like 4men, 5men, ...) is fine when all data files in these directories will allways be relevant. But it is needlessly inefficient when the files that are needed are just a small subset of all the files that are there. That would already be true if the necessity to load the file can be judged by the filename only, but is even more so when it has to be judged by content, requiring opening of every file. (I don't know what system Syzygy uses for this.) And, as I said, it is also pretty user-unfriendly to _require_ the option to be a ;/: separated list of pathnames where a single path could have done the job, even when the specs allow it.

[ddugovic]

I store all my TB files in a single directory, although there was a bug preventing them from being loaded (on ucinewgame Stockfish loads files by their extension): https://github.com/ddugovic/Stockfish/pull/568#issue-353169285

EDIT: TB files are also loaded on SyzygyPath and UCI_Variant.

[ianfab]

The distinction of TB files for variants is done via the file name ending https://github.com/ddugovic/Stockfish/blob/1c74db188501660a0e290343300accb8d6d7d08b/src/syzygy/tbprobe.cpp#L60-L290 so no confusion is possible and the overhead to ignore irrelevant files is also very limited. If you really want to you can also do with one path by just putting all files into one directory, whereas if you prefer to structure the directories, you can also use multiple paths. This makes it flexible and safe, whereas having hard-coded directory names takes away flexibility. I do not see how this solution is user-unfriendly.

[HGMuller]

OK, having the variant indicated in the filename (or extension) does indeed make it possible (and not too inconvenient) to store them all in the same directory. And it does not require the engine to open the files it doesn't need, just to go through the list of names in the directory. So this is fine.
I guess there is in principle little difference between indication the variant by extension (.) or by sub-folder (/), in both cases having the engine dynamically decide on what should be.

[HGMuller]

Oh, I see the forum software thoroughly mutilated my previous posting; I wanted to say:

... by extension (_name_._variant_) or by sub-folder (_variant_/_name_), ...

[GeorgeMJ23]

Edit: Issue is indeed solved.
My bad i initially said it's not. I had to reconfigure slightly Winboard.ini :)

Many thanks!