Proposal for Linux engine standard

[bnemias]

If we are defining a standard here, then do it. The objective should be to make it simple while also accommodating most of what's out there now. It takes hold, and then is considered during future engine design.

One reason I like asking the engine those details is it keeps stuff up to date by design. The engine knows (or should) all those details, so it's logical to get that information from the engine instead of elsewhere. Otherwise you duplicate data from different sources, that WILL change over time. The package maintainer might not notice that the authors have increased by one member, but the engine will have had that information added already. Or support for 960 is added, but the package maintainer doesn't notice and now you have a misconfiguration situation-- one that is more difficult to solve for the end user as a result of using data from the wrong source

[hgm]

I think the best solution is to have one file for each separate variant that is played under a 'catchall' name. Suppose I would be the author of a Crazyhouse engine that can also do Loop Chess, and I want to make it easy for users to run it under WinBoard. I would then supply an extra ini file, containing

Game = chess
Variant = loop
Command = crazyloop_2.3.exe
[GUI options]
xboard = -variant normal -holdingsSize 5 -firstOptions "Play variant normal as=Loop Chess"

Now XBoard should be smart when it encounters this ini file: at first glance it sees a Variant it does not know. This could be a variant only supportd by other GUIs, or perhaps by a later version of XBoard, in which case the current version has no chance using the engine this way.

OTOH, XBoard is aware of its high configurability, which makes it possible to apply modifyers to existing variants and turn them into others. So it doesn't despair right away, but checks if there is a work-around provided in the GUI-options section. It finds the line "xboard = ...", so it knows that at least some XBoard version must be able to play this. And the work-around contains a -variant option (which normally would not be present, as XBoard would derive it from the Variant line). So it can conclude that it is dealing with a variant that is a modified form of 'normal'. Now it does play normal, so this engine is acceptable, and it can install it with the given engine command and options. Apparently the engine has some combo option "Play variant normal as", but apart from the engine author, no one has to know that. Perhaps

In a similar spirit, Fairy-Max plays Ouk (Cambodian Chess) as modified makruk (Thai Chess). To this end it has a check option "Play Makruk with Cambodian rules". So its ini file should look

Game = chess
Variant = ouk
Command = fairymax
[GUI options]
xboard = -variant makruk -testLegality false -firstOptions "Play Makruk with Cambodian rules=1"

Perhaps it would be good to define an option VariantName distinct from Variant, which would provide a string that could be used to mention the variant in the nickname the user will see in his engine menu (e.g. "crazyloop (Loop Chess)"). OTOH this might more accurately be given by the engine author as Name option, e.g.

Name = CrazyLoop 2.3 (Loop Chess)

while in absence of a Name option the nickname would have defaulted to "crazyloop (loop)".

