How to suspend a Winboard tournament?

[cnchang]

I hope your test on Shiga.ini is a success this time.

Why Engine #1 settings and Engine #2 settings in Winboard menu only allow users to activate debug mode? In Winboard help, it says users are allowed to set each engine's defined options there. Is "Common Engine" the only place to do that for both engines now?

If you are willing to modify UCI2WB and UCCI2WB with another beta to set hash and threads# on those non-compliant engines. I can test them and list which engine crashes on just receiving that. To be on the safe side, why not consider making this force-to-set-hash-and-threads-by-Winboard as an option, which can be called by an argument, e.g., "-hashthreads"? Therefore, users will have the discretion to invoke it in Edit Engine(or combo box) stage.

BTW, my setting up Shiga's hash&threads, since uci2wb is not triggered to do so, is to modify Shiga.ini and then:
1. start Winboard and load Shiga engine, if Winboard and Shiga are not loaded yet.
2. goes to Winboard>File>New Game, if Shiga engine is already loaded.
Then, the new settings will kick in!
You can see CPU utilization and memory footprint changed accordingly.

[H.G.Muller]

Why Engine #1 settings and Engine #2 settings in Winboard menu only allow users to activate debug mode? In Winboard help, it says users are allowed to set each engine's defined options there. Is "Common Engine" the only place to do that for both engines now?

The debug checkbox in the Engine Settings dialogs are not for WinBoard's debug mode, but for UCI2WB's debug mode. The nature of adapters is such that (UCI2WB + UCI engine) is a WB engine, (and (WB GUI + UCI2WB) is a UCI GUI). So according toe WinBoard UCI2WB is the engine, and the Engine Settings dialogs serve to set the options of UCI2WB itself, as well as those it relays from the engine. Since Shiga does not report any options, there is nothing to relay, however, so the dialogs might give the wrong impression. Cyclone reports some checkbox options, but ggChess really reports tons of options, so it really has a well-filled Settings dialog.

If you are willing to modify UCI2WB and UCCI2WB with another beta to set hash and threads# on those non-compliant engines.

Yes, I do plan to do this. Faking option announcements from the engine by some INI file should cause everything to work as normal. (I.e., the options will appear in the Engine Settings dialog, or in case of the Hash option WB wil set it automatically from the value in the Common Engine settings.) UCI2WB does not recognize any 'threads' option, though, to connect it to the WB 'cores' command that relays the setting in the Common Engine dialog to the adapter. The reason is that there seems to be no consensus about the name of this option. But if it is not recognized, it will simply appear in the Engine Settings dialogs in stead, and the user could set it from there.

I can test them and list which engine crashes on just receiving that. To be on the safe side, why not consider making this force-to-set-hash-and-threads-by-Winboard as an option, which can be called by an argument, e.g., "-hashthreads"? Therefore, users will have the discretion to invoke it in Edit Engine(or combo box) stage.

Well, this is a bit difficult as WB dos not communicate directly with the UCI engines, but only through the adapter. So it is really UCI2WB that should have such an option.

BTW, my setting up Shiga's hash&threads, since uci2wb is not triggered to do so, is to modify Shiga.ini and then:
1. start Winboard and load Shiga engine, if Winboard and Shiga are not loaded yet.
2. goes to Winboard>File>New Game, if Shiga engine is already loaded.
Then, the new settings will kick in!
You can see CPU utilization and memory footprint changed accordingly.

Oh, that is interesting. Weird that it does not react immediately, but only after New Game. But at least this proves that the Shiga.ini file is read directly by the Shiga engine. (It could also have been a file read by the GUI, and then relayed through the engine.)

You should realize, however, that the fact that Shiga.exe reads the INI file, and obeys the settings in it, by no means implies that the same options can be set through an UCI 'setoption' command. Most engines I know that use INI files do not react to 'setoption' commands at all. In fact this is the very reason they use INI files. If Shiga does not respond to 'setoption' commands, there is nothing that can be done from UCI2WB. The only way then would be to modify the INI file.

[cnchang]

