The Pipes seem to work now, and I can communicate with Scan.
The first moves in a game are no problem, when I enter a move (with the mouse on my GUI), Scan enters with a book move.
Things go wrong, when Scan starts thinking and sends the move.
The move is normally processed by the Damage GUI.
However on the move I hereafter sent to Scan, I get a Illegal Move Error reply.
From what I can see there seems nothing wrong with the move format send.
And it always occur after the first search of Scan, so when its out of opening book.
Hope this sounds familiar...
No, but I'm used to eternal confusion around protocol categories. In the first post in the "Protocols and tools" thread, I compared event-based protocols where you send events (mostly moves) that occurred during a time interval, to position-based protocols where you send the relevant part of the state before every search (position + clock information). It's connected to functional programming: engine_move = search(pos, time); so you need to send the position and time information just like for function calls (except that it's in text form).
I suspect that you tried sending events (in your case, user moves) instead of the current position every time that Scan is expecting. It only accidentally worked for book moves because Scan updates its board when looking for a move to ponder on (which the book doesn't provide on its own).
Here's an actual (but edited) log-file extract from the Olympiad (">" = to engine, "<" = from engine):
> pos wbbbbbbbbbbbbbbbbbbbbeeeeeeeeeewwwwwwwwwwwwwwwwwwww
> level 75 1320000 0
< info 0 0.0 0 0 0.00 0.0 34-30
< move 34-30 17-21
> pos wbbbbbbbbbbbbbbbbbbebeebeeeeeewwwwewwwwwwwwwwwwwwww
> level 74 1319997 0
< info 0 0.0 0 0 0.00 0.0 30-25
< move 30-25 20-24
> pos wbbbbbbbbbbbbbbbbbbeeeebbweeeeewwwewwwwwwwwwwwwwwww
> level 73 1319993 0
< info 0 0.0 0 0 0.00 0.0 33-29
< move 33-29 23x34x29
Another small thing, I have to sent the init command initially.
Is there a reason that Scan does not execute the init self at start-up and then sends the name and author?
There are three. 1) the GUI needs to know quickly whether the engine supports the protocol (timeout). 2) initialisation depends on GUI parameters so the engine has to give the GUI a chance to set them first. Setting "bb-size" to 5 will make loading much faster for instance. 3) I wanted to respect a concept in the UCI documentation, even though I have no use for it yet:
* The engine should boot and wait for input from the GUI,
the engine should wait for the "isready" or "setoption" command to set up its internal parameters
as the boot process should be as quick as possible.
We can imagine a GUI just wanting to collect the engine name or parameters.
Unrelated to your questions, UCI is using "isready" for two purposes: initialisation and synchronisation; I separated it into "init" and "ping".