UCI extension: nodestime

[Daniel Mehrmann]

I was trying to help you with an idea, and as always, you're not open for any kind of other ideas like your own of course. You think you're the king of the hill, wel,l maybe you are, but don't wonder if a lot of people don't like a tech talk with you (specialy UCI).
For myself i was trying to help and i know that some unix knowledge is needed to understand the conf.d idea But i can't teach you in this case, you need to learn it by yourself. But a simply google search for "conf.d" seems to be to much for you (I guess lazyness). That's all pretty sadly.

[ (Because that was what I was talking about, before you started to drag in some off-topic stuff on engine-GUI recognition!)

Before that you wrote a sadly words like this:

I'm not surprised. It doesn't matter much what you think, though. If you want Stockfish to be crap, its your call. But you shouldn't expect many other engines or GUIs to adopt a poorly working system that is wrong by design. But that is fine if you want Stockfish to live inside its own bubble...

I don't need to comment that. Thats my last statement and please stop trolling the UCI protocol.

[hgm]

Therefore you can produce stronger / weaker oppenents artifically somehow.

This of course has always been possible, by using time-odds games. The NIT approach was only conceived as a work-around for highly-variable machine loads. And it makes much faster TC possible than ay timed approach, as the latter have resolutions of 1 millisec (in UCI, 10 msec in WB protocol), which you can only realize by unusual timer calls, as the standard calls are based on clocks that tick every 16 msec. But that is mainly a consequence of delegating the measurement to the engine, which could have been done for a true time measurement as well.

[Michel]

I was trying to help you with an idea, and as always, you're not open for any kind of other ideas like your own of course. You think you're the king of the hill, wel,l maybe you are, but don't wonder if a lot of people don't like a tech talk with you (specialy UCI).
For myself i was trying to help and i know that some unix knowledge is needed to understand the conf.d idea But i can't teach you in this case, you need to learn it by yourself. But a simply google search for "conf.d" seems to be to much for you (I guess lazyness). That's all pretty sadly.

Sigh.... I think you are seriously confused.

Some large applications have instead of a configuration file, a directory of configuration files (one file for each feature) commonly called conf.d. This makes it easy to turn features on or off.

For example xboard could one day replace its xboard.conf file by a directory xboard/conf.d/ which could contain a configuration file for each variant it supports. Supporting a new variant could then be done by dropping a file in that directory (rather than directly editing xboard.conf).

Now please explain what this has to do with the autodetection of engines by a GUI (which does not have to be xboard)?

[Daniel Mehrmann]

Sigh.... I think you are seriously confused.

Nope, but it seems to you're on very good way to understand it

[qood staff]

Now please explain what this has to do with the autodetection of engines by a GUI (which does not have to be xboard)?

More or less you're right so far. Now every engine package will add a own file.conf into conf.d for each gui and tells the gui about itself (like hgm would do).
The gui, like xboard, read these conf files and has all informations of any single of engine.

[Michel]

Now every engine package will add a own file.conf into conf.d for each gui and tells the gui about itself.
The gui, like xboard, read these conf files and has all informations of any single of engine.

So instead of dropping a single file in a known directory the engine installer would now have to drop a file in the conf.d directory of every GUI on the system.

Questions:

(1) How would the engine installer even know which GUIs are on the system?

(2) What happens if a new GUI is installed after the engine is installed?

[hgm]

For example xboard could one day replace its xboard.conf file by a directory xboard/conf.d/ which could contain a configuration file for each variant it supports. Supporting a new variant could then be done by dropping a file in that directory (rather than directly editing xboard.conf).

Actually we are already evolving in that direction. XBoard used to have a theme list, (where a theme is basically a collection of low-level graphics settings, like square textures, colors and piece glyphs), and it used to be in the settings file (like the list of registered engines). But that makes it hard to expand that list if a new theme is installed.

One of the problem is that the xboard.conf file isn't really the place where users save settings. He does that in his own directory, as ~/.xboardrc. And when you install a new theme (say a set of SVG files with piece designs), it is not really doable to hunt down all the user's private settings files, and start editing those (especially since these might have redirected the actual saving of settings elsewhere).

So XBoard themes are now typically packaged with a settings file containing the definition of all low-level options needed to activate it, and such files are installed in /usr(/local)/share/games/xboard/themes/conf. A simple "xboad @chu" will make XBoard look in the cof directory for a file "chu" (if it wasn't found in the current directory), which would then configure XBoard for Chu Shogi. The user can then decide if he wants to save these settings as a new theme to his private theme list.

But to prevent very specific themes (like kanji Tori-Shogi pieces) to spoil his general settings for other variants, the conf files for such odd-ball themes usually redefine the file for saving and reloading settings as well. So that playing oriental-stule Tori Shogi won't make your Chess board turn into gibberish next time you connect to FICS. But that means that a user with broad interests will get a bunch of settings files ~/.xboard-xq-rc, ~/.xboard-shogi-rc, ~/.xboard-chu-rc, ~/.xboard-tori-rc... To combat this proliferation problem future versions of XBoard will probably place all these in a directory ~/.xboard/chess.ini, ~/.xboard/shogi.ini etc.

[Daniel Mehrmann]

(1) How would the engine installer even know which GUIs are on the system?

(2) What happens if a new GUI is installed after the engine is installed?

That would be no problem, because the conf file would be part of the engine package. The conf file would be created always - With or without a installed gui. It's a common way for a lot of programs.
The gui package only create a (empty) conf.d directory if it doesn't exist.

[Michel]

(1) How would the engine installer even know which GUIs are on the system?

(2) What happens if a new GUI is installed after the engine is installed?

That would be no problem, because the conf file would be part of the engine package. The conf file would be created always - With or without a installed gui. It's a common way for a lot of programs.
The gui package only create a (empty) conf.d directory if it doesn't exist.

So there would be a conf.d directory somewhere on the system in a known location (it would be created if it wasn't there) and the engine installer drops a configuration file in there...

Congratulations. You have rephrazed HGM's proposal (clumsily though).

[mcostalba]

I introduced the "NIT" ( Node Is Time ) option in my engine a long time ago now with a simple translation from time to nodes.

I think I miss something here: without help of the GUI how you can keep track of lost time?

For instance the engine can take 1 second or 2 second to compute the same number of nodes, for instance because in the second case is slowed down by some other background process. The GUI should account for the same elapsed time in both cases (because nodes searched are the same), but this is possible only if the GUI knows that nodes, and not elapsed time, is the reference value to look for. And this is possible only if engine tells the GUI that is operating in NIT mode.

So I miss how your scheme can work transparently without the GUI knowing you are in NIT mode.

[hgm]

Congratulations. You have rephrazed HGM's proposal (clumsily though).

Well, I don't think he is quite there yet. I believe he is proposing to do what I proposed in 10-fold: each engine would create a conf.d directory for every GUI in existence or to be yet invented, in case that GUI was not installed yet. One for XBoard, one for SCID, one for PyChess, one for Tagua, one for Omaha... And then announce its presence in each of them, so that you get a dozen directories with all exactly the same content.