I suppose that cutechess-cli and icsdrone also have command-line options (or ini-file settings) that could be used to set options of the engines they run (like XBoard's -first/secondOption), and these could be given in the "icsdrone = ..." line in the GUI-options section.

[Michel]

Or support for 960 is added, but the package maintainer doesn't notice and now you have a misconfiguration situation

Again you are too pessimistic. These situations happen but they are quickly resolved with a package update, pushed to all users of the distribution.

(and if the author has provided his own engine file, installed by make install, this scenario cannot even happen).

[Michel]

I think the best solution is to have one file for each separate variant that is played under a 'catchall' name. Suppose I would be the author of a Crazyhouse engine that can also do Loop Chess, and I want to make it easy for users to run it under WinBoard. I would then supply an extra ini file, containing

Game = chess
Variant = loop
Command = crazyloop_2.3.exe
[GUI options]
xboard = -variant normal -holdingsSize 5 -firstOptions "Play variant normal as=Loop Chess"

Now XBoard should be smart when it encounters this ini file: at first glance it sees a Variant it does not know. This could be a variant only supportd by other GUIs, or perhaps by a later version of XBoard, in which case the current version has no chance using the engine this way.

OTOH, XBoard is aware of its high configurability, which makes it possible to apply modifyers to existing variants and turn them into others. So it doesn't despair right away, but checks if there is a work-around provided in the GUI-options section. It finds the line "xboard = ...", so it knows that at least some XBoard version must be able to play this. And the work-around contains a -variant option (which normally would not be present, as XBoard would derive it from the Variant line). So it can conclude that it is dealing with a variant that is a modified form of 'normal'. Now it does play normal, so this engine is acceptable, and it can install it with the given engine command and options. Apparently the engine has some combo option "Play variant normal as", but apart from the engine author, no one has to know that. Perhaps

In a similar spirit, Fairy-Max plays Ouk (Cambodian Chess) as modified makruk (Thai Chess). To this end it has a check option "Play Makruk with Cambodian rules". So its ini file should look

Game = chess
Variant = ouk
Command = fairymax
[GUI options]
xboard = -variant makruk -testLegality false -firstOptions "Play Makruk with Cambodian rules=1"

Perhaps it would be good to define an option VariantName distinct from Variant, which would provide a string that could be used to mention the variant in the nickname the user will see in his engine menu (e.g. "crazyloop (Loop Chess)"). OTOH this might more accurately be given by the engine author as Name option, e.g.

Name = CrazyLoop 2.3 (Loop Chess)

while in absence of a Name option the nickname would have defaulted to "crazyloop (loop)".

I suppose that cutechess-cli and icsdrone also have command-line options (or ini-file settings) that could be used to set options of the engines they run (like XBoard's -first/secondOption), and these could be given in the "icsdrone = ..." line in the GUI-options section.

Ok that makes very good sense!

[bnemias]

Or support for 960 is added, but the package maintainer doesn't notice and now you have a misconfiguration situation

Again you are too pessimistic.

I think it's important to design standards that prevent problems.

These situations happen but they are quickly resolved with a package update, pushed to all users of the distribution.

They tend to get resolved. I'm not sure I agree with quickly though. But in the meantime, the user is going to have to find the solution on his own if he wants the functionality right away. That is the very problem this standard is meant to avoid.

[hgm]

So in the rare case something goes wrong, he would have to do what he otherwise would always have to do...

[bnemias]

So in the rare case something goes wrong, he would have to do what he otherwise would always have to do...

Not exactly. Now he has to deal with a configuration setting somewhere very different than how problems of this nature used to be addressed. He'll find and change settings the old way, and thus fight the very config files the GUI is making use of.

Anyway, I don't see why you are reluctant to get the data from the engine. It's easy, it prevents sync issues, and it is simpler.

[hgm]

It seems to be a non-starter in the most literal sense. How would you know where the the engine is, or even what is an engine? Randomly starting every binary of the system several times, to see if you can play a game of Chess in them in any of the protocols you know? You still wouldn't find all those that need command-line arguments to play, like TSCP...

And if it reacts to the UCI command, how would you know whether it plays Chess, Xiangqi or Seirawan Chess? Try different opening moves? But UCI engines don't give illegal-move errors when you feed them wrong moves.

[bnemias]

It seems to be a non-starter in the most literal sense. How would you know where the the engine is, or even what is an engine? Randomly starting every binary of the system several times, to see if you can play a game of Chess in them in any of the protocols you know? You still wouldn't find all those that need command-line arguments to play, like TSCP...

I already explained both points....

And if it reacts to the UCI command, how would you know whether it plays Chess, Xiangqi or Seirawan Chess? Try different opening moves? But UCI engines don't give illegal-move errors when you feed them wrong moves.

Don't UCI engines spit out the variants they play? Certainly they know what variants they play. If all protocols have that, I don't know.

[gbtami]

It seems to be a non-starter in the most literal sense. How would you know where the the engine is, or even what is an engine? Randomly starting every binary of the system several times, to see if you can play a game of Chess in them in any of the protocols you know? You still wouldn't find all those that need command-line arguments to play, like TSCP...

And if it reacts to the UCI command, how would you know whether it plays Chess, Xiangqi or Seirawan Chess? Try different opening moves? But UCI engines don't give illegal-move errors when you feed them wrong moves.

Hi all! I'm Bajusz Tamás, one of a PyChess developer and UHU-Linux packager too. This is my first post on talkchess.

First of all I like the main idea of this proposal a lot.
At this moment how PyChess handles this problem:
1. There is a hardwired backup string (xml) of "most popular free engines" in a .py source file with binname and protocol.
2. It maintains the ~/.config/pychess/engines.xml file on startup. If it not exists yet, it creates from backup, then checks if engine binary md5 is changed. If yes, it introspect the engine what options (including variations) it supports, and updates the .xml file.

We have no gui (yet) to add new engines or edit their config options, and I know this syncing process is not perfect in general. But as I know the UCI doesn't support chess variants at all (except Chess960, but it has option to ask for and set to play), so no need to answer your last question.
CECP protocol supports variant introspection, so let GUI programmers use it.

All in all, I like Don Dailey's one file for one engine suggestion:
/usr/share/games/chess/fruit
/usr/share/games/chess/toga

/usr/share/games/shogi/*
/usr/share/games/checkers/*

with two command lines for two protocols.