Re: [XBoard-devel] Future plans

[Michel Van den Bergh]

h.g. muller wrote:
> 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.
Well polyglot has always made it possible to change the engine name. 
This feature which makes it easy
to autoplay engines with different settings (and I use it this way). 
This feature would remain available
for people using polyglot with classical config files.

I think it is very far fetched to suggest that this feature invites 
"cheating". What kind of cheating
are you thinking of?  If I want to post a pgn on TalkChess with a Crafty 
game
posing as a micro-max game then I can do that whether of not WB or PG allows
me to change the engine name or not.

Besides your proposals below seem to amount to  more convoluted ways of 
changing the engine name.

> 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.
With this I agree. Attaching automatically some suffix to the engine 
name to indicate that it is not using the
default settings is indeed a very good idea.  I like to play Rybka with 
UCI_LimitStrength since
in that way I have a (slight) chance of winning. But there should indeed 
be some indication
in the pgn and title bar that Rybka is not using its default settings.

This should even apply to people who modify the settings of Rybka using 
traditional config files.

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

And what would be the default name of the SaveFile be then? If it is not 
derived from
the engine name, what then?

And how would the user change it? By a command line option or some input 
field in the
engine settings dialog? This would just be a different way of creating 
an alternative engine name
which is logically equivalent to my proposal I think.

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

Debugging in WB and polyglot is an exceptional situation.

You turn on debugging if something goes wrong and then it seems easiest 
to me
to generate all debug information at once.  If for some reason this is 
not what
you want (which I think is not very likely) then you could always change 
the template
by which PG is invoked to sever the link between the two.


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