How to suspend a Winboard tournament?

[cnchang]

Did you press New Game or anything like that, that might have triggered it to send the threads/hash/bookstuff again?

No, I didn't. As long as BHGUI is started with two engines loaded, then this(i.e., hashsize and threads sent twice) is log.txt:

Code: Select all

out: protocol UCCI
in:  ucci
out: id name anita 0.2
out: id copyright 2006 - 2006
out: id author 夷+?-
out: id user Unknown User
out: id birth Jun 15 2006 10:27:00
out: copyprotection OK
out: ucciok
out: option name Hash type spin default 16 min 4 max 1024
out: option name Ponder type check default false
out: option name BookFile type string default book.dat
out: option name NullMove Reduction type spin default 2 min 1 max 3
out: option name History Pruning type check default true
in:  isready
out: readyok
in:  setoption usemillisec true
in:  setoption repetition asianrule
in:  setoption drawmoves 100
in:  setoption usebook false
in:  setoption useegtb false
in:  setoption threads 4
in:  setoption hashsize 512
in:  setoption name OwnBook value false
in:  setoption name Threads value 4
in:  setoption name Hash value 512

If there is only one engine(UCCIspy) loaded when BHGUI is started, then this(i.e., hashsize and threads sent once) is log.txt.

Code: Select all

out: protocol UCCI
in:  ucci
out: id name anita 0.2
out: id copyright 2006 - 2006
out: id author 夷+?-
out: id user Unknown User
out: id birth Jun 15 2006 10:27:00
out: copyprotection OK
out: ucciok
out: option name Hash type spin default 16 min 4 max 1024
out: option name Ponder type check default false
out: option name BookFile type string default book.dat
out: option name NullMove Reduction type spin default 2 min 1 max 3
out: option name History Pruning type check default true
in:  isready
out: readyok
in:  setoption usemillisec true
in:  setoption repetition asianrule
in:  setoption drawmoves 100
in:  setoption usebook false
in:  setoption useegtb false
in:  setoption threads 4
in:  setoption hashsize 512

Installing Cygwin is a bit of a pain. Gcc is NOT included in the base install. When you run the Cygwin Setup.exe, you should explicitly select it (and binutils) in the "devel" section.

I only see a net release cygwin setup.exe @cygwin.com. If possible, I'd like to have a setup_full.exe to download and scan for virus. Did you use net release setup, any particular release?

[H.G.Muller]

Hmm, weird. Sounds like a bug, where it sends to engine #1 what was intended to engine #2. Anyway, it probably would not hurt.

What is non-compliant is that it does not send 'isready' AFTER sending the 'setoption' commands. The protocol is designed to use 'isready' after sending 'setoption' commands that could be potentially time consuming. Like setting hash size (which might require swapping out other task images to disk, to free the requested amount of RAM), or enabling EGTBs (which usually leads to loading of the EGTB index files fom disk). By waiting for the 'readyok' response to the following 'isready' the GUI can then know whether the engine is finished loading, so that it won't start its clock prematurely. Sending 'isready' before any 'setoptions' is completely pointless, as you have not asked the engine anything to do yet. So you aleady know it must be ready. The protocol does not forbid you to do this, but doing it won't free you from the need to send another 'isready' after the 'setoption' commands.

It seems BHGUI makes a complete mess of things...

As to Cygwin: AFAIK it can only be installed through a network installer, which fetches the actual packages from a server (mirror). I suppose you can ask it to not install, but download to a temporary folder, and scan it there before proceeding. But I guess you can trust Cygwin to be virus-free.

[cnchang]

What is non-compliant is that it does not send 'isready' AFTER sending the 'setoption' commands. The protocol is designed to use 'isready' after sending 'setoption' commands that could be potentially time consuming. Like setting hash size (which might require swapping out other task images to disk, to free the requested amount of RAM), or enabling EGTBs (which usually leads to loading of the EGTB index files fom disk). By waiting for the 'readyok' response to the following 'isready' the GUI can then know whether the engine is finished loading, so that it won't start its clock prematurely. Sending 'isready' before any 'setoptions' is completely pointless, as you have not asked the engine anything to do yet. So you aleady know it must be ready. The protocol does not forbid you to do this, but doing it won't free you from the need to send another 'isready' after the 'setoption' commands.

