UCI Engine Tuning

[stevenaaus]

Well, talking about engine options, there definitely seems to be a problem in SCID vs. PC:

when I load Fairy-Max, (through the Tools -> Analysis Engines -> New... dialog) the "Configure" button for the engine options stays grayed out, so I can't configure any of its options...

It stays grey because Scid and ScidvsPC only configures UCI engines.
And AFAIK xboard engines don't have a common configuration standard akin to UCI ?

[hgm]

Of course they have.

Try to run Fairy-Max (or Gaviota) in WinBoard or XBoard, and see what happens if you open the Engine #1 Settings dialog.

[michiguel]

Of course they have.

Try to run Fairy-Max (or Gaviota) in WinBoard or XBoard, and see what happens if you open the Engine #1 Settings dialog.

http://sites.google.com/site/gaviotache ... figuration

Miguel

[stevenaaus]

And AFAIK xboard engines don't have a common configuration standard akin to UCI ?

Of course they have.

Ok, i found some doco.
I wonder why no-ones coded that before. Shit, i'll probably have to do it.

[hgm]

Well, if you already support UCI options, it should not be much work to use the same infra-structure you have for that forXBoard options as well. It would only be a matter of recognizing the feature option commands from the input stream, and then parsing the accompanying string to fill the list of options you maintain for each engine.

XBoard protocol has more different option types than UCI, but the distinction between -string, -file and -path is only needed to allow the GUI to provide the proper browser button (if any) with the text edit, and I am not sure SCID provides such buttons in the first place. So you could all map them to string.

Note, however, that UCI supports the concept of "standard options", like "Hash", which every engine should implement the same way, and in GUIs usually are controlled from another settings dialog, common to all engines. SCID does not seem to make that destinction, and displays the Hash option together with the non-standard (private) engine options. There is nothing against that, but in XBoard engines the equivalent options are not announced by the engine through feature option commands, but use dedicated names and commands to set the options, like feature memory=1, with possible reply memory 64 to set the size to 64MB. So you would have to somehow map those features to the option list as well, so they get presented to the user in the configuration dialog.

[stevenaaus]

And AFAIK xboard engines don't have a common configuration standard akin to UCI ?

Of course they have.

Ok, i found some doco.
I wonder why no-ones coded that before. Shit, i'll probably have to do it.

....
You're right HGM - of course i can reuse the UCI procedures. But after looking at my 30 odd engines, engines, I can only see Gaviota and Fairymax really using the options feature. Gnuchess does, but it also supports UCI. I couldnt see any options in Crafty-234.

So i probably won't write a config widget for xboard. O(cost/benefit)~epsilon. ;> Someone else is welcome to. The relevant code can be found in uci.tcl::{uciConfig,readUCI,uciConfigWin} and should be ported to analysis.tcl::{xbConfig,readXB,xbConfigWin}

[stevemulligan]

The various options supported by engines varies alot. What are the best sites for some general purpose doco ? Sorry for being such a noob.

I consider myself to be a pretty big newb and the Xboard protocol was the easiest for me to implement. The docs were easy to find and understand and the implementation took less than half an hour. After playing dozens of games by hand I was pretty happy to see Winboard automating the process.

One GUI that wanted to get working at the time was Arena. I found it had problems with Xboard engines. I decided to add UCI support and it took me a couple days, and I'm still don't have a complete implementation. It did work slightly better with Arena though. EDIT: The problem was most likely with my xboard implementation, not Arena, but switching to UCI fixed my problem.

So I would say it depends on your GUI. I'm trying to use WinBoard exclusively now because it's very fast on my slow hardware.

[hgm]

So i probably won't write a config widget for xboard. O(cost/benefit)~epsilon. ;> Someone else is welcome to. The relevant code can be found in uci.tcl::{uciConfig,readUCI,uciConfigWin} and should be ported to analysis.tcl::{xbConfig,readXB,xbConfigWin}

That is of course free for you to decide.

Just so long as it is clear that this was not really a poll on what is the best protocol, but about which protocol is supported best by SCID...

[stevenaaus]

Just so long as it is clear that this was not really a poll on what is the best protocol, but about which protocol is supported best by SCID...

It's not ~just~ the effort of coding xboard dynamic config support. Scid is a huge sprawling project, and I've started to not add code/features just to avoid more bloat. For good or bad, UCI seems the prevalent protocol.

I'd like to support xboard engines better, especially for the tournament feature. I just did some quick testing. Fairymax doesn't support the setboard command. Currently, Scid vs PC's tournament assumes this command is working , so maybe i will/should write code for engines without 'setboard'.

And Gaviota 0.74 doesn't like my xboard code. I can't get more than one move out of it at either time-pre-game or seconds-per-move. For seconds-per-move I issue both "st" and "time" and it's quite possible this is wrong ?

setboard rnbqkbnr/ppp1pppp/8/3P4/8/8/PPPP1PPP/RNBQKBNR b KQkq - 0 2
st 5
time 500
go

For time-per-game i issue
setboard r1bqkbnr/pppppppp/2n5/8/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 0 2
level 0 0:56 1
go

but still can't get more than one move out of it. The latest Gaviota linux bins won't run on this box because of glibc version conflict. Any link for recent gaviota source ?

And I will mention Scid's engine configuration does allow for command line options to be given to the engine, which many engines support.

[michiguel]

Just so long as it is clear that this was not really a poll on what is the best protocol, but about which protocol is supported best by SCID...

It's not ~just~ the effort of coding xboard dynamic config support. Scid is a huge sprawling project, and I've started to not add code/features just to avoid more bloat. For good or bad, UCI seems the prevalent protocol.

I'd like to support xboard engines better, especially for the tournament feature. I just did some quick testing. Fairymax doesn't support the setboard command. Currently, Scid vs PC's tournament assumes this command is working , so maybe i will/should write code for engines without 'setboard'.

And Gaviota 0.74 doesn't like my xboard code. I can't get more than one move out of it at either time-pre-game or seconds-per-move. For seconds-per-move I issue both "st" and "time" and it's quite possible this is wrong ?

setboard rnbqkbnr/ppp1pppp/8/3P4/8/8/PPPP1PPP/RNBQKBNR b KQkq - 0 2
st 5
time 500
go

For time-per-game i issue
setboard r1bqkbnr/pppppppp/2n5/8/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 0 2
level 0 0:56 1
go

but still can't get more than one move out of it. The latest Gaviota linux bins won't run on this box because of glibc version conflict. Any link for recent gaviota source ?

And I will mention Scid's engine configuration does allow for command line options to be given to the engine, which many engines support.

There were many releases after 0.74, current one is 0.83
http://sites.google.com/site/gaviotache ... e/releases

Please let me, know, I am very interested to make sure there are not protocol issues. I put a lot of effort to make sure Gaviota work in every single GUI I and many others tested for both, UCI and winboard.

I am not sure what you mean by getting more than one move, but if you try to send several "go" you need to send "force" (I think, I do not remember this detail from memory). i.e. you cannot change sides w/o using force IIRC.

Miguel