Complete engine configuration

[Fulvio]

I am rewriting the SCID's window for the engine configuration and I would like to include all the useful features.
I would appreciate if you can let me know if I forgot something or if you have suggestions.
This is what I have done:

- Engine name: it is set with the name sent by the engine (uci's "id name" or xboard's "myname"). It can be changed freely.
- The usual command parameters: filename of the executable, command line args and working directory.
- The communication protocol with the engine (uci or xboard).
- Options for formatting the engine output: score perspective (white or engine), moves notation (SAN, English SAN, utf8 figurine, raw unmodified engine pv lines) and line breaks (single line, a line break may occur after any character or a line break will only be made at word boundaries).
- Debug frame: hide or show a frame with all the unmodified input/output between SCID and the engine. Useful for engine authors.
- Engine process priority: allows to give a lower priority to the engine. It is useful if you want to use all the available threads for the analysis and at the same time maintain a reactive system.
- Accept network connection: allows remote instances of SCID to connect to and use this engine. It is useful if you want to use multiple computers.
- Then there are the options sent by the engine. For each option the name, the current value and possibly the range of valid values ​​are displayed. The name of the options that have a value different from the default is displayed in bold. Clearing the value of an option restores the default value.

[Ovyron]

The only thing I see missing is an "Edit Engine File" button like in Shredder GUI. Clicking this button opens the text file where the GUI stores the information about the engine. Sometimes the fastest way to set an engine up is to copy the settings from another one from the text file (say I have Honey installed, I click Edit Engine File to open its text file, copy the settings as text, paste them to the text file on an already installed Bluefish with default settings, and save. Now Bluefish uses Honey's settings and this was done in a breeze.)

[hgm]

It seems to me that there are many settings in there that a typical user would want to be the same for every engine. E.g. how you display the engine's PV is a display matter for the GUI, and I cannot imagine that there are users that would like to see Stockfish PVs in long algebraic, and Komodo PVs in SAN. This is something that seems to belong in the View menu. You are also not going to ask what colors it should use for checkering the board squares on a per-engine basis.

Process priority could also fall in this class. In WinBoard it is just a global option applied to all engines. Perhaps it is my lack of imagination, but I see no use case for running different engines at different priorities. It would make more sense to make it dependent on the number of threads than on the engine.

Just out of curiosity: for the networking, you run SCID on both computers, and configure it as a server for running the engine on one, to which the other than connects?

For the engine options there are many standard (or de-facto standard) options there that probably also would be better controlled centrally rather than per engine. If users have Syzygy EGT installed on their machine, they won't have different copies of it for each engine. So why bother them with setting the Syzygy path? The GUI should know where to find the EGT (preferably automatically, as part of the install procedure for those EGT on the machine), and just tell it to all engines that request it. Hash size is probably also something that only depends on your hardware, and you would want to be the same for every engine.

MultiPV is an 'interactive' option that you would want to change all the time during an analysis session, depending on the position you visit. It would be extremely inconvenient if you had to open the engine settings dialog each time you want to change it. In WinBoard the setting of it can be controlled by clicking in the Engine Output window itsef (where the PVs are diaplyed), so that you never have to open any dialog. Just hit 'More' or 'Fewer' to alter its setting. Same for move exclusion; you can do this through the board display, but it is often much easier to permanently show moves that have been excluded, and allow the user to toggle their state by clicking them. (Especially if the current best move is present in that list as special entry.)

[Fulvio]

The only thing I see missing is an "Edit Engine File" button like in Shredder GUI. Clicking this button opens the text file where the GUI stores the information about the engine. Sometimes the fastest way to set an engine up is to copy the settings from another one from the text file (say I have Honey installed, I click Edit Engine File to open its text file, copy the settings as text, paste them to the text file on an already installed Bluefish with default settings, and save. Now Bluefish uses Honey's settings and this was done in a breeze.)

Thanks, it's an interesting suggestion. What happens in the Shredder GUI if you enter incorrect data in the configuration file?
My idea was to use the "clone" button for the type of operation you described. Pressing it creates a copy of the current configuration. At that point the user can change the name and the path of the executable. Changing the executable restarts the engine and sends the old options: the unsupported ones are discarded, the others kept.

[Ovyron]

Thanks, it's an interesting suggestion. What happens in the Shredder GUI if you enter incorrect data in the configuration file?

The files follow a structure like this:

[ENGINE]
Name=Polyfish
Author=T. Romstad, M. Costalba, J. Kiiski, G.
Filename=C:\Chess\Stockfish\P\Stockfish_Polyglot_2019-12-20_x64.exe
[OPTIONS]
MultiPV=1
Threads=4
SyzygyPath=Y:\tb

If the file doesn't follow this structure the GUI would just ignore it as if the file was deleted (this is for advanced users that know what they're doing when editing the file.)

If the user adds something like:

[OPTIONS]
Gibberish=YaddaYaddaYadda

The GUI would think this is valid and send it to the engine and let it handle the invalid data.

My idea was to use the "clone" button for the type of operation you described. Pressing it creates a copy of the current configuration. At that point the user can change the name and the path of the executable. Changing the executable restarts the engine and sends the old options: the unsupported ones are discarded, the others kept.

I guess we're diving into unlikely scenarios , but sometimes there's many settings, say, there's 14 settings in the engine, the first 7 are used to change piece values for white and 7 for black. One wants to copy only the first 7 into a new engine, while keeping the other ones the same.

The fastest way to do this remains to open the engine file and

[OPTIONS]
White Pawn cp=2 <- Copy these
White Knight cp=8 <- Copy these
White King Bishop cp=8 <- Copy these
White Queen Bishop cp=8 <- Copy these
White Rook cp=13 <- Copy these
White Queen cp=32 <- Copy these
Black Pawn cp=3 <- Ignore these
Black Knight cp=10 <- Ignore these
Black King Bishop cp=10 <- Ignore these
Black Queen Bishop cp=10 <- Ignore these
Black Rook cp=17 <- Ignore these
Black Queen cp=40 <- Ignore these

Then paste them into the text file of another engine that already has in some other values for the black pieces we don't want to overwrite.

When playing with engine personalities one does stuff like this a lot and being able to just copying and pasting text in bulk and saving has been a life saver.

[Fulvio]

It seems to me that there are many settings in there that a typical user would want to be the same for every engine. E.g. how you display the engine's PV is a display matter for the GUI, and I cannot imagine that there are users that would like to see Stockfish PVs in long algebraic, and Komodo PVs in SAN. This is something that seems to belong in the View menu. You are also not going to ask what colors it should use for checkering the board squares on a per-engine basis.

I started with global options.
Then I changed my mind because of some old xboard engines
The "add engine" button opens the system file dialog for selecting the executable file.
After that the engine is ready to start, and I think that most users will not change the default values (white perspective, SAN translated in the current language, word line breaks, no debug frame, normal priority).
But allowing to set the option differently on an engine basis gives the maximum flexiblity imho.

Process priority could also fall in this class. In WinBoard it is just a global option applied to all engines. Perhaps it is my lack of imagination, but I see no use case for running different engines at different priorities. It would make more sense to make it dependent on the number of threads than on the engine.

Yes, that's the my most common use case. I usually have different configurations for the same engine and I set the low priority only on the one with all active threads.

Just out of curiosity: for the networking, you run SCID on both computers, and configure it as a server for running the engine on one, to which the other than connects?

SCID runs normally on both (or more than two) computers.
An engine that accepts remote connections can always be used normally locally. However, it also accepts commands (such as the position to be analyzed or options to be set) from all remote clients and also broadcasts them the output. From the user's point of view, using a local or a remote engine, makes no difference, just like using a uci or an xboard one. (in fact, I wrote it as an additional protocol: uci, xboard or network).

MultiPV is an 'interactive' option that you would want to change all the time during an analysis session, depending on the position you visit. It would be extremely inconvenient if you had to open the engine settings dialog each time you want to change it.

Yes, in SCID too the MultiPV sbinbox is also displayed during the analysis and can be changed with a single click.
But the cool part is that I didn't write a dialog! (I hate the old SCID dialog). For example if during the analysis you want to add a thread: with a click you go to the configuration, with another click you add the thread, and with the last click you return to the analysis

[hgm]

Not sure what you mean by 'go to the configuration' if it is not a dialog. Is it a tab? I don't think that is much different: you get something else in view that covers/replaces what you were looking at before, have to do something there, and then move back. Whether it is a separate dialog and the thing you were originally looking at in theory still exists in some covered window makes no difference to the user.

The point is that you need three clicks, while you would only have needed a single one if the control had been permanently in view during the main task. I would consider that 3 times worse. And in the main time your view changes, which is yet an extra annoyance. Each time the view changes you have to 're-orient' yourself, locate the relevant items again.

But I guess for changing the number of threads this would be OK; it is not really what I would call an interactive option (needing a value dependent on the position). Changing Threads cannot even be done during search in UCI, AFAIK. So it would have to abort the analysis, and then start a new search. Which could be very damaging, if you were doing a long analysis. If I want to free CPU time for another task during a long analysis it would be better to stall one of the threads, by setting an empty affinity mask for it. (I usually do that through the task manager.)

As long as MultiPV can be changed with a single click without 'going anywhere' first, it is fine. But why would you want to have a control for it also in the engine configuration window? That can only be confusing. (I have it in WinBoard in the Enige Settings too, I must admit, but I am not happy with that.)

I don't quite understand the argument about the old xboard engines. If they don't provide a mechanism to set the hash through the protocol, there really is not much you can do about it through the GUI. They would not respond to a centralized hash setting, but they also would not respond to a Hash option in their configuration window. So why would you prefer to have the latter for the engines that would respond?

BTW, I have no problem with all info about the engine, even when it is only for one-time use when you first register it, being in the same window. (As long as I don't have to go there to change something that needs as much changing as MultiPV!) But I would consider it annoying when changing something like the PV format in the window for one engine would not automatically carry over to all other engines.

[Fulvio]

Not sure what you mean by 'go to the configuration' if it is not a dialog. Is it a tab? I don't think that is much different:

There was a select/add/delete dialog with an "edit" button that opens a general uci/xboard configuration dialog with a "Configure UCI engine" button that opens another dialog...

I don't quite understand the argument about the old xboard engines.

There is an old version of an xboard engine called Phalanx which is distributed together with SCID because it's surprisingly fun to play against it.
It sends the pv as: Pd2-d4
Then to test the new xboard code I tried Arasanx which can be used both as uci and as xboard.
It sends the pv as: d4
Nice this feature san=1 I thought, less work for me.
Then I tried Crafty, which sends the pv as: 1. d4
At this point I consulted the short and concise xboard documentation:
"Freeform text giving current" best "line"
It became mandatory to have a per engine option: show the pv as it is sent.
The point, however, is that I can have both.
I can always add the ability to set the defaults globally, or I can look at how the other engines are configured and decide that if the user always choosed the same value that's the default.
Still keeping the possibility of setting each individual option differently for each engine.

[hgm]

The purpose of a GUI is to shield the user from all that protocol nonsense. When you parse the PV all 'decorations' would disappear, and you have the moves in some internal format, which would always be the same, whether you are running Phalanx, Arasan, Crafty or a UCI engine. The GUI option would then determine how that move sequence is presented to the user. (E.g. SAN/long algebraic, with/without move numbers.)

If the engine really sends gibberish that your move parser doesn't understand (that can also happen for illegal or ambiguous moves), you can always show the literal text it sent from that point on.

[Fulvio]

I have no idea what the motivation for the "freeform text" is. I like to think of the hacker of twenty years ago who wants to play chess on a mainframe which can only be accessed via telnet and wants to receive a readable output from the engine
The fact is that an xboard engine could at this point legally decide to use different formats in the same line. And it is certainly possible to try to interpret every line sent by the xboard engines, but it annoys me the idea of ​​so much waste of resources to manage cases that probably will never occur.

The purpose of a GUI is to shield the user from all that protocol nonsense.

I do not agree. I think that a user may legitimately ask to have the raw pv line of an engine.
Of course the user can just press "add engine", choose the executable and then simply click "go" without setting anything else. Indeed, if he downloads the Windows version he can just click go because there is already Stockfish configured.
But I also want advanced users to have maximum control and give them the freedom to set each parameter as they wish.