Well, you know better where to put those arguments, uci2wb adaptor then. I agree my suggestion may not cure all but at least worth trying due to the significance of the hash and threads#/core# settings and how they can affect the outcome of a game/tourney. If a engine maker is too lazy to code its engine to listen and parse setoption commands, then it won't help a bit. But, then I would never understand why Shiga team would design its engine to only listen for setoption name Ponder value false(or true) while this ponder option is there with other options, e.g., hash and threads, in the ini file.

The debug checkbox in the Engine Settings dialogs are not for WinBoard's debug mode, but for UCI2WB's debug mode. The nature of adapters is such that (UCI2WB + UCI engine) is a WB engine, (and (WB GUI + UCI2WB) is a UCI GUI). So according toe WinBoard UCI2WB is the engine, and the Engine Settings dialogs serve to set the options of UCI2WB itself, as well as those it relays from the engine. Since Shiga does not report any options, there is nothing to relay, however, so the dialogs might give the wrong impression. Cyclone reports some checkbox options, but ggChess really reports tons of options, so it really has a well-filled Settings dialog.

Well, so for those silent engines that don't announce their options, users won't see engine options at Engine #1 settings or Engine #2 settings. It is really cool how handshaking can dynamically change the engine configuration screen. But, when I checked my elephant eye 3.1 UCCI2WB engine settings, I saw all options shown up on Winboard engine settings screen except option "hashsize". I can see this option announced by executing typing ucci in engine execution, but for some reason it can't be found in the UCCI2WB engine settings.

Sadly, my ggchess doesn't have any options, neither from UCI2WB engine settings nor from typing uci in engine execution(it only shows id name ggChess-UCI-4U, and id author LgL). May I know if your ggchess is a ucci or uci edition?

[H.G.Muller]

I uploaded a new UCI2WB to http://hgm.nubati.net/UCI2WB.exe . This looks for a file named 'DefectiveEngineOptions.ini' in the engine folder, and pretends that what is in there was sent by the engne. So you could try to make a file with

option name Hash type spin default 512 min 16 max 512

and variout threads options. I tied it with my Shiga version, but I could not get that to run at all now. (Also not in the old situation, when I did not have the DefectiveEngineOption.ini file.) Perhaps because I changed something in the Shiga.ini file. I have not tried the Shiga.exe you mailed me yet.

As to the 'hashsize' option: UCI2WB recognizes this as a special case, and connects it to the WB 'memory' command, which is controlled from the Common Engine options dialog. It is not announced to WB (by UCI2WB) as an engine-defined option, and therefore does not appear in the Engine Settings dialog.

[H.G.Muller]

btw, this is what my ggChess prints, when I run it from the command prompt:

Code: Select all

¢¡-¤©µ¦­¦µ+Ð+Ð ...
info initok ...
info Á¦Ã¦-¦Ë+¤¯¦¦-²ú¦2
id name ggChess-UCI-X32_U6_20100716-1-SZ-GG-MAX-6T
id author ãÕÍð+¾ËÐ
option name Hash type spin default 128 min 32 max 1024
option name Clear Hash type check default false
option name MultiPV type spin default 1 min 1 max 10
option name Ponder type check default true
option name Search Depth type spin default 0 min 0 max 128
option name Search Time type spin default 0 min 0 max 3600
option name Threads type spin default 6 min 1 max 8
option name NullMove Pruning type spin default 1 min 1 max 3
option name NullMove Reduction type spin default 2 min 1 max 4
option name Verification Search type spin default 1 min 1 max 3
option name Verification Reduction type spin default 4 min 1 max 6
option name History Pruning type check default true
option name History Threshold type spin default 55 min 0 max 100
option name History Pruning Depth type spin default 4 min 1 max 6
option name Futility Pruning type check default true
option name Futility Margin type spin default 100 min 0 max 500
option name Extended Futility Margin type spin default 300 min 0 max 900
option name Futility Depth type spin default 2 min 1 max 6
option name Delta Pruning type check default true
option name Delta Margin type spin default 80 min 0 max 500
option name Quiescence Check Plies type spin default 1 min 0 max 2
option name Material type spin default 100 min 0 max 400
option name Piece Activity type spin default 100 min 0 max 400
option name Piece Square Activity type spin default 100 min 0 max 400
option name King Safety type spin default 100 min 0 max 400
option name Pawn Structure type spin default 100 min 0 max 400
option name Passed Pawns type spin default 100 min 0 max 400
option name Gaga Lazy Eval type check default true
option name Gaga Lazy Eval Margin type spin default 200 min 0 max 900
option name Gaga Exchange Bonus type spin default 20 min 0 max 100
option name Gaga King Safety type check default false
option name Gaga King Safety Margin type spin default 1550 min 500 max 3000
option name Gaga Extended History Pruning type check default false
option name Gaga History Threshold type spin default 30 min 0 max 100
option name UCI_EngineAbout type string default ggChess by lgl, http://www.ggchess.com
uciok
info Á¦Ã¦-¦Ë+¤¯¦¦-²ú¦1
info initend


