UCI error codes?

[Ras]

I'm adding UCI support to my engine. Since the engine itself cannot deal e.g. with more promoted pieces than legally possible, I added these kind of checks for FEN parsing.

Now what if the GUI tries to transmit a position with 10 queens of the same colour? With Winboard, I'd send some error for either the edit or the setboard command, but how to proceed with UCI?

And what if the move list contains illegal moves? Yeah, that's a GUI problem, but crashing is not an option, so what's the most useful kind of reaction?

Right now, I maintain an "illegal position" flag, and if the engine is requested to do anything, it will react with "bestmove 0000".

Btw., I can see why a stateless protocol is nice especially for games over unreliable networks where CECP would struggle to get GUI and engine in line again after disconnect/reconnect. But it's interesting to hack around a stateless protocol e.g. for still using PV hits to improve move sorting. Looks like it works.

[hgm]

The only way to output text (like error messages) in UCI is through "info string" commands. It seems logical to have those start with "info string error".

I guess the philosophy of UCI is that the GUI should be on guard for the engine, and refuse any attempt to do something that would violate FIDE rules. The engine then has an obligation to handle everything that FIDE rules would allow. So you will never get positions with 10 Queens, but if you cannot handle 10 Knights the engine is not fully UCI compliant.

[Ras]

The only way to output text (like error messages) in UCI is through "info string" commands. It seems logical to have those start with "info string error".

Thanks, that makes sense.

I guess the philosophy of UCI is that the GUI should be on guard for the engine

I expect GUIs not to work as they should, and while an engine may refuse to work, I'd still consider crashing as an engine bug.

and refuse any attempt to do something that would violate FIDE rules.

In http://www.talkchess.com/forum/viewtopi ... 36&t=64634 , you mentioned that a GUI validating positions for legality even was a defect?

but if you cannot handle 10 Knights the engine is not fully UCI compliant.

10 knights is fine as long as there are no pawns and no other promoted pieces of the same colour.

[hgm]

I expect GUIs not to work as they should, and while an engine may refuse to work, I'd still consider crashing as an engine bug.

Crashing may be, but controlled exit after a message would be acceptable, IMO.

In http://www.talkchess.com/forum/viewtopi ... 36&t=64634 , you mentioned that a GUI validating positions for legality even was a defect?

Well, according to me UCI is one big defect. Not allowing the engine to make game-playing decisions on offering or accepting draws is the best-known example of that. Not defining proper error handling is another. And not defining a way to communicate whether 'searchmoves' is supported or not. It just utterly sucks.

A properly designed GUI, however, would support a way to switch pedantic checking against FIDE rules of, and delegate the responsibility to not 'overload' the engine to an expert user, who knows what he is doing.

[Ras]

Crashing may be, but controlled exit after a message would be acceptable, IMO.

That would be the next best alternative. Still, I prefer having the engine in a mode where it won't calculate, but is open for receiving a different position.

Well, according to me UCI is one big defect.

I like the basic idea of statelessness when it comes to network connections. Not having shared state is the most reliable way to reach synchronisation.

The hack I needed to make in order to still take advantage of PV hits when the opponent answers (in case the next position and move list actually belongs to the same game) is only a few lines of code, so the criticism that chess is a stateful game doesn't wash.

However, the other idea of UCI to put the GUI in control is indeed just bad. I also dislike the GUI having the opening book - hopefully GUIs will listen to my OwnBook setting.

Not defining proper error handling is another.

Agree - I really wonder what other protocol designer would forget error handling. What's also nonsense is allowing an arbitrary number of spaces and even tabs as whitespace. Not that it's difficult to sanitise the input, but it shouldn't be necessary. The isready command is lacking the number that ping has, so there is no way to tell what isready the readyok actually belongs to.

And not defining a way to communicate whether 'searchmoves' is supported or not.

I've often seen something similar as industrial standard practice: if you sell a product and establish a standard, then try to bake as many of your existing product features fixed into the standard as you can get away with. Also (and even especially) the useless ones because that will slow down competitors to be fully standard compliant.

It just utterly sucks.

I guess it has taken over because the one advantage of avoiding state outweighs the sloppy parts, given that online connectivity is common these days.

A properly designed GUI, however, would support a way to switch pedantic checking against FIDE rules of, and delegate the responsibility to not 'overload' the engine to an expert user, who knows what he is doing.

An even more robust approach would be a protocol that allows the engine to tell the GUI whether relaxed checking is OK. Possibly with different flags like overpromotion, mutual checks and super-long castling. Disabled by default.

[hgm]

I guess it has taken over because the one advantage of avoiding state outweighs the sloppy parts, given that online connectivity is common these days.

I am pretty sure that online connectivity has nothing to do with it. It is not trivial to run engines on another machine as the GUI, and only very few people have ever managed to do it.

Besides, UCI is not robust against random disconnection at all. When a disconnect would go unnoticed after sending 'go', the GUI would wait forever for the matching 'bestmove'. The obligation for instant response to isready even while thinking does make it possible for the GUI to check if the connection is alive, though. But I don't think any existing GUI does that. It also seems to be a task that belongs to a lower layer of the connection protocol. The GUI should be warned automatically when a disconnect occurs, so that it can take the appropriate action. The required action (restarting of the latest search) can be taken in any protocol.

