You are on the backup site for Chessvariants.com. Any posts, moves, or other changes you make here will not be permanent, because the pages and database from the main site will be backed up here every midnight EST. Additionally, things may not be working right, because this site is also a testbed for newer system software. So, if you are not here to test, develop, or merely read this site, you may want to change .org to .com in the navigation bar and go to the main site.



The Chess Variant Pages




[ 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 EarlierEarliest
Fairy-Max: an AI for playing user-defined Chess variants. A chess engine configurable for playing a wide variety of chess variants.[All Comments] [Add Comment or Rating]
Aurelian Florea wrote on 2021-06-27 UTC

Actually for this project, no. This is about checking the NmH, the NmD and the NmA against bishops on a 10x10 board in order to see if these knights are very close in value to the bishops. But for the apothecary chess games I'm awaiting the source code in order to tweak the piece value of the joker. That is if you are happy with how things are going so far with the joker.


Greg Strong wrote on 2021-06-26 UTC

Probably I should stick to ChessV, but I'm awaiting for the new version

Is there something specific you are waiting for?  Release Candidate 2 is solid, as far as I know, and is probably the strongest variant engine available.


Aurelian Florea wrote on 2021-06-26 UTC

I think sjaak II does not do bent riders. Probably I should stick to ChessV, but I'm awaiting for the new version.


H. G. Muller wrote on 2021-06-26 UTC

The way castling works in Fairy-Max is that any piece that has castlings amongst the moves on its definition line will castle with the piece on the same rank on the left or right edge. Provided both are virgin. The problem is that while setting up a position from an external source, virginity is judged by whether the piece is placed in the same position as the internal start position. And that currently the internally defined start position can only have non-Pawns on the back rank, and a single rank of Pawns placed on another rank (which cannot be specified fully independently from the width of the promotion zone).

This is already versatile enough to implement many chess variants, but by no means all. Multi-variant engines like Sjaak II are much more flexible in this respect.

What I am thinking about is to allow the lines that specify the (non-Pawn) piece placement in the fmax.ini file to be longer than the board width, and put the extra pieces that are specified on the next rank, bumping the Pawns one rank forward for every new rank. For engine-defined variants Fairy-Max has to communicate the internally defined initial position to the GUI in FEN format, though. And the current FEN generator is not completely general, but assumes there will only be pieces on the back rank. So this will have to be entirely rewritten.


Aurelian Florea wrote on 2021-06-26 UTC

Is it possible to make castling work also on the second rank with the piece on the edge (not just on the corner)?


H. G. Muller wrote on 2021-06-25 UTC

Only pieces that start on a location they also have in the initial position as the fmax.ini file defines it will be considered virgin. It is possible to shift the Pawn rank of the initial position (Grant Acedrex uses that), or enlarge the promotion zone (Makruk & Cambodian Chess use that). But not independently. So if you want a zone wider than one rank that does not extend all the way (and including) the Pawn rank, the current version of Fairy-Max cannot do it.

Perhaps I should devise some upgrade that makes it possible to add extra piece ranks, which then automatically push the Pawns forward. I will think about that.


Aurelian Florea wrote on 2021-06-25 UTC

@HG, Is pawn virginity lost when using a external fen file for the starting position in a tournament. It figures to me that pawns on the 3rd rank cannot make double steps.


Aurelian Florea wrote on 2021-06-23 UTC

Thanks, HG!


H. G. Muller wrote on 2021-06-22 UTC

You mean the examples given for the various pieces? These are indeed still given in the original system (which still is the internal representation), that didn't have the possibility to optionally specify a secondary step vector.

With B2-then-R you mean a piece that slides on a trajectory that starts with (exactly) 2 diagonal steps, and then continues orthogonally after a 45-degree bend? This would be nearly the same as Griffon, except that you would have to specify a delay of 1 step before the move switches from primary to secondary leg. E.g. for one of the trajectories the Griffon would use 15,3,1, and the corresponding trajectory of the B2-then-R would be 15,403,1. The 4 there specifies a delay of 1 step, and the 0 that there is no change in rights between the first and second leg. (Both are mc.)

Note that to avoid duplicat generation of the F moves, you could specify the other trajectory that starts with the same step without any rights in the first leg, like 15,30,16 for Griffon. This has 0 for primary rights (= cannot do anything), and then toggles that to 3. (I did not do that in the example.)

 


Aurelian Florea wrote on 2021-06-22 UTC

The Osprey now works fine and I understand why. I'm likely to be able to make the gryphon on my own. But may you please add to your to do list upgrading the explanatory text in the .ini file for bent riders? For example I'm interested in how to do a B2 then rook or a R2 then bishop even if I successfully used the XBetza notation for them in the interactive diagrams. To my understanding they can actually be easier in fairy-max.


H. G. Muller wrote on 2021-06-21 UTC

First matter is usually because you ask for a save file in a non-existent folder.

You can register Fairy-Max twice (through the Load Engine dialog), specifying different nicknames, and ticking the checkbox to use the nicknames also in the PGN files. What you can also so is start WinBoard with ' additional option' -sameColorGames 100 . This will suppress the color alternation in matches, so that you can configure Fairy-Max with a variant that uses, say, Knights for white and Bishops for black, and just play a match. Then the first number in the match score will be the white Knights.

About the Osprey moves: I think it is not WinBoard that rejects them, but Fairy-Max. The Betza notation is correct, and WinBoard understands it (as the highlighting on user moves shows). But the line you posted for the move definition is not an Osprey. (Not sure what it is, but it doesn't have the correct step after the trajectory turns the corner.) The problem is that you use the notation that specifies a move through 2 numbers (separated by comma), where the second number has to specify both the move rights, and the alteration in step vector. I suspect you started from the Griffon definition, and just changed the vector of the first step. But because the second number encodes the change in step (in a cumbersome way), that implicitly also alters the secondary step.

Recent Fairy-Max versions allow you to specify the secondary step explicitly, rather than as a change of the primary step, by appending the secondary step after an extra comma. For the Osprey this would give a move definition like

2,3,17 2,3,-15 -2,3,15 -2,3,-17 31,3,15 32,3,17 -32,3,-15 -32,3,-17


Aurelian Florea wrote on 2021-06-21 UTC

While holding a tournament after a game ends, I keep getting an error saying the system cannot open a certain png file. Why?

How do I label the 2 engines (both fairy-max) so that I can figure out who plays a set of pieces and who plays the other? Something like bishops vs knights.

Edit: I had managed to figure out the firs matter.


Aurelian Florea wrote on 2021-06-21 UTC

Well, Winboard rejects the Osprey move as illegal, although it represents it correctly for the human player.


H. G. Muller wrote on 2021-06-20 UTC

I think even pretty old WinBoard versions should understand that Betza string. (But I did not actually try it). Just to be sure, use the version at http://hgm.nubati.net/WinBoard-AA.zip .

The Fairy-Max in that package also has a more user-friendly way to specify bent sliders; you can specify each move also as a triple s1,r,s2 . Where s1 is the initial step (+/-32 or +/-2 for an Osprey), and s2 is the step after the bend (+/-15 or +/-17).  The middle parameter specifies the 'move rights' and should be 3 for a piece that slides and can both capture and non-capture.


H. G. Muller wrote on 2021-06-20 UTC

The parent variant is indeed the word on the ' Game:' line after the piece-to-char table. I don't think there are any standard variants with a 2-deep zone, for 8x8 boards or larger. In variant shogi it uses 1/3 of the board height, which works for the 6x6 Judkin's Shogi (which has a zone of 2 ranks).

With legality testing switched off, however, WinBoard would obey the engine when it plays a promotion move. That solves the problem in engine-engine games. In human-engine games it might work when you type moves that should promote, in this case.


Aurelian Florea wrote on 2021-06-20 UTC

Unrelated to my earlier questions: It seems to me that fmax understands the Osprey as n:600 32,1003 32,1F003 -32,1003 -32,1F003 2,10003 2,FFFF0003 -2,10003 -2,FFFF0003 but WinBoard does not understand : DmpafyafsW . Am I correct?


Aurelian Florea wrote on 2021-06-20 UTC

How do I pick a parent variant in winboard? The variants I had defined in Fairy-max.ini have the dimension line set 10x10=3 but whenever promotion occurs winboard gives an error. This was happening actually before my last questions. Do I have to name my variant Elven? Later Edit. I prefer a depth of 2 anyway. So this probably cannot be done! Even later edit: You meant at the end after the piece to char. I figured it know. But this is still for a depth of 3. How do I make a depth of 2?


Aurelian Florea wrote on 2021-06-20 UTC

Thank you for the info HG!


H. G. Muller wrote on 2021-06-20 UTC

Recent versions of Fairy-Max allow the nottation FxR=D in the line of the game definition that sepecifies the board size. The number D after the equal sign specifies the depth of the zone. In case this number is larger than 2 it also assumes that the Pawns start at the foremost rank in the zone. So for Camboian Chess and Makruk the game definitions specify 8x8=3. (A negative number there redefines the Pawn rank without affecting the zone size, and its absolute value then indicates the number of ranks behnd the Pawns. So Grant Acedrex uses 12x12=-3.)

The depth of the promotion zone icannot be independently set in WinBoard, but follows from the parent variant. So you would have to pick a parent variant that has a zone depth of 3, rather than 'fairy' (which has only promotion on the last rank). Variant 'elven' could be good for this.

Castling will be a problem. This is related to the way position setup works in Fairy-Max: it only assumes castling is possible if the piece on which such a move is defined, and the pieces on the edge of the same rank, start in the same location as what was defined as the start position. And in the current version of Fairy-Max start positions can only have pieces on the back rank, plus a single rank of Pawns.


Aurelian Florea wrote on 2021-06-19 UTC

@HG,

I had asked a few questions earlier this week. May you find the time to take a look?


Aurelian Florea wrote on 2021-06-15 UTC

HG,

For fairy max the promotion zone of the games is still 1 or 3 deep (no 2)?

Later Edit: Is there a way to do castling if the king and rook start on the second to last rank (like in expanded chess say)?

Even Later Edit: How do I tell Winboard that the promotion zone is the last 3 ranks?


H. G. Muller wrote on 2021-06-14 UTC

At the time I wrote that there was a problem with engine-defined variants running in a match that started from an externally set-up position, where the position sent by the engine overruled the position requested by the user. But I think this was fixed in the latest beta version of WinBoard. There it should be possible to run a tournament or match specifying a 'position file' in the Tournament Options dialog, which contains the FEN(s) of the desired start position(s). I hope.


Aurelian Florea wrote on 2021-06-12 UTC

HG,

You have explained to me here :

https://www.chessvariants.com/index/listcomments.php?id=33121

how to set up a machine match to test something. Is this still the way to do it or are there different things now?


Aurelian Florea wrote on 2021-06-10 UTC

It works, thanks!


H. G. Muller wrote on 2021-06-10 UTC

I had computer trouble, so I had no opportunity to check it out yet.

Fairy-Max does ignore game names that start with a capital. I forgot what was the reason for that (but originally there was one). But when you change the T to t the variant will appear in WinBoard's New Variant menu, from where you can select it. (If you did not put the definition too far down in the fmax.ini file; WinBoard can only display a limited number of engine-defined variants.

You did not specify what piece should be used for K/k in the pieceToChar string. Change it to

PNBRQ.EA.........G......MKpnbrq.ea.........g......mk


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.