UCCI2WB

[hgm]

Well, adapters are GUIs to the engine, and engines to the GUI.

Your work on XBoard is much appreciated. The icsEngineAnalyze is still in there. And I have indeed seen the draft for the v3 version of the protocol, and used some of the ideas in it. (Some urgent problems were not addressed, however, while there didn't seem to be much demand for some other ideas, so I did not implement it all, and saw also no need to step up the version number, as the current protocol is still fully compliant with the original v2 specs.)

I am just objecting to the notion that an opinion would not be an objective one just because it is widely known, or that I would have any reason not to be objective. And that UCI has deficiencies is not a matter of opinion, but a widely known fact (no draw offers, resigning, standardized error messages, versioning).

[Daniel Mehrmann]

I am just objecting to the notion that an opinion would not be an objective one just because it is widely known, or that I would have any reason not to be objective. And that UCI has deficiencies is not a matter of opinion, but a widely known fact (no draw offers, resigning, standardized error messages, versioning).

Now we have a nice loop...

As i wrote some posts ago, you don't understand UCI at all and why it is designed as it is. I wan't response on your list, because your things are wrong and now it starts to go boring.
Basicly i like to tell you that UCI is a strict master/slave modell. Maybe you should think about that.

[JoshPettus]

(Some urgent problems were not addressed, however, while there didn't seem to be much demand for some other ideas, so I did not implement it all, and saw also no need to step up the version number, as the current protocol is still fully compliant with the original v2 specs.)

Well adding another version would be equivalent of creating yet another protocol, which should be a sin on all that is holey and sacred. Granted it's creating a protocol with a heavy implication for others to switch to it, but id imagine not everyone is going to, and would be a huge pain for other GUIs that support that protocol. I think most of us would be glad v3 didn't come out.

[hgm]

As i wrote some posts ago, you don't understand UCI at all and why it is designed as it is. I wan't response on your list, because your things are wrong and now it starts to go boring.
Basicly i like to tell you that UCI is a strict master/slave modell. Maybe you should think about that.

UCI does not allow engines to offer or accept a draw. Right or wrong?
FIDE rules do specify you can offer a draw with any move. Right or wrong?

For those that can manage to answer those simple questions, it will be obvious that UCI protocol does not support Chess according to FIDE rules.

No amount of babble about masters or slaves or other irrelevancies will change that. UCI just doesn't allow you to communicate the full Chess move to the engine, or the engine to communicate it back to you. They might as well have left out promotion suffixes, and make the GUI 'master' of what you get on promotion. Or castlings. Or Pawn moves. Or better yet, only allowing null moves. (Nicely simplifies the engine...) Then it would still be a strict master/slave model. And utterly useless...

What you say makes no sense.

[Evert]

Hmmm, i have no glue why you think that i'm handle this topic emotional ?

Well,

Shocked Shocked Are you kidding ?

The UCI protocol (syntax) should be leave untouched in such cases. Instead of using same keywords and/or extend them, you should follow the offical way to add extensions to the UCI protocol.

i'm missing the real understanding about UCI, how it works and why is it desigend as it is.

I don't want to waste my time here, but here are some few words:

The main problem is your personal perspective and thoughts about UCI.

your reactions here are fairly strong (or at least worded that way) and you do not go beyond "your approach is wrong and you should do such and so" without explaining why you think that is the case. So either you have a reason and choose not to share it for whatever reason, or your argument is just based on emotion. If it's not the latter, great - but then it would be nice if you could actually contribute something to the discussion.

]For myself the facts are clear

Ok. What "facts" are those then?
See, for me, the facts are these:

• There are a number of UCI-like dialects (namely, UCI, USI and UCCI) which are at least somewhat accepted standards. The differences between these are mostly minor, but subtle and important. Then there are the common incompatibilities that one runs into.
• Having all this documented in one place is useful for someone who wants to implement an engine or interface that handles all of this.
• UCI was never designed to handle chess variants, and has no way to communicate that a particular engine (or GUI) supports any particular variant
• People use it for that purpose anyway

Now, based on those facts, my opinion is that

• We do not need further proliferation of slightly incompatible UCI dialects
• If people do want to extend UCI in some way, it would be far preferable if they used constructs already established in USI/UCCI than if they did something entirely different again
• If there are several UCI engines that can play a particular variant, it would be extremely sad if you can't use both in a GUI that could support both, if only it would understand that it can (due to a lack of any sort of standard)

So again, what facts are you talking about?

and, just for example, hgm isn't the right men for such things, because it's impossible for him to see some things objective. No protocol is perfect of course and i never wrote UCI is a numinous thing.

Well, I'm not in a discussion with HGM, I didn't (specifically) ask for his opinion on any of these things, and I don't always agree with what he says (but I always find it worth listening to). I fail to see how any of that is relevant though?

However, look at hgm last posts. Well, they are no direct personal attacks, but his kind of posts include a foolishness and/or (hidden) malicious act.

I don't see any indirect personal attack, foolishness or malicious intent (hidden or open). If you do see those things, then I think you're taking things far to seriously.
That's my opinion, clearly.

[Evert]

As i wrote some posts ago, you don't understand UCI at all and why it is designed as it is.

Well, you're probably referencing some discussion I'm not aware of, but I fail to see what's not to understand about UCI. It's a specification for information exchange between a chess engine and a GUI.

What is clear (whether you agree or not) is that people think that UCI lacks things and add them in, which is basically how we end up with UCCI and USI (in the case of USI, the main difference is actually in the way squares are named).

Basicly i like to tell you that UCI is a strict master/slave modell. Maybe you should think about that.

And who, according to you, is the master and who is the slave in that model?

[PK]

my (most recent) engine uses UCI. still I think that even in a master/slave model a question like "puny slave, wilt thou graciously accept my magnanimous draw offer" would not be out of place.

[hgm]

If it can decide what to promote to, or what to move, without violating the master/slave model, it should also not be a problem to offer a draw. Draw offers are as much part of a move as the from- and to-square.

[Evert]

my (most recent) engine uses UCI. still I think that even in a master/slave model a question like "puny slave, wilt thou graciously accept my magnanimous draw offer" would not be out of place.

Well, all my engines speak CECP, but none of them offer or accept draws. It's on my list of things to do, once I work out how I want to do it. I'd prefer something more intelligent than "score stayed drawish for N moves"…

Also, in my interpretation of the master/slave relationship, the GUI is the slave, which relays the input from the user to its master and displays whatever information the engine decides it should display.

[Evert]

If there is only one legal move, the GUI could just make it and not bother the engine. In fact, it wouldn't even have to start the clock.