Comments/Ratings for a Single Item

Except for the promotions to Buddhist Spirit / Teaching King because of 'contageon' in Maka Dai Dai Shogi

XBoard supports Maka Dai Dai with its 19x19 board and 50 piece types?  Holy crap!

Fairy-Max not supporting under-promotion, and only allowing promotion to the army's own superpiece, this problem so far did not occur in CwDA. I still have the feeling that this promotion to opponent piece types is an ugly solution to a non-existent problem, as the armies that supposedly would be disadvantaged by promotion to own pieces are already overly strong without that.

Yeah, I'm not sure this rule really needed to be this way.  The Nutters are the ones most likely to promote to another piece since their pieces can't move backwards quickly and so a promoted piece is stuck, greatly reducing the value of promotion.  But that army also seems to be over-powered and it is not obvious how to weaken it.  Preventing promotion to a piece from the other army might be a good way to go, but that would be a change to the game and not just a change to the army.

Any guess when you think you'll have your new cwda engine ready for testing?

XBoard supports Maka Dai Dai with its 19x19 board and 50 piece types?  Holy crap!

Well, it depends on what is meant by 'support'. Problem is that 50 is just the number of unpromoted piece types, and that there also are a lot of promoted types (although many promote to Gold, and some not at all). The standard edition of XBoard comes with SVG images for 66 piece types, and falls just short of the mark. In the development version I have increased the number of piece types, but not the number of supplied SVG images. The additional piece types thus can only be used when external piece images are supplied by the user. (WinBoard already used that strategy for a long time, as it has fewer than 66 built-in bitmaps.) The idea was that only Shogi variants have such a large number of pieces, and that people that want to play those would want to use traditional kanji pieces rather than XBoard's default pictograms, and thus would have to supply external piece images anyway. And I added special support for kanji pieces, through a general -inscriptions option, which can define an arbitrary UTF-8 string, the characters (or pairs of characters) of which will be printed on top of the corresponding pieces (upside-down for black). So all that has to be supplied is 5 or 6 SVG images of blank Shogi tiles in various sizes, and with the aid of those XBoard can be configured for any Shogi variant.

fig 1 - XBoard using kanji-inscribed Shogi-tile images.

The piece IDs and the way the pieces promote would come from the -pieceToCharTable option, or the 'setup' command received from the engine, and likewise the initial position (and board size) from the -fen option, a PGN tag, or the 'setup' command. And the way the pieces move would come from the -men option, a PGN "VariantMen" tag or the 'piece' commands received from the engine.

I must admit I did not really try that for Maka Dai Dai Shogi; just for my own shrunken (13x13) version of it, Macadamia Shogi. Which can be done with the default pictogram pieces, already in XBoard 4.9.

For WinBoard there is the 'Alien Edition'; this really does have Maka Dai Dai Shogi as a standard variant, and contains built-in kanji and move tables for all variants up to Tai Shogi, and in two of the 18 board sizes generates mnemonic piece images from the move table. This doesn't support the dressed-letter IDs, though, so FENs do not work there.

fig 2 - part of the board of the WinBoard Alien Edition set for 'variant maka' (board size 'Petite').

fig 3 - The WinBoard Alien Edition configured for Macadamia Shogi (board size 'Mediocre').

Good news.  I think I have ChessV working as a stand-alone CECP engine now.  I've played a few variants with it under Winboard and it seems to be working pretty well.  There's a little more that could be done but all the core functionality is there.

I haven't messed with programming Quadrox for CwDA yet but ChessV is ready when Kingslayer is (although I have not programmed understanding of all the endgames you've categorized yet...)  I've also been putting a lot of work into increasing its strength.  I have been playing 1600 game matches against FairyMax, Capablanca and variants, and it is now testing 106 ELO stronger than FairyMax.  I haven't tested recently, but it is probably still a good 150 ELO weaker than Joker80.

That's indeed great news! I haven't been able to do any further work on KingSlayer yet; this entire weekend I spent at the semi-annual tournament of the Dutch Computer Chess Association where my engine Spartacus scored 0 out of 7...). Now that most of the end-games have been solved, I am ready to progress with that. 'Army picking' is an issue that I have no clear idea on how exactly to implement, though. Of course I want the engine to be able to do games between all the standard armies, controlled by the CECP name of the (sub-)variant (like cwda~nutters~fide).

