Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: new autoplayer interface standard

Author: Robert Hyatt

Date: 06:47:10 09/16/98

Go up one level in this thread


On September 15, 1998 at 22:31:33, Keith Ian Price wrote:

>On September 15, 1998 at 17:47:23, Robert Hyatt wrote:
>
>>On September 15, 1998 at 17:19:30, Roberto Waldteufel wrote:
>>
>>>
>>>On September 15, 1998 at 10:57:31, Robert Hyatt wrote:
>>>
>>>>Below is some excerpts from the current xboard/winboard interface standard
>>>>that can serve as a jumping-off point for developing an autoplayer that should
>>>>finally be able to connect windows and unix boxes together using serial or
>>>>network connections.
>>>>
>>>>========================================================================
>>>>Chess Engine Communication Protocol
>>>>========================================================================
>>>>
>>>>1. Commands to the engine
>>>>
>>>>All commands from the interface to the engine end with a newline (\n), even
>>>>where that is not explicitly stated.  All your output to the interface must
>>>>be in complete lines; any form of prompt or partial line will cause
>>>>problems.
>>>>
>>>>draw
>>>>  The engine's opponent offers the engine a draw.  To accept the draw,
>>>>  send "draw".  To decline, ignore the offer, or send "decline".
>>>>  Note that it's possible for the draw offer to have been withdrawn by
>>>>  the time you accept it, so don't assume the game is over because you
>>>>  accept a draw offer.  Continue playing until the interface tells you the
>>>>  game is over.
>>>>
>>>>    [snip]
>>>
>>>Hi Bob,
>>>
>>>In fact, the laws of chess are very specific about draw offers.
>>>
>>>1) It is only allowed to offer a draw when it is your turn to play, not while
>>>your opponent is thinking (or searching).
>>>
>>
>>correct.  the issue is, however, "asynchronous communication".  In the case
>>of Crafty, it makes a move, offers a draw, and starts thinking based on what it
>>expects for you to play.  The "retraction" was a simple term for you making a
>>move without saying "yes".  If I offer you a draw, you can say "accept" and the
>>game ends or you can say "decline" and keep playing, or you can make a move and
>>press the clock, which is the same as saying "decline"..
>>
>>
>>
>>>2) Having made a draw offer, you do not have the right to retract it. The
>>>opponent may think as long as his clock permits before either accepting the
>>>offer or making a move. Once he makes a move and presses his clock, he loses the
>>>right to accept your draw offer (unles you make a new draw offer).
>>
>>right.  I worded that poorly, but it's worded like that because of playing
>>on ICC.  Because I can get confused with draw offers when there is lots of
>>lag...
>>
>>
>>
>>>
>>>I think that this actually simplifies the task for an autoplayer compared to
>>>what you suggest, since the program that has been offered the draw does not need
>>>to check if the offer has been rescinded, since that would be illegal. Although
>>>it is only a minor point of the FIDE laws, I do think it is important to get
>>>this sort of thing right at an early stage, otherwise in years to come it will
>>>remain an embarrasing anomally once multiple programs support the standard. This
>>>is how we come to rely on arrangements that ignore rare but important situations
>>>like underpromotions, for example.
>>>
>>>Can you explain how the engine and the interface communicate in the set-up you
>>>propose? I imagine it would be quite simple, but I don't really know anything
>>>about communications programming, so I'm not quite sure what extra code t
>>>Best wishes,
>>>Roberto
>>
>>
>>
>>
>>communication is easy.  To send something to the interface, you simply
>>do a "printf("move %s\n",move_text)"...  ie normal I/O to stdout goes to
>>the interface.  To read a command or move, just read from stdin, like you
>>would if in a dos window...
>>
>>That code is easy...
>
>What about the fact that DOS/Windows programs' newlines will have carriage
>returns attached, and the Unix ones will only have the line feeds? It should be
>made standard that either case is acceptable, or is that handled well enough by
>modern compilers?
>
>kp

For portability, I handle this inside crafty.  When I read a line of input,
I always do something like this:

   if (strchr(buffer,'\r') *strchr(buffer,'\r')=' ';

to remove the return and leave the \n...

otherwise there are problems with dos/windows/macintosh/etc...



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.