Comments/Ratings for a Single Item

Do you mean you use the rule that stalemate is a win? Otherwise DW-D would not be won, contrary to what you claim for "Duke + any piece". DR-K has no checkmates at all, and would be a reglementary draw. (And even when stalemate is a win it would be a general draw.) KQ-KR is only barely won, and when you weaken the Q side to DQ-KR, it becomes a general draw. KR-DR is a general win, though.

FairyGen cannot do hoppers (like the Cannon). The other pieces you mention are all standard, and already pre-configured in FairyGen's piecedef.ini file. (There is no need to assign other letters to royal types; the first piece mentioned of any color is always assumed royal. So KKK.KR would mean King + 2 commoners against King + Rook, and NQ.N would be a Knightmate end-game.)

To be frank, after having done nothing but generating hundreds of EGT and interpreting the results for more than a week, I was longing to do something else for a change. Like finishing the conversion of KingSlayer to a CwDA engine. But that doesn't have to stop you from doing it yourself. FairyGen can be downloaded from http://hgm.nubati.net/fairygen.zip , and it should be easy to run it from a command-prompt window.

Oh yes I forgot to mention stalemate = win.

Does FairyGen need any specialized support package? Java? .Net? And how do you loop through all the possible combinations? Also how do you tell the program that whether the bishops are same or different color？

FairyGen is just a set of Windows .exe files, one for each number of men (e.g. 4men.exe), it doesn't need anything else.  The FairyGen package contains a README.txt file with info on how to use it, but basically one just opens a command-prompt window, goes to the folder where the package was unzipped, and types a command like "4men -s KR.WR" (to generate royal King + Rook vs royal Wazir + Rook). The "-s" option specifies that stalemat should be considered a win. It then already prints some statistics info during generation, which you can ignore, and finally gets into a loop where you interactively can specify individual positions in this end-game that you want to probe, which you can immediately quit by hitting Ctrl-C. You can then find the stats of the end-game on a file "rep2.txt", in the following format:

WR_W stalewin

WON.wtm      62496
K capture    16352
other        46144
  0.          1671
 10.           404
 11.           968
 12.          3082
 13.          6133
 14.         12997
 15.         16010
 16.         14704
 17.          3136
WON.btm      57434
stalemate        0
W check       3391
LEGAL        59105
TOTAL        62496

WON.wtm gives the number of positions that white can win when he has the move, WON.btm the white wins with black to move. These are split up by distance to conversion (mate or capture) on the lines above, starting at 10 (so 11 means mated in 1 etc.) The total includes also 'illegal' positions where a King can be captured; their number with white to move is listed after 'K capture', and also gives an impression of how many of the listed wtm wins are due to immediate capture of possible other black pieces (although these sometimes will be protected).

If two or more of the pieces are color bound, the statistics will automatically be split into the like and unlike case, and presented in multiple columns.

Hi H.G. , this is helpful. I got it to run I wonder if there is a way to cycle through pieces combinations, ie, KQ v DQ, Then KQ v DR, then KQ v DB, etc? 

I started a new discussion for this, to not further contaminate the CwDA comments with unrelated stuff.

@Prussia General: Unfortunately looping over all piece combinations is not a standard feature in this version of FairyGen. The source code contains commented-out loop statements to do this, but that was from the time it used internal piece defintions rather than an external piecedef.ini file. It would also be hard to know exactly what it should loop over (e.g. which pieces in the file are acceptable as royal? Which as non-royal?).

Nice.  Thank you for making a page for this awesome utility!  I have moved the comments about this from the CwDA page here.

Very handy tool! I was able to check the end games of most of my variants. 

I do have a question on King vs Royal Wazir + knight. How do I check the winning percentage for the King? It gives me an error when I attempt 3men K.WN, whereas WN.K is a sure 0% win.

Alternative pieces that I have questions with:

how could I define a unit that cannot capture at all?

how could I drfine a unit that cannot move at all?

thanks

Prussia

This unfortunately runs into one of the limitations of FairyGen: it assumes there are always at least two white pieces. It uses that for the application of symmetry to save memory: it only tabulates positions with the first piece in the triangle a1-d1-d4, and when it is on the diagonal a1-d4, with the second piece in a1-h1-h8. Other positions are mapped onto these by vertical, horizontal and diagonal flipping. But this is only done after white moves. The assumption was that a bare royal would never be able to win. Of course for 3-men EGT memory is not a very large concern, and even for 5-men the EGT would only measure 1GB (=64^5), which isn't much for today's memory technology. When I wrote FairyGen even my largest computer had only 1GB. I guess I could compile a version that doesn't apply any symetry at all, and try if that one does 1+2-men without problems. (I already have versions that I made for private use, that can handle reduced symmetry, like needed for the pieces of the CwDA Nutters army, but even there it still does horizontal flipping.)

To define divergent moves in the piecedef.ini file you can add an 'm' or a 'c' to the third parameter. E.g.

X: 1,0,sm* 1,1,sc*

would be a piece that moves like a Rook but captures like a Bishop. To define a piece that doesn't capture at all you just make all its moves 'move-only'. If you want a piece without any moves or captures, perhaps you can just leave the entire line after the colon empty. I never tried that, but I think it should work.

HG,

the sm* code did not work, as I tested by defining a unit called S with the same movement of rook but unable to capture (0,0,sc*). This piece should have zero winning chances against a bare King. Fmax gave the exact same stats as a regular rook, so somehow it's ignoring the sc* part of the code.

yet a different note - for a piece that could not move, you need the 0,0 otherwise it would still give an error. also, can you define a unit that is immune to capture?

Oops, my bad! Non-capture only is indicated by 'n', not by 'm'. I was mixing it up with Betza notation. :-(

So the non-capturing Rook (Betza mR) would be R: (1,0,sn*). An 'm' would be simply ignored; FairyGen checks for occurrence in the string behind the second comma for 'n', 'c', 's' and '*' only. You don't have to specify anything about captures if you don't want them.

Using (0,0) as step for a completely immobile piece might work, as the piece would see itself in the target square, and captures of friendly pieces is never allowed. It should not be needed, though. But there must be a space behind the colon, perhaps this was the problem.