Non-compliancy here is that it does not wait until it receives 'uci' before printing all this, but prints it spontaneous after a ~1 sec delay. But as GUIs usually would send the'uci' immediately, this should not matter much.

[Edit] The Shiga.exe you sent me seems to contain the BackDoor.Hupigon5.CCZJ virus. So I won't risk trying it.

[cnchang]

I used virustotal.com and indeed found Shiga was caught by more antivirus wares saying it contains some virus(backdoor something).
https://www.virustotal.com/file/19c0514426b9316984785ea36e310981e1100e1efcc53d10e9d6a3ed0fd1c4f5/analysis/1355389426/
Last time I sent it in for a test, there were only a few AV detected something. Now, the list is growing longer.
Hmm, maybe not using it is a good choice.

Shiga can still run on my computers probably because Kaspersky, ESET NOD, and Avira are not complaining.
To be honest, I don't know how seriously I should take the warnings.
For example, your beta winboard.exe was caught containing some Trojan malware. But, it could just be false alarm.
https://www.virustotal.com/file/c643d7ea4445cbf0cc5319de97adaf0fffa678f8e96a6cecba1a9a268025de84/analysis/1355389637/

I uploaded a new UCI2WB to http://hgm.nubati.net/UCI2WB.exe . This looks for a file named 'DefectiveEngineOptions.ini' in the engine folder, and pretends that what is in there was sent by the engne. So you could try to make a file with
option name Hash type spin default 512 min 16 max 512
and variout threads options.

If a UCI engine's announced options differs from its ini file defined options, which one will be outweighed?

[H.G.Muller]

I am afraid both UCI2WB and WB itself are pretty stupid in this respect. They don't check for duplicates at all, and the option would simply appear twice in the Engine Settings dialog. With some inconsistent behavior as a consequence, because WB would not always notice that a setting changed (e.g. if you changed it, and then tried to set it back to the original value through its duplicat).

[cnchang]

Some updates for you after I tested Shiga on BHGUI:
1. In addition to using its ini, Shiga is also capable of taking BHGUI command to change its max threads# and hash size.
2. Shiga's ini file outweighs GUI engine settings, but removing ini from the same folder where Shiga.exe resides will stop these two from getting conflicted. The moment you move it in, ini rules it all.
3. Shiga ini new setting can kick in during an ongoing game. You can modify ini in the middle of the game to make Shiga use more or less resources on the very next move's thinking in the same game.

[H.G.Muller]

OK, (3) probably explains (2). If I were to design a UCI engine, I would use the settings in the INI file as defaults at statup, and then have the GUI protocol commands override them. But if you want to obey changes in the ini file during the game, they will automatically prevail, as the GUI does not resend the settings automatically during the game. WinBoard only sets hash size before every game, but I allow the user to change ponder and cores usage at any time.

But in any case this explains why I was so unsuccessful in affecting Shiga's parameters; I never removed the INI file.

Is there a way to figure out which commands BHGUI uses for changing thread#? (I suppose spy.exe could also be used to spy on BHGUI.) Have you already tried to use the DefectiveEngineOptions.ini file to make UCI2WB believe that the engine has options it does not announce? With what you say now, it sounds like that removing the Shiga.ini file and faking a hash and threads# option is really all that is needed to make Shiga work satisfactorily under WB.

