Engines that support the new WB3 protocol ?

[Michael Diosi]

Hello,


I am interested what engines support the new protocol,
especially : cores, memory and options.

You might guess why...

Michael
http://www.playwitharena.com

[hgm]

I just answered your PM about this. In short, good test cases would be:

Fairy-Max (memory and all option types)
Gaviota (egtpath, cores and many others)
All UCI engines running under Polyglot 1.4.56b (wich translates all UCI options to WB protocol)

[Michael Diosi]

Hi Harm ,


Thanks.



Michael
http://www.playwitharena.com

[F. Bluemers]

Hello,


I am interested what engines support the new protocol,
especially : cores, memory and options.

You might guess why...

Michael
http://www.playwitharena.com

Dirty uses options
Best
Fonzy

[Sven]

Hello,


I am interested what engines support the new protocol,
especially : cores, memory and options.

You might guess why...

Michael
http://www.playwitharena.com

I wonder why you mention "WB3" in the subject of your post. AFAIK there is no such "WB3" protocol, it is still version 2, although new commands and features were added by HGM and some clarifications were done in the spec.

Sven

[Michael Diosi]

Hi,


Well as far as I understood this is meant to be WB3 ?


Also Vas was going to release a description of the new added options to UCI => UCI 3 (?) like Monte Carlo stuff so we could use it in Arena too. Unfortunately this was never released.

Michael
http://www.playwitharena.com

[Michael Diosi]

Hi,


Thanks.

Michael
http://www.playwitharena.com

[michiguel]

I just answered your PM about this. In short, good test cases would be:

Fairy-Max (memory and all option types)
Gaviota (egtpath, cores and many others)
All UCI engines running under Polyglot 1.4.56b (wich translates all UCI options to WB protocol)

I think that the only command that Gaviota does not support (yet) is multipv. It uses all the flavors of "feature option", egtpath, cores, memory, the nps features etc.

The current development version also supports pause/resume, which is a very valuable tool (ever been playing against an engine and receive a phone call?) but it is not supported by any GUI that I know of, even winboard (only command no supported). Let me know whether you want to test pause/resume and I can release what I have.

Miguel

[hgm]

Well as far as I understood this is meant to be WB3 ?

Perhaps this deserves some clarification:

I consider WB protocol v2 the protocol that negociates capabilities through feature commands, and v1 the protocol that does not send any features in response to the protover 2 command (for engines) or does not send a protover command altogether (for GUIs). As v2 already specifies that a GUI should be able to withstand any feature it does not know (by replying with XXX rejected), I consider it undesirable to create an extra barrier for engines to send such feature commands. Protocol v2 gives no guarantee that all of the features it specifies are implemented by the GUI; a GUI can always reserve the right to leave some features unimplemented, and reject them.

The most profitable situation is if there is just one big pool of features, and that GUI and engine authors pick those that they want to implement. An artificial division in v2 and v3 features would only discourage people implementing those v3 features they do like, because it would suggest it was pointless to implement some if they did not implement all.

So engines should always send all features they can exploit to the GUI. The fact that the GUI sends protover 2 should not discourage them sending feature memory=1. They might be lucky, as it could be a GUI that elected to implement only the memory feature next to the old v2 features, and did not dare to call itself a v3 GUI. Most options modulate GUI->engine traffic (like memory), and the engine does not even have to pay attention if the GUI accepted the feature or not. It will simply not get any memory commands when the GUI didn't, and continue using its default memory allocation. Which is exactly what it would have to do anyway if it had known in advance that the GUI does not support the memory feature.

Even the original v2 specs recommended ignoring the version number, and always send all features. Much better to allow implementation of features on an individual basis than to force package deals of the kind: "if you want this (which you do want), you must also provide that (which you might not like), just because it was introduced earlier and belongs in a lower version". If engines are interested to know the exact GUI capabilities, they should listen to the accepted / rejected answers to their feature, not make assumptions based on a version number. And if it is not desirable that engines make assumptions based on a version number, the best thing is to always send the same number. Then they cannot do it!

[Sven]

So the point is, even if you write about "old v2" and "new v2", that there is no v3 of the WinBoard protocol at the moment, that the WinBoard/xboard GUI also does not send "protover 3", and that the main focus for everyone shall be on features not on version numbers.

I think it is best that we take it as it is to avoid irritation, even though there may be some people who would have expected a version number change just due to the amount of modifications since "old v2". But you explained why you didn't do that, and that's fine for me.

At least the WB spec document should really get version numbers, though, in addition to the date of last change. Maybe you call the last version from Tim Mann "v2.1" and your current version "v2.2", or something similar, and make that explicit within the document itself as well as at those places where you refer to it.

Sven