Could someone out there fork Crafty and produce a UCI version?
I realise Crafty's author, Bob Hyatt, doesn't like UCI as it cedes too much control to the GUI.
Very well then, let someone else do it while keeping to all the legal proprieties including publishing the changed code, etc.
I think this is a great idea and it's such a shame some people have landed on your thread just to bash your idea.
UCI has huge GUI advantages and to get Crafty into this format would be brilliant.
Can you specify these "huge GUI advantages"?
I'll try to help the TS.
There are two points.
The first point is that if Crafty supported UCI, that would make it slightly easier to use Crafty with GUIs that only support UCI. There are always other ways to make it work, but they are slightly more cumbersome.
The second point is that if Crafty supported UCI options (or xboard/winboard options, for that matter), that would also make it easier for many people to configure Crafty. (Apparently Crafty relies on configuration files whereas more recent versions of the xboard/winboard protocol offer a "standard" way of configuration through the GUI.)
These points are really two separate points, even if they might be one and the same point in the view of the TS. But they are not unreasonable points and they do not mean that either protocol is superior to the other or anything like that.
There is no longer (version 25.0) much to configure in terms of the usual suspects. You can still alter piece values, but those are optimized already. I am finishing up the autotune code to optimize SMP parameters automatically.
I think it is easier for someone to get an xboard protocol program up and running, it doesn't have all the twists and quirks of UCI. Crafty works just fine as a console application, and works the same way under xboard. A UCI program is not exactly convenient to use as a standalone application because of the protocol. I like simple, and I also like what already works. If the world wants to go UCI that's fine by me. Personally I still also use C rather than C++, it works well too.
bob wrote:I think it is easier for someone to get an xboard protocol program up and running, it doesn't have all the twists and quirks of UCI. Crafty works just fine as a console application, and works the same way under xboard.
Sure, but most people happen to use a GUI that uses the UCI protocol.
A UCI program is not exactly convenient to use as a standalone application because of the protocol. I like simple, and I also like what already works. If the world wants to go UCI that's fine by me. Personally I still also use C rather than C++, it works well too.
The xboard and UCI protocols do not exclude each other. The engine only needs to switch to UCI upon receiving the string "uci".
Adding the xboard protocol to a UCI engine might be tricky, but adding UCI to an xboard engine should be pretty straightforward. Of course nobody can force you to do it, and nobody can force you to give permission to anybody else to do it.
Marek Soszynski wrote:
Bob can speak for, and defend, himself.
Yes, and if you ask a question on a general forum, anyone can answer. If you wanted an answer specifically from Bob Hyatt, you should have contacted him directly.
In this case you were sort of asking Marek why Bob is of the view that UCI takes too much control. It makes sense for Marek to leave that question to Bob instead of trying to answer it himself. (And I think Bob has answered it many times already on this forum.)
Ah, I guess it could be interpreted that way. What I was responding to specifically was "doesn't like UCI as it cedes too much control to the GUI" for which the wording suggests that it's meant to be an objective statement (or at least not the opinion of Bob or the OP). I maintain that this isn't an objective truth.
bob wrote:
There is no longer (version 25.0) much to configure in terms of the usual suspects. You can still alter piece values, but those are optimized already. I am finishing up the autotune code to optimize SMP parameters automatically.
Does Crafty implement the "cores" and "memory" commands? Other options people might look for are whether tablebases are enabled or not, or the location of the opening book.
jdart wrote:I support both, but adding UCI was not exactly trivial, and there were quite a few bugs I fixed.
What kind of bugs can I expect? I'm planning to stop maintaining my xboard protocol mode and switch over to UCI, because with the first, there is always seems to be something that is not working right from the user point of view unless you implement it in the engine as well. (And secondly, because the GUIs I want to use don't understand xboard protocol). I don't see technical issues (yet), such as keep using my own book, or pondering on the moves I decide. That all seems possible.
bob wrote:
There is no longer (version 25.0) much to configure in terms of the usual suspects. You can still alter piece values, but those are optimized already. I am finishing up the autotune code to optimize SMP parameters automatically.
Does Crafty implement the "cores" and "memory" commands? Other options people might look for are whether tablebases are enabled or not, or the location of the opening book.
