H. G. Muller wrote on Mon, Nov 21, 2016 11:11 AM UTC:
I tried your game definition, and it needed the following fixes:
The first was my bad: the lame Knights did not require 43 move rights, but 70 move rights, because otherwise they would be able to make the W or F step already with full rights (3), and the secondary step would only toggle the termination bit (4) on. But the W or F step should not have any rights (0).
The piece ID of N and B equivalents in the piece lines was made lower case; this makes them seek the center. Otherwise Fairy-Max becomes very tardy developing them. I also did that for the Elvish Queen, as in Capablanca Chess the Archbishop also seemed to be worth more when seeking the center. Not sure if this is also true for the cylinder version, however. Perhaps the short Rook should also be center seeking to let Fairy-Max make better use of it.
I changed the name into orc-elf; it should now appear under that name in WinBoard's New Variant dialog
I appended " # fairy" to the game line to specify 'fairy' as parent variant. This variant implements normal Chess rules w.r.t. promotion, check, stalemate, castling etc., and is thus a good parent for most western Chess variants. Because it is a 'catchall' variant where WinBoard has no prior notion of the initial setup, WinBoard will pay attetion to the engine's setup command even when legality testing is on,which is another advantage.
I appended Betza move definitions to the game definition, which don'tmean anything to Fairy-Max, but are sent to WinBoard at the start of the game, to make WinBoard aware of how the pieces move. This enables WinBoard to highlight target squares in human-engine games, and properly disambiguate the move notation. (It is of course bad design that two independent, and therefore possibly conflicting move descriptions are needed. But the ability of WinBoard to accept piece definitions from the engine is a recent enhancement, and was then added to Fairy-Max as an afterthought. Ideally Fairy-Max would derive one set of move definitions from the other.)
I played a bit with the 'pieceToChar' string in the game line. Each position in this string corresponds to a WinBoard piece glyph, and specifies the piece it has to be used for. The first half of the string is for white pieces, the second half for black. The first five for each color are standard symbols for PNBRQ, the last one for K. In between come upto 17 other piece glyphs built into WinBoard. I selected some of those that seemed applicable. (Masked knight and unicorn for the lame Knights, commonly used pictograms for Archbishop and Chancellor. WinBoard does not have enough rookish or pawnish glyphs, however, so the 'Skip-Rook' is still depicted as an orthodox Rook. Of course it is a matter of taste whether you want all pieces to look different or just use the orthodox images. This whole issue can also be solved purely on the GUI level, by configuring use of (and providing) external images in WinBoard.)
I tried your game definition, and it needed the following fixes:
______________________________________________________________________