But I want it to be able to do more than that, because my main reason for converting KingSlayer was to be able to improve the accuracy of piece-value measurements over what Fairy-Max was capable of, by taking into account pair bonuses and mating potential in the eval, and providing a generally better level of play (to be exploited by being able to do more games of the same quality in the same time). For this reason I want to embed pieces in armies to which they do not belong, so that they are part of the only imbalance in otherwise symmetric setups. This requires 5 piece types per player (plus Pawns plus King), which should not be a major problem, since the internal piece encoding uses 3 bits for piece type (while white and black pieces are independently specified), code 0 being reserved for empty squares.

So I would need some manner to specify 5 pieces for each side, taken from the total collection of all supported pieces, independently. This would not be so much of a problem for properties of a single piece, (such as value, mating potential or color binding) which could just be copied from a table. But it is more problematic to get properties concerning multiple pieces, such as the winning prospects of 5-men end-games. If armies can be arbitrarily composed there would be 16000 of those (for 5 armies), most of which I have not calculated yet because they would consist of unnatural or impossible combination. And I want to be able to test pieces not in any of these armies as well (such as R3, RF).

Perhaps the best method would be to program a heuristic for determining the winning-prospects based on the individual properties of the participating pieces (piece value, mating potential, color binding) that roughly captures the general trends that were revealed by the EGT generation I did so far, and then supplement that with a list of exceptions located in an external file. To be fully accurate it would be enough to only have the exceptions in that file that can occur with the piece sets currently in use (which, for unconventional combinations, could be calculated by EGT generation for the purpose, if not yet available).

Perhaps I should define a general variant 'cwda', which would be entirely configurable through an external file, the latter containing the info which of the programmed pieces occur in either army, and under which single-letter ID. Where piece number 1-20 are those of the 5 standard armies, (hard-coded in KingSlayer) and 21-26 would be configurable through the same file (as any combination of possibly divergent finite-range slides).

You are taking on a couple of difficult problems ...

Being able to mix-and-match pieces is obviously difficult and the CECP isn't really suitable for this.  External configuration with a text file is probably what is required.  It wouldn't need to be all that sophisticated if your configurablity is limited to adding new piece types.  ChessV does offer a simple scripting language that will let you accomplish this.  What it supports is hit-and-miss but just adding new (basic) piece types is no problem.  Your ski-jump move is not presently supported however.  I need to add that anyway for the Grand Accetrix Griffin, but it won't make this next release.  It has been almost a year and a half since I've put out a new version and I have added so much new stuff since then that I just need to wrap up and get it out.

