Winboard Forum

I know it sounds crazy, but why not?

Actually, I would like even better a merged protocol. Call it WbUCI (pronounced Wah-Bookie) where it recognized any feature from either protocol inline.

So an engine would announce its ability as winboard protocol 2, UCI, or WbUCI.

The WbUCI protocol would allow the wonderful ease of setup of UCI together with the simplified (and stateful) game play of Winboard. So (in my view) you would get the best of both worlds.

But lacking WbUCI protocol, just having Winboard natively support UCI engines would be very nice, so that we do not have to perform a polyglot mapping for every UCI engine. Not that I'm lazy. No, actually, that is exactly the reason.

I am not sure how you imagine this, and how it could beat using Polyglot. WinBoard already has a mode where it automatically invokes Polyglot, so that the user does not have to set up a polyglot.ini file himself, but merely tells WinBoard that the engine is UCI (through the command-line option -fUCI or -sUCI). So it seems that lazy people don't have any worry at all...

H.G.Muller wrote:I am not sure how you imagine this, and how it could beat using Polyglot. WinBoard already has a mode where it automatically invokes Polyglot, so that the user does not have to set up a polyglot.ini file himself, but merely tells WinBoard that the engine is UCI (through the command-line option -fUCI or -sUCI). So it seems that lazy people don't have any worry at all...

I was not aware that it was that simple to run a UCI engine.

However, that still does not give the capability of a new merged protocol (e.g. tell a Winboard engine where the Nalimov tables or bitbase files live, e.g. tell a UCI engine what moves to make with a SAN stream)

To tell a WinBoard engine where the tablebase files are would not require an undertaking as big as the unification of the protocols. It would suffice to extend WB protocol with a simple command to do this, and we already discussed the syntax for such a command, which IMO would do the job quite well:

http://www.open-aurec.com/wbforum/viewt ... =&start=16

I am ready to make a new WB release any day now, and perhaps I should put this in already.

[edit] Oh, I see the code was already put in by me before. So the alpha.tst on my website probably already implements it. But it uses egtbpath for the command to send to the engine, while I think we came to the conclusion that egtpath (without the b) would actually be a better word to cover both egtb and egbb. So I will change this before the release.

H.G.Muller wrote:To tell a WinBoard engine where the tablebase files are would not require an undertaking as big as the unification of the protocols. It would suffice to extend WB protocol with a simple command to do this, and we already discussed the syntax for such a command, which IMO would do the job quite well:

http://www.open-aurec.com/wbforum/viewt ... =&start=16

I am ready to make a new WB release any day now, and perhaps I should put this in already.

[edit] Oh, I see the code was already put in by me before. So the alpha.tst on my website probably already implements it. But it uses egtbpath for the command to send to the engine, while I think we came to the conclusion that egtpath (without the b) would actually be a better word to cover both egtb and egbb. So I will change this before the release.

But the types of the files differ. I suggest that a different keyword be used for every different type of endgame database path, and that we standardize them.

NalimovEGPath
ShaulBBPath
something like that.
Whatever it is, as long as it is formalized in a document then we can program to it.

But that still does not help a UCI engine to perform learning or avoid clearing its hash table.

If you would have read the post I linked to, you would have seen that the format name would go as an argument to the egtpath command:

egtpath nalimov D:\nalimov
egtpath scorpio D:\bitbases

Adding new formats will not require any changes in WinBoard, they an be set by the user through command-line options. The format names and what follows them is formally not part of WinBoard protocol, and can be freely defined by the inventor of the format.

The other options you are talking about are likely non-standard UCI options. (I say likely, as my knowledge on UCI protocol is close to zero.) These options are indeed a problem, but I am not sure this problem could be ameliorated in any way by uniting the protocols. The point is that you still would have to provide values for those options. If these are written in a polyglot.ini file, they are set for once and for all. If you would want WinBoard to set those options, you would have to supply the values each and every time you invoke WinBoard with that engine. Either interactively through the menus, or on the WinBoard command line as options. That does not seem like an improvement at all, especially not for lazy people!

In some other threads we already discussed how we could extend WinBoard protocol to allow engine-specific options similar to UCI. That is easy enough. The problem is how to use such protocol to any advantage.

One could doubt the need to specify too much in WinBoard protocol anyway. The protocol is mainly useful for things that both GUI and engine (or both engines) have to be aware of (to enforce consistency), and things that have to be changed interactively (during a game). For static settings, engine.ini files (or polyglot.ini files) or engine command-line options are just as convenient. Of course it would make life much easier if there was some standardization there as well.

Dann Corbit wrote:I know it sounds crazy, but why not?

Actually, I would like even better a merged protocol. Call it WbUCI (pronounced Wah-Bookie) where it recognized any feature from either protocol inline.

So an engine would announce its ability as winboard protocol 2, UCI, or WbUCI.

The WbUCI protocol would allow the wonderful ease of setup of UCI together with the simplified (and stateful) game play of Winboard. So (in my view) you would get the best of both worlds.

But lacking WbUCI protocol, just having Winboard natively support UCI engines would be very nice, so that we do not have to perform a polyglot mapping for every UCI engine. Not that I'm lazy. No, actually, that is exactly the reason.

yes...i like this idea
it may very well lead to one common protocol...

i know one thing...new users have a lot of difficutly and confusion getting started...wouldn't this perhaps help?

