🚀 go-pugleaf

Tim:

I know you don't have very much to do where you work, so I thought
I would give you a "wish list" for Zippy. [ :^)  ] I could do these things
pretty easily, but they are probably of general interest and would be useful
to many zippy users.

1. add a prompt from zippy, something like "oname scratchy" to indicate
the name of the opponent.  I would like for Crafty to know who it's
playing so it can create a database where it keeps up with what openings
it has played against "x" and how successful each opening type was.

2. add two new prompts, like "orate n" and "prate n" to give the rating
for the opponent and the computer program itself.  I would use these in
Crafty to "adjust" the draw score, as I did in Cray Blitz.  When playing
higher rated players, the draw score would increase to something > 0, while
when playing much lower rated players the draw score could drop below -1 
pawn.

3. add a command-line option to allow the "draw" and "abort" requests to
be passed through to the program.  IE, -draw would tell zippy to stay out
of the draw loop and simply pass "draw" through to the program.  Ditto
for -abort.  This would give the program (if it's capable) more control
over what is going on.

4. add a -match command-line option that then passes the match command
thru to the program so that it can (if wanted) choose to accept/reject
match requests.  There is currently a significant amount of abuse
regarding "color" and zippy (not keeping a database) doesn't know that
it is accepting match requests where Crafty plays black 20 times in a
row.

Note that 3-4 also require that zippy then be prepared to pass "match",
"accept", etc. back through to the server.

I would propose that *any* commands that are passed through to the
program be accompanied by the "time" and "otim" commands as well.  I've
found that in crafty, it is unreliable to use the FIONREAD trick on
TCP/IP sockets...  it will correctly say that the stream has data,
but if you do a single read and then test again, on some implementations
you get a "no more input" indication.  The problem seems to be that
three "parcels of data arrive" (time, otim, and move) and the descriptor
is flagged as "got data" but the first read seems to clear that flag.
I solved this in Crafty by doing three reads anytime I detect input
present, which sucks in the two time commands and the move.  Don't
"break" this!!!  :^)  In short, anytime you send something to the
program, tack on the time and otim commands as well.

Hope this list isn't too long.  Zippy has worked well, letting Crafty
play an average of over 200 games a day.  It's provided an outstanding
testbed for me, letting me try things I could never test without some
type of automated interface.  Now I can make a change and simply watch
how the games go.

Bob Hyatt


-- 
Robert Hyatt                    Computer and Information Sciences
hyatt@cis.uab.edu               University of Alabama at Birmingham
(205) 934-2213                  115A Campbell Hall, UAB Station 
(205) 934-5473 FAX              Birmingham, AL 35294-1170