Shogi problem in WB 4.5.1

[Tony Hecker]

I remember that when WinBoard interprets a move string from a shogi engine, it assumes promotion by default (if promotion is possible), and to defer promotion, the "=" character must be appended.
But it looks like this behavior changed sometime between WB 4.4.4 and WB 4.5.1.
The following PGN reproduces the issue. If you play this game back in WB 4.5.1, you will see move #10 "b7e4" interpreted as a non-promotion move.

[Event "Computer Chess Game"]
[White "TJshogi"]
[Black "TJshogi"]
[Result "0-1"]
[TimeControl "60"]
[Variant "shogi"]

1. b4 {+0.00/10} b6 {+0.00/9 1.7} 2. c4 {-0.05/11 0.4} b5 {+0.20/10 0.6} 3.
bxb5 {-0.20/11 0.5} Rxb5 {+0.20/9 0.5} 4. Gc2 {-0.20/11 0.9} g6
{+0.20/8 0.8} 5. Bxh8= {-0.20/9 0.5} Sxh8 {+0.25/7 0.4} 6. P@b2
{-0.20/9 0.8} Sg7 {+0.20/6 0.4} 7. g4 {-0.20/9 1.4} B@e6 {+0.40/6 0.6} 8.
Nc3 {-0.40/8 0.3} Rf5 {+0.40/7 0.5} 9. B@b7 {-0.35/9 0.6} Bxc4
{+0.35/7 0.3} 10. b7e4 {-0.35/9 0.3} Re5 {+2.40/7 0.5}
{Xboard: Forfeit due to invalid move: e4e5 (e4e5) res=23} 0-1

[H.G.Muller]

Indeed, it changed. The old behavior was untenable. Virtually no engine was writing a '=' on deferral. And virtually no game in PSN format was either. And it is impossible to figure out if a move without suffix is really a deferral, if you don't keep track of game state. When I programmed the original behavior I was not aware that '=' in practice is never written.

So I changed the parser to consider a '+' suffix an integral part of the move (which the necessarly holds for all variants), losing the ability tohave it recognize the non-compliant game-end messages "++" and "+-+", because it ate the first '+' as part of the move.

So the new rule is that default when parsing written moves is deferral, and promotion needs an explicit '+' sign. Perhaps I did not stretch this change enough, but the protocol requirement has always been that there is a promotion character (be it + or =), and the rule applied just as a "tie breaker" in the non-compliant case where there is none. (Just like when it gives you a Queen when you fail to specify a piece in Chess.)

I have been working on a completely new parser, which can handle variant-dependent syntax, where this problem would go away. I can even read moves in Shogi coordinates automatically, and handle double-digit rank numbers. Only problem I still have with it is in reading traditional Xiangqi (AXF) notation, when the piece idicators are lower-case.

[Tony Hecker]

Ok, thanks. Then I'll update TJshogi to follow the new WinBoard 4.5 shogi protocol. The new syntax is actually simpler for me to implement than the old syntax was, and it is also now consistent with USI.

[H.G.Muller]

Indeed, the fact that USI engines never write the = was the main problem. Because UCI2WB is not game-state aware, it cannot know whether an = should be appended to translate the USI move into a WB move, because that depends on the piece moved, which it didn't know. So the only solution was to suffix all WB moves that touched the promotion zone with =, but WinBoard sometimes relayed such superfluous suffixes to the opponent, which would then choke on it.

I can't recall the version of TJshogi having any problems with it: both it and WB always wrote a promotion suffix.

[Tony Hecker]

I'll test it later but I think the old TJshogi 0.03 (WB version) would have this issue if run under WinBoard 4.5. I wonder if your windows port of Gnu Shogi has this issue?

[Tony Hecker]

I just verified that TJshogi 0.03 WB version cannot run under WinBoard 4.5.1 because of this protocol difference. Possible workarounds are to use TJshogi 0.03 USI version with your adapter, or just use an older WinBoard version. But I will eventually release a new TJshogi WB version that works with the latest WinBoard.