Time Control

[tvt2020]

how do I save the "Time Control - Fixed time per move" on exit.

[H.G.Muller]

Apparently you can't. WinBoard considers this an uncommon time control, (I must admit many engines will use time very inefficiently with it, if they do support it at all), and thus too unlikely that anyone would want to use it in the next session, even when it is in use in the current session. Hence /searchTime is defined as a volatile option, that reverts to the default setting.

If you want to use this mode often, and always with the same time per move, (say half a minute), you could make a shortcut for starting up WinBoard with the option /searchTime=0:30 next to everything else you want to set. But that does not help much if you often want to change time. (But of course then saving it would also be less useful.)

[tvt2020]

The shortcut setting works for me. Thank you

[tvt2020]

HMG,
you are righ the SearchTime function is a a volatile one, sometimes it works but often Winboard-Xiangqqi would freeze and crash. To make this work, Winboard could keeps track of time and issue a MoveNow command when time is up. Just a suggestion. Thanks

[H.G.Muller]

Well, WinBoard does keep track of the time (at least the development version 4.2010.... also does in /st mode), so an option could be added to WinBoard for doing as you say. But the problem is that not every engine supports the move-now command, and the engines that fail to check the clock to see if they are going to forfeit on time will almost certainly also fail to check for input during the search, and thus simply ignore the move-now command until it is too late.

For the UCCI Xiangqi engines it is even worse. They are a buggy and non-compliant bunch, and even forfeit on time quite often in X moves / Y min mode. Mostly because their programmers only test them at incremental TC, which is the TC used in the UCCI-league competition. (Some of them even always play 15min + 1 sec/move, no matter what TC you send them from the GUI.) These engines play through an adapter, and the adapter would have to implement the WB move-now command by sending the engine a UCCI stop command. But there is no way to predict when engines will react to that.

I must admit that none of my own engines implements 'move now'.