Re: [XBoard-devel] Future plans

[h.g. muller]

At 09:58 7-9-2009 +0200, Michel Van den Bergh wrote:
> Hi,
>
> I have been thinking which template strings should be defined. I can think 
> of the following
>
> EngineCommand
> EngineDir
> EngineName (not yet available as command line argument)
>
> debug (true/false)
> engine# (1 for fcp, 2 for scp, possibly more).
>
> Then my template for invoking PG would be
>
> polyglot -noini -ec <EngineCommand> -ed <EngineDir> -en <EngineName> -log 
> <debug> -lf polyglot_<engine#>.log
>
> Does that sound reasonable?

Well, I have thought a bit on your proposal for the engineName option,
and I m not too keen on it. It i essentially an option to facilitate cheating:
let Crafty play and name it micro-Max. I think the ultimate authority for
deciding uponits name shoud ly with the engine.

I can imagine that a user would want to run different versions of the same
engine, with different settings. But it is up to the engine (author) to decide
if he wants to underwite a certain setting with its own name. If some engine
allows you to set the value of Queen to 100 and that of Pawn to 900, and
then plays like crap, and the author does not want to taint the reputation
of his engine by these silly games being published as due to this engine,
he should simply make the engine print another name in the myname
feature. Like "Fruit 2.1 (modified)" if someone plays with non-standard
settings. Perhaps I should anchor it in the specs that resending features
(other than the option feature) overwrites the previous value.

In the case of Polyglot mediating a UCI engine, I think the logical way to
handle things is exacty the opposite of what you proposed: not derive the
(WinBoard) name of the SaveFile for that of the engine, but in stead derive
the name of the engine (reported to WinBoard in the myname feature)
from the name of the SaveFile. Then, when a user decides to tailor
the option settings and save them under a different name, this would
automatically change the name under which the engine would appear
in the PGN. You could even make it such that any attempt to play
the engine with different settings than the engine defaults would suffix
the WB name with "(m)" if the settings-file name was the default name
for that engine, and suffix it with "(m)" if the settings differed from what
was specified in the ini file. Polyglot would be aware of this.

The -fcp, -scp -fd and -sd arguments should certainly be available to pass
as EngineComamnd and EngineDir, and the engine number is a good idea.
Prsonally I would not enslave the Polyglot logs to the WinBoard -debug.
Polyglot debugging is quite distinct from WinBoard debugging, and usually
would be done only for one engine at a time, if it is done at all. But that
does not mean that we could not make the -debug value availale for
people that do want to do this. But I would likely set the default value
of the WinBoard -adapterCommand to

polyglot -noini -ec %cp -ed %d

I am not sure about the book stuff. I guess we should leave that out now that
WinBoard has a GUI book, and use the menu book controls exclusively
for the GUI book. (Currently they control both the Polyglot and GUI book,
which is pointless, but not harmfull.) Currently WinBoard is aware of
EGTB cache size, through command-line option or menu dialog, which is
something I dislike, but which people will not want to see removed. So
perhaps this should be passed to Polyglot in the default adapterCommand
too. The hash size, nalimov path, cores and variant are all taken care of
by the extended WB protocol.