[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I made gnuchess freak out
From: |
Tim Mann |
Subject: |
Re: I made gnuchess freak out |
Date: |
Sat, 02 Mar 2002 11:27:31 -0800 |
Things are a little harder than that, but only a very little. See below.
> Tim Mann wrote:
> >
> > xboard doesn't check move legality in all cases. The engine is
> > supposed to report an "Illegal move" error on illegal moves (see the
> > protocol spec for details), but GNU Chess 5 tends to just ignore any
> > input it doesn't understand, including illegal moves.
>
> Thanks Tim,
>
> the CVS version of GNU Chess now spews "Illegal move:
> <inputstring>" to anything it doesn't understand. The cheap and
> cheerful 2 line change.
>
> This can, and will make this reply to unimplemented commands ;(
To avoid problems, you also need to go through the protocol spec and see if
there are any commands that are sent by default (that is, without having to be
turned on by the feature command) but that GNU Chess doesn't implement, and
implement them as no-ops. xboard can sometimes get quite confused if you
reply "Illegal move" to a command that all engines are expected to recognize,
thinking that it applies to the most recent move rather than the command.
Hmm, let me simplify that for you. The commands listed below are sent by
default:
xboard
protover
accepted (in response to 'feature' from the engine)
rejected (in response to 'feature' from the engine)
new
variant (you can limit which variants you support with a feature command)
quit
random
force
go
white (can be turned off with a feature command)
black (can be turned off with a feature command)
level
st
sd
time (can be turned off with a feature command)
otim (can be turned off with a feature command)
?
draw (can be turned off with a feature command)
result
edit (can be replaced by "setboard" with a feature command)
hint
bk
undo
remove
hard
easy
post
nopost
analyze (can be turned off with a feature command)
name (can be turned off with a feature command)
rating
computer
partner (only in variant bughouse)
ptell (only in variant bughouse)
holding (only in variant bughouse)
If you are trying to work with protocol version 1 GUIs (xboard/winboard 4.1.x
and earlier, or some other GUIs), turning off commands with "feature" doesn't
work, so you'd have to implement all those above at least as no-ops. Note
that GNU 5 already doesn't fully work with protocol version 1 because it
implements only "setboard", not "edit". It's probably not worthwhile to
implement "edit", but it's pretty quick and easy to recognize and discard any
of the commands above that aren't implemented.
The "variant" command usually isn't sent for normal chess, which is the
default, so you usually won't see it if you did 'feature variants="normal"' to
say that normal chess is all you can handle. However, the protocol doesn't
guarantee that you won't see "variant normal", and some xboard versions have
had bugs that would cause that to happen under some circumstances.
> This gets me an "Illegal move: <inputstring> (fcp rejected this
> move)" or some such for the problematic en passant captures.
>
> > If it's painful to tell the difference between "illegal move" and
> > "unimplemented command that we want to ignore without bothering to
> > write code to recognize it", you could set feature usermove=1. Then
> > (if talking to a GUI that implements protocol version 2), moves from
> > the user will look like "usermove e2e4" instead of just "e2e4". That
> > should make it easier to generate an error message when the move is
> > illegal, since you always know whether it's meant to be a move or not.
>
> Hmm, I'll probably add this as well before 5.04 is released. Do
> you know off hand what version of xboard this was introduced at,
> as presumably I might be breaking support for earlier versions
> of xboard/winboard.
Feature usermove was introduced in 4.2.0beta along with the rest of protocol
version 2. A bug in it was fixed in 4.2.1.
I suggest you send "feature usermove=1" but continue to accept moves with or
without "usermove" in front of them. That way you can give an "Illegal move:
MOVE" response to "usermove Nf3" when that's not a legal move, and an "Error:
COMMAND" response to anything that doesn't start with "usermove" and is not
understood.
I think some versions of SCID had a bug where they didn't implement "usermove"
but also didn't reply "rejected usermove" if you asked for it.
> > Alternatively, you could make sure that all the standard commands in
> > the protocol are recognized (even if GNU Chess does nothing with some
> > of them) and print a proper error message for all unrecognized commands.
>
> But then it might be broken by future versions of the protocol,
> unless you ignore "Illegal move: newcommandname" in which case I
> probably don't need to worry about recognising all the commands
> anyway.
No! This is an important point about the protocol. Future versions are
guaranteed never to send commands to the engine that didn't exist in previous
versions unless the engine turns on those new commands with "feature". So you
only have to worry about the commands that exist today.
> I think we already catch most of the commands :), even if they
> aren't implemented :(
>
> Simon
> --
> Free Software: What good is Open Source without Freedom?
> Open Source Day 2002/04/27 Exeter University
> Entry is free (as in free beer, but there isn't any free beer)
> http://www.dclug.org.uk/ossday/
--
Tim Mann address@hidden http://www.tim-mann.org/