UCI2WB could still be improved in some ways: Currently no UCI option is associated with the standard WB-protocol command 'cores', with as a result that engines running under UCI2WB will never obey the 'Max CPUs' setting in the Common Engine dialog. In stead the option it uses to set thead# would appear in the Engine Settings dialog. The problem is that UCI does not define a standard name for this option, unlike that for hash-table size. (It dfines Hash for that, but some XQ engines use 'hashsize' in stead, so UCI2WB checks both.) For Chess engines, a large variety of option names is used for this. ggChess seems to use 'Threads'. (In theory UCI should not be case sensitive.)

Another improvement could be in the implementation of pondering. I think the UCI specs prescribe that the GUI should set the 'Ponder' option in a game where pondering is allowed. This has nothing to do with actually making the engine ponder, for which there are other commands, but to allow the engine to allocate the available time more generously, in the knowledge that it will save time on future ponder hits. UCI2WB now does not do that.

[cnchang]

I didn't try your new UCI2WB because I was not quite sure you wouldn't make another beta after my last updates to you.
Anyway, I just tested your new UCI2WB.
I assume your file UCI2WB will check and take what is in the ini and treat those options as they are directly received from the engine.
If it is, then what should I test?
(1) If I leave ini inside the same directory with Shiga.exe, your uci2wb will be able to handle it now. But, it doesn't matter because GUI is outweighed by ini.
(2) If I remove ini from the directory, that part of the uci2wb function won't even start.
I don't know how it should ever work.
Nonetheless, I tried and tested (1) and (2) anyway, and Winboard GUI failed to control those options as expected.
Other than Shiga, since you worry about the possible malware and dare not to try, do you have any other UCI chess engine to verify or cross examine my results?

My suggestion is just let GUI take control sending setoption commands doesn't matter if engine announces its options or if there is an associated ini at all.
If you worry about the unknown consequences or Winboard's stability, you can always make this GUI-force-mode enabled/activated by argument only.
That way users will still have the discretion to choose what they want.

[H.G.Muller]

The idea is that ou would move away the Shiga.ini, so it no longer overrules everything, and then create a file named DefectiveEngineOptions.ini in the same folder as Shiga.exe containing the options we want to fake for the engine. Like

option name Hash type spin default 64 min 16 max 512
option name terads type spin default 2 min 1 max 8
option name Ponder type check default true

The presence of a file DefectiveEngineOptions.ini should not affect Shiga's operation diretly; Shiga will simply ignore it like any file it does not know.

My suggestion is just let GUI take control sending setoption commands doesn't matter if engine announces its options or if there is an associated ini at all.
If you worry about the unknown consequences or Winboard's stability, you can always make this GUI-force-mode enabled/activated by argument only.
That way users will still have the discretion to choose what they want.

The current solution is better, because it will not only fool the GUI in sending the required setoption commands, but will also make them automatically appear in the Engine Settings dialog, so the user could alter them later. And it is not limited to just the options Hash and thread#, but could be used for arbitrary options the user knows the engine to have (from the README file or by looking in an INI file that came with the engine). Without the need to recompile anything, but simply using a text editor.

[cnchang]

The idea is that ou would move away the Shiga.ini, so it no longer overrules everything, and then create a file named DefectiveEngineOptions.ini in the same folder as Shiga.exe containing the options we want to fake for the engine. Like

option name Hash type spin default 64 min 16 max 512
option name terads type spin default 2 min 1 max 8
option name Ponder type check default true

The presence of a file DefectiveEngineOptions.ini should not affect Shiga's operation diretly; Shiga will simply ignore it like any file it does not know.

I made a DefectiveEngineOptions.ini and put it in the same folder with Shiga.

Code: Select all

option name Hash type spin default 64 min 16 max 512
option name Threads type spin default 2 min 1 max 8
option name Ponder type check default true

Ponder and threads option show up in Engine #1(Shiga) settings, but no hash size option there.
Thus, I tried 64MB/1core, 128/2, and 256/4 in GUI Common Engine.
Shiga Hash size seems under full control of WB GUI, but threads number stay at 1, not even the default defined by DefectiveEngineOptions.ini.
Maybe the syntax for "threads" need some check up.
For ggchess UCI engine, after I put DefectiveEngineOptions.ini in, it stays at 128/4 in all GUI 64MB/1core, 128/2, and 256/4 conditions.
Bugchess, a UCCI, came up 48/1 in all GUI settings.
Bugcchess has no ini or any other files in the same folder with the engine, while ggchess has a bin file.

