Check out Atomic Chess, our featured variant for November, 2024.


[ 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]
Aaron Z wrote on Thu, May 30 10:37 PM UTC in reply to H. G. Muller from 07:12 AM:

Thank you!


💡📝H. G. Muller wrote on Thu, May 30 07:12 AM UTC in reply to Aaron Z from 12:16 AM:

Fairy-Max communicares through CECP ('WinBoard protocol'), described at https://www.gnu.org/software/xboard/engine-intf.html#5 . It is not really designed for running on the command line.

You get command sequences like

memory 64

level 40 5 0

new

variant capablanca

usermove f2f4

 


Aaron Z wrote on Thu, May 30 12:16 AM UTC:

Is there documentation anywhere how this works on the command line?

I've gotten as far as "go" and anything after seems to crash it. Loading positions, getting more than one move in, etc, I can't figure out. ):


💡📝H. G. Muller wrote on Sat, Mar 30 09:54 PM UTC in reply to Daniel Zacharias from 08:30 PM:

Is the Sissa possible in fairy-max?

No.:-(

I am planning to create an engine similar in strength to Fairy-Max which can do anything the Interactive Diagram can do. But it is in a very early stage of inception,  and the project was interrupted by the necessity to rescue the TalkChess forum.


Daniel Zacharias wrote on Sat, Mar 30 08:30 PM UTC:

Is the Sissa possible in fairy-max?


💡📝H. G. Muller wrote on Thu, Dec 15, 2022 09:51 AM UTC in reply to Aurelian Florea from Sun Jun 27 2021 03:16 AM:

Luke Scholler wrote on 2022-12-13 CET

Hello! I know this may be a strange comment, but I am working on a project involving your micro-max engine and have a few questions. Believe it or not, this site is the only place it seems that I am able to contact you directly. Maybe you have contact info on your website, but I could not find it.

Anyways, my question is simple: is it possible to play as the black pieces on this chess engine? I have tried changing the "initial piece setup" line of code and swapping the king and queen, but that doesn't seem to work. What would I have to do to get this to work? Thanks

I read the TalkChess forum (talkchess.com) every day, and normally post there almost as often, and that would be a more natural place for questions like this.

Are you asking this for the stand-alone version of micro-Max? The WinBoard-compatible version is a normal WB engine, which can be set to play white or black through the GUI in the normal way. The stand-alone version does not play for a particular color; it just moves for the side that is on move when you enter an empty line of text (i.e. press the <Enter> key), or performs the move that you entered.


Aurelian Florea wrote on Sun, Jun 27, 2021 03:16 AM UTC in reply to Greg Strong from Sat Jun 26 11:37 PM:

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 Sat, Jun 26, 2021 11:37 PM UTC in reply to Aurelian Florea from 04:49 PM:

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 Sat, Jun 26, 2021 04:49 PM UTC in reply to H. G. Muller from 10:21 AM:

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 Sat, Jun 26, 2021 10:21 AM UTC in reply to Aurelian Florea from 03:37 AM:

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 Sat, Jun 26, 2021 03:37 AM UTC in reply to H. G. Muller from Fri Jun 25 08:25 PM:

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 Fri, Jun 25, 2021 08:25 PM UTC in reply to Aurelian Florea from 07:30 PM:

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 Fri, Jun 25, 2021 07:30 PM UTC in reply to H. G. Muller from Tue Jun 22 06:48 PM:

@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 Wed, Jun 23, 2021 08:55 AM UTC in reply to H. G. Muller from Tue Jun 22 06:48 PM:

Thanks, HG!


💡📝H. G. Muller wrote on Tue, Jun 22, 2021 06:48 PM UTC in reply to Aurelian Florea from 07:41 AM:

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 Tue, Jun 22, 2021 07:41 AM 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 Mon, Jun 21, 2021 11:55 AM UTC in reply to Aurelian Florea from 05:43 AM:

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 Mon, Jun 21, 2021 05:43 AM UTC in reply to H. G. Muller from Sun Jun 20 09:23 PM:

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 Mon, Jun 21, 2021 04:25 AM UTC in reply to H. G. Muller from Sun Jun 20 09:23 PM:

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


💡📝H. G. Muller wrote on Sun, Jun 20, 2021 09:23 PM UTC in reply to Aurelian Florea from 08:20 PM:

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 Sun, Jun 20, 2021 09:09 PM UTC in reply to Aurelian Florea from 07:30 PM:

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 Sun, Jun 20, 2021 08:20 PM 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 Sun, Jun 20, 2021 07:30 PM UTC in reply to H. G. Muller from 09:43 AM:

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 Sun, Jun 20, 2021 11:34 AM UTC in reply to H. G. Muller from 09:43 AM:

Thank you for the info HG!


💡📝H. G. Muller wrote on Sun, Jun 20, 2021 09:43 AM UTC in reply to Aurelian Florea from Tue Jun 15 04:01 PM:

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.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.