WinBoard-AA beta release

[hgm]

When an engine is loaded, it will be automatically switched to the variant WinBoard is currently set for. You can force WinBoard to change to Crazyhouse when loading an engine even if it was not yet set for it by also putting -variant crazyhouse on the engine line.

[styx]

Uuuh HGM I think I know what it is! The problems occurs when I load the engine from the quick menu (last four engines used) instead of "load new first chess program"

When you load the engine from the quick menu, saving engine settings by using "make persistent" is impossible (error: "saving failed: engine not from list" ) - at least after you hit "new game"

Here is the debug log (*edit* too much text):

https://www.dropbox.com/s/olduabl0fpobq ... debug?dl=0

I don't know where to find the UCI2Wb debug log

[Carlos777]

When an engine is loaded, it will be automatically switched to the variant WinBoard is currently set for. You can force WinBoard to change to Crazyhouse when loading an engine even if it was not yet set for it by also putting -variant crazyhouse on the engine line.

Right now, I am running a gauntlet for SF 010117.

Firstly, I open WB AA plus a zh engine like CrazyWa with "-variant crazyhouse", then I create the tournament and run it. I do the same to have another instance of WB running at the same time. It has worked fine the 2 first games, then it seems SF forgot that is playing zh after the second game and plays illegal moves.

The question is, could I set -variant crazyhouse for an UCI engine?

[Carlos777]

I tried SF with -variant crazyhouse and the gauntlet is running fine so far.

[hgm]

I uploaded an update of the WinBoard-AA package. Improvements are:

New winboard.exe:
* Fixes the problem that in Crazyhouse ICS mode white pawns would be cloned rather than moved (i.e. they would stay on the from-square as well as appear on the to-square, when moved).

New UCI2WB.exe:
* Suppresses duplicat and lower-depth PVs that are sent in UCI multi-PV, which caused excessive clearing of the WinBoard Engine Output window.
* Guesses which UCI string options are -file or -path options (to give them browse buttons).
* Fixes CECP handling of Gaviota tablebases (which use UCI option GaviotaTbPath rather than GaviotaPath).

[styx]

Thank you for the fixes and improvements

However now xboard fails to load the personality files of Rodent. I don't know why. I worked in the previous version at least via "new first engine" menu.

Funny things is, that other -firstOptions entries do work (like Stockfish's "Skill Level" or even Rodents "Own Book". There only seems to be a problem with the Personalities-String.

I made a short video:

https://youtu.be/p9RORCQxZd4

And here is the corresponding xboard log:

https://www.dropbox.com/s/olduabl0fpobq ... debug?dl=0

[hgm]

Well, something is wrong, for sure. But I get the suspicion that it is actually XBoard lying about the engine settings. The video shows the engine list with Rodent having a -firstOptions that sets the personality to 'amy.txt'. And then when you load Rodent as first engine, and show its settings, it says 'rodent.txt' (the default). But when I look at the debug log I see that the option command for 'amy' does get sent, and that the engine does acknowledge it has read it. You did not try how long Rodent would think, but my guess is it would have played fast at this point. Instead you continue using the settings dialog to change the personality to 'amy' by hand (which is also acknowledged by the engine).

So what is wrong is that altering the engine settings with the aid of -firstOptions fails to alter XBoard's idea of what the settings are. It only goes to the engine. Note that what XBoard shows when you open the Engine Settings dialog is what XBoard remembers. There is no way to interrogate a UCI engine for what its current settings are. The engine tells the defaults at startup, but after that the GUI has to keep track of how it altered them to know the current status. Apparently XBoard does this wrong. Which can cause trouble, because when OK'ing the Engine Settings dialog, it only sends the settings it thinks were changed. So if it thinks it is at 'rodent.txt' while in fact a -firstOptions set it to 'amy.txt', it would not be possible to change it back to 'rodent.txt' through the dialog.

But at least I know what to fix now.

[Ferdy]

Load Shokidoki as 1st engine, Lima as 2nd engine, press analyze twice and only Shokidoki run, with following box.



This is Lima's feature.

Code: Select all

xboard

feature done=0
protover
feature ping=1 time=1 setboard=1 name=1 colors=1 debug=1, nps=0
feature draw=0 sigint=0 sigterm=0 reuse=1 analyze=1 ics=1
feature variants="shogi,mini,5x5+5_shogi"
feature myname="Lima v2-00 64bit POPCNT"
feature memory=1
feature option="UseBook -check 1"
feature option="BookLearning -check 0"
feature option="Ponder -check 1"
feature option="Resign -check 1"
feature option="NullMove -check 1"
feature option="MaterialEvalFactor -spin 100 0 1000"
feature option="MultiPV -spin 1 1 250"
feature exclude=1
feature done=1

What Lima did something wrong here?

I am using WB 4.9.161222 and mini.ini file from mini shogi package.

[hgm]

However now xboard fails to load the personality files of Rodent. I don't know why. I worked in the previous version at least via "new first engine" menu.

OK, I think the latest commit in hgm.nubati.net v4.9.x branch should have fixed this.

There were actually two bugs:
* When a -firstOptions caused changing of an engine option from the default on first loading of the engine, the 'current setting' of that option as remembered by XBoard was not updated for -file and -path option types. This caused 'Rodent.txt' to remain in the Engine Settings dialog,while in fact it was correctly changed. Now it handles -file and -path the same as -string, in this respect.

* The 'default setting' remembered by XBoard (to decide which settings need to be added as a -firstOptions to the engine line when you press MakePersistent) was taken AFTER a previous -firstOptions had already been processed. This could lead to erroneous omission (disappearance) of altered settings in the -firstOptions made by a later Make Persistent. Now XBoard copies the default settings before processing the -firstOptions.

[styx]

Yeah! Everything is fine now. Thank you very much. You're lightning fast at debugging