In BHGUI, I can use GUI to set 64/1, 128/2, and 4/256, and all the above mentioned UCI and UCCI engines will follow the rule of BHGUI.
The only thing I need to do is removing(or renaming) Shiga.ini.
Your WB approach is delicate, users can set each engine's options respectively in a custom made fashion.
I think BHGUI just sends setoptions to them and believe they should listen as UCI or UCCI engines, while Shiga.ini is the earmuff to be replaced.
Of course, some engines, like Elephant Eye and KOU, will follow BHGUI's hash size settings but simply ignore threads# settings because of the built-in restraint, but no engine crashes.

BTW, this new UCI2WB.exe will change the playing engine's name in WB Engine Output window from Shiga to UCI2WB. ggchess is fine.

[H.G.Muller]

Ponder and threads option show up in Engine #1(Shiga) settings, but no hash size option there.

That is by design; hash size is controlled from Common Engine.

Thus, I tried 64MB/1core, 128/2, and 256/4 in GUI Common Engine.
Shiga Hash size seems under full control of WB GUI, but threads number stay at 1, not even the default defined by DefectiveEngineOptions.ini.
Maybe the syntax for "threads" need some check up.

Indeed, this shows that 'Threads' is not the name of the option it uses for this. That is what you get when you are guessing for the option names; sometimes you guess wrong. You could try several likely alernatives for 'threads', in the hope that you strike lucky. (I suppose you tried to control this through the Engine Settings dialog; 'Max CPUs' in Common Engines cannot be expected to work ever, with the current versions if UCI2WB and UCCI2WB, which ignore the WB 'cores' command.)

The 'default' in the DefectiveEngineOptions.ini does not mean anything; it is only there to satisfy the syntax requirements of the option. The default reported b the engine (because that is where WB thinks it is comming from) is only used by WB to present it in the Engine Settings dialog to the user, and know when the user changed it, so it has to send a 'setoption' command to the engine.

For ggchess UCI engine, after I put DefectiveEngineOptions.ini in, it stays at 128/4 in all GUI 64MB/1core, 128/2, and 256/4 conditions.

That means it doesn't only fail to respond to 'Threads', but also to 'Hash'. You could try 'hashsize', which is what some UCCI engines (including the 'reference implementation' Elephant Eyes) use.

Bugchess, a UCCI, came up 48/1 in all GUI settings.
Bugcchess has no ini or any other files in the same folder with the engine, while ggchess has a bin file.

Well, UCCI engines do use UCCI2WB, and I have not adapted that yet to make use of a DefectiveEngineOptions.ini file. It could be that doing so cures BugCChess. In fact that is likely, its author (Liuzy) once complained to me that BugCChess did not respond to the WB hash setting, and when I explained him that this was because BugCChess did not suppot any hash option, and that being able to parse it is not worth anything if it does not announce it to the GUI first. So he made a version of BugCChess to run in my tournaments that did announce the options.

In BHGUI, I can use GUI to set 64/1, 128/2, and 4/256, and all the above mentioned UCI and UCCI engines will follow the rule of BHGUI.
The only thing I need to do is removing(or renaming) Shiga.ini.
Your WB approach is delicate, users can set each engine's options respectively in a custom made fashion.
I think BHGUI just sends setoptions to them and believe they should listen as UCI or UCCI engines, while Shiga.ini is the earmuff to be replaced.

Indeed, I think this is what BHGUI must do. I prefer the more subtle approach where it does not send guessed commands unconditionally, but where this can be easily controlled on an engine-by engine basis. And repair the problem by altering the (perceived) engine behavior rather than altering the GUI behavior, for that is where the problem really lies.

But if BHGUI know what to send to these engines, it should be possible to reverse-engineer that by using spy.exe to mask as ggChess or BugCChess, and then run it under BHGUI. (I guess for the latter we would need a UCCI version of spy.exe.) From the log.txt we will then be able to see whether BGGUI uses 'threads', 'threadnumber', 'cpus', 'cores', 'searchthreads' or whatever.

