Beware! It is Polyglot that creates the ini files in _PG. You should never do it yourself. In what I wrote before I assumed Polyglot would have created such a file there due to your earlier attempts to load Vitruvius. But the exact name might not be Vitruvius.ini, because Polyglot derives it from the name the engine reports for itself (in the 'id name' response). And I don't know how exactly Vitruvius calls itself; it could use a version number in the 'id name', or whatever. If the name does not correspond to the filename Polyglot would use for this version of Vitruvius, it would also not consult the file when you load Vitruvius, so any settings you would alter in there (like LogFile) would not be seen.
However, since you said that after adding Log = true in the file you got an error message "the log file could not be read or created", it must somehow have seen what you did in the file.
Btw, if the Polyglot log gives problems, you could also try to run Vitruvius through UCI2WB in stead of Polyglot. UCI2WB should be included in the WB install. To do that, you would have to specify (in the Load Engine dialog)
as .exe:
UCI2WB
as 'engine parameters:
debug Vitruvius.exe ../Vitruvius
(or whatever file and folder you have for Vitruvius). This should produce in the engine list something like:
"UCI2WB" -fcp "UCI2WB debug Vitruvius.exe ../Vitruvius"
(So you would NOT have to tick UCI, as UCI2WB is a WB engine, and WB does not know that it gets its moves from Vitruvius) Because of the 'debug' parameter UCI2WB would send debug info to WB. If you run WB with the Additional option -debug (or press Ctrl+Alt+F12 before Loading Vitruvius), all this debug info would end up in the winboard.debug file. (Which you could then post here.)
Kyodai wrote:I also study your "conserving volatile options in your ini file",
from Winboard Forum very carefully. This is excellent stuff! Thanks!
Note that the standard install of WB already uses this 'two-level' trick, and that the winboard.ini in your WinBoard folder is a master ini file, which redirects the actual saving of settings to the user-dependent file %APPDATA%\winboard.ini (i.e. in your private AppData folder). So if you want to persistently alter the default of a volatile option, you could write it at the end of this master winboard.ini file (after the /settingsFile line, which causes reading of your saved settings). Anything you would write in the master ini file before that line will essentially not be noticed (only on first time use, when you don't have a user ini file yet).
In WB X7 it was needed to put an engine.ini file in the same directory
as polyglot.exe
Well, this was actually never really
needed. Polyglot has always been able to use ini files of any name, provided that you told it what that name was. polyglot.ini in the current directory was only the default, which it took if you did not specify anything else. So even in Winboard_x it was perfectly possible to install an engine as
'Fruit 2.1' -fcp "polyglot.exe _PG/fruit.ini"
where polyglot.exe would be in the WinBoard folder (so that you only needed one copy of it, and no need to specify an -fd), and all your ini files would in _PG.
But modern Polyglots ae even smarter. They don't even need an ini file name on heir command line, but just the name of the engine (like polyglot -noini -ec ../Fruit/fruit.exe). They then run Fruit with the specified command, and
create a polyglot.ini file for it. Which you can then alter through WinBoard's Engine Settings dialog. (If you press the "Polyglot Save" button there.)