i.e. if UCI spoke WB, and if WB spoke UCI...no more language barrier.

H.G.Muller wrote:If you would have read the post I linked to, you would have seen that the format name would go as an argument to the egtpath command:

egtpath nalimov D:\nalimov
egtpath scorpio D:\bitbases

Adding new formats will not require any changes in WinBoard, they an be set by the user through command-line options. The format names and what follows them is formally not part of WinBoard protocol, and can be freely defined by the inventor of the format.

The other options you are talking about are likely non-standard UCI options. (I say likely, as my knowledge on UCI protocol is close to zero.) These options are indeed a problem, but I am not sure this problem could be ameliorated in any way by uniting the protocols. The point is that you still would have to provide values for those options. If these are written in a polyglot.ini file, they are set for once and for all. If you would want WinBoard to set those options, you would have to supply the values each and every time you invoke WinBoard with that engine. Either interactively through the menus, or on the WinBoard command line as options. That does not seem like an improvement at all, especially not for lazy people!

In some other threads we already discussed how we could extend WinBoard protocol to allow engine-specific options similar to UCI. That is easy enough. The problem is how to use such protocol to any advantage.

One could doubt the need to specify too much in WinBoard protocol anyway. The protocol is mainly useful for things that both GUI and engine (or both engines) have to be aware of (to enforce consistency), and things that have to be changed interactively (during a game). For static settings, engine.ini files (or polyglot.ini files) or engine command-line options are just as convenient. Of course it would make life much easier if there was some standardization there as well.

I have well over 3000 chess engines. If I spend one minute editing each ini or cfg file, that will take 50 hours (assuming no mistakes). Now, imagine (if you will) setting up a tournament for 1000 engines where I want to specifiy memory, use of books, nalimov paths, etc. If you believe that it is just as easy to edit files as to make one single specification of UCI parameters, then I say you are mighty quick with ultra-edit, and a better man than I am.

What I understood from UCI is that there are general options (like EGTB path and hash-table size), which are defined in the protocol, and engine-specific options, which are defined by the engines themselves, and differ from engine to engine. It are the latter that are the problem, and require you to edit the polyglot.ini files.

If such options would be passed to WinBoard by means of some protocol (which, btw, we already discussed here), tha latter can do little else than display these options as menus to the user. So that the user would have to set them. You would have to do that interactively each time you started the engine.

The standard options are not a problem: you can set these once and for all in the winboard.ini file, and WinBoard will pass them to each engine it invokes (if the engine is programmed to understand this command).

I guess what is needed to solve your problem is a smarter Polyglot. Because of the engine-specific options it is unavoidable that there is a database somewhere which stores all the specific engine settings. There are no shortcuts there, and the database might as well be the collection of polyglot.ini files. But Polyglot should be pepared to overrule the settings in the Polyglot.ini file for the general options if it receives a WinBoard command that would specify a value for that option different from what was in the Poltglot.ini.

Or perhaps this is not what we want, and the polyglot.ini value should overrule what WinBoard specifies, e.g. to deal with engines that would crash with the standard settings. Engines that are able to handle any value that WinBoard would sent them should then not have a value for this parameter specified in their polyglot.ini. This is the most logical solution, but unfortunately it requires a large one-time investment, as you would have to edit almost all polyglot.ini files to remove the parameter (which, presumably, is specified there now).

A compromise might be to control this with an argument of Polyglot: by default Polyglot would overrule the polyglot.ini values for parameters for which WinBoard sends a value. But by invoking Polyglot with an argument -useIniValues it would invert the dominance. This then only requires the UCI engines that do need special coaching to be re-installed in the engine manager with this Polyglot argument.

What do you think of that?

In Uci these values are controlled from the Gui:
NalimovPath
NalimovCache
Hash
UCI_AnalyseMode
UCI_Opponent
UCI_Chess960


To set these polyglot could use the appropiate values that winboard sends to the engine.
Another solution could be if polyglot reads this set from a special ini file
(e.g. global.ini) and let these supersede the settings in all engine ini files.

But I think what Dann wants is that one could set these values in the winboard gui and that winboard engines would use these automatic!?
(Probably together with a unified aproach for setting engine parameters)
Best
Fonzy

You already can set the first three from the WinBoard GUI, since Winboard_x (in the "Options->UCI ..." menu). Only curently this info is passed to UCI engines only if WinBoard makes the polyglot.ini (i.e. if the engine is run under its own name, with the -fUCI or -sUCI option).

Variant is sent standard to the engine, as is opponent name, even in WB protocol v1.

The user-set values for all these parameters (except pehaps the analysis option, for which I don't know what that is) are also sent to all WinBoard engines, provided they let WinBoard know that they can understand these commands (through the feature command). That there might be only few WB engines that can understand these commands is not something that can be solved in the GUI.

So it seems that most of what you think Dan wants is in fact already realized. The only problem is that UCI engines that are not run under their own name, but by explicitly invoking Polyglot (so they can use tailored engine-specific options in a user-supplied polyglot.ini file, rather than a WinBoard created generl one) do not get the hash and egtb parameters transmitted. This because the current Polyglot does not use or understand the WB protocol commands for transmitting these values.

So I think the only thing that has to be fixed is that Polyglot transmits the egtPath nalimov <path> and memory <size> commands, the latter after subtracting the EGTB cache size (from the polyglot.ini file) + 1MB from the parameter before transmitting it as hash size.