Of course, some engines, like Elephant Eye and KOU, will follow BHGUI's hash size settings but simply ignore threads# settings because of the built-in restraint, but no engine crashes.

BTW, this new UCI2WB.exe will change the playing engine's name in WB Engine Output window from Shiga to UCI2WB. ggchess is fine.

Hmm, I did not (intentionally) change anything in this respect. Normally it would report to WB the name the engine reports in its 'id name' command, followed by '(UCI2WB)'. What you say suggests that it did not process the 'id name' command from the engine correctly. The contents of the DefectiveEngineOptions.ini is read just before the regular output of the engine, though. So maybe something goes wrong when it switches the input from ini file to engine, corrupting the following 'id name' command. I will try if I can figure this out.

[cnchang]

I, as any user, indeed can't keep guessing what to put in DefectiveEngineOptions.ini to control max# of threads.
Your current subtle approach is always your best choice, but I really think taking standard UCI options as granted should be at least the second best, and an alternative when your best choice fails.
Why let users take the burden to find where each UCI options are or guess it and then have to create all kinds of files for UCI and UCCI engines?
AFAIK, this DefectiveEngineOptions.ini UCI2WB approach is still neither working on Shiga nor ggchess.
Can you test with your Shiga now? Do you have any UCI engine to test with?

[H.G.Muller]

Well, neither can I be bothered guessing at options of engines that I don't have, or even are not aware of their existence. It is the responsibility of authors to see that their engines are usable.

If you think that sending some fixed set of option commands to all engines is the solution, then this is fully supported by the current scheme: users can simply put the same DefectiveEngineOptions.ini in all their engine folders to fake those options for the engine. And if they don't like the fat that they will have to redo that for every new engine they install, they can complain to the engine author that he should include such an ini file with the engine. Or better yet, make his engine compliant with the protocol specs, so that no work-arounds are needed.

[cnchang]

Quite some engines that can't be configured by WBGUI may still be considered UCI/UCCI compliant even though they may not have all options implemented. For example, BHGUI took them as UCI/UCCI compliant engines by default w/wo seeing their options announced, nonetheless it has no difficulty to use all their implemented engine setting options.

I really can't say those engines are not UCI/UCCI compliant because they responded to setoptions command properly and ignored those setoptions commands they didn't implement or understand. Isn't that what UCI originally asked for? I have not found UCI strictly asks ENGINES MUST FIRST ANNOUNCE THEIR IMPLEMENTED OPTIONS BEFORE PUTTING THOSE OPTIONS INTO USE.

If you think that sending some fixed set of option commands to all engines is the solution, then this is fully supported by the current scheme: users can simply put the same DefectiveEngineOptions.ini in all their engine folders to fake those options for the engine.

My tests shows no UCI engine work in that scheme; they either failed on threads# or failed on both(hash & threads#). Do you find it work on any?

In my suggested scheme, nobody is obliged or bothered to guess anything. Just take those engines as they announced who they are. If they are UCI(saying uciok, readyok), then GUI should faithfully send users' preferred settings to those engines in UCI style. Trust me users will definitely accept the fact that some engines may not implement all available UCI options(i.e., some of their preferred settings will not take effect), but it may be hard for them to understand why their settings/options are actually blocked by the WBGUI itself because of some unsatisfactory handshaking process. Moreover, is this engine's total confess to the GUI really UCI mandatory?

[H.G.Muller]

Quite some engines that can't be configured by WBGUI may still be considered UCI/UCCI compliant even though they may not have all options implemented. BHGUI took them as UCI/UCCI compliant engines by default w/wo seeing their options announced, nonetheless it has no difficulty to use all their implemented features.

I really can't say those engines are not UCI/UCCI compliant because they responded to setoptions command properly and ignored those setoptions commands they didn't implement or understand. Isn't that what UCI originally asked for? I have not found UCI strictly asks ENGINES MUST FIRST ANNOUNCE THEIR IMPLEMENTED OPTIONS BEFORE PUT THOSE OPTIONS INTO USE.

The paragraph quoted below actually requires this. 'Should be sent' means it is obligatory. It does not say 'could send when it feels like it'.

