HaChu 0.19 in Winboard

[lantonov]

I use the package Winboard-Chu which is bundled Winboard Alien and HaChu 0.15 with corresponding configuration files. It plays well in all variants.
Then I compiled the latest HaChu 0.19 from the HGM sources and replaced HaChu 0.15 with it in the package. It gave the message "Illegal move" on the first move and stopped. This behavior is similar in all variants. I suppose that something in the configuration files should be changed but I don't know what.

Any suggestions, please?

[H.G.Muller]

Ah yes, this is a problem. I am currently in a transition stage, implementin Chu Shogi in the regular version of XBoard (there is no Alien Edition for XBoard). And I decided to change the move notation, to use rank counting 1-12 rather than the 0-11 the WinBoard Alien Edition currently uses (and which really no one liked). HaChu 0.19 is adapted to this new XBoard standard. The plan is to also make a version of the WinBoard Alien Edition that uses it, but I have not done that yet.

The best fix until then is adapt the HaChu source back to the old standard, by changing line 75:

Code: Select all

#define ONE 1 /* currently no variants with 10-deep board */

to

Code: Select all

#define ONE (BH < 10)

and recompile.

[lantonov]

Thanks, HGM, you are really helpful as usual and I will certainly try your suggestion.

I will try also something else. Since I like the new Winboard / xboard (it has some very useful additional features) more than Winboard Alien, I will change the name of WB-alien.ini to winboard.ini and use the newest winboard.exe and HaChu.exe instead of Winboard Alien and HaChu 0.15.

Is this possible?

[lantonov]

