force go white black

[David Weller]

Hi all,

Is the engine supposed to wait for an explicit 'go' command before it 'goes'?
or, can we assume that if we are on move, the receipt of a legal move from the gui signals it is time to start producing our move?

I had always done the former. But recently have had an occasional problem with Arena telling my engine:

time ####
white/black
go

while it was thinking. and upon finishing it would interpret the above as 'go again' !

upon reflection, it makes no sense to send the 'go' command unless we were supposed to wait for it, so maybe I have assumed incorrectly.

In my defense, however , my winboard code was modeled after TSCP and it seems he had the same assumption

[Niyaz Khasanov]

Winboard Protocol is used for GUIs as well as for humans with keyboard.
Therefore the protocol assumes that a stupid user can enter any command in any time on the keyboard.
If you get a command that already has been executed, fulfil it again.
If you get a command that cannot be executed because it already has been executed, just ignore it.

[David Weller]

OK, so just ignore go if we're already 'going' [ie., if computer IS playing stm]

Thanks, Niyaz.

oops, wait a minute.... this doesnt work

What is happening is, the commands are 'postponed' until after the computer makes its move, so as far as the engine is concerned, it is being told to go again, after it went already, it is no longer on move. So it doesnt 'appear'as some sort of duplicate, but a simple instruction to play the side on move.

1. Arena sends a move, eg., e2e4
2. Engine receives the move and begins thinking....
3. Arena, as though on drugs, sends - black, go
4. Engine finishes its time thinking, and sees the commands: black, go

now black is inconsequential, but go means - play the side to move
I cant ignore it, as this might be, as you said, a user asking the engine to play side to move.

This must be part of that 'buffered input' stuff Tim Mann was talking about in his readme....

[Pallav Nawani]

Hello,

Arena must put your program in force mode before it can say go. Does it give the command force?

Which winboard protocol are you using. I am using WB2, and my logs don't show a single go command in normal games.

Pallav

[José Carlos]

Yes, the protocol says you can be in playing mode or in force mode. After the command force you don't think until you get a go. If you have a defined color (a white or black command) and receive a move, you start thinking.
I implemente this with 3 possible colors for my program: white, black, undefined. A force command makes color=undefined, a white or black command makes the engine be that color, a go always put the engine in the color to move and starts thinking and a usermove makes the engine move only if color to move == engine's color.
Hope this helps.

[David Weller]

Code: Select all

47139483*1*Start calc, move no: 6

47139784>1:time 29996
47139784>1:otim 30000
47139784>1:d7d5

               47139824<1: 1    22      3      5260  Bg5 dxe4 Nxe5
               47139844<1: 2    22      4      6752  Bg5 dxe4 Nxe5

47139924*1*Start calc, move no: 6

                 47139944<1: 3    37     14     22682  dxe5 Nxe4 Nbd2

47140204>1:time 29996
47140204>1:otim 30000
47140204>1:white
47140204>1:go

             47140405<1: 4    38     60     90285  exd5 exd4 Qxd4 Qxd5 Bf4 Qxd4 Nxd4
             47146163<1: 5     0    636    968551  --
             47146904<1: 5    32    710   1077110  exd5 e4 Ne5 Nxd5 Nd2
             47150699<1:move e4d5

47150699*1*Found move:e4xd5
47150830**New move before message, game, Game: 0 Move: 7
47150830**New move after message, game 0, should be: 0 engine to move:2

              47150830<1: 1   132      1      1743  Bb5+ c6 dxc6 bxc6 dxe5 Qxd1+ Kxd1 cxb5 exf6 gxf6
              47150830<1: 2   132      1      2039  Bb5+ c6 dxc6 bxc6 dxe5 Qxd1+ Kxd1 cxb5 exf6 gxf6

47150840*2*Start calc, move no: 7
47150840>2:ucinewgame
47150840>2:isready

                  47150890<1: 3   185     19      8885  dxe5 ++
                  47150930<1: 3   194     23     14081  dxe5 Nxd5 Bg5
                  47151380<1: 4   174     68     78668  dxe5 Nxd5 Bb5+ c6 c4 Bb4+ Bd2
                  47151861<1: 5   271    116    146838  dxe5 ++
                  47152853<1: 5   271    215    289558  dxe5 Nxd5 Bc4 Be6 Kg1

47154585<2:readyok
47154605>2:position startpos moves e2e4 e7e5 g1f3 g8f6 d2d4 d7d5 e4d5
47154605>2:go wtime 289465 btime 300000 winc 0 binc 0 movestogo 37
...
47156297<2:bestmove e5d4 ponder d1d4
47156297*2*Found move:e5xd4
...
47156418*1*Start calc, move no: 8

47156728>1:time 28947
47156728>1:otim 29966
47156728>1:e5d4
...
47156918*1*Start calc, move no: 8
47157179>1:time 28947
47157179>1:otim 29966
47157179>1:white
47157179>1:go

             47159282<1: 6   232    859   1113380  dxe5 Nxd5 Bc4 Be6 Kg1 Nc6
...
47161645<1:move d4e5
47161645*1*---------> Arena:Illegal move! (d4e5)

the engines thinking output is indented

and, no I didnt see a force command...?

Jose',
It sounds like we have a similar implementation.

Yes, GES will not 'respond' to a move [besides updating the internal board] until after a go

[Pallav Nawani]

Very strange . I don't have a clue what's happening! You are using WB1 protocol? What about switching to WB2?