When I first do a few moves so that Elephant Eye is out of book, and start a ponder-on game then, it runs like a charm. Elephant Eye even resigned, in the end. (Apparently the opening moves I made for it were not so good! )
I am running a pretty old version of Elephant Eye, though (3.1). So perhaps yours won't have this problem.
Last edited by hgm on Tue Oct 28, 2014 4:30 pm, edited 1 time in total.
Nice to have something able to give HaQiKid some trouble, I certainly cant.
hgm wrote:When I first do a few moves so that Elephant Eye is out of book, and start a ponder-on game then, it runs like a charm. Elephant Eye even resigned, in the end. (Apparently the opening moves I made for it were not so good! )
Is there a way we can have -fUSI and -fUCCI come from separate commands in xboard? Or I suppose I should just make a separate XiangqiXq app, with UCI2WB instead of Polyglot. Otherwise we should probably change "USI" in the load engine dialog to "UXI"
Shame engines quit when they receive the wrong command, otherwise we could just have UCI2WB test the engine for the protocol variant and configure itself.
In WinBoard the checkbox is indeed called "USI/UCCI". The idea of having only one uxiAdapter was that people would not be interested to do all these games. For Xiangqi UCI2WB could be installed in stead of Polyglot as main adapter to handle the UCI Cyclone dialect (and could still do Chess), while the uxiAdapter would be UCCI2WB. Shogi users would configure the uxiAdapter as 'UCI2WB -s', and keep Polyglot for Chess. (UCI2WB can decide after startup whether to use regular UCI or the Cyclone dialect, based on reception of the 'variant xiangqi' command, because it only makes a difference when it starts sending moves. For USI and UCCI it must be told in advance, though, because the first thing it must do is sent 'usi' or 'ucci' in stead of 'uci', when it has no idea yet of what it will be asked to play. The problem is that it is hard to probe what the engine need. You cannot just sent 'uci', get an error message like "sorry, I don't speak UCI" and then try something else until you hit pay dirt (or better yet, "I only speak USI" so that you know at once). The engines just exit immediately when they don't receive what they want. They are not only incompatible with the other protocols, they are intentionally made intolerant of them! Of course UCI2WB could restart them after that, and try another guess, but that is soooo ugly...)
An alternative is that XBoard would be aware of the peculiarities of UCI2WB, rather than considering it an arbitrary command, and splice in the proper flag for the current variant. It is rather unlikely there ever will be USI engines that play Xiangqi or UCCI engines that play Shogi. So you are likely to install them while already in the applicable variant, so you can also tick "Force current variant with this engine". Ticking USI/UCCI then could add a -x flag in Xiangqi and a -s flag in Shogi.
I guess a neat way to do this is make the value of the flag optionally available to the -uxiAdapter command. E.g.
-uxiAdapter {UCI2WB -%proto "%fcp" "%fd"}
where %proto would be assigned a variant-dependent value "x" or "s" just before starting the engine.
Hmm...
I guess it would already work this way (by amazing coincidence). You could define
-uxiAdapter {UCI2WB -%variant "%fcp" "%fd"}
If the engine was installed with the option -variant xiangqi on its engine line the variant would already be set when it starts, and the command would expand to
UCI2WB -xiangqi EleEye.exe ../EleEye
As it happens UCI2WB only looks at the first character after the dash, and sees an 'x', which means UCCI. (This was a totally arbitrary choice; because "cc" was two characters and the flag was only one, I figured 'x' would be a good symbol for cc, without it crossing my mind for a moment that it was also the first letter of Xiangqi!) For Shogi it would see an 's', meaning USI.
Last edited by hgm on Tue Oct 28, 2014 5:12 pm, edited 1 time in total.
What, if with the UXI command, Xboard loads the engine and then exits (whether it needs to or not) repeatedly until it gets some output other then unknown.
Unless it's only UCCI engines that are finicky and quit upon receiving a wrong protocol command. So UCI2WB just tries to run the engine in the order of UCCI, USI, UCI. Gpsfish (shogi) doesn't seem to quit instantly.
[EDIT] Just saw your post, your idea is much better, as always.
Well, it always is a question how far one should go in repairing problems that really ly elsewhere. And you would have to update it every time there originates yet another protocol.
I very much like XBoard to stay "protocol blind". Telling the adapter what variant it will be used for in advance through an optional %variant in its adapter-command option value (which is a specific application of the general method to pass the value of any XBoard option to the adapter anyway) does seem an acceptable practice, however.
Now I should contemplate whether to put in a work-around for Elephant's Eye ponder-in-book bug. (Shelve the move when it moves before its turn, and release it only later, when the turn comes up.) Normally I would not do such things. But Elephant Eye is supposed to be the reference implementation that defines UCCI...
Great !
-uxiAdapter {UCI2WB -%variant "%fcp" "%fd"} works well
In xboard you might want to change the new USI switch in Load Engine Dialog to read UXI or less confusingly USI/UCCI. Not sure what to do about the Cyclone UCI case, but I doubt that will ever be a need in unix anyway.
Yah I can make a separate XboardXq app to do that. Also someone might want XQ to be the main variant on launching.
Since you include ElephantEye in the main winboard package, I might as well too.
I put all the variant engines pre-installed in xboard under the sublist "variant engines" so as not to be obtrusive anyway. So all it will add is a few hundred k to the download.
Note that XQ UCI engines are pretty rare (if you discount all those renamed hacked Cyclone versions). You can always install them by mentioning UCI2WB explicitly, rather than using the -fUSI / -fUCCI / -fUCI arguments. In the WinBoard package I pre-install Cyclone with the engine line
UCI2WB cyclone.exe ..\Cyclone
When people install it in the mentioned directory it will then automatically run (and if not, they should be smart enough to see what they would have to change when they edit the engine list). Then Chess engines can continue to use Polyglot through the UCI checkbox.
)