[ Help | Earliest Comments | Latest Comments ][ List All Subjects of Discussion | Create New Subject of Discussion ][ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]Comments/Ratings for a Single Item Later ⇩Reverse Order⇧ Earlier FairyGen. Generator for end-game tables with fairy pieces.[All Comments] [Add Comment or Rating]H. G. Muller wrote on 2019-11-13 UTCOops, 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. Prussia General wrote on 2019-11-13 UTCHG, 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? H. G. Muller wrote on 2019-11-12 UTCThis 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. Prussia General wrote on 2019-11-12 UTCExcellent ★★★★★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 Greg Strong wrote on 2019-05-23 UTCExcellent ★★★★★Nice. Thank you for making a page for this awesome utility! I have moved the comments about this from the CwDA page here. H. G. Muller wrote on 2019-05-16 UTCI 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?). Prussia General wrote on 2019-05-16 UTCHi 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? H. G. Muller wrote on 2019-05-16 UTCFairyGen 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. Prussia General wrote on 2019-05-15 UTCOh 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？ H. G. Muller wrote on 2019-05-15 UTCDo 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. Prussia General wrote on 2019-05-15 UTCGreat job, H.G.! Could you do an end game table with the following set of pieces? I plan to use them in an upcoming mod pieces from FIDE are K, Q, R, B, N. Other common Fairy pieces are Cannon from Chinese chess (C), Ferz (F), Wazir (W), non royal King (Mann), or let’s call him Guard (G) and a royal wazir, let’s call him Duke (D). I plan to have rule saying that a player can have either a King or a Duke but not both. Also, Duke vs Duke is defined as immediate draw not withstanding any stalemate situation. It is trivial that Duke with any extra piece beat a lone Duke. A lone King also beats a lone Duke. Things get interesting when you have endings such as KR vs DQ, or even DR vs K. It would be appreciated if you could test the end game scenarios. Thanks Prussia 11 comments displayedLater ⇩Reverse Order⇧ EarlierPermalink to the exact comments currently displayed.