Banksia GUI released

[phhnguyen]

Please please no a new holy war CECP vs UCI here.

The question is whether Banksia should go for a good user experience and encapsulate the CECP oddities, or let them spill out to the user. HGM favours shifting over everything to the user which I consider bad UI design while I think the GUI should deal with it as well as possible.

What's your take?

Sorry, it is hard to answer clearly. Frankly speaking, I didn't think much and I didn't support fully CECP - only version 2 and just (hopefully) enough for running. It is somewhat as your words "just about damage control" but to fix what I have: whenever there are requests or bug reports I will work on them to support/fix.

[swissman]

Thank you very much. The GUI works fine. One only question: Is there no mode where the chess program analyses the current board position without making a move. This option is the one I use most of the time when using a chess GUI and studying games.

[phhnguyen]

Thank you very much. The GUI works fine. One only question: Is there no mode where the chess program analyses the current board position without making a move. This option is the one I use most of the time when using a chess GUI and studying games.

- Let engine play for one side (menu -> File -> Game setup) and then set time control to Infinite
- Click on button Play (on the control toolbar) to un-pause

The selected engine will start computing but won't make any move.

The limit is that it computes for the last position only but it can update to the new position when users play move (manually).

I will add later a new feature for analyzing any position.

[hgm]

This is not intended to be a CECP vs UCI war, but a discussion of whether Banksia, supporting both, should implement extensive work-arounds to hide engine defects. And it is not my fault that the alleged need for this is argued more on prejudice then on fact.

It is of course your decision to make, but I would consider it sad if you were convinced by false arguments to implement a 'solution' to a non-existing problem, which would then help causing that very problem in future engines, by masking the fault that would cause it for engine developers. And I don't think it is the GUI's task to test an engine for every conceivable defect. If you change the hash setting, does it really change the size of its memory use? Does it not use more threads than you specified in the Threads option? Would it react to 'stop' while thinking? Or to 'isready'? Does it support 'searchmoves'? Doesn't it spontaneously terminate a ponder search when it sees a mate? Does it really report the score in centi-Pawn, and is the sign correct? Aren't the mating distances off?

All that could be tested in advance, and for many problems work-arounds could be devised. Don't do it!

If you really want to have set of engines that make a mess of their protocol, try the UCCI engines.

[Ras]

a 'solution' to a non-existing problem

The problem is that "?" and analysis support is optional with CECP. The result is that each engine behaves differently and is allowed to do so. This violates a basic UI design principle - consistency. I suggest you'd read up on UI design e.g. at the Nielsen Norman Group with regard to fundamental concepts like consistency, discoverability and affordability.

In UCI, the support for "stop" is about 100%. What is messy in practice is the lack of "searchmoves" support although that's mandatory. That's actual engine defects and should be fixed. Although a feature test would also be a good idea in practice, like my test positions and only including moves that don't lead to the mate in 2.

[hgm]

Well, I also would not recommend a GUI to try to find out in advance whether searchmoves works in UCI engines. And certainly not to implement an automatic work-around if it doesn't. If the user excludes a move, and it turns out the engine searches it any way (which is very easy to see from the "info move" commands UCI engines like to bombard the GUI with), you can just show the a message: "move exclusion seems to be defective in this engine".

Like with the CECP "?" command you can just display the message "this engine refuses to be hurried" in response to the user operating "move now", when there is no response within, say, 100msec. In any case, leave no misunderstanding that it is a problem of the engine.

That is not any less 'consistent' than sometimes greying out a menu item, and sometimes not. (And what would you do for consistency if the user used the acceleratior key for the command? How would you make that 'consistent'?) You will never be able to hide the fact that some engines can do things others cannot, unless you are prepared to make it impossible for any engine to do the thing.

[swissman]

Thank you very much. The GUI works fine. One only question: Is there no mode where the chess program analyses the current board position without making a move. This option is the one I use most of the time when using a chess GUI and studying games.

- Let engine play for one side (menu -> File -> Game setup) and then set time control to Infinite
- Click on button Play (on the control toolbar) to un-pause

The selected engine will start computing but won't make any move.

The limit is that it computes for the last position only but it can update to the new position when users play move (manually).

I will add later a new feature for analyzing any position.

Many thanks for these explanations. In this way it works perfectly.
Kind regards
swissman

[Ras]

Well, I also would not recommend a GUI to try to find out in advance whether searchmoves works in UCI engines. And certainly not to implement an automatic work-around if it doesn't.

There is no workaround for defective "searchmoves" because what moves are legal is determined by the position itself. The GUI cannot compensate for that. The next best thing is to announce it beforehand instead of letting the user run into "oh doesn't work". Maybe MultiPV could be abused, but that's optional, and "searchmoves" is useful mostly as "poor man's multipv" replacement.

By contrast, the GUI can easily kill and reload engines that don't read "?" during search. This way, even analysis becomes possible by just giving a move time of several days. This in turn is useful for questions like "does the engine find this move at all, and if so, when?". Together with automatic score sign and mate score detection, these three issues so common with CECP engines can be abstracted away from the user, which would give a smooth user experience. Sure, layer 7 isn't the ideal place to do that from an architectural point of view, but still better than "layer 8".

Of course, the question is whether this nicety is actually worth the implementation effort in the GUI, but that's up to its author.

[hgm]

Well, as I explained before, that is the worst you could do. Killing the engine won't make it move. It only makes sure you will never know what it intended move. What move would you play for it, after you kill it, and in what position would you start the new instance? It seems you completely misunderstand the purpose of the "?" command; this is not for aborting a search. For that CECP has the 'force' command.

In general, people would use 'move now' only during games. If they want to do analysis they would use analyze mode, which should always respond to commands immediately. And in case you want to provide a work-around for engines that do not support analyze mode by giving them near-infinite thinking time and killing them when the user want to move to another position: this is also worse than useless. People that do interactive analysis expect the result of the position they just left to stay in the hash table, so that they can propagate the score backwards, and killing loses you the hash table. You would only have made them waste massive time on obtaining a result that would not propagate, without warning.

[jorose]

I used the recent Winter v0.8 release as an opportunity to test a couple GUIs, including Banksia. I am for the most part quite happy and feel this will likely be one of my main chess applications (together with Cutechess, XBoard and Scid) moving forward. That being said, two points:

When I ran a tournament and set base hash and threads to respective values, some of the engines seemed to ignore these values so I ended up restarting the tournament with the settings for all the engines individually fixed to the correct values. Is there something I did incorrectly, or was that just a bug?

The other point is I was wondering where I can access or save the PGN(s) of the games from the tournament? I can replay the games in a small window in the application, but I can't figure out how to save those games to PGN. The application seems well thought out and intuitive mostly, so I imagine I am misunderstanding something obvious.