An even more robust approach would be a protocol that allows the engine to tell the GUI whether relaxed checking is OK. Possibly with different flags like overpromotion, mutual checks and super-long castling. Disabled by default.

For the purpose of supporting variant engines that would be a very good thing. But of course standard UCI doesn't address variants at all. For the purpose of running the Stockfish variant engine in variants like Horde and King of the Hill we made an extension to UCI, where setting an UCI_Variant option would cause the engine to send an "info string variant ..." response with details about the variant (in this case just the initial setup), in analogy with the "setup" command in WB protocol.

WB protocol already allows the engine to redefine the pseudo-legal moves for all pieces, so that legality checking in the GUI would not have to be switched off when it is used for a variant that contains fairy-pieces (e.g. where the Knight moves as Nightrider instead), but all GUI functionality associated with legality checking (e.g. move-target highlighting, proper SAN disambiguation) can remain fully operational. Non-standard castlings can already be defined this way too, as special moves of the King. Ignoring check could be done by nut using the standard King piece in the initial setup, but a piece type that the GUI does not consider royal instead. Having other rule modifications transmitted this way too, as you suggest, would be a good next step. (What is 'overpromotion', btw?) In WB protocol this is currently taken care of by inheriting such rules from a 'parent variant', where one of the many different standard variants can be chosen.

[Ras]

I am pretty sure that online connectivity has nothing to do with it. It is not trivial to run engines on another machine as the GUI, and only very few people have ever managed to do it.

It's trivial today - just start the appropriate app. You can e.g. play Shredder over the internet, which has the great advantage that the computations don't drain the battery of the smartphone.

Besides, UCI is not robust against random disconnection at all.

That's correct, but syncing up after the reconnect is easy because there is no special syncing at all, just the normal procedure.

But I don't think any existing GUI does that.

No, but that's because most programs have regular output with the nodes, NPS and hash table usage. I'm doing that once per second, on top of the info when a new depth has been reached.

The required action (restarting of the latest search) can be taken in any protocol.

True, you can use new/force with Winboard also. However, since Winboard doesn't require the engine to answer anything while computing, there is no way to check whether the engine is still alive during computations.

An optional feature "immediate ping" would help here, a ping that has to be answered immediately and possibly out of order with other commands. Optional because that would not work with engines that don't use any threading. Something like "feature iping=1".

Would you want to amend the protocol with that idea?

Plus of course that syncing is even necessary and therefore requires special action.

Non-standard castlings can already be defined this way too, as special moves of the King.

So, assuming that any engine would support this, you could actually do the super-long castling to a freshly promoted rook? Illegal as per FIDE rules these days, but Tim Krabbé's famous puzzle was really fun.

(What is 'overpromotion', btw?)

Having more promoted pieces than the amount of absent pawns would allow for.

[hgm]

An optional feature "immediate ping" would help here, a ping that has to be answered immediately and possibly out of order with other commands. Optional because that would not work with engines that don't use any threading. Something like "feature iping=1".

Would you want to amend the protocol with that idea?

I think that a low-level task like testing the connection is just not an engine task. The connection adapter does this. You would always need connection adapters on both ends, as GUIs and engines communicate through pipes, not through sockets. And connection adapters should scream to the GUI when they get disconnected, and cannot reconnect. In that case there isn't much chance that the GUI will be able to reconnect by restarting the adapter. So why try?

Plus of course that syncing is even necessary and therefore requires special action.

So, assuming that any engine would support this, you could actually do the super-long castling to a freshly promoted rook? Illegal as per FIDE rules these days, but Tim Krabbé's famous puzzle was really fun.

I suppose so, although I have never tried. The code for castling is On, with n the number of squares the King moves. This can be prefixed with the usual directional modifiers, usually 's' for sideways. (So regular castling is indicated by isO2, where the 'i' indicates it is an 'initial move', for virgin pieces only.) So you could write ifO6 for a forward castling.

Having more promoted pieces than the amount of absent pawns would allow for.

OK, I see. I suppose this is implied by the initial position, by counting the Pawns.

[Ras]

I think that a low-level task like testing the connection is just not an engine task.

When you think of TCP, level, I agree - but you can also test whether the engine itself is still responding. Maybe I'm thinking in terms of watchdogs here.

So you could write ifO6 for a forward castling.

Now that's cool! Does any engine actually understand this?

OK, I see. I suppose this is implied by the initial position, by counting the Pawns.

Yes, and for the NG-Play engine, and thus also mine, this is deeply baked into the underlying data and code structure.

[hgm]

So you could write ifO6 for a forward castling.

Now that's cool! Does any engine actually understand this?

In WB protocol it is the engine that sends this to the GUI, so it is the GUI that has to understand it. For the engine it just has to be in its move generator.

If the engine is configurable for various variants, there is the theoretical possibility that it would take the rule description of the variant in this form (e.g. from an ini file). But there currently is no engine I am aware of that does this. Sjaak II does the reverse; it has its own game-description format, and it calculates what it has to send to the GUI ('Betza notation') from this. In Fairy-Max the Beza notation has to be given as text next to its native rule description, and then is used only for sending to the GUI. It is on my to-do list to derive the move-generator tables from the Betza description there. But it would not support 'vertical castling'; Fairy-Max can only castle with a corner piece. (Dont know about Sjaak II.)