Winboard Forum

Whenever I use a commandline like the following to have two copies of sjeng 10.0 match each other crazyhouse games on Winboard 4.4.4 alerts of Illegal move ALWAYS occur in the midst of game and force the game to abort. However, when I do the same thing with Winboard 4.2.7 everything works fine without any error.

Code: Select all

start winboard.exe /cp /fcp="sjeng10.exe" /scp="sjeng10.exe" /variant=crazyhouse /mg 2 /tc 1 /inc 0 /debug

I just tried Sjeng 11.2 (I don't have Sjeng 10.0) under WB 4.4.3 and I get illegal move errors too.

My guess is that WB 4.4.x doesn't like the lower case p in the move "p@e4". Seems like the error always occurs on black's first drop move of the game? Apparently Sjeng is using upper case piece char for white and lower case for black in its drop move notation.

Code: Select all

......
97120 <second:  7     151    55   299286  P@e4 h3 Bb4 P@d2
97751 <second: Used time : 118
97751 <second: tellics whisper d7 +1.51 P@e4 h3 Bb4 P@d2 n: 679936 qp: 9% fh: 91% c-x: 25434 r-x: 18686 1-x: 2 egtb: 0 time: 1.18 nps: 578668
97752 <second: Learning score: 151  best: 53  depth:7  hash: 49135A54
97753 <second:
97753 <second: Nodes: 679936 (8.89% qnodes)
97753 <second: NPS: 574755
97753 <second: ECacheProbes : 559138   ECacheHits : 7216   HitRate : 1.290556%
97753 <second: TTStores : 536381 TTProbes : 808591   TTHits : 117174   HitRate : 14.491115%
97753 <second: NTries : 126742  NCuts : 97700  CutRate : 77.085125%  TExt: 2
97753 <second: Check extensions: 25434  Razor drops : 64639  Razor Material : 364988
97754 <second: EGTB Hits: 0  EGTB Probes: 0  Efficiency: 0.0%
97754 <second: Move ordering : 91.409005%
97754 <second: Material score: -100   Eval : -112  White hand: 100  Black hand : 0
97754 <second: Hash : 6884A1C3  HoldHash : 6AB40CE2
97754 <second: move p@e4
machine move 31, castling = 9 2 6 45 2 6
move to parse: p@e4
Disambiguate in:  22(6,-1)-(6,3) = 0 (-)
 22  1 25 23 24 44 43 44 44 25  0 44
 44  0 22 22 26 44 44 22 22 44  0 44
 44  0 44 44 22 24 44 23 44 22  0 44
 44  0 44 44 44 22 44 44 44 44  0 44
 44  0 44 44 44 44 44 44 44 44  0 44
 44  0 44 44  1  2  0  1 44 44  0 44
 44  0  0  0  0 44 44  0  0  0  0 44
 44  0  3 44  2  4 21 44 44  3  1  0
Impossible move _1_1", type = 36
GameEnds(37, Xboard: Forfeit due to invalid move: p@e4 (_1_1) res=36, 4)
97759 >first : result 1-0 {Xboard: Forfeit due to invalid move: p@e4 (_1_1) res=36}
97760 >second: result 1-0 {Xboard: Forfeit due to invalid move: p@e4 (_1_1) res=36}

I also just saw a case where sjeng played "b@g6" but WB did not reject the move. Instead, WB interpreted the move as a regular pawn move "g6" aka "g7g6", rather than dropping a bishop on g6. Of course this lead to an illegal move error later in the game.

Indeed, Sjeng is non-compliant. Pieces indicators should be capitalized. The move parser is pretty tolerant to noise, though, so it just eats away stuff it does not recognize: b@g6 -> @g6 -> g6, and then it sees something it recognizes, so it happily interprets that.

The WinBoard 4.2.7 parser was a bit more tolerant in this respect; because any letter in WB can now both be a piece or a file, I applied the rules for capitalization more strictly. I have contacted the Sjeng maintainers about this a long time ago, and they said they would fix it.

I think the current 4.5.0 beta actually does recognize lower-case drop moves; on drop moves there s not so much danger for ambiguity as with other SAN moves.