Author: Robert Hyatt
Date: 18:56:14 09/16/98
Go up one level in this thread
On September 16, 1998 at 05:28:01, Dan Newman wrote: >On September 15, 1998 at 10:57:31, Robert Hyatt wrote: > >Posted by Robert Hyatt on September 15, 1998 at 10:57:31: > ><snip> > >Great. I'm glad you've started this. I think what we need is >a set of commands that is 1) simple, 2) clear, and 3) complete. >(I hope these aren't mutually exclusive.) > >One thing I would suggest is that all commands between engine and >interface be of the form <command-name> <parameters>. Then moves >sent to the engine would look like "move Nf3" instead of the current >xboard/winboard "g1f3". The reasons for this move command format are >1) consistency with the other commands and 2) it makes it easier on the >engine to distinguish moves from un-implemented commands--especially >important if we go to SAN representation. > I agree with this. My approach has always been to first parse something from xboard to see if it is recognizable as a move. If not, try it as a command. If that fails, reject as an error. adding "move xxx" would be fine by me... >> >> Questions remaining: >> >> 1. should the interface program be "smart" and understand the rules of >> chess and take care of 50 move draws, draws by repetition, and so forth, >> or should we make the engines handle this themselves. I vote for the >> latter, since an engine should handle this as part of the game, and it >> will tend to keep the interface program simpler. > >The engines should be able to understand these things themselves. >However, I don't see why an interface program couldn't be smart--just >that it shouldn't be a requirement. One reason I can think of for >having a "smart" interface is so it can act as an arbiter when a >program makes a claim that the game is over or that the opponent made >an illegal move, etc. Currently if you send winboard/xboard a "1-0" >(for instance) whether white has won or not, winboard/xboard immediately >terminates the game, sends the result command to both engines, and >records the game (if you have that set up) to a PGN file with the result >as "1-0". This is of course no problem if both engines are functioning >correctly. But it does allow "cheating" of sorts: imagine you run a 500 >game match (1 sec/move) between two programs and one of them emits the >occasional erroneous "1-0" or "0-1" in its favor... > this is an issue. It is broken in the current auto232 however. Maybe we need an option that lets us connect two programs via two interface programs, in the current mode, or have a "referee" program that sits between the two interface programs and it is the "final authority"... then we could do with or without that program... >> 2. move format? I vote for SAN. Easier to read, is more standard, is >> the PGN standard, etc. > >I slightly favor the non-SAN xboard representation of moves because that >representation is much easier to encode and decode--but if the consensus >favors SAN, I have no real objection. I am a SAN fan even though it is somewhat more complex to parse, because it fits with the PGN standard for saving games... But at present, I parse both with no problems so it isn't an issue at all for me. > >> >> 3. should the engine be able to communicate with the interface program >> for any reason? IE might the interface program have a window open for >> each program and let the programs send "analysis" to it for display in the >> appropriate window? Or should we "keep it simple, stupid" and not worry >> about this? > >What about having a core set of commands that all engines/interfaces >must implement along with a (perhaps large) set of non-essential commands? >For instance we could have commands to send analysis or other messages to >an interface window, but the interface need not implement these commands >and can just ignore them. > >I've often thought it would be nice to have commands that would cause the >interface (xboard/winboard or whatever) create special engine-specific >menus, dialog boxes, etc. These, again, could just be ignored by an >interface. If the interface implements these commands, it could send >back some sort of confirmation that a menu or dialog was created. The >menu commands might look something like this: > >menu <menu name> >additem <menu name> <item name> <command string> >displaymenu <menu name> >deletemenu <menu name> > >(The command string would be sent to the engine whenever the menu item >is selected.) > >Finally, how about a "comment" command so that an engine can send junk >to the interface to be recorded in a debug log file (much as winboard >has) without any worries of accidentally sending a valid command (and >freeing the interface code from having to figure out that the junk >is just junk). > >-Dan. agreed... I haven't gone into optional things yet. But would definitely like a way to "tune" xboard to a program.
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.