Moderator: Andres Valverde
The clocks in fact always remain with the color. Which clock reading is relayed with "time", and which by "otim", is determined by which side the engine plays. Note that the way the clocks operate and receive extra time (in accordance with the selected time control) is not affected in any way by which moves are made by the engine, which by the opponent, and which were forced.
Olivier Deville wrote:Hi Kirill
I have the email address of Chua Kong Sian. I can forward him the bug report if you want.
Kirill Kryukov wrote:(Still I stand that a stateful protocol is inherently full of pitfalls).
I tried to run some matches with GNU Chess 5.07, and noticed that it has the same bug with number of other Winboard engines: It does not count the opening moves from external book as part of time control.
Michel wrote:I tried to run some matches with GNU Chess 5.07, and noticed that it has the same bug with number of other Winboard engines: It does not count the opening moves from external book as part of time control.
Are you sure about this? I had a quick look at the source code of GNU Chess and the ply counter (called GameCnt) seems to be updated correctly during force mode.
H.G.Muller wrote:Kirill Kryukov wrote:(Still I stand that a stateful protocol is inherently full of pitfalls).
That might be, but I don't think that in this case staeless vs stateful has anything to do with it in this case. The problem is that on forcing in a move the state is not consistently updated: the move is accepted and the position altered, but the move counter is not incremented. Exactly the same could happen in an UCI engine: there you force in moves for every move the engine has to make. If an engine would not increment the move counter then, you would get similar problems...
H.G.Muller wrote:Oh, does it? Well, then you would get an error when the engine would decrement that remaining-move-count for every move it receives.
Kirill Kryukov wrote:It's great that you improved the protocol specs! Hopefully new engines will not have this problem. (Still I stand that a stateful protocol is inherently full of pitfalls).
; You can set program option here if its not possible in the server program
; The priority flag is if you want the server app. to run with lower priority.
; This could be when you want use an engine to analyze games/positions and
; you also want to use the computer to other work. If this is not set it will
; try to see what the client wants and set the server to this priority.
; Don't use the high option is you don't know what you do.
;Priority := low, normal or high
;CommandLine := f:\cygwin\home\chess\GNShogi\gnushogi.exe
; The debug switch is if you want to see the command flow in a window when the
; server and client talks. 1 means viewpoint is on the client interface, 2 means
; viewpoint is on the server interface, and finaly 3 means that the viewpont is
; after the translation (input to client and input to server).
;Debug := 0, 1, 2 or 3
Debug := 0
; A try to pass any control signal.
;Ctrl := False or True
; The logfile is if you want that InBetween log all communications.
;Log := logfile.log
; Set the translation of client command to server here.
; clientword := serverword
black := zzzzz
white := black
zzzzz := white
; Set the translation of server response to the client here.
; serverword := clientword
Users browsing this forum: No registered users and 3 guests