Conserving volatile options in your ini file
Posted: 24 Feb 2010, 11:15WinBoard does not save all its settings in the winboard.ini file. For instance, the engine names and directories, if the engine has its own book or not, the /ics option and server name, time odds factors and many more are all considered 'volatile' options. It is considered too unlikely that you will need the same setting for those options next time. They are therefor not saved, so that next tme they start at the 'factory setting' for the corresponding option, which is likely more useful to you.
Sometimes this is inconvenient. You can add volatile options to the winboard.ini file with a text editor, and this will make them take effect when you start up WinBoard. But on the first occasion that WinBoard saves settings, the ini file is overwritten, making the options disappear from it. This can be prevented to some extent by setting /saveSettingsOnExit=false, but then you are still sensitive to the user selecting "Save Settings Now" in the Options menu, and none of your other settings will be saved either.
But there are alternative ways to protect your ini file from being overwritten. When WinBoard encounters the option /settingsFile="..." (shorthand /ini="..."), it will not only read all options in the mentioned settings file, but it will also remember its name as the place to write for saving the settings. So by specifying another ini file that way in winboard.ini, you effectively protect the winboard.ini file from being overwritten. And the options will still be saved and read back, but from that other ini file. So in winboard.ini you can then write any option you like, volatile or not: it will remain there forever!
The easiest way to set this up is as follows:
1) Rename your existing winboard.ini file to "second.ini".
2) Create a new winboard.ini file with a text editor, in the same folder as the orginal winboard.ini, containing only one line:
/settingsFile="second.ini"
This is enough to make WinBoard use the file second.ini for reading and saving the settings. The user will not notice anything of this, everything will work exactly as before. But now you can do a few things you could not do before, by further editing of the winboard.ini file.
1) You can safely add volatile options there.
E.g. if you always want the engines to play with the GUI book in stead of their own book, you could add the lines
/firstXBook
/secondXBook
This effectively inverts the factory defaults for these volatile options. You could still countermand them with options written on the command line, or given in the startup dialog as "Additional options", e.g. /secondHasOwnBookUCI=true if you want the second engine to use its own book, like otherwise you would have had to do /secondHasOwnBookUCI=false to let it use the GUI book.
It does not matter if you specify these volatile options in the winboard.ini before or after the /settingsFile option: the other settingsfile will usually not contain volatile options anyway.
2) You can specify persistent options after the /settingsFile option.
In that case they would overrule the setting specified for them in the settings file. When WinBoard encounters the same option twice, the one encoutered last prevails. So specifying persistent options before the /settingsFile option will have no effect: the option will almost certainly occur in the specified settings file as well, and that one will prevail.
The consequence of that is that you effectively turn a persistent option into a volatile one with a chosen default setting. E.g. if you want WinBoard always to pop up with /boardSize=middling, no matter what size it had when you last closed it, your winboard.ini file would have to consist of the two lines:
/settingsFile="second.ini"
/boardSize=middling
Sometimes this is inconvenient. You can add volatile options to the winboard.ini file with a text editor, and this will make them take effect when you start up WinBoard. But on the first occasion that WinBoard saves settings, the ini file is overwritten, making the options disappear from it. This can be prevented to some extent by setting /saveSettingsOnExit=false, but then you are still sensitive to the user selecting "Save Settings Now" in the Options menu, and none of your other settings will be saved either.
But there are alternative ways to protect your ini file from being overwritten. When WinBoard encounters the option /settingsFile="..." (shorthand /ini="..."), it will not only read all options in the mentioned settings file, but it will also remember its name as the place to write for saving the settings. So by specifying another ini file that way in winboard.ini, you effectively protect the winboard.ini file from being overwritten. And the options will still be saved and read back, but from that other ini file. So in winboard.ini you can then write any option you like, volatile or not: it will remain there forever!
The easiest way to set this up is as follows:
1) Rename your existing winboard.ini file to "second.ini".
2) Create a new winboard.ini file with a text editor, in the same folder as the orginal winboard.ini, containing only one line:
/settingsFile="second.ini"
This is enough to make WinBoard use the file second.ini for reading and saving the settings. The user will not notice anything of this, everything will work exactly as before. But now you can do a few things you could not do before, by further editing of the winboard.ini file.
1) You can safely add volatile options there.
E.g. if you always want the engines to play with the GUI book in stead of their own book, you could add the lines
/firstXBook
/secondXBook
This effectively inverts the factory defaults for these volatile options. You could still countermand them with options written on the command line, or given in the startup dialog as "Additional options", e.g. /secondHasOwnBookUCI=true if you want the second engine to use its own book, like otherwise you would have had to do /secondHasOwnBookUCI=false to let it use the GUI book.
It does not matter if you specify these volatile options in the winboard.ini before or after the /settingsFile option: the other settingsfile will usually not contain volatile options anyway.
2) You can specify persistent options after the /settingsFile option.
In that case they would overrule the setting specified for them in the settings file. When WinBoard encounters the same option twice, the one encoutered last prevails. So specifying persistent options before the /settingsFile option will have no effect: the option will almost certainly occur in the specified settings file as well, and that one will prevail.
The consequence of that is that you effectively turn a persistent option into a volatile one with a chosen default setting. E.g. if you want WinBoard always to pop up with /boardSize=middling, no matter what size it had when you last closed it, your winboard.ini file would have to consist of the two lines:
/settingsFile="second.ini"
/boardSize=middling