Winboard Communication (@HG)

[Dan Honeycutt]

When I look at a Winboard debug file I see:

Code: Select all

551 >first : xboard
protover 2

A similar situation occurs with 'new' and 'random'. The lack of a '>first :' in front of 'protover 2' I assume means that the two commands are sent in one batch with a '\n' in between. Is that correct?

Thanks
Dan H.

[hgm]

Correct. For new, random this is because these are supplied in the same, user setable initString. Here it is just lazynedd, I guess.

[Dan Honeycutt]

Okay. Thanks for confirming.

Best
Dan H.

[Sven]

Correct. For new, random this is because these are supplied in the same, user setable initString. Here it is just lazynedd, I guess.

Let me add one more question here. The protocol describes the "xboard" command as follows (emphasis mine):

This command will be sent once immediately after your engine process is started. You can use it to put your engine into "xboard mode" if that is needed. If your engine prints a prompt to ask for user input, you must turn off the prompt and output a newline when the "xboard" command comes in.

The bold part has always puzzled me. In my opinion this protocol requirement to output a newline in that case is fully redundant. Do you agree? I think that turning off the prompt is sufficient since WinBoard/xboard ignores all unknown commands (so also a prompt like "Your move: "), even when not terminated with a newline character. Is that right?

The fact that WinBoard/xboard does not really expect any reply to its "xboard" command seems to be confirmed by printing "xboard\nprotover 2\n" in one batch, so I wonder what the "newline" mentioned above should be good for.

Sven

[hgm]

The newline serves to flush the previous prompt, which is not terminated by a newline yet. Otherwise, when the engine would send its first command (e.g. 'feature setboard=1'), XBoard would see it on the same line, appended to the prompt, which would probably make the command unrecognazible, and XBoard would ignore it. Note that the order in which commands are sent by different processes is in general not related in any way to the order in which they are received.

[Sven]

The newline serves to flush the previous prompt, which is not terminated by a newline yet. Otherwise, when the engine would send its first command (e.g. 'feature setboard=1'), XBoard would see it on the same line, appended to the prompt, which would probably make the command unrecognazible, and XBoard would ignore it. Note that the order in which commands are sent by different processes is in general not related in any way to the order in which they are received.

O.k, that makes sense. But I remember having seen some engines that do not send such a newline after receiving "xboard", that do have a prompt in console mode, but do not cause any trouble for WinBoard/xboard. I just don't remember which ones ... Maybe I'll try what happens if I do the same in my own engine.

Sven

[hgm]

Well, perhaps they are just lucky. If they start sending 'feature done=0', there usually isn't too much harm in WinBoard ignoring that.