Code: Select all

* option
   This command tells the GUI which parameters can be changed in the engine.
   This should be sent once at engine startup after the "uci" and the "id" commands
   if any parameter can be changed in the engine.
   The GUI should parse this and build a dialog for the user to change the settings.
   Note that not every option needs to appear in this dialog as some options like
   "Ponder", "UCI_AnalyseMode", etc. are better handled elsewhere or are set automatically.


Besides, it is a logical requirement: a GUI cannot possibly send 'setoption' commands for options it does not know exist. Even if a standard name for the option was defined (which is not the case for the number of threads), the GUI still cannot know what the valid range for its values is. (I suspect that this is why Shiga now fails to do anything at all for me; I must have set the hash size below the minimum it can handle.)

So fact is that these engines are non-compliant, and that BHGUI is non-compliant too by sending setoption commands for unannounced options.

If you think that sending some fixed set of option commands to all engines is the solution, then this is fully supported by the current scheme: users can simply put the same DefectiveEngineOptions.ini in all their engine folders to fake those options for the engine.

My tests on that scheme can't make one UCI engine work, they either failed on threads# or failed on both(hash & threads#). Do you find it work on any?

I have not tried any; I have no confidence in guessing options. I never use engines with more than 1 thread anyway, and for Cyclone that happened to be the default value, so it was no big deal to me it did not announce a maxthreads option. Engines for which the number of threads could not be set to 1 through an option or an ini file (as well as engines that used significantly more than 1 CPU even when set to 1 thread) I simply excluded from my tourney (using an older, non-SMP version in stead).

Did you have any success in setting the number of threads with the same option as BHGUI does? It should be logically impossible for the scheme not to work if you use the same option name as BHGUI does. The engine cannot know which GUI it is running under. So if you make UCI2WB sends the same commands to it as BHGUI does it simply should work. You must have used the wrong option names if it does not work for you.

[cnchang]

Code: Select all

* option
   This command tells the GUI which parameters can be changed in the engine.
   This should be sent once at engine startup after the "uci" and the "id" commands
   if any parameter can be changed in the engine.
   The GUI should parse this and build a dialog for the user to change the settings.
   Note that not every option needs to appear in this dialog as some options like
   "Ponder", "UCI_AnalyseMode", etc. are better handled elsewhere or are set automatically.

Where is this paragraph extracted from? If Hash is not mentioned as "not need to appear in this dialog", why doesn't it appear on WB's Engine #1 settings dialog window? If "Ponder" needs not to appear, why "Ponder" option appear in that dialog window in the DefectiveEngineOptions.ini test? I'd like to comprehend the reasonings behind those UCI rules. I also wonder why UCI doesn't specify the standard name for threads#. What is WBGUI's default name for threads# setting? If there is no standard/default name at all, how does Winboard know what to parse for?

Did you have any success in setting the number of threads with the same option as BHGUI does? It should be logically impossible for the scheme not to work if you use the same option name as BHGUI does. The engine cannot know which GUI it is running under. So if you make UCI2WB sends the same commands to it as BHGUI does it simply should work. You must have used the wrong option names if it does not work for you.

No. No engine will work on setting threads# in the DefectiveEngineOptions scheme. BHGUI works successfully on setting threads# with most engines, except some older ones, because
(1) it will not block users' preferred settings due to the "confess first" issue. Some engines may still have their own restraints so as not 100% GUI controllable, and that is always acceptable.
(2) it found the common language for setting threads#. Maybe BH team has found the standard name for that.
I didn't have to manually use any option names on BH. Why should I? I just used BHGUI to configure hash & threads#, and it worked as expected. Of course, Shiga.ini must be handled with care.

[H.G.Muller]

Where is this paragraph extracted from?

The first hit I get when I Google for "UCI protocol": http://wbec-ridderkerk.nl/html/UCIProtocol.html .

If Hash is not mentioned as "not need to appear in this dialog", why doesn't it appear on WB's Engine #1 settings dialog window?

Because in the design of WinBoard the option is centrally controlled, from the Common Engine dialog. This is in practice more convenient, as allowing specification per engine, as there usually is no reason why you would have one engine use a different amount of hash from the other. It just leads to errors when you would have to do it for each engine separately, so that you mistakingly play engines against each other with unequal hash.

