CSVN Programmers' Tournaments May 2014

[Henk]

WinBoard, I suppose. (Or XBoard, when you run on Linux.) And opponents. (But WinBoard comes with Fairy-Max and optionally Fruit and Pulsar, and on Linux there are many packages with engines of various strength, amongst which fairymax.)

And which link can I use best to download winboard. I remember I have tried to download winboard weeks or months ago and there were problems which I cannot remember.

[hgm]

It is available from WinBoard forum, but a direct link is

http://hgm.nubati.net/WinBoard-4.7.3.exe .

[ernest]

http://hgm.nubati.net/WinBoard-4.7.3.exe .

Actually 4.7.3a !

[hgm]

Yes, that is in there. But better use the link I gave to get it, if you want to avoid a 404 error...

[Henk]

I have implemented the minimum. Being busy half a day now. I tested it but my engine plays only one move if I use the winboard interface.
It says {Xboard: Forfeit due to in

Looks like he doesn't show the whole message.

Do you know what's wrong. And how can I simulate it in my console application.

Commands:
new
e2e4
usermove d7d5
go
quit

seems to work fine.

[Richard Allbert]

There's a C# version of Jabba with source, the winboard code is in there.



www.rja-software.com click on Jabba

[Henk]

I have implemented the minimum. Being busy half a day now. I tested it but my engine plays only one move if I use the winboard interface.
It says {Xboard: Forfeit due to in

Looks like he doesn't show the whole message.

Do you know what's wrong. And how can I simulate it in my console application.

Commands:
new
e2e4
usermove d7d5
go
quit

seems to work fine.

I think I already found one bug. To be continued. Still don't know how to debug this winboard driver part.

[hgm]

If you run WinBoard with the extra option -debug, it creates a file called winboard.debug, which contains a complete log off all communication to and from the engine. That is often helpful, to see where your engie hangs.

Most common problem is that the engine fails to flush its output, so that GUI and engine start waiting for each other, the progress-causing command hidden in some buffer.

[xmas79]

Well sometimes WB protocol seems to me a bit strange... It leaves freedom of interpretation.... eg. "setboard xxxx w" implicitly makes the engine play black, and should put engine in "run" mode, so if the user makes a move the engine should start thinking and move. This is a bit strange, and that's less obvious since before a "setboard" command engine is put in force mode by "force". I expected a "go" command to resume play after a user move, "go" that never arrived...

Just now debugging further my protocol I discovered I can't paste a position in winboard and make a move, since my engine would start to play and winboard doesn't expect that

Code: Select all

PasteTextFromClipboard(): lock count 0
PasteTextFromClipboard(): lock count 0
PasteTextFromClipboard(): err 0 locked 0
FEN castling rights: 7 0 4 7 0 4
PasteFenFromString(): fen 'rnbqkbnr/p1pppppp/1p6/8/4P3/8/PPPP1PPP/RNBQKBNR w KQkq - 0 1'
FEN castling rights: 7 0 4 7 0 4
2179 >first : force
2180 >first : memory 68
2180 >first : cores 1
2180 >first : new
random
2181 >first : level 0 0:05 0.05
2181 >first : post
2181 >first : hard
2181 >first : easy
2181 >first : ping 2
Impossible move , type = 0
2182 >first : force
write FEN 50-move: 0 0 0
e0. p=-4
2182 >first : setboard rnbqkbnr/p1pppppp/1p6/8/4P3/8/PPPP1PPP/RNBQKBNR w KQkq - 0 1
EditPosDone
2201 <first : pong 2
20568 >first : usermove 20569 >first : e4e5
20574 <first : 1 -51 0 1 h7h6
20575 <first : 1 -39 0 2 g7g6
20576 <first : 1 -29 0 4 e7e6
20576 <first : 1 -13 0 18 d7d5 e5d6 e7d6
20577 <first : 1 0 0 21 b8c6
20578 <first : 1 41 0 25 c8b7
20578 <first : 2 9 0 62 c8b7 b1c3
20579 <first : 3 26 0 260 c8b7 g1f3 d7d5 b1c3 b8c6
20579 <first : 4 10 0 675 c8b7 g1f3 d7d5 f1b5 b8c6
20579 <first : 5 6 0 3369 c8b7 g1f3 b7f3 g2f3 b8c6
20580 <first : 6 -15 0 7404 c8b7 g1f3 b7f3 g2f3 b8c6 d2d4
20621 <first : 7 -12 5 47318 c8b7 g1f3 b7f3 g2f3 b8c6 f3f4 d7d5 d2d4
20636 <first : 8 -27 6 71971 c8b7 g1f3 b7f3 g2f3 b8c6 f3f4 a8c8 f1a6
20669 <first : move c8b7
Undoing extra move from first, gameMode 6
20669 >first : undo
GameEnds(28, xboard exit, 2)
22616 >first : quit

If I don't put my engine in play mode then it doesn't start to play when it should... Why don't issue a simple "go" after a "force"?

[Sven]

Well sometimes WB protocol seems to me a bit strange... It leaves freedom of interpretation.... eg. "setboard xxxx w" implicitly makes the engine play black, and should put engine in "run" mode, so if the user makes a move the engine should start thinking and move. This is a bit strange, and that's less obvious since before a "setboard" command engine is put in force mode by "force". I expected a "go" command to resume play after a user move, "go" that never arrived...

The behaviour of "setboard" is consistent with that of "new". In both cases you reset the game and start from some initial position. After "new" the engine is expected to play black. After "setboard" the engine is expected to play the colour that is not on move. In both cases the "force" mode, if previously entered, is left (since entering it happened in the previous game's context which is now gone). When not in "force" mode you start the game either by making a (user) move or by sending "go" to tell the engine that it should play the colour that is on move.

So there is no room for interpretation in this area, I think the spec is precise here.

Sven