Well, from what I checked at xqbase.com -- http://www.xqbase.com/protocol/cchess_ucci.htm, it seems in UCCI 3.0 'isready' is only used to ask whether UCCI engine is ready to receive commands from GUI. When engine responds with "readyok", it only means engine is ready to receive GUI commands, and it doesn't mean engine can do whatever GUI's setoption command has asked for. On the same page, it also says it is better to use setoption command to set those options announced by the engine, but it should not cause any problem ignoring engine announced options. For example, Xqwizard GUI never checks engine announced options but simply sends setoption commands to engines based on users' requested settings.

I extract the quoted part of this page so that you can use Google or any other translator to verify the above note.

4. ucciok
　　引導狀態的反饋，此後引擎進入空閒狀態。
　
5. isready
　　空閒狀態和思考狀態的指令。檢測引擎是否處於就緒狀態，其反饋總是readyok，該指令僅僅用來檢測引擎是否能夠正常接收指令。
　
6. readyok
　　空閒狀態和思考狀態的反饋。表明引擎處於就緒狀態(可正常接收指令)。
　
7. setoption < 選項> [< 值>]
　　空閒狀態的指令。設置引擎參數，這些參數都應該是option反饋的參數，例如：
　
setoption usebook false，不讓引擎使用開局庫；
setoption selectivity large，把選擇性設成最大；
setoption style risky，指定冒進的走棋風格；
setoption loadbook，初始化開局庫。
　
　　但是，設置option反饋沒有給出的參數，並不會出錯。例如UCCI界面《象棋巫師》就從不識別option反饋，而直接根據用戶的設置發送setoption指令。

It makes sense. On the overall game setting perspective GUI, representing users, has a higher privilege to define the game settings for the participating engines; on the other hand, engine will accommodate as best as it can to the extent not exceeding its own design limits.

[H.G.Muller]

Well, from what I checked at xqbase.com -- http://www.xqbase.com/protocol/cchess_ucci.htm, it seems in UCCI 3.0 'isready' is only used to ask whether UCCI engine is ready to receive commands from GUI. When engine responds with "readyok", it only means engine is ready to receive GUI commands, and it doesn't mean engine can do whatever GUI's setoption command has asked for.

Indeed, it does not confirm that it has pocessed the option as requested. But it does confirm that it is no longer working on any of the previous commands (in this case 'setoption' commands). If it was still working on any of them (e.g. loading EGTB index files), it would obviously not be ready to receive new GUI commands. A good GUI would verify the readiness of the engine after changing its hash size. BHGUI 'verifies' this before it asks the engine to do something. So of course it will be ready... This is non-sensical (though not forbidden) use of the protocol.

On the same page, it also says it is better to use setoption command to set those options announced by the engine, but it should not cause any problem ignoring engine announced options. For example, Xqwizard GUI never checks engine announced options but simply sends setoption commands to engines based on users' requested settings.

Well, so UCCI2WB now does it the way the specs describe as 'better'...

I extract the quoted part of this page so that you can use Google or any other translator to verify the above note.

...
　　但是，設置option反饋沒有給出的參數，並不會出錯。例如UCCI界面《象棋巫師》就從不識別option反饋，而直接根據用戶的設置發送setoption指令。

OK, thanks. Although Google translate does not really transform it into something that is intelligible.

It makes sense. On the overall game setting perspective GUI, representing users, has a higher privilege to define the game settings for the participating engines; on the other hand, engine will accommodate as best as it can to the extent not exceeding its own design limits.

