Holdings size in Xboard 4.7.2 and Atomic Chess

Discussions about the WinBoard protocol. Here you can also report bugs and request new features.

Moderators: hgm, Andres Valverde

Holdings size in Xboard 4.7.2 and Atomic Chess

Postby chessplayer » 18 Sep 2013, 09:41

Hello, consider this game, which I played with holdings size = 5 (like in Crazyhouse).
Please note that you can't load it (it will complain about 3. exd6) but you can make the same moves
Code: Select all
[Event "-"]
[Site "-"]
[Date "-"]
[Round "-"]
[White "-"]
[Black "-"]
[Result "1-0"]
[Variant "atomic"]

1. d4 e5 2. dxe5 d6 3. exd6 Ke7 4. dxe7
{Xboard adjudication: King destroyed} 1-0

By default, you play this variant with holdings size = -1 (no holdings). If you don't use that value, the atomic capturing doesn't happen. Is it expected?
chessplayer
 
Posts: 14
Joined: 14 Sep 2013, 15:13

Re: Holdings size in Xboard 4.7.2 and Atomic Chess

Postby H.G.Muller » 18 Sep 2013, 13:08

Well, I can load the game (by pasting it from the clipboard) when I first set WinBoard to atomic with holdings size 5 (in the New Variant dialog).

I admit that the recognition of non-standard variants from the PGN alone is not yet possible. The Variant tag in the PGN only says "atomic", and there is no indication that it was really atomic + holdings. Part of the problem is that this would need an extension of the PGN standard. Either haddition of Holdings, Width and Height tags, or (perhaps simpler, but more ugly) using prefixes like '8x8+5_atomic'. WinBoard should then be made to write and recognize these prefixes or tags when it saves/loads PGN.

That exd6 is rejected is an entirely different problem, caused by holdings apparently preventing the atomic captures, so that if there are no holdings (as WinBoard deduces from the PGN), there is no Pawn on e5. But even without that problem, you would sooner or later run into illegal moves when you got the board or holdings size wrong. (E.g. dropping a piece would also not work if there are no holdings.

This is also quite annoying to me when I use WinBoard for mini-Shogi (= shogi on 5x5); the games are saved with 'shogi' in the Variant tag, and WB would not recognize the games as mini-Shogi when you load them. So you would always have to configure WB for mini-Shogi first, and only then you can load. It would of course be nicer if it would automatically switch to the right variant (even if it is a modified variant) on loading.

This is not that simple to achieve, though. It is true that the initial position (and even the board format) could be concluded from the FEN tag in the PGN. But to handle the holdings WB must also know which piece types are supposed to go in there. E.g. in mini-Shogi it must know the Knight and Lance are not participating (while in regular Shogi they are), so that when you specify a holdings size of 5, it would know it is for P, B, R, S, G. Otherwise it would reserve places for N and L, which would leave no room for S and G, so that these would be demoted to Pawn on capture. WinBoard uses the -pieceToCharTable option to set which pieces participate, and which pieces promote. But that has a very WinBoard-specific format, and could not be elevated to a standard for in the PGN. (It might not even be compatible with future WB versions!) A more general solution would be to add a Holdings tag to the PGN standard, like
Code: Select all
[Holdings "PNBRQpnbrq"] (for Crazyatomic)
[Holdings "PSGBRpsgbr"] (for mini-Shogi)

which would specify which pieces can be held in hand, and thus imply the size of the holdings. (The FEN tag would already imply the size of the board. A PGN tag would be mandatory on a non-standard board size.)

That atomic captures don't work with holdings, is because the program structure currently used by WinBoard is like

Code: Select all
if(HOLDINGS) DO_THIS; else if(ATOMIC) DO_THAT;

So if there are holdings, it will not even check if the variant is 'atomic'. This cannot be simply solved by leaving out the 'else', as the DO_THAT which now removes the exploding pieces, never considers there might be holdings. It is sort of a mystery what you would want to happen to these pieces anyway. Should they be permanently destroyed? Or should they be considered captured, and go into the hand? Note that they can be of either color. Should they always change sides? Or should they just go back to their own hand (perhaps except the directly captured one)? Or should all (friend or foe) go to the hand of the side making the capture? I would not really know what to do here. But in any case the pieces should be destroyed by the explosion, or it would no longer qualify as 'atomic'. So I definitly will remove the 'else'. The consequence would be that the directly captured piece goes to the hand of its capturer, while all other pieces are permanently destroyed. Which, I guess, is just as arbitrary as any of the other options.
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Holdings size in Xboard 4.7.2 and Atomic Chess

Postby chessplayer » 18 Sep 2013, 14:14

Thank you for the explanation, I understand the underlying problem. I ask every time if it was intended because I don't really know it.
Chess960 is another similar case which shows the complexity of holdings: if you castle, the other player gets a rook in his holdings.
e.g.
Code: Select all
[Event "-"]
[Site "-"]
[Date "-"]
[Round "-"]
[White "-"]
[Black "-"]
[Result "*"]
[Variant "fischerandom"]
[FEN "bnrkrbqn/pppppppp/8/8/8/8/PPPPPPPP/BNRKRBQN[-] w ECec - 0 1"]
[SetUp "1"]

{--------------
b n r k r b q n
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
B N R K R B Q N
white to play
--------------}
1. O-O-O R@d5
*
chessplayer
 
Posts: 14
Joined: 14 Sep 2013, 15:13

Re: Holdings size in Xboard 4.7.2 and Atomic Chess

Postby H.G.Muller » 18 Sep 2013, 18:27

Oops! :(
User avatar
H.G.Muller
 
Posts: 3453
Joined: 16 Nov 2005, 12:02
Location: Diemen, NL

Re: Holdings size in Xboard 4.7.2 and Atomic Chess

Postby chessplayer » 22 Sep 2013, 08:55

I'm not a programmer, but I suggest to avoid to capture your own rook in order to castle. I tried to use the parser to avoid it, but it didn't work.
I think that it will be useful so we can avoid some corner cases in which capturing is not irrelevant (maybe some actual cases and some other future cases), but I'm not a programmer
chessplayer
 
Posts: 14
Joined: 14 Sep 2013, 15:13


Return to WinBoard development and bugfixing

Who is online

Users browsing this forum: No registered users and 17 guests