If "Ponder" needs not to appear, why "Ponder" option appear in that dialog window in the DefectiveEngineOptions.ini test?

Because UCI2WB does not handle it properly yet. I already mentioned that above. Polyglot (which is a more popular UCI-to-WB adapter, but alas only usable for Chess) would not show Ponder in the Engine dialog. I never bothered to put the code for special treatment of this option in UCI2WB, because no XQ engine seemed to have that option. They did not announce it. If now it turns out that they actually do support it, there would be a reason to correct that situation.

I'd like to comprehend the reasonings behind those UCI rules. I also wonder why UCI doesn't specify the standard name for threads#. What is WBGUI's default name for threads#? If there is no standard/default at all, how does WB parser know what to wait for?

UCI was designed when SMP was not common. When it became possible every engine author picked his own name for the option.

In WB protocol there is a command 'cores N' to set the number of search threads. The engine announces that it supports it by sending 'feature smp=1' to the GUI at startup. If they don't announce it, WB does not inform them of the setting of the Max CPU parameter in the Common Engine dialog.

No. No engine will work on setting threads# in the DefectiveEngineOptions scheme. BHGUI works successfully on setting threads# with most engines, except some older ones, because
(1) it will not block users' preferred settings due to the "confess first" issue.
(2) it found the common language for setting threads#. Maybe BH team has found the standard name for that.
I didn't have to use any option names manually. Why should I? I just use BHGUI to configure hash & threads#.

Well, if there is a standard name for it, they must have found it. Good for them, but that doesn't help much.

It seems you misjudge the problem. Which is NOT whether it is better to specify the option in an ini file or to hard-code it in the GUI, but that the option is kept SECRET by the engines so that it can be neither put in an ini file nor hard-coded in the engine or adapter. A situation where there is a secret standard option that all engines use is certainly better than one where every engine needs a different option (which would be no problem for the ini-file method, btw), but without knowing that option it is not possible to exploit that.

It is not possible for me to reverse-engineer the BHGUI (with spy.exe), because I am not able to operate it. So the option remains secret, and talking about the best way to use it is a waste of breath... Without knowing the option, nothing can be done.

And this is exactly why UCI requires engines to announce their options, rather than keep them secret...

[cnchang]

There should be a more updated UCI protocol standard, newer than this 2004 edition, which includes the consideration of SMP. Is the person chartered UCI still operating? If UCI is an open standard, there should be no secret options allowed in public, at least, not on such an important one. Secret ones or no standard at all are both unacceptable. Winboard just randomly picked some name for threads# out of the thin air?? Are you kidding me? If "feature smp=1" carries no weight in UCI, why should engines respond? According to UCI, engines should ignore the unknown commands.

Regarding the possible use of different hash settings for each engine, I just tested something related to that a couple of days ago. I wondered how Shiga 64MB/1core stacks up against 512MB/4cores. When I set both to play with time control 40 steps/10minutes. They drawed. But, with the time control 10 steps/10 minutes, Shiga 512/4 won. This kind of test can only be done with the help of Shiga.ini now because of Winboard's decision. UCI's not listing hash size as "not need to appear in this dialog" may find a cause here.

"Ponder" must be a common engine option for any meaningful game. Thus, it should be centrally controlled. Isn't it?

Above all, I can't see the reasoning behind this:

* option
This command tells the GUI which parameters can be changed in the engine.
This should be sent once at engine startup after the "uci" and the "id" commands
if any parameter can be changed in the engine.
The GUI should parse this and build a dialog for the user to change the settings.
Note that not every option needs to appear in this dialog as some options like
"Ponder", "UCI_AnalyseMode", etc. are better handled elsewhere or are set automatically.
If the user wants to change some settings, the GUI will send a "setoption" command to the engine.
Note that the GUI need not send the setoption command when starting the engine for every option if
it doesn't want to change the default value.

It sets the "confess all your options first at startup before putting em into use" rigid rule on the engines while setting a relatively lax rule on the GUI side, "need not to send setoptions if GUI doesn't feel like it", without elaboration. How arbitrary and strange!