I am not sure what you mean by that. Announcing options is a logical necessity, for a GUI cannot know what name to use for a certain parameter unless the engine tells it. UCCI engines have many options that BHGUI does not send by default. So how would a user exercise his 'higher privilege' to set those options (such as Elephant Eye's options 'promotion', 'randomness', 'pruning')? Should he scrutinize the engine's documentation and README files to figure out which options the engine has, in oder to be able to set them without any help of the GUI? I would not consider that much of a 'privilege'... Besides, do you really think that engine authors that are too lazy to put a printf statement in their engine to announce the option, would take the trouble to descibe it in the docs?

[cnchang]

Indeed, it does not confirm that it has pocessed the option as requested. But it does confirm that it is no longer working on any of the previous commands (in this case 'setoption' commands). If it was still working on any of them (e.g. loading EGTB index files), it would obviously not be ready to receive new GUI commands. A good GUI would verify the readiness of the engine after changing its hash size. BHGUI 'verifies' this before it asks the engine to do something.

Regarding that, I have some questions:
(1)If an engine received a setoption command to set hash size to 256MB, and this engine can only handle a hash size up to 192MB or just 32MB, should it return readyok and wait for the next command?
(2)If this engine can't set to any new hash size other than its hard-coded amount and thus doesn't take or understand any such command, should this setoption command be ignored(can't get ready) and not responded?
In case (1), if engine replies with "readyok", will this "readyok" confuse GUI into believing engine has done assigned works(e.g., swapping out other task images to disk to free the requested amount of RAM, and loading EGTB index files, etc)?
in case (2), if engine does not respond with "readyok", should GUI keep waiting or just send the next setoption commands?
(3)Does each setoption command need to be acknowledged by engine before the next one gets sent out? Could there be a buffer on the engine side to take more than one setoption at a time?

I am not sure what you mean by that. Announcing options is a logical necessity, for a GUI cannot know what name to use for a certain parameter unless the engine tells it. UCCI engines have many options that BHGUI does not send by default. So how would a user exercise his 'higher privilege' to set those options (such as Elephant Eye's options 'promotion', 'randomness', 'pruning')? Should he scrutinize the engine's documentation and README files to figure out which options the engine has, in oder to be able to set them without any help of the GUI? I would not consider that much of a 'privilege'... Besides, do you really think that engine authors that are too lazy to put a printf statement in their engine to announce the option, would take the trouble to descibe it in the docs?

All UCCI 18 options are listed on that UCCI 3.0 protocol page. GUI doesn't need to learn from engines what standard options can be configured. But as for the clarity of engine's readiness, I agree there are areas to be worked upon like "displaying each loaded engine's announced options"(for which WinBoard is doing well) and "displaying the status of each available option to show which options are taking effect after GUI sends commands". Another problem is that not all available options are announced by some engines because they may be not too sure about the limits of max hashsize or max threads#.

[H.G.Muller]

Regarding that, I have some questions:
(1)If an engine received a setoption command to set hash size to 256MB, and this engine can only handle a hash size up to 192MB or just 32MB, should it return readyok and wait for the next command?

It should never return 'readyok' in response to anything else than 'isready'. The protocol does not define any 'error response' to faulty 'setoption' commands (or in fact to any commands). One presumes that the protocol designers through such responses were not needed, because a compliant GUI should never send a request to set hash size to 192MB if the engine only supports upto 32MB. So I guess that what happens if it does, is undefined. Which means that it would be entirely up to the engine to decide what it does. The final remark in the protocol you quoted says that it should not crash, but anything else is allowed. So it could take the maximum it supports, but it would also be well in its rights to switch hashing off altogether, or keep the hash size it was using before.

I admit that currently WB + UCCI2WB also sin in this respect. The meaning of the WB 'memory' command does not coincide fully with that of UCCI 'setoption hashsize'. In WB protocol it is defined as an upper limit. So there is no need for the engine to tell the GUI what its maximum capacity is, and indeed WB protocol does not even support a command for that. (It does support commands for engines to pop up general warning or error dialogs from the GUI,with an engine-specified text, however.) So in translating 'memory' to 'setoption hashsize' the burdon is really on the adapter to enforce the limits announced by the engine. And I did not do that in UCCI2WB. (Working on UCCI2WB is difficult for me anyway, as it was not written by me, in a programming language (C++) that I don't really understand, with comments in Chinese, and given the fact that almost no UCCI engine announces a hashsize option anyway, it seemed a complete waste of time...)

(2)If this engine can't set to any new hash size other than its hard-coded amount and thus doesn't take or understand any such command, should this setoption command be ignored(can't get ready) and not responded?

It has little choice other than ignoring it. In any case, it can never respond. The UCI specs actually do say you should ignore any token that is not supposed to come at that point. (Although I suppose this is mainly fo solving the race condition for 'stop' commands, where it was received after the search already terminated spontaneously.)

In case (1), if engine replies with "readyok", will this "readyok" confuse GUI into believing engine has done assigned works(e.g., swapping out other task images to disk to free the requested amount of RAM, and loading EGTB index files, etc)?
in case (2), if engine does not respond with "readyok", should GUI keep waiting or just send the next setoption commands?

If there is no unanswered 'isready' the engine should not send 'readyok'. So if the GUI receives one, it is another case of a command that was not valid at that point, for which UCI explicitly specifies it must be ignored.

Note, however, that the situation where the GUI sends 'isready' and then first receives a number of other commands from the engine before 'readyok' is quite normal. This simply tells the GUI that these were responses to commands that the GUI sent before it sent the 'isready'. Commands wait in the pipe to the engine untill the engine is ready to start reading them, and the GUI has no way of knowing when they are actually read.

It is not really important for the GUI to know when each and every 'setoption' command finishes, so in general they don't have to acknowledge their completion. When a GUI is interested in the exact time of completion of a command that does not automatically acknowledge, it just sends 'isready' after it. Then, when the engine finishes, it will encounter the 'isready', and immediately replies with 'readyok'. That is the intended use of the protocol.

(3)Does each setoption command need to be acknowledged by engine before the next one gets sent out? Could there be a buffer on the engine side to take more than one setoption at a time?

From the above it should be clear now the answer to the first is a loud and unequivocal 'NO'. The only commands that are acknowledged by the engine in UCI/UCCI are 'isready' and 'go' (by 'readyok' and '(no)bestmove', respectively). There is no way for an engine to complain (e.g. against illegal positions or moves); it can only suffer in silence.

There is always an implicit buffer, which is the pipe that connects engine and GUI. The engine can write many commands into this pipe without them being read, before the OS will eventually stall it. The commands then just sit in the OS buffer until the engine reads them (which would cause a stalled GUI to be resumed by the OS).

All UCCI 18 options are listed on that UCCI 3.0 protocol page. GUI doesn't need to learn from engines what standard options can be configured. But as for the clarity of engine's readiness, I agree there are areas to be worked upon like "displaying each loaded engine's announced options"(for which WinBoard is doing well) and "displaying the status of each available option to show which options are taking effect after GUI sends commands". The big problem is that some available options are not announced at all.

In UCCI it is possible fo engines to define arbitrary options with arbitrary name, like in UCI, right? You are not limited to a small set of 'standard options'.


Btw, I just discovered a bad defect in WinBoard itself. Because I unt the adapters with feature reuse=0, WB will restart a new engine process for every game. But this means the handshaking takes place again, and the engine resets all option settings to their defaults in the process. (E.g. if you use Engine Setting to set Elephant Eye's 'randomness' option to 'large', it will revert to 'none' in the next game.) This definitely is not what was intended. Chess UCI engines normally use Polyglot as adapter, which runs with reuse=1, so that the problem is not apparent there. I don't there to run UCCI2WB with reuse=1, because I don't understand it well enough to know what internal variables I have to reset to start a new game. But in any case WB should not do this; there could also be native WB engines, running without an adapter, that request reuse=0.

I am now trying to fix this. Another problem I noticed is that UCCI2WB does not seem to use the isready-readyok handshaking spontaneously. And I never made it respond to the equivalent ping-pong from WB protocol. So I have a version now that does make the ping->isready translation one way, and the readyok->pong translation the other. This can be important in tournaments, where WB probes newly-loaded engines for readiness before starting their clock.

[H.G.Muller]

I uploaded new versions of WinBoard ( http://hgm.nubati.net/WinBoard-4.7.beta.zip ) and UCCI2WB ( http://hgm.nubati.net/ucci2wb.exe ), which fix the reuse=0 problem. (Suspect is that this new ucci2wb.exe is suddenly 72KB, while the one I had at that link before was only 48KB, while I hardly changed anything. But the previous one could have been a wrongly renamed .zip file.)

Now every reload of the same engine will have all current option values sent to the engine immediately, even before WB receives the option features announcing them. (Because it still remembers them from the previous time.)

StartChildProcess (dir=".") UCCI2WB -noini "C:\WinBoard-4.6.2\EleEye\ELEEYE.EXE"
952 >first : xboard
protover 2
1102 <first : UCCI2WB 1.8 by Morning Yellow and H.G.Muller
1102 <first : # to engine : ucci
1102 <first : # from engine: id name ElephantEye 3.1
1102 <first : # from engine: id copyright 2004-2007 http://www.elephantbase.net
1102 <first : # from engine: id author Morning Yellow
1102 <first : # from engine: id user ElephantEye Test Team
1102 <first : # from engine: option usemillisec type check default true
1102 <first : # from engine: option promotion type check default false
1102 <first : feature option="promotion -check 0"
1102 >first : accepted option
...
1112 <first : # from engine: option knowledge type combo var none var small var medium var large default large
1112 <first : feature option="knowledge -combo none /// small /// medium /// *large"
1112 >first : accepted option
1112 <first :
1112 <first : # from engine: option randomness type combo var none var small var medium var large default none
1112 <first : feature option="randomness -combo *none /// small /// medium /// large"
1112 >first : accepted option
1112 <first :
1112 <first : # from engine: option newgame type button
1112 <first : feature option="newgame -button"
1112 >first : accepted option
1112 <first :
1112 <first : # from engine: ucciok
1142 <first : feature myname="ElephantEye 3.1 (UCCI2WB)"
1142 >first : accepted myname
1142 <first :
1142 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1 smp=1
1142 >first : accepted variants
1142 >first : accepted setboard
1142 >first : accepted debug
1142 >first : accepted reuse
1142 >first : accepted memory
1142 >first : accepted smp
1142 <first : feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 ping=1 done=1
1142 >first : accepted usermove
1142 >first : accepted sigint
1142 >first : accepted sigterm
1142 >first : accepted colors
1142 >first : accepted pause
1142 >first : accepted ping
1142 >first : accepted done
1152 >first : memory 68
1152 >first : cores 2
1152 >first : new
random
1152 >first : variant xiangqi
1152 >first : level 40 5 0
1152 >first : post
1152 >first : hard
1152 >first : ping 1
1172 <first : # to engine : setoption hashsize 68
1172 <first : # to engine : setoption newgame
1172 <first : # to engine : isready
1352 <first : # from engine: readyok
1352 <first : pong 1
... Here I used Engine Settings to alter knowledge and randomness
14521 >first : option knowledge=none
14521 >first : option randomness=large
14551 <first : # to engine : setoption knowledge none
14551 <first : # to engine : setoption randomness large
20730 >first : time 30000
20730 >first : otim 30000
20730 >first : usermove 20730 >first : e3e4
21171 <first : # to engine : position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1 moves e3e4
21171 <first : # to engine : go time 299900 movestogo 40
22403 <first : # from engine: info time 1082 nodes 877298
22403 <first : # from engine: info depth 8 score 11 pv h7e7 h0i2 e6e5 i0h0 e5e4 h2e2 e7e2 c0e2 h9g7
22403 <first : 8 11 108 877298 h7e7 h0i2 e6e5 i0h0 e5e4 h2e2 e7e2 c0e2 h9g7
.... Press New Game
50083 >first : quit
StartChildProcess (dir=".") UCCI2WB -noini "C:\WinBoard-4.6.2\EleEye\ELEEYE.EXE"
50753 >first : xboard
protover 2
50753 >first : option promotion=0
50753 >first : option batch=0
50753 >first : option debug=0
50753 >first : option ponder=0
50753 >first : option usebook=1
50753 >first : option bookfiles=C:\WinBoard-4.6.2\EleEye\BOOK.DAT
50753 >first : option evalapi=C:\WinBoard-4.6.2\EleEye\EVALUATE.DLL
50753 >first : option idle=none
50753 >first : option pruning=large
50753 >first : option knowledge=none
50753 >first : option randomness=large
50753 >first : memory 68
50753 >first : cores 2
50753 >first : new
random
50753 >first : variant xiangqi
50753 >first : level 40 5 0
50753 >first : post
50753 >first : hard
50753 >first : ping 2
Impossible move h9g7, type = 0
50894 <first : UCCI2WB 1.8 by Morning Yellow and H.G.Muller
50894 <first : # to engine : ucci
50894 <first : # from engine: id name ElephantEye 3.1
50894 <first : # from engine: id copyright 2004-2007 http://www.elephantbase.net
50894 <first : # from engine: id author Morning Yellow
50894 <first : # from engine: id user ElephantEye Test Team
50894 <first : # from engine: option usemillisec type check default true
50894 <first : # from engine: option promotion type check default false
50894 <first : feature option="promotion -check 0"
50894 >first : accepted option
....
50904 <first : # from engine: option knowledge type combo var none var small var medium var large default large
50904 <first : feature option="knowledge -combo none /// small /// medium /// *large"
50914 >first : accepted option
50914 <first :
50914 <first : # from engine: option randomness type combo var none var small var medium var large default none
50914 <first : feature option="randomness -combo *none /// small /// medium /// large"
50914 >first : accepted option
50914 <first :
50914 <first : # from engine: option newgame type button
50914 <first : feature option="newgame -button"
50914 >first : accepted option
50914 <first :
50914 <first : # from engine: ucciok
50944 <first : feature myname="ElephantEye 3.1 (UCCI2WB)"
50944 >first : accepted myname
50944 <first :
50944 <first : feature variants="xiangqi" setboard=1 debug=1 reuse=0 memory=1 smp=1
50944 >first : accepted variants
50944 >first : accepted setboard
50944 >first : accepted debug
50944 >first : accepted reuse
50944 >first : accepted memory
50944 >first : accepted smp
50944 <first : feature usermove=1 sigint=0 sigterm=0 colors=0 pause=1 ping=1 done=1
50944 >first : accepted usermove
50944 >first : accepted sigint
50944 >first : accepted sigterm
50944 >first : accepted colors
50944 >first : accepted pause
50944 >first : accepted ping
50944 >first : accepted done
50944 <first : # to engine : setoption promotion false
50954 <first : # to engine : setoption batch false
50954 <first : # to engine : setoption debug false
50954 <first : # to engine : setoption ponder false
50954 <first : # to engine : setoption usebook true
50954 <first : # to engine : setoption bookfiles C:\WinBoard-4.6.2\EleEye\BOOK.DAT
50954 <first : # to engine : setoption evalapi C:\WinBoard-4.6.2\EleEye\EVALUATE.DLL
50954 <first : # to engine : setoption idle none
50954 <first : # to engine : setoption pruning large
50954 <first : # to engine : setoption knowledge none
50954 <first : # to engine : setoption randomness large
50954 <first : # to engine : setoption hashsize 68
50954 <first : # to engine : setoption newgame
50954 <first : # to engine : isready
51144 <first : # from engine: readyok
51144 <first : pong 2
52826 >first : time 30000
52826 >first : otim 30000
52826 >first : usermove 52826 >first : h2g2
53207 <first : # to engine : position fen rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w - - 0 1 moves h2g2
53207 <first : # to engine : go time 299900 movestogo 40
...

[cnchang]

Tested XQWizard and captured UCCI spy log as I set engines to use 256/2.

Code: Select all

out: protocol UCCI
in:  ucci
out: id name anita 0.2
out: id copyright 2006 - 2006
out: id author 夷+?-
out: id user Unknown User
out: id birth Jun 15 2006 10:27:00
out: copyprotection OK
out: ucciok
out: option name Hash type spin default 16 min 4 max 1024
out: option name Ponder type check default false
out: option name BookFile type string default book.dat
out: option name NullMove Reduction type spin default 2 min 1 max 3
out: option name History Pruning type check default true
in:  setoption promotion true
in:  setoption usebook true
in:  setoption useegtb true
in:  setoption hashsize 256
in:  setoption threads 2
in:  setoption idle none
in:  setoption randomness small
in:  setoption style normal

As you can see, XQWizard GUI, like BHGUI, just unconditionally forwards users' preferred settings to UCCI enignes.
Before UCCI 3.x or 4.x protocol specifically defines how engines should respond to GUI setoption commands in different situations such as:
1. It doesn't have the option available for GUI as it didn't announce it or implement it.
2. It has the specified option but can't commit to the exact value requested by the GUI.
with the status quo, it is logical to let GUI send user preferred setoption commands unconditionally while engines can try their best to accommodate. Hopefully newer version UCCI and UCI can show users how those options are actually committed and deployed by the engines.

[H.G.Muller]

Well, the way you translated the UCCI 3.0 specs for me it clearly says the GUI preferably should only 'setoption' commands only for options they first received an 'option' announcement for. Which is the recommendation I will follow, because it is the way the protocol is intended to be used, and similar to how it mandatory has to be done in UCI. The 'also allowed' alternative of sending the options blindly I consider highly inferior, not acceptable for WinBoard.

I don't think adding the printing of option announcement at startup should pose an insurmountable problem for any engine author. But if for whatever unfathomable reason they want to shift this burden to the user, it is their choice, and UCCI2WB / UCI2WB now provide the work-around infra-structure (in the form of the ini file) for the user to fully fix the engines' shortcomings.

[cnchang]

Is it really a better alternative to use the DefectiveEngineOptions.ini workaround and to teach users to distinguish between setoption "Hash" and "hashsize" in that custom ini file for each UCCI or UCI engine? All your doing so is based on UCCI 3.0's suggestiion that UCCI engines announced option ought to be used by the setoption commands, but UCCI 3.0 also explicitly makes amend that GUI setoption commands don't have to be limited to those engine announced options. It uses XQWizard as an example for this valid GUI implementation. I used both BHGUI and XQWizard traces to prove the case.

If you still decide only to take the first stated rule and ignore the amend, I would feel sorry as a user because Winboard is less convenient that way.

[H.G.Muller]

The amandmend does not say that GUIs must send options that are not announced. In fact it recommends against it, which is geat, because I think it would be extremely crappy GUI design. My primary goal fo WinBoard is to povide a high-quality product that I can be proud of. Not something of poor design that can conveniently handle as many non-compliant engines as possible. In fact, I consider anything that encourages non-compliance an extremely reproachable and immoral act.

And these engines are non-compliant, notwithstanding the UCCI 3.0 amendment. There is NO amendment that says announcing the options supported by the engine is optional.

[nathanhoover]

This topic is old, but one way to suspend a Winboard tournament is to just close Winboard. I found another nice way to suspend a Winboard tournament, but it's quite technical. You have to go to the tournament file which is most likely in the Winboard installation folder and ends with ".trn". It's just a regular textfile and can be edited with Notepad. Find the line that says "-results". At the end of that string, put a bunch of asterisks * inside the quotation marks making sure to keep any results or spaces as is. It has to be enough asterisks to cover all remaining games. Basically, the asterisk means don't play that game yet. When you want to replay the tournament, just remove the asterisks. You can do this while a game is in progress, just be sure it is not going to finish while you are making the edit. Please note, modifying this file incorrectly can ruin your tournament, so modify with caution.

[H.G.Muller]

The risk is that while you are editing the tourney file, the game that was still going on finishes, and you overwrite the result WinBoard put in the tourney file for it when you save the version you were editing from NotePad.

The recommended way to suspend a tourney without losing the game in progress is to select Machine Match again from the Mode menu to switch it off. The WinBoard instance where you do this will then not start a new game after the current one finishes. (But it will not close automatically, unless you started the match mode from the command line, using the -mm and -mg options.)