Closed GoogleCodeExporter closed 8 years ago
I talked to the reporter of this bug, jonas.th@web.de, on IRC. He is writing
his own
chess engine and said that this feature was blocking him from using pychess. He
sent
me this example xboard GUI <-> engine conversation as an example of how this
would
look:
< Ildtiadar Chess Machine (c) Jonas Thiem
< Free to use. No warranty (to maximum extend allowed by German law).
< Stand-alone distribution of unmodified engine permitted, any other
sort of distribution (especially bundled with e.g. a chess GUI or as
part of an engine collection) requires explicit permission.
< .
< Ok, if you're a human you probably got a problem now. There's no
suitable, easy-to-use human interface yet.
< Try to use this engine with winboard/xboard or other chess GUI
applications that support the Chess Engine
< Communication Protocol in Version 2 or newer.
<
> xboard
> protover 2
< feature ping=1 playother=0 variants="normal,knightmate,berolina"
analyze=0 sigterm=0 sigint=0 time=1 usermove=1 setboard=0 colors=0
name=1 nps=0 ics=0 debug=1 pause=0 memory=0 san=0 reuse=1
> accepted ping
> accepted playother
> accepted variants
> accepted analyze
> accepted sigterm
> accepted sigint
> accepted time
> accepted usermove
> accepted setboard
> accepted colors
> accepted name
> accepted nps
> accepted ics
> accepted debug
> accepted pause
> accepted memory
> accepted san
> accepted reuse
< feature myname="Ildtiadar 0.9e"
> accepted myname
< feature option="Author -string Jonas Thiem"
> accepted option
< feature option="About -string A free amateur chess engine written for
fun. Feel free to redistribute. No warranty (to maximum extend allowed
by German law). Do not modify or distribute in modified state."
> accepted option
< feature done=1
> accepted done
Original comment by mattgatto
on 20 Nov 2010 at 5:45
Attached is a preliminary patch which seems to work OK with gnuchess, pychess
engine, and crafty.
Original comment by mattgatto
on 20 Nov 2010 at 9:54
Attachments:
Seams good to me.
Original comment by lobais
on 20 Nov 2010 at 9:39
Updated patch that supports the "colors" feature. Inverse CECP analyzers that
don't work when being sent a "white/black" before a "go" (i.e. that
specifically set "features colors=0") probably won't work although I doubt that
anyone newbie enough to use an inverse analyzer would configure a different
inverse analyzer in the preferences. The patch is not quite finished though:
the pychess engine needs to be updated to recognize "accepted"/"rejected" and
should probably also send "features colors=1".
Original comment by mattgatto
on 22 Nov 2010 at 1:27
Attachments:
I tested this patch aswell and it seems to work with quite awesome results. My
engine perfectly runs (when it just couldn't before).
Is there any chance this will still make it into the next bigger release which
I heard will arrive soon?
Original comment by jonas.thiem@gmail.com
on 31 Dec 2010 at 9:52
Regarding the colors feature with inverse CECP analyzers: What about using the
"playother" command (of course only if the engine doesn't specify feature
playother=0 aswell, in which case you're probably lost)? I think this is the
situation which it has been made for.
Original comment by jonas.thiem@gmail.com
on 1 Jan 2011 at 9:43
This patch updates the PyChess.py engine too.
Original comment by mattgatto
on 27 Feb 2011 at 11:06
Attachments:
I don't think that the 'playother' command would work for the inverse CECP
analyzer scenario, because it would take the engine out of 'force' and analysis
mode and causes it to think it was playing when it isn't. I could be wrong
though. Thomas, what do you think?
I've committed this in revision cc647016ce.
Original comment by mattgatto
on 4 Mar 2011 at 12:27
Well you just need to read the specs:
"playother
(This command is new in protocol version 2. It is not sent unless you enable it with the feature command.) Leave force mode and set the engine to play the color that is not on move. Associate the opponent's clock with the color that is on move, the engine's clock with the color that is not on move. Start the opponent's clock. If pondering is enabled, the engine should begin pondering. If the engine later receives a move, it should start thinking and eventually reply. "
As you can see, it specifically means the engine should NOT attempt to move,
just change the playing colour and wait for a move to arrive (and eventually
ponder, but that doesn't hurt).
It leaves force and probably analyse mode indeed, but you can easily put it
back into it.
While I don't know whether that is its purpose, I think using this to change
the engine colour and then put it into analyze mode should work fairly well
without any trouble (like the engine suddenly attempting to play moves).
Original comment by jonas.thiem@gmail.com
on 4 Mar 2011 at 2:51
To make it more clear:
If you send "new", "playother" and then enter analyse mode as before, you
should have a perfect inverse analyzer in place despite no "white"/"black" was
used.
Original comment by jonas.thiem@gmail.com
on 5 Mar 2011 at 11:44
playother is very different from white/black.
white/black makes the engine think that it is on move, with the specified color.
playother makes it think it is not on move.
This is important, because from the definition of analyze mode:
"your engine thinks about what move it would make next if it were on move".
As far as I remember from the engines that support playother, this essentially
changes the engines color back to where it came from.
Original comment by lobais
on 6 Mar 2011 at 11:06
I am not sure. From reading the analyze specs you might be right, since
playother puts the engine into normal play mode where there is a concept of a
specific colour it plays, while in analyze mode it is apparently supposed to
'forget' any colour it played and just analyze as if it would be on move now
(even if it isn't) - which probably means also the other colour.
Then again I wonder how playother is of any use at all if not for this
situation. But I suppose you're probably right... I guess it's only useful at
the beginning of the game then, to enable pondering instantly when the engine
is supposed to play black (while white is thinking about the first move).
Interesting to know.. and at the same time not very useful, since first moves
usually take only a fracture of seconds anyway (thanks to opening books) and as
soon as black has been on move at least once, the situation is clear even
without any use of playother.
Original comment by jonas.thiem@gmail.com
on 7 Mar 2011 at 1:29
Original issue reported on code.google.com by
jonas.thiem@gmail.com
on 1 Nov 2010 at 5:21