Arena

[Evert]

No, this is another undocumented and 'unstable' feature, and will probably remain so until I am sure how to best handle it (i.e. what information exactly to put in it,and when to accept it). Currently the formats supported in WinBoard 4.5.x is

setup <FEN>
setup (<pieceToCharTable>) <FEN>

But the WinBoard Alien edition already supports the additional format

setup (<pieceToCharTable>) <BoardSize> <FEN>

where <BoardSize> is something like 10x8+7 to specify a 10x8 board with holdings for 7 pieces.

Awesome.
That immediately answers another question that occurred to me regarding alternate board sizes. Very good, I'll put this to use.
The only downside is that I'll have to reinstall xboard again (I'd just gone to 4.5.3 from an old alien version).

That opens up a can of works though: there is no way for me to test whether XBoard will accept these commands, right? Would it be an idea if I could send "feature alien" and get either "accepted alien" or "rejected alien" (the latter I would always get, of course)? I can then filter out variants that need to set the board size when running under older versions of xboard.
In fact, maybe you only want to accept "setup" when an engine sends "feature alien" and the current variant is "fairy"?

When the user started from a position setup by himself, the FEN part is ignored. (A bug I corrected only recently is that the pieceToCharTable in that case was also ignored.)

Speaking of which, is that properly documented somewhere? I have a copy of the Spartan-thread from a while back saved for reference.

I am still in doubt if it should also be made possible to transfer info on the rules, e.g. define how the pieces move. It could be useful to allow that, so that any variant can be played with legality-testing on (and give better SAN). But it might be better to create a separate command for that, like

piece <ID> <gait>

where ID is the single-letter code as defined in the pieceToCharTable, and <gait> is a representation of the moves that piece can make, like

piece A {1,1}* {1,2}
piece H {1,0;2,1}
piece P (1,0)m (1,1)c (1,-1)c (1,0;2,0)vm
piece C {1,0}m* {1,0}hc*

I guess it depends on whether the descriptions are sufficiently general. I looked at notation for describing piece moves when I started working on Sjaak and they all gave me a headache, so I ended up just writing my own (with things like "slide H,V" describing a rook and "hop H,V" describing a cannon capture). Of course, I have yet to implement loading game descriptions from an input file...

Note that the Alien edition defines other protocol extensions as well, all designed to allow total control of the GUI by engine. WB protocol was already pretty good at that, e.g. leaving the engine in charge of legality checking through proper use of the Illegal Move error message and result-claim commands. But some features, like marking the target squares of a move, where not possible without the GUI knowing the piece moves. To remedy that, we added commands that inform the engine when a user picks up a piece, puts it down again, or hovers it over a capture square (lift <square>, put <square> and hover <square>), enabling the engine to send highlight <colorFEN> commands to cause highlighting of the indicated squares. Nebiyu is the only engine currently using that.

Interesting. What do I send to request that information?

[hgm]

That opens up a can of works though: there is no way for me to test whether XBoard will accept these commands, right? Would it be an idea if I could send "feature alien" and get either "accepted alien" or "rejected alien" (the latter I would always get, of course)? I can then filter out variants that need to set the board size when running under older versions of xboard.

For board sizes in setup this is not yet possible. The highlighting commands lift, put and hover are controlled by feature highlight=1.

Problem with the setup command is that the acceptance is not just dependent on the GUI version, but also on the settings, which can be changed interactively. E.g. the user might set legality testing on after engine startup. So you cannot control it very well by features. I could let the GUI make a reply rejected setup whenever it refuses the command (due to settings or syntax problems). But versions not supporting setup at all would not send that, of course. So perhaps I should let it send accepted setup in stead. Except that some versions exist that do support setup, but do not send that...

Note that the engine is expected to send setup in reply to the variant command, and that the latter informs the engine of current boardsize (implicitly through the variant name and the known default size for that variant, e.g. 8x8 for fairy, or explicitly through a size prefix, like 13x13+0_fairy). So your engine can know if the GUI is set for the required board size, and only include the board size in the setup when it needed a change. When this then does not work, you would be dead anyway.

In fact, maybe you only want to accept "setup" when an engine sends "feature alien" and the current variant is "fairy"?

In the end we could do something like that, but I prefer to wait until the format of the setupcommand is really stable, to avoid proliferation of features to detect all existing forms.

Speaking of which, is that properly documented somewhere? I have a copy of the Spartan-thread from a while back saved for reference.

Note that some description of the Alien protocol extensions is already at http://hgm.nubati.net/alien.html .

Interesting. What do I send to request that information?

feature highligh=1

This will enable sending of the lift, put and hover commands. In the current implementation, the engine can send the highlight command at any time, though, to apply board markers. (This could be useful in educational engines, that comment on their moves.)

