H.G.Muller wrote:If it starts with 4 integers, WB considers it thinking output. And if /engineDebugOutput=1, anything the engine sends, no matter how incompliant, should be copied to the debug file. So if it is not there, it means WB did not receive it, which must mean the engine did not actually send it.
Either the engine somehow hangs in the input loop, or the output is not flushed...
In my engines the test for input is like this, however:
- Code: Select all
int unbuffered_input(int init)
{
static int pipe;
static HANDLE inp;
DWORD cnt;
if(init)
{ inp = GetStdHandle(STD_INPUT_HANDLE);
} else
{ if(!PeekNamedPipe(inp, NULL, 0, NULL, &cnt, NULL)) return 1;
return cnt;
}
}
I'm not sure. Is WB that different from just opening the EXE? It does not get stuck then, and the engine does send the output and the move.
Also, I know from the debug output on WB, the engine responds properly to the "quit" command even though it was sent during the time the engine should have been thinking. So that would suggest the engine does not get stuck.
As for the input function, I have 2 separate functions, one for when the engine is thinking, and one for when the engine is not thinking.
EDIT: I will test the /engineDebugOutput=1 statement once I get off from work today. Having checked and double-checked the engine output, I'm pretty sure it's correct, but it's still worth a test, I think.
EDIT 2: I should note that in addition, the engine, on the statement right before the statement that calls the search function (this is after the engine gets out of the input loop), sends the statement "# searching" to WB. That DOES show in the debug file.