Question about winboard commands to the engine

[Fguy64]

ok So it seems there are two ways to bring the engine up to date with what is happening in a game, either by sending a position using the setboard command, or sending a move either by itself or with the usermove command.

I expect that sending a move is the normal method when playing a game realtime.

One thing is not clear, if you want the engine to send back a move after due consideration, then the GUI issues a go command each and every time after sending a usermove. Is this correct?

[Fguy64]

OK I'll answer my own question. Subsequently I have surmised that the normal mode for a realtime game is "non" force mode, in which case the engine responds not to "go" but directly to a move. I think.

[bob]

ok So it seems there are two ways to bring the engine up to date with what is happening in a game, either by sending a position using the setboard command, or sending a move either by itself or with the usermove command.

I expect that sending a move is the normal method when playing a game realtime.

One thing is not clear, if you want the engine to send back a move after due consideration, then the GUI issues a go command each and every time after sending a usermove. Is this correct?

No.

If you send a move to the engine, it will normally send a move back, unless you are in "force" mode which is the mechanism used to "stuff" a series of moves into the engine before starting the game (this is used to resume an adjourned game on a server for example).

If the program is supposed to play white, from the beginning of the game, the GUI will send "go" to tell it to make a move. And from then on the GUI will simply send a move to the engine and expect a move to come back.

[Fguy64]

ok So it seems there are two ways to bring the engine up to date with what is happening in a game, either by sending a position using the setboard command, or sending a move either by itself or with the usermove command.

I expect that sending a move is the normal method when playing a game realtime.

One thing is not clear, if you want the engine to send back a move after due consideration, then the GUI issues a go command each and every time after sending a usermove. Is this correct?

No.

If you send a move to the engine, it will normally send a move back, unless you are in "force" mode which is the mechanism used to "stuff" a series of moves into the engine before starting the game (this is used to resume an adjourned game on a server for example).

If the program is supposed to play white, from the beginning of the game, the GUI will send "go" to tell it to make a move. And from then on the GUI will simply send a move to the engine and expect a move to come back.

Thanks Robert. I think we kind of crossed paths in this thread I must have been composing my reply to myself while you were composing yours.

regards.

[kranium]

ok So it seems there are two ways to bring the engine up to date with what is happening in a game, either by sending a position using the setboard command, or sending a move either by itself or with the usermove command.

I expect that sending a move is the normal method when playing a game realtime.

One thing is not clear, if you want the engine to send back a move after due consideration, then the GUI issues a go command each and every time after sending a usermove. Is this correct?

Hi Fred-

starting with WB2, there's a FEATURE command: 'usermove'

if this 'feature' is enabled, then all moves sent to the engine by the GUI are prefaced by usermove, for ex:

usermove e2e4

otherwise, winboard engines should simply parse the command line for something like:
e2e4

many winboard engines use isdigit, isalpha, etc. to determine if there's input on the command line in such a pattern:
alphabet numeric alphabet numeric

if so, they read it as a move (and should then test for legality)...

the go command simply means 'go'... it signals the engine to start thinking on the current position and need not be coupled with move input...
i.e. they are mutually exclusive

[Fguy64]

ok So it seems there are two ways to bring the engine up to date with what is happening in a game, either by sending a position using the setboard command, or sending a move either by itself or with the usermove command.

I expect that sending a move is the normal method when playing a game realtime.

One thing is not clear, if you want the engine to send back a move after due consideration, then the GUI issues a go command each and every time after sending a usermove. Is this correct?

Hi Fred-

starting with WB2, there's a FEATURE command: 'usermove'

if this 'feature' is enabled, then all moves sent to the engine by the GUI are prefaced by usermove, for ex:

usermove e2e4

otherwise, winboard engines should simply parse the command line for something like:
e2e4

many winboard engines use isdigit, isalpha, etc. to determine if there's input on the command line in such a pattern:
alphabet numeric alphabet numeric

if so, they read it as a move (and should then test for legality)...

the go command simply means 'go'... it signals the engine to start thinking on the current position and need not be coupled with move input...
i.e. they are mutually exclusive

yeah, I noticed about usermove. It definitely makes life easier for the programmer, doesn't it? but it sounds like I will need also to use isdigit and isalpha, etcetera, if I want to communicate with some engines that do not implement usermove?

duly noted about the additional info that go need to follow user move input.

[hgm]

A WinBoard engine has a notion of the side it is playing: white, black, or none. If the turn of the side it is playing comes up, it automatically moves.

When you start a new game (through the 'new'command), the engine is set to play black. When you send 'go', the engne is set to play the color that is on move (so it will make a move). When you send 'force', the engine is set to play neither.

[Fguy64]

hmmm one thing leads to another.

From reading the posts here, after the GUI first says "go" to the engine, then moves are passed back and forth. It has been pointed out that the GUI sends a move and expects one back, or else some kind of a result.

Q: When things are in "go" mode, does that limit the number of different commands that might be sent by the GUI. Maybe just moves, and a command to leave "go" mode? That would make things easier for the programmer.

If the answer is yes, then just sending repeated "go" commands would not be the way to have a computer play itself. It sounds like one would have to alternate "go" and "force" with no moves being sent by the GUI, for the engine to play itself?

[kranium]

but it sounds like I will need also to use isdigit and isalpha, etcetera, if I want to communicate with some engines that do not implement usermove?

no.
don't forget...an engine does not normally communicate directly with other engines...only with the GUI, so if the FEATURE command
feature usermove=1
is sent to the GUI
the GUI will respond:
accepted usermove

afterward the GUI will indicate moves in the following format:
usermove e2e4

yes this make parsing the input a bit easier...
you simply have to wait until the command line contains usermove,
then parse the next 5 characters for the (actual) move

[kranium]

hmmm one thing leads to another.

From reading the posts here, after the GUI first says "go" to the engine, then moves are passed back and forth. It has been pointed out that the GUI sends a move and expects one back, or else some kind of a result.

Q: When things are in "go" mode, does that limit the number of different commands that might be sent by the GUI. Maybe just moves, and a command to leave "go" mode? That would make things easier for the programmer.

If the answer is yes, then just sending repeated "go" commands would not be the way to have a computer play itself. It sounds like one would have to alternate "go" and "force" with no moves being sent by the GUI, for the engine to play itself?

"go" is a command, not a mode....
for ex:
use any wb engine...
type go
then type go
then type go
then type go
etc...

the engine will play an entire game against itself...
it simply thinks and makes a move when it sees the "go" command...