Note that sending feature highlight=1 really obliges the engine to send highlight in response to lift: WinBoard will only accept user moves to a highlighted square (so that legality-checking can already be done in the GUI despite the fact that legaity-testing is off). The hover command is sent when the mouse pointer enters a square where a previous highlight put a red marker, and the markers revert to that setting automatically when the mouse pointer leaves the square again (when a highlight in response to hover had altered them). This is to enable the engine to indicate capture victims, when red markers are used to indicate capture to-squares. (For Chess this would only be meaningful for e.p. captures, but it is instructive and entertaining to try this with NebiyuAlien set for Ultima.)

[Rebel]

I will try something like that with Arena HGM.

But there is a dark side, programmers can cheat with official releases, when behind a pawn (or so) force the next game.

Ouch....

Indeed. So my current policy is to only react on such engine->GUI commands under GUIsettings you would not use for official matches.

Very good

But why make things so complicated? One GUI option (on/off) should suffice. Default setting OFF of course.

[hgm]

True, but WinBoard already have many hundreds of options, so I think it is in the interest of the user to limit further proliferation as much as possible. And 'test legality' seemed a natural choicefor controlling this: the only situation in which you should switch legality testing off is when the pieces move differently from how the GUI thinks they should. this would not occur in variants the GUI knows. So when it is off, apparently you are playing a variant the GUI does not know. And then it is very likely it would not know the opening position either. The original reason for adding setup was to alliviate the user from supplying an external .fen file with the opening position for such unsupported variants.

But I agree it is not entirely satisfactory. Now that the feature exists it would also be natural to use it, for instance, in variant capablanca, so the engine can support a combo option (in the Engine Settings dialog) where the user can select the Capablanca / Carrera / Gothic / Bird / Embassy position as initial position, and the engine the would relay that to the GUI in a setup command. It is a bit sad that you would have to switch off legality checking for that, as the GUI would know all the pieces participating in it.

Nevertheless, adding just another option that people would not expect and know where to find in the menus does not sound like an attractive fix. The fact that there is such a thing as a setup command at all is a technical detail, with which users should not be bothered. So perhaps I should piggy-back this on the 'verify engine claims' option in stead. It is much less disruptive to have to switch that off than legality testing. When the GUI would notify the engine when a setup command was rejected, the engine could then notify the user through a telluser command, and instruct him to switch off claim verification and start a new game.

[Evert]

feature highligh=1

This will enable sending of the lift, put and hover commands. In the current implementation, the engine can send the highlight command at any time, though, to apply board markers. (This could be useful in educational engines, that comment on their moves.)

Note that sending feature highlight=1 really obliges the engine to send highlight in response to lift: WinBoard will only accept user moves to a highlighted square (so that legality-checking can already be done in the GUI despite the fact that legaity-testing is off). The hover command is sent when the mouse pointer enters a square where a previous highlight put a red marker, and the markers revert to that setting automatically when the mouse pointer leaves the square again (when a highlight in response to hover had altered them). This is to enable the engine to indicate capture victims, when red markers are used to indicate capture to-squares. (For Chess this would only be meaningful for e.p. captures, but it is instructive and entertaining to try this with NebiyuAlien set for Ultima.)

Ok, Sjaak now implements this as well (although I'm not quite sure what the use of "hover" is, so it's ignored).

[bob]

Can you in Arena (while playing an eng-eng-match) as an engine force the interface to abort the current game and adjudicate the game in the PGN output with an "*" ?

It would speed-up certain types of tuning, examples:

1. Testing King-Safety, once the ladies left terminate the game;
2. Testing Rook-eval, no rooks on the board terminate the game;
3. etc. etc.

It would also give you automatically the number of games the element you are testing played a role and those that are not which ain't bad information.

Current score needs to fall in a reasonable margin of course as you don't want to "*" a game with a score above 3.xx.

Why would you want to do that? Not count a game when queens come off? Suppose you were winning (or losing) because of queen evaluations BEFORE the queens came off?

The bold.

Makes no sense to me. +1.0 can be winning. +0.5 can be winning. I don't see how you can reasonably exclude a game when queens come off, regardless of the score. Something got you to that point. That "something" might be the eval changes you are measuring. Eventually +.5 can become +5.0 and beyond, if you don't bail out.

Of course a reasonable margin would be 0.25

But even a higher margin would work because in self-play the knife statistically cuts both ways and every randomness is flattened by the volume of games. The goal is to shorten time.

Sorry, but that's nonsense. You don't think you can reach positions where your king safety says +x, and some pawn evaluation says -x, and yet your king safety is wrong, but the overall score is within .25 window?

Randomness won't cover up these kinds of mistakes.... I think the time you save is more than offset by the error this introduces...

[Shaldm]

Good day!

Is it possible that one and the same book at the Arena on different computers show different variations of moves?
And different versions of the Arena (3.0 and 2.5)?

Here a dispute arose:
http://www.chess2u.com/t5179p45-chess2u ... ooks#30843