[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XBoard-devel] Future plans
From: |
Michel Van den Bergh |
Subject: |
Re: [XBoard-devel] Future plans |
Date: |
Mon, 07 Sep 2009 13:44:07 +0200 |
User-agent: |
Thunderbird 2.0.0.22 (X11/20090608) |
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.
- [XBoard-devel] autogen.sh, Arun Persaud, 2009/09/06
- Re: [XBoard-devel] autogen.sh, Ali Polatel, 2009/09/06
- Re: [XBoard-devel] autogen.sh, Arun Persaud, 2009/09/06
- Re: [XBoard-devel] autogen.sh, h.g. muller, 2009/09/07
- Re: [XBoard-devel] autogen.sh, Michel Van den Bergh, 2009/09/07
- Re: [XBoard-devel] Future plans, h.g. muller, 2009/09/07
- Re: [XBoard-devel] Future plans,
Michel Van den Bergh <=
- Re: [XBoard-devel] Future plans, h.g. muller, 2009/09/07
- Re: [XBoard-devel] Future plans, Michel Van den Bergh, 2009/09/07
- Re: [XBoard-devel] Future plans, h.g. muller, 2009/09/08
- Re: [XBoard-devel] Future plans, Michel Van den Bergh, 2009/09/08
- Re: [XBoard-devel] Future plans, h.g. muller, 2009/09/08
- Re: [XBoard-devel] Future plans, Michel Van den Bergh, 2009/09/09
- Re: [XBoard-devel] Future plans, Michel Van den Bergh, 2009/09/10
- Re: [XBoard-devel] Future plans, Michel Van den Bergh, 2009/09/11
- Re: [XBoard-devel] Future plans, h.g. muller, 2009/09/11
- [XBoard-devel] Keyboard navigation problem (game list), h.g. muller, 2009/09/11