I tried first your suggestion with the code change. It works well with the default settings ("Chu Shogi " -fcp hachu /variant=chu; "Dai Shogi " -fcp hachu /variant=dai; "Sho Shogi (Oriental) " -fcp hachu /variant=shogi -holdingsSize 0 -pieceToCharTable "PNBRLSE..G.+++++++Kpnbrlse..g.+++++++k" -size moderate -flipBlack true -allWhite true -blackPieceColor #FFFFCC -lpf sho.fen; "Sho Shogi (Western) " -fcp hachu /variant=shogi -holdingsSize 0 -pieceToCharTable "PNBRLSE..G.+++++++Kpnbrlse..g.+++++++k" -size middling -blackPieceColor #202020 -lpf sho.fen; "Chu (Renmei rules) " -fcp hachu /variant=chu -firstOptions "Promote on entry=1,Allow repeats=1"). However, once I have hieroglyphics for pieces, those appear in all the following variants and I can't change them back to other types of pieces other than replacing WB-alien.ini with the original file in the package. This is perhaps due to the "Save settings on exit". If I use the "New variant ..." from the File menu and then choose dai or tenjiku variants, the engine still plays without error messages but sometimes Winboard Alien crashes.

The second experiment (with the latest Winboard) was partly successful. It worked well for the setting "Chu Shogi " -fcp hachu /variant=chu. It has chesslike + additional pieces which is a board that I like best (more familiar). It doesn't like dai and tenjiku (more than 12 x 12 boards) giving a message in the sense that I must recompile for larger boards.

[H.G.Muller]

Not sure what exactly you mean by hieroglyphics. WB-Alien has built-in rendering for the pieces of the large Shogi variants (Chu and larger), which in some board sizes are geometric forms representing the move, but in most sizes render as Chinese/Japanese kanji. But the pieces used in these variants should not occur in any of the smaller variants. Only for regular / Sho Shogi the 'normal' pieces are used. WB has a built-in set of bitmaps for traditional Shogi pieces at board size moderate. But these should never appear outside variant shogi. Only when external pieces (font-based rendering) would be used for the 'normal' pieces it can also affect other variants.

The latest regular WinBoard does not really support Chu Shogi. The back-end does (because that is shared with XBoard, which now does support Chu), but Chu Shogi needs a great many more piece types than the 22 XBoard had before. So I had to double the number of piece types, mainly to provide pictograms for all the promoted pieces. But WinBoard does not have any built-in bitmaps for these new piece types. So the initial position for Chu Shogi might look OK, but when you would play and promote a piece, there would be trouble.

Dai Shogi and larger are not supported in the regular version of XBoard/WinBoard at all. But the latest Win/XBoard has this feature of 'engine-defined' variants, which makes any variant that an engine reports appear in the New Variant menu, even if it is unknown. But then it expects the engine to send an initial setup etc., which HaChu does not do (except for Sho Shogi, which is neither a standard variant in the regular nor the Alien edition, but just a modification of variant shogi). Apart from the board size being too big, the regular version would also not have enough piece types even for Dai, and even if there were, setting up the position with an external FEN would not work, because the alphabet does not have enough letters to indicate all pieces. So playing Dai as Chu with the board modified to 15x15 will not work. Variants defined in the Alien edition, but not in the regular one, should really be recognized by the regular one, so that they will not be displayed as engine-defined variants.

[lantonov]

Thank you for the very detailed explanation. That the regular Winboard does not support larger boards was expected, so my message is just a statement rather than a bug report.

By hieroglyphics I mean the kanji. Once they appear in some variant, they appear in all variants and board sizes after this. It is impossible to change them in geometric or chesslike pieces short of replacing the WB-alien.ini file. Maybe there is some setting in this file that can be changed back but I couldn't find it by comparing the original and changed files.

[H.G.Muller]

Yes, but what I wanted to pint out is that compiling with a larger board size would not be enough to fix it.

What kind of kanji for you see that stay in other variants? Is it any of the three following (and if so, which?):

[lantonov]

The type of kanji that I see depends on the board size. If I choose the variant "Dai Shogi " -fcp hachu /variant=dai , I get the kanji from the third image (two kanji per square, one on top of the other). The board size is Moderate. Increasing the board size up to Titanic doesn't change the type of kanji. Decreasing the board size down to Middling doesn't change the type of kanji either (two kanji per square, one on top of the other). Size Mediocre changes the kanji to Shogi-type (the second image), however, all the pieces are in one direction (up) so the two sides can't be distinguished. Decreasing further to Small changes the kanji to those from the first image (one kanji per square). Decreasing further to Slim doesn't change the type of kanji (one kanji per square). Decreasing the size to Petite gives geometric shapes. Sizes Dinky and Teeny give again one kanji per square. Size Tiny gives geometric shapes.

It turned out that the board sizes are inherited from the previous game. So I found a way to get rid of the kanji by selecting the size Petite or Tiny and then quitting. If I start again with the default "Chu Shogi " -fcp hachu /variant=chu , I get geometric pieces.

[H.G.Muller]

OK, that is clear, and what you describe is like it is supposed to be. But if I understand you correct, the problem then is that when you switch back to Chess or other western variants, that the pieces continue to be displayed as the kanji in Chu / Dai at that same board size? Even when you quit WinBoard and restart it with the same WB-alien.ini file?

This would be very strange and buggy indeed. The way the large Shogi variants are implemented in WB Alien is that after the first 22 'normal' pieces (for which it has bitmaps) I added some 500 new piece types that (mostly) do not have bitmaps, but are composed on the spot, either by rendering bare kanji (which can be done at any size), or, at some selected sizes, from combining components based on their moves. But the latter should never be done for the 22 'normal' piece types, and never if a bitmap for the piece existed even in other cases.

So this is what makes it very puzzling. The kanji are not alternative representations for normal piece types only used for large Shogi variants, which it could then forget to switch back. They are completely different pieces, that should exist always, but just happen not to be used in normal Chess, etc. (While Chu and Dai do not use any of the 'normal' pieces.)

[lantonov]

You understood very well the problem. After I get kanji in some variant, and then restart Winboard, I can get geometric shapes only in some sizes (Petite and Tiny). The other sizes give some type of kanji and those can't be changed.

[H.G.Muller]

I finally figured this one out. At first I could not reproduce it at all. So I went to the code to look when exactly it would print kanji, and it turned out it tries to print kanji for every piece that does not have a bitmap. So the problem would only manifest itself when I would select a variant that needs unorthodox pieces (as the orthodox pieces are available in any size), and then select a board size where those pieces did not exist. (Which I naturally avoid, knowing what works in which size.) In my case, when I did that, I did nt get any kanji, but WinBoard simply crashed!

I now added code that prevents printing of kanji or composing a geometric shape when the piece-type number is lower than 22, so that missing bitmaps there are simply rendered as an empty square. This should solve the problem. (In any case, it solved the crashes.)

I included a fixed WinBoard binary in the Chu package, bundled with HaChu 0.19. It can be downloaded from:

http://hgm.nubati.net/WinBoard-Chu.zip

[lantonov]

Thank you very much, HGM. Maybe it's partly my fault because I'm tinkering with these variants in ways I should use.

[H.G.Muller]

It is certainly not your fault, and it is in fact very helpful that you uncover these bugs by thorough testing.