Knowing when to end a game due to insufficient mating material and when to return a zero evaluation is also obviously tricky.  The currently released ChessV 2.1 doesn't do anything about this at all.  IIRC, you can be down to two kings and it'll happily wander around until the 50-move rule is triggered.  The new version is somewhat better.  It knows about endings with standard chess pieces, and even includes customized evaluation for a few combinations (KRKP, KRKB, and KRKN), plus a "mop-up" evalution for lone king vs. rook or more.  But throw in any non-standard pieces and it goes back to not making any decisions... King + Camel vs. King and you are back to wandering around for 50 moves with it stupidly thinking the side with the Camel is ahead (although it is smart enough to know that if the other side has a pawn then the side without and less than a rook's worth of material should be scaled down massively.)  I would like to program in more smarts here, too, especially in light of all your work to quantify these endings.  I now have a material hashtable so it could be done without worrying about computational cost, but probably won't get to too much of this for this version.  Looking for low-hanging-fruit, like a simple piece property that says "this piece can't mate without help."  It would be really, really awesome to make it smart enough that, when a game starts, even if it is a user-define game through an include file, it does enough endgame table generation to make some basic decisions about this stuff, but that is probably a long way off.

It would be really, really awesome to make it smart enough that, when a game starts, even if it is a user-define game through an include file, it does enough endgame table generation to make some basic decisions about this stuff, but that is probably a long way off.

I think Sjaak II makes an attempt at that. Of course there are some cases where this is obvious, such as not attacking any orthogonally adjacent squares. Beyond that heuristics quickly get as complicated as a single iteration of EGT generation, meaning that code-wise there is litlle to gain, and you might as well put the loop around it to do the full generation, if you can afford it timewise. Without full generation you would probably never see that a Silver General has no mating potential, or that the forced mate with  a 'Turtle' (fhNfAbF) is almost entirely cursed because it takes on average 100 moves.

This is not out of the question; even the JavaScript generator in the checkmating applet typically needs under 100 msec to solve a 3-men 8x8 ending. And you could have the engine maintain a file where it 'caches' the conclusions from such EGT generation on disk. It could consult that file whenever a new variant is selected (or even just at the start of every game), to see if it contains data on all of the participating pieces, and if not, generate the EGT and add the data. With such a design it could even be acceptable to generate all 4-men of the participating pieces, to know what in general draws what, and which pairs of minors can checkmate. It only means that first time you use a newly defined variant it takes a few minutes to start.

A nasty aspect of EGT generation is that you don't just need the normal moves of the piece, but also the retrograde moves. For point-symmetric leapers and sliders these are the same, and even for asymmetric pieces you can just use the flipped version of the piece for the retrograde moves. But for bent sliders the moves are fundamentally different, and would need a separate provision in the move generator.

I now managed to have KingSlayer play some CwDA games against Fairy-Max, which it eventually could do without illegal-move complaints (and even win some). This is just the basics (move generator and check test); the material table is not implemented yet. The non-standard a-side castling of the Clobberers works, though. No bent or ski-sliders yet, so also no Dragons Army.

This already touched on some compatibility issues. Like Fairy-Max KingSlayer now supports two methods for variant selection: in variant 'fairy' the armies are decided based on White Army / Black Army engine options. This is compatible with Fairy-Max, which has a single engine option to select a pair of armies, but the options have to be set by hand anyway, and mean nothing to WinBoard. The other method is through the variant names, but the names are incompatible with those in use by Fairy-Max; I currently programmed names like "fide~nutters~(cwda)" (all lower case; the space existing WinBoard versions reserve for these names in the New Variant dialog is rather small, and capitals take more space). This we obviously have to sync between ChessV, Quaddrox and KingSlayer, and then I will adapt the names in Fairy-Max' ini file likewise.

The other issue is the piece IDs. I currently use the same as Fairy-Max already used. These are not very satisfactory, though; many were picked to match the piece symbol I picked to represent the piece in WinBoard (e.g. U for Charging Knight because I displayed it as a Unicorn, E for Waffle because I displayed it as an Elephant). They make no sense in a GUI that would use a less fanciful representation.

Promotion to an opponent piece will always be somewhat problematic in KingSlayer, as it can only support 7 piece types per army (including Pawn and King), now that I patched it to allow use of the formerly unused type code 7. So that could be its own pieces plus the opponent's super-piece. But then under-promotion to an opponent piece will always be impossible. This is not very important for the purpose I wanted to use it for, but it makes it a somewhat incomplete implementation of the official rules. Things could be stretched a bit further by dynamically assigning the piece type during the game. But that would not remove all limitations, and add a lot of cumbersome code for something that would be almost entirely hypothetical.

I also discovered a problem in WinBoard: it does not relay castling rights in a FEN when the corner piece is not a Rook. This never hurt Fairy-Max, as this relies on the 'edit' command rather than 'setboard', which does not relay any info on castling rights. So Fairy-Max would reconstruct these just based on the corner piece being the one from the initial setup. KingSlayer takes the rights in the FEN seriously, though, and in an engine-engine game the initial setup specified by the first engine would be loaded in the second engine, which then would lose its castling rights. (With external configuration of the initial position both engines would lose these rights, if they rely on 'setboard'.) There is a WinBoard command-line option that can force the castling field to a desired value, though (to force compatibility with the broken Arena Chess960 FEN), so I suppose that would be a work-around. Obviously I have to fix this in WinBoard.

I now managed to have KingSlayer play some CwDA games against Fairy-Max, which it eventually could do without illegal-move complaints (and even win some). This is just the basics (move generator and check test); the material table is not implemented yet. The non-standard a-side castling of the Clobberers works, though.

Nice.  That's progress :)

I currently programmed names like "fide~nutters~(cwda)" (all lower case; the space existing WinBoard versions reserve for these names in the New Variant dialog is rather small, and capitals take more space). This we obviously have to sync between ChessV, Quaddrox and KingSlayer, and then I will adapt the names in Fairy-Max' ini file likewise.

That's fine.  I will present the formal names to the user so it doesn't matter much to me what is sent to the engine in the backgrond.  I will synch to whatever you settle on.

The other issue is the piece IDs. I currently use the same as Fairy-Max already used. These are not very satisfactory, though; many were picked to match the piece symbol I picked to represent the piece in WinBoard (e.g. U for Charging Knight because I displayed it as a Unicorn, E for Waffle because I displayed it as an Elephant). They make no sense in a GUI that would use a less fanciful representation.

Yeah, there is that too.  But I'm not sure what the "correct" notations would be anyway.  I have assigned letters already but you probably won't like them.  I abandoned Betza's terrible, horrible, absolutely no good names at least a decade ago, using alternatives when they already existed.  The Waffle?  For real?  People will not take seriously a game with a piece called the Waffle...  And that piece is already know by the far more satisfactory "Phoenix".  Betza had already started fixing the names - the "Furhrurlbakking" becoming the Colonel for example.  Too bad he disappeared before he finished.

I patched it to allow use of the formerly unused type code 7. So that could be its own pieces plus the opponent's super-piece. But then under-promotion to an opponent piece will always be impossible.

This is not ideal, but is probably not all that big a deal.  How often will any engine pick something other than the two super-pieces?  I would think pretty rare, and then 50% of the time it will still pick one of its own lesser pieces.

But I'm not sure what the "correct" notations would be anyway.  I have assigned letters already but you probably won't like them.  I abandoned Betza's terrible, horrible, absolutely no good names at least a decade ago, using alternatives when they already existed. 

I completely agree. I am all in for renaming them, but I do think it is important we do it in the same way. 'Phoenix' is great, but what ID do you use, as the P is already taken? I would use 'X', as that is otherwise in little demand. 'Short Rook' (S) for the R4 would also be an obvious choice. I always liked the name 'Tower' for Rookish pieces (as there is also little pressure on T), but am not sure whether that would best fit the WD or the Charging Rook. 'Lighthouse' would also be a suitable name for an augmented Rook. 'Duck' for the HFD seems as good a name as any. Fairy-Max used 'Unicorn' for the Charging Knight, but this has already a Grant Acedrex meaning. How about 'Jockey' for a Horse/Man-like piece (other than the KN Centaur)? The Bede should probably have the name of some sort of (rather important) cleric. How about 'Ayatollah'? The FAD gives the impression of nervously jumping around, but the name Squirrel is already taken. It can be seen as an augmented Modern Elephant, but that seems a misnomer for a jumping piece in the first place. 'Kangaroo' would be fitting, but has occasionally been used for several other pieces.

Excellent.  I'm glad you're on board.  And I did, indeed, use X for the Phoenix.  I think I used S for Short Rook also if memory serves.  I have to head to work so I don't have time go into too much detail about what I chose and why right now.  My goal was to not invent names myself any more than absolutely necessary - I used existing naming wherever I could find one.

Funny you mention "an important cleric" for the BD.  The name I have been using is "Cleric".  This is a case where I was not aware of any existing name and Cleric was a nice medieval name that hadn't been used.  For FAD I used "War Elephant" - the piece is an elephant crossed with a dabbabah (war machine.)  I didn't invent that, but I don't remember exactly from where it came.  I think Joe Joyce may have come up with that originally.  The Fibnif, I used "Narrow Knight".  This just seemed obvious and similar to Charging Rook and Charging Knight, who's names I didn't feel needed changing.  The HFD is the "Lion".  This was originaly used by David Paulowich in his games and I followed his lead in my games (Opulent Chess and Hubbub.) This is one of my favorite variant pieces.  Yes, the Lion has a different meaning in Chu Shogi, but that piece is pretty different and wasn't really used in conventional chess variants.  You have since used it in Elven Chess with a different name, but that was long after.  David used this name about 15 years ago.  Then there's the BD.  I have been using "Bowman" but I was never all that happy with this one.  It came from Compton Medieval Chess, which was the only existing use of the piece I could find, but this game is extrememly obscure and the name didn't really seem to match the piece.  Tower is probably a better name and I'm happy to change.

How about this? I changed Bowman to Tower, which is probably a little better. It is unfortunate that I cannot find a historical precident. It seems like this is an obvious piece that would have been used log ago but apparently not. For the Nutty Knights, We have Charging Rook, Charging Knight, and Colonel all beginning with C. The Charging Rook can be R. The Charging Knight could be N, but then what about Narrow Knight? I think Jockey sounds like a reasonable choice for the Charging Knight (a piece that moves partly like a horse and partly like a man) and J is unused. Leaving us with:

I'm also open to something other than Narrow Knight if we can come up with a GOOD name that makes sense. Although, if we did that, that would free up N for Charging Knight, which would have the advantage of not reassigning names to those pieces that Betza already fixed. I suppose that the Fibnif could be Jockey since it also has horse-moves and man-moves, although not as obviously as the Charging Knight.

A good name for the narrow knight could be searched in the realm of light cavalry, maybe. Lancer or hussar could be interesting options. Donkey is a fun option also for the not this "not that horse" piece, but maybe this is not that appropriate. 

"Lancer" does seem a good name, as a Lance seems to be a weapon ill-suited for lateral combat.

I like Lancer as well.  So the Fibnif becomes Lancer (L), freeing up N for the Charging Knight.  Now we are only changing the names of pieces Betza didn't get around to yet and we still have pretty good one-letter notations.

I have updated the table below.

Wouldn't it be more logical to use 'E' for the War Elephant? It is likely to be depicted as an Elephant, so this would have a better mnemonic value.

You make a strong case for 'Lion'. (And it indeed is a very nice piece.) I suppose the reason I don't like it is that I am just too involved with Shogi, and that the Lion is such an iconic piece there. But I guess I just should come to terms with the fact that Shogi names often have completely different meaning than those in western chess variants, and that a (Drunk) Elephant is nothing like an Alfil, and a (Dragon) Horse nothing like a Knight.

@HG

I had sugested, for one of his variants, the name platinum general for the drunk elephant. To me that seems more interesting. But that's a bit off topic!...

Wouldn't it be more logical to use 'E' for the War Elephant? It is likely to be depicted as an Elephant, so this would have a better mnemonic value.

Yup, I agree with this.  I have updated the table.

Just let me know what exactly you want the xboard game names to look like.  I was thinking we could extend your idea a little and say that where game-specific parameters need to be encoded in the game identifier, they are formatted like P1(game) or P1~P2(game) or P1~P2~P3(game), etc.  CwDA has two parameters, P1 is white army and P2 is black army.  At some point I would like to come up with a better option for programs that support it so we don't have an exponential explosion of game names, but as a starting point, and for backwards-compatability with programs that don't support it, this seems like a promising approach.

I'm really looking forwards to having multiple interoperable CwDA engines.  I originally started writing ChessV because I wanted to better study CwDA and Zillions wasn't good enough (and there was nothing else.)

I currently put an extra ~ in the names compared to what I proposed here earlier: A~B~(C) instead of A~B(C). This looked more balanced (the latter form suggested a tighter coupling between B and C). This would also make it possible to recognize '1-parameter' sub-variants by the ~ alone, e.g. bird~(10x8), carrera~(10x8).

Name explosion would occur when a sub-variant needs multiple parameters (such as CwDA); with a single parameter the possible parameter values would have to be mentioned anyway. We could solve it by introducing wildcards for the parameters: nutters~*~(cwda) would mean the variant group 'cwda' has two parameters, and 'nutters' would be a possible value for the first parameter. Such a partial variant declaration would be discarded if there weren't also declarations of the form *~rookies~(cwda) in the variants feature to specify some possible values for the second parameter. This is not backward compatible with existing GUIs, though; these would not recognize the * as wildcard, and take the names litterally. This problem could be ameliorated by making the engine such that it would also accept the names with the wildcard in it in the 'variant' command, and would treat the parameter value * as a command to keep the previous value of that parameter. A user could then still make the selection Nutters vs Rookies by first selecting nutters~*~(cwda), and then switch to *~rookies~(cwda). (On second thought, we could adopt the convention that a second parameter that is only given as a wildcard in all the supported sub-variants would be assumed by the GUI to allow the same values as the first parameter. The engine, when confronted with * for this parameter, could then use the previous value of the first parameter for it.)

BTW, many of the problems you mention for Cylinder Chess sound familiar. I remember that at some point of implementing XBetza support in XBoard I decided moves should be generated after 'lifting' the moving piece off the board, in order to allow bent multi-leg moves to pass back over itself (e.g. for igui). That caused XBoard to hang with an oR on an empty rank... I solved it by making the Betza-driven move generator such that it would treat all slides as finite-range slides with the maximum board dimension minus 1 as range. If you already support finite range slides, this would cause no extra overhead.

SEE is indeed troublesome, if there are pieces with fancy moves. But like you say, it isn't really necessary. Pure MVV/LVA already is pretty good, and Fairy-Max gets by with only sorting the MVV/LVA-wise best move in front, and searching the other captures in arbitrary order. My guess is that >90% of the beneficial effect of SEE comes from detecting if a piece is completely unprotected, so that HxL captures on it are safe. So I often use the simpler algorithm BLIND, which postpones HxL capture of protected pieces compared to MVV/LVA. This still requires you to know whether a piece is protected, though. The null-move reply could have told you, but in QS there is no null move. You could get (somewhat inaccurate) protection information as a side effect from the move generation that was done in the parent; this could have marked all pieces that block friendly captures as protected (e.g. in a bitmap of the board or of the piece list, or even a (packed?) set of counters, to be able to correct single protection for the piece that was moved).

KingSlayer uses MVV/LVA, but it has a provision to initially abort the search of HxL captures that go sour, to reschedule them until after the other captures have been searched. To this end it can pass the value of the victim as 'threshold' to the child. When that child then generates a capture of a piece more valuable than 'threshold' on that same square (which it would after H x protected L), it immediately returns 'abort score' INF+1 (so the caller can see that the capture was bad and needs to be rescheduled). As an extra it would also abort if the 'obvious gain' from capture on a different square would exceed 'threshold'. Where that gain is defined as the value of the victim if unprotected, or the difference between victim and attacker value if protected. This protection information is obtained from the parent (inaccurate as it is, but only used in 'second order'). Normally you would only abort on capture of a King (returning +INF, as no rescheduling is needed), i.e. use threshold = INF-1. This is what is done during the search of the rescheduled captures, to prevent it would abort again.

Duplicat moves are not really a very large problem; the duplicat should give a hash hit that makes it fail low immediately. Bifurcating pieces (e.g. bent sliders like the Griffon) also tend to produce them, if you are not careful to define the overlapping part of one of the branches as a lame leap.

Bent sliders (including the ski-jump case) are pretty nasty anyway. They blur the distinction single vs double check, as beside offering the possibility for triple (or even quadruple) check, they can cause double check to occur along a single path. So that contrary to normal double check, it can be resolved by interposition (but still not by capture of the checker). The ski-slide of the Wyvern thoroughly wrecks KingSlayer's implementation of check detection and handling. Perhaps I should not spent further time on that now, and try to get the other armies working as quickly as possible.

In that case I am nearly there; I have implemented a rather general material evaluation that reproduces the general trend of the EGT results, driven by a 32-bit 'properties' word for each piece type. The even bits in this word are used as flags to indicate whether that piece has the corresponding property (e.g. mating potential, color binding, lacking mating potential even as a pair, being rather weak for a major, etc.). As I won't do any score discounting with more than 2 pieces for each side, the property words can be added for each player, and when both pieces have a certain property, this cause a carry to the (originally unused) next-higher (odd) bit. This makes it easy to recognize conditions like having two majors (almost always a win), having a pair of Knights (draw), having only minors (draw against any defender), etc. Pieces with the 'super-piece' property will use a 2-bit field in the properties word to indicate their ranking, so that we can decide whether an extra minor on their side will make it a win.

It also detects uneven distribution of color-bound pieces over the square shades, to penalize that by a fixed score (which is equivalent to awarding a pair bonus), and declaring a draw when it happens to the only two pieces in absence of Pawns. And when both sides have full color binding on opposite shades it will discount the evaluation by a factor 2 even with many Pawns. This seems to capture the most important effects. I guess I could still have it invoke the existing code for detecting a KBP.K draw in all cases where the only remaining piece is color bound.

Still have to test everything, though.

OK, I seem to have produced something that works according to specs. I uploaded it to http://hgm.nubati.net/CwDA.exe. I had it play matches against Fairy-Max in FIDE-Nutters and Clobberers-Rookies, and there don't seem to be any illegal moves anymore. I did this using the old piece IDs of Fairy-Max, but in the uploaded version I replaced this by the new IDs we agreed on, but added a checkbox option that can be used to select the old IDs. The piece-to-char tables sent in the 'setup' command still always use the old IDs, though, and don't provide IDs for pieces of the opponent army; this is still something I have to fix. But I am not sure ChessV even looks at the setup command, and the pieceToCharTables probably have meaning for Win/XBoard only.

I also added a checkbox option 'Traitor promotion', where you can switch the possibility to have it promote to the super-piece of the opponent army on or off.

[Edit 2019-05-28] I fixed a problem with input of under-promotions, (which could not be tested by playing against Fairy-Max, as it never does those). It now also can do all under-promotions to pieces of its own army (the FIDE version of KingSlayer only considered promotion to Q and N, but not in all armies the other pieces are as redundant as B or R). The pieceToCharTables in the 'setup' command now use the piece IDs that are selected by the old IDs option, and merge in the super-piece of the opponent army, if the 'Traitor promotion' option is enabled.

The previous version was still plagued by a woken-up 'sleeper bug': all the end-game discounting worked fine when I tested it on setup positions for the end-game, but it did not apply it when the same end-game was reached in games! Turned out castling messed up the Rook counter, which had never mattered before, as the count was not used. But now it made the drawishness code think both sides had (tons of) Rooks. I uploaded a fixed version ("KingSlayer cwda-1.2") to the same link. This also prints some results of the drawishness detection for the root as part of the Thinking Output, so that it can be easily seen when it misjudges. Like Fairy-Max it slightly randomizes the first 8 ply of any game, (adding -8 to +7 cP to the score of each move in the root), to provide more game diversity in test runs.

Nice!  I didn't have an opportunity to mess with this during the week, but I now have KingSlayer cwda integrated within ChessV cleanly.  It is pretty strong!

I am finding one issue, though.  Sometimes upon promotion KingSlayer sends the wrong notation. For example, ChessV was playing the Clobberers with the white pieces and KS was playing the FIDEs with the black pieces.  When it went to promote, it sent c2c1q' which is not correct.  The Queen is part of its army, not the opponents, so the quote shouldn't be there.  (ChessV then says it forfeited due to illegal move.)

A yes, this was something I couldn't test, because WinBoard doesn't accept dressed letters as promotion suffix yet. This was a bit of a subtle bug: the quote suffix was initialized to 0 when entering the MoveToText routine, and then set to a quote if promotion to the 7th piece type occurred before being printed. But by an oversight the suffix had been declared as a static char, so the initialization did not work on every call of MoveToText, but only at program start. So once a move with quote suffix was printed, all promotions would from then on be printed with this suffix. (But WinBoard happily ignored that.)

I uploaded a fixed version to the same link.

Sorry, H.G., it looks like that did not solve the problem.  I am also getting an occasional crash.  I'll email you the debug output.  But when it doesn't crash or make illegal moves, it seems to win the majority of the time :)

Also, it looks like it doesn't support both sides playing the same army?