So the recommended implementation is:
* With explicit size prefix in the variant name, use the specified size, so that the user can set it for both engines at once in the New Variant menu.
* Without size prefix to the variant name, use the engine default, possibly set through a -combo engine option.
This is what I wanted to hear Now it works perfectly as I wanted it. I didn't even need to touch the variants menu anymore.
Just changing the first engine's variant only also works perfect!
I was under the impression that I should setup the default 8x8 board for 'variant checkers' . But it just meant any checkers variant, so I now skip this all in all and change the variant only when I get it with dimension!
Please put this recommended implementation in writing at your webiste so that others will avoid going to the same trouble.
I would also like to add that, for multiple variant cases with the same board size, both engine's variant should be set the same in the combos. In the previous case with only 10x10+0_checkers variant it was easy because I had only one 10x10 variant. But if I added another 10x10 checkers variant f.i Ghanian draughts , there would be a confusion of which to pick because winboard can not specifically tell the second engine which variant to play. The same situation happens also with the alien variant in case only the first engine's option is modified. So I would say it is safer to set both engine's to the same variant.
Edit:
In case only the first engines variant is modified from the combo's, and the second changed its variant by the variant message it got from winboard, then the second's engine's variant combo will not be in sync with what it has internally. I think winboard keeps contents of its options dialog box somewhere , if I remember my old MFC windows programming correctly. It displays those at startup not what the engine internally has. This is only cosmotics and causes no problem at all.
It would be good if the engine can initialize those values at startup but I am not sure if it will be worth the trouble though.
I'm not sure where this would best fit in the discussion, so I'll just throw it in here.
When defining chess variants in Sjaak (or however it's going to be called on public release), I define the pieces and rules for a variant when I get a "variant xxx" command. That includes setting the relative piece values and overriding any evaluation terms I might want to override.
It would be neat if that could be done through XBoard. Here's the problem: I only have the option to tell XBoard about options I know about when I send "feature blablabla" in response to "protover", but at that point I don't know yet what options are going to be available.
Of course, I can work around that easily enough by collecting all options for all variants I know about and report all of those at once. That feels like a bit of a hack though and it's probably not the best way to do this. The problem, of course, is that the protocol was never designed with this in mind.
So here's my question/suggestion: would it be possible to extend the protocol in such a way that after a variant is selected, the engine is asked whether there are any new options that it would like to report?
An unrelated question, having to do with the problems I was having playing Burmese Chess as variant Seirawan (namely, XBoard only seems to accept the first two drops): can I simply tell XBoard that I want to play "8x8+6 alien"?
Final question: what does XBoard do if my engine says it supports "variant foo"? Can I tell it to let me play foo against my engine, even if it doesn't know about foo?
We already defined an option of type -reset in the protocol, which is a button that, when used, tells XBoard it will invalidate the setting of all options, and indeed the existence of the options itself. The engine is supposed to react to this by resending all its option-feature commands, so that XBoard will know the new settings. (Note that XBoard in fact is always sensitive to incoming feature commands, and later features simply overwrite earlier ones. E.g. you could initially send setboard=1, change your mind after a few games, and send setboard=0, after which XBoard would start using the edit command on your engine to set up positions. feature option is special, though, because they do not overwrite, but accumulate. No attempt is made to remove duplicats, though.) This seems usable for the purpose you want. You could make the engine define an option
feature option="Options for variant -combo CURRENTVARIANT"
as a kludge to get a read-only display of the variant name in the engine-settings dialog, and define
feature option="Current Variant -reset"
to create a button with which the user can refresh the option menu. Pressing the button would make WinBoard clear all the options and their settings for that engine, and send
option Current Variant
The engine should then send a new set of feature commands to redefine the options, possibly dependent on the variant it is set to.
Problem is that XBoard does not implement this yet. It should not be very hard to implement it, though.
This is a bit kludgey; originally the -reset option type was designed to switch the aready existing options back to their engine defaults, which (as XBoard cannot know these) requires sending of all values. But to not need new protocol commands for just sending values, I decided to use the already existing option-feature command for that. And just clearing the list, and rebuilding it from scratch is easier than figuring out to which existing option a new value belongs. And it does offer these extra possibilities of completely redefining the list of options. (Like having an "Advanced" button that suddenly shows you many more, or dividing up the options over several "pages", and have a -reset button to call up each page, etc.)
Perhaps a valuable addition to the protocol could be to extend the meaning of
feature done=0
to completely clear the list of options, after which the engine could send a new list of option features. This way the initiative could be taken by the engine at any time to redefine its options. For instance after every variant command it receives.
WinBoard refuses variant names it does not recognize.
The version I uploaded now implements feature done=0 as clearing the option list. So you can use it any time when the engine wants to redefine its settings dialog by sending new option features. Do not forget to send feature done=1 afterwards!
The dialog is not automatically updated when you have it open! Using a stale dialog to change options that no longer exist leads to undifined effects, which might include crashing WB! I guess to make this safe, I would have to pop down or refresh the settings dialog, and I still have to figure out how to do that.
For the time being the WB beta also uses codepage 1528 (Vietnamese). This might make translations look funny (?). English should be OK, as this code page contains normal ASCII just as the one normally used, and untranslated WB uses nothing else.
Now it works perfectly as I wanted it. I didn't even need to touch the variants menu anymore.
