Engines playing Musketeer Chess, good price

[Ferdy]

If a fairy piece had the chance to get into play but declined it, it is as if the piece is out of the game forever, right?

Right.

So why not
make this move forced? No player is ever going to decline to do that anyway... also it is easier to handle for engines too
i.e. b1c3 and b1c3C are the same now.

That is possible as long as the to_square of musketeer piece is still a virgin.

But there is a rule that a musketeer piece loses its right to gate if its to_square is no longer a virgin.
Example (see image below) black to play and would like to play f5b1 capturing the knight at B1 square, in this case the white cannon at b file loses its right to gate for the rest of the game. So the engine may only send b1c3 or b1a3 like a normal move, or if after f5b1 white replies with a1b1, later when that rook at b1 moves, it could not gate a cannon at b file too.



The other case that I thought is something like of a puzzle, where if you gate a piece (say dragon), and that piece may cause a stalemate, so it is better not to gate. But for a tournament that starts from a normal position, gating always is fine. Better if it is b1c3c for example.

So I made this move forced now and also instead of a "combo" move, I now handle
this move as I do castling. That is, nothing needs to be encoded with the move, but proper way to do/undo the move will be figured
out later. Also, now I use an 8x10 board for the fen, which I believe is what is agreed upon for the tournament ...

Here is a search from a pre-selected start position:

Code: Select all

feature done=0
Number of cores 4 of 4
treeht 18641351 X 720 = 12800.0 MB
processors [1]
ht 1048576 X 48 = 48.0 MB

	    a b c d e f g h 
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	 10 * d * * * a * * * * * * * * * * * * * * * * * * * * * * 10  
	  9 r n b q k b n r * * * * * * * * * * * * * * * * * * * * 9   
	  8 p p p p p p p p * * * * * * * * * * * * * * * * * * * * 8   
	  7 . . . . . . . . * * * * * * * * * * * * * * * * * * * * 7   
	  6 . . . . . . . . * * * * * * * * * * * * * * * * * * * * 6   
	  5 . . . . . . . . * * * * * * * * * * * * * * * * * * * * 5   
	  4 . . . . . . . . * * * * * * * * * * * * * * * * * * * * 4   
	  3 P P P P P P P P * * * * * * * * * * * * * * * * * * * * 3   
	  2 R N B Q K B N R * * * * * * * * * * * * * * * * * * * * 2   
	  1 * D * * * * A * * * * * * * * * * * * * * * * * * * * * 1   
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    a b c d e f g h 
 
		[Material: 8996 9002 ]
*d***a**/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*D****A* w KQkq - 0 1

movelist 20 h3h4  h3h5  g3g4  g3g5  f3f4  f3f5  e3e4  e3e5  d3d4  d3d5  c3c4  c3c5  b3b4  b3b5  a3a4  a3a5  g2h4  g2f4  b2c4  b2a4  
EgbbProbe not Loaded!
loading_time = 0s
# *d***a**/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*D****A* w KQkq - 0 1
# [st = 8335ms, mt = 29250ms , hply = 0 , moves_left 10]
2 -20 0 44  h3h4  h8h6 
2 -6 0 75  h3h5  h8h6 
3 18 0 253  h3h5  h8h6  a3a5 
4 -6 0 410  h3h5  h8h6  a3a5  f8f6 
5 4 0 1185  h3h5  a8a6  g3g5  d8d6  f3f4 
6 -6 1 2515  h3h5  a8a6  g3g5  h8h6  e3e5  d8d6 
7 8 3 8852  h3h5  a8a6  d3d5  d8d6  f3f4  c9f6  g1f3 
8 14 4 16002  h3h5  a8a6  f3f5  f8f6  g1f3  h8h6  f3d5  d8d6 
9 14 5 26616  h3h5  a8a6  e3e5  d8d6  f3f4  h8h6  g1f3  c9e7  f2d4 
9 18 5 30531  f3f5  h8h6  h3h5  a8a6  d3d5  c8c7  g3g4  b10c8  g1f3 
10 14 7 44778  h3h5  a8a6  d3d5  h8h6  c2e4  d8d6  f3f5  f8f6  b1d3  c9e7 
10 18 8 67648  d3d5  d8d6  c2e4  c8c7  b1d3  c9e7  f3f5  b10d8  g1f3  f8f6 
11 14 14 150884  d3d5  d8d6  a3a5  f8f6  c2f5  c9e7  b1e4  b10d8  b3b5  a8a6  c3c4  a6b5  c4b5 
12 8 28 405926  d3d5  d8d6  h3h5  h8h6  c2f5  c9e7  b1e4  b10d8  b3b5  f8f6  a3a5  a8a6 
13 8 54 923679  d3d5  d8d6  c2f5  c9e7  b1d3  g9f7  h3h5  b10d8  b3b5  f7e5  d3e4  a8a6  b2c4 
14 8 75 1342536  d3d5  d8d6  f3f4  a8a6  g1f3  c9e7  h3h5  b10d8  c2f5  c8c7  a3a5  d9b7  b1c2  f10d9 
15 10 136 2580115  d3d5  d8d6  h3h5  h8h6  c2f5  c9f6  f3f4  b10e7  b1e4  e7e4  f5e4  b8b6  g1f3  a8a6  a3a5 
16 10 247 4880634  d3d5  d8d6  h3h5  h8h6  c2f5  c9f6  b1e4  b10d8  a3a5  g9f7  f3f4  a8a6  g1f3  b9c7  c3c5  a9c9 
17 6 409 8352941  d3d5  d8d6  h3h5  h8h6  c2f5  g9f7  b1e4  c9e7  a3a5  b10d8  g2f4  a8a6  b2c4  f7g5  e4d3  f8f6  f4e6  g5e6  f5e6 
# splits = 0 badsplits = 0 egbb_probes = 0
# nodes = 9241870 <75 qnodes> time = 4573ms nps = 2020964 eps = 0  nneps = 0
move d3d5
Bye Bye

That is nice.

I am still trying to implement the 8x10 fen. I have a perft but only after PS and GP phases. Can be a combo of CE, LD (Leopard/Dragon) and others, located at different files, will post it later for comparison.

Perhaps the first tournament of musketeer chess will be from pre-selected positions after the PS and GP phases. The side will be reversed so it is fair.

[Daniel Shawul]

But there is a rule that a musketeer piece loses its right to gate if its to_square is no longer a virgin.
Example (see image below) black to play and would like to play f5b1 capturing the knight at B1 square, in this case the white cannon at b file loses its right to gate for the rest of the game. So the engine may only send b1c3 or b1a3 like a normal move, or if after f5b1 white replies with a1b1, later when that rook at b1 moves, it could not gate a cannon at b file too

Here is what I don't understand. A musketeer piece has only one chance to enter the game i.e. the _first_ time the back-rank piece moves. It is advantageous to always drop the musketeer piece as far as I can see, even if it will be captured immediately. When you play b1c3 without entering the cannon, you loose the cannon forever, right? If so, move the cannon and let the black bishop capture it and then you capture back, in which case at least you exchanged the cannon for the bishop...

Another thing I found difficult is with promotions. One would need to remember what musketeer pieces were selected (i.e. initial position) to decide which pieces to promote to.

Also, when the to_square of a musketeer piece is no more a virgin, I don't bother to remove the musketeer piece from the back ranks, because it is never entering play anyway. Well if nebiyu is used as a referee engine this may be necessary but not for gameplay ...

Tip: I had a bug which I fixed now, in which musketeer pieces directly moved into the board. This tells me rank 0 and 9 should not really be part of the board IMO, and it may be better to encode them as holdings -- ones that could be dropped to specific squares e.g. [Cb1E1fcd8eg8] -- we don't really need the rank letters here.

[Ferdy]

But there is a rule that a musketeer piece loses its right to gate if its to_square is no longer a virgin.
Example (see image below) black to play and would like to play f5b1 capturing the knight at B1 square, in this case the white cannon at b file loses its right to gate for the rest of the game. So the engine may only send b1c3 or b1a3 like a normal move, or if after f5b1 white replies with a1b1, later when that rook at b1 moves, it could not gate a cannon at b file too

Here is what I don't understand. A musketeer piece has only one chance to enter the game i.e. the _first_ time the back-rank piece moves.

Yes.

It is advantageous to always drop the musketeer piece as far as I can see, even if it will be captured immediately. When you play b1c3 without entering the cannon, you loose the cannon forever, right?

Right.

If so, move the cannon and let the black bishop capture it and then you capture back, in which case at least you exchanged the cannon for the bishop...

The cannon cannot really move while it is still in ranks 0 or 9 but it can gate once the FIDE piece after it, at rank 1 or 8 on virgin square is moved. In the example image below, that white cannon is still on B0 square and black bishop had captured the knight at B1 square.



White can play Nxb1 or Rxb1, lets say Nxb1 to preserve white long castle. That cannon marked X cannot gate anymore. The GUI can remove it or make it smaller or mark it with X or something.

Another thing I found difficult is with promotions. One would need to remember what musketeer pieces were selected (i.e. initial position) to decide which pieces to promote to.

Yes you have to remember.

Also, when the to_square of a musketeer piece is no more a virgin, I don't bother to remove the musketeer piece from the back ranks, because it is never entering play anyway.

Yes you can remove it, just remember it for promotion possibilities.

Tip: I had a bug which I fixed now, in which musketeer pieces directly moved into the board. This tells me rank 0 and 9 should not really be part of the board IMO,

I consider those ranks as part of the game or board, the squares on those ranks have strategic and sometimes tactical (depending on what piece is selected, i.e Unicorn or hawk, and what files they are placed) importance. I played this game in jocly server before, the GP (at what file I am going to place the musketeer piece so that my first move as white d2d4 is effective) phase has to be handled with care.

and it may be better to encode them as holdings -- ones that could be dropped to specific squares e.g. [Cb1E1fcd8eg8] -- we don't really need the rank letters here.

My implementation is something like that using holdings, but with virgin squares field similar to seirawan chess.

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[CEce] w KQGFDCBkqgfdcb - 0 1

[CEce] - the musketeer piece types selected.
KQGFDCBkqgfdcb - this is the castle and gating fields combined.

In that sample fen, the CEce has all the posibilities to be dropped at any file. With that limitation, I offer gating files to the user via engine options, there the user can select cannon at any file or a, b up to h files or no file at all. So my implementation does not include PS and GP phase.

HGM has published a winboard version that can play musketeer chess, it includes the musky.exe engine that can play variant musketeer.
http://hgm.nubati.net/WinBoard-AA.zip

I am trying to revise the engine to suit this system.

After the PS and GP phase, a fen with cannon/fortress selected piece could be.

Code: Select all

***c**f*/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*C***F** w KQkq - 0 1

Now selected CF are there, so it is easy to remember for promotion, the gating files are there too.

[hgm]

@HG My implementation was rather limited because I assumed that the fairy pieces are already in play. I did not even
implement how they get into play properly. It is my understanding that ranks 0 and 9 are "water" and can not be moved to
with other pieces. I have a holdings area just like that but is not file-restricted. So are there represented in the FEN as
e.g [C2D1c4d3] where they are preceded by file numbers? The drop rule is not a regular one and I probably need to implement a
special rule for it ( Not moved piece + drop-to-from square -- I like Ferdy representation with promotion letters but since I have a combo move
capability it may be easier for me to do "move b1c3 move C@b1" )
Edit: In a way the drops of pieces is square-restricted because it can only go to first/last rank. So the first time the target square becomes
empty, I drop it or lose it forever. In the latter case, do we just remove the piece from the holdings list forever?

Indeed, declining gating is not even allowed, so gating can be fully automatic. You can still lose a gating posibility when the original piece on the gate gets captured before it moves. The situation is actually more like 'stacking' than like gating: it is like two pieces are stacked on the same square, and only the topmost piece is allowed to move, thereby uncovering what was underneath. For this reason one of the proposed FEN formats would use a general notation for stacked pieces, by enclosing the occupants of a square in parentheses when there is more than one. E.g.

rn(bc)q(ku)bnr/pppppppp/8/8/8/8/PPPPPPPP/R(NU)BQKB(NC)R w KQkq - 0 1

Note that this then would be an 8x8 FEN again.

But GUIs would in general not be able to display stacks of pieces, and a straightforward work-around for that is to add dummy 0th and 9th ranks to the board display, on which the pieces could be shown directly above/below the location where they gate. Like you say, these dummy ranks are 'water', and moves into them from the proper (8x8) board should not be allowed. When a piece is gated, the off-board 'square' it came from should also revert to water rather than empty. As a GUI designer I would also stop displaying pieces that lost their gating possibility because the piece at the gate was captured. Ferdy, however, would consider it important to keep such pieces on display. (This seems mostly a hypothetical problem, as no sane player would ever allow his gating opportunity to be destroyed that way; Musketeer pieces are all so valuable that even together with a minor they would be worth more that a Queen. Gatings are also likely to occur very early in the opening, long before any complex tactics can develop, as (unlike in Seirawan Chess) there is no benefit in postponing the gating when the opponent already knows where it is going to occur.)

The current WinBoard + KingSlayer implementation of Musketeer Chess plays this as an engine-defined variant 8x10+0_seirawan, and I made some modifications in WinBoard that cause special handling of 'holdingless' seirawan: in that case the extreme ranks of the specified board are treated as holdings instead, but unlike the normal holdings, these then are file-specific holdings, where the location in the holdings implies the location where the piece must gate. I did not make any modifications in the FEN parser and generator (yet), so it still uses the 'natural' (WYSIWYG) representation

**c*u***/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*U****C* w KQkq - 0 1

for the same position as given above.

As for the move format, WinBoard still uses (and requires) the normal Seirawan notation, where a promotion suffix on a non-Pawn move is interpreted as gating. But as the gating is implied it ignores the actual value of the suffix, and always gates what is on the 0th/9th rank behind it. Without gating suffix it declines gating, though, so the engine must suffix gating moves, and will receive suffixed moves from WinBoard on a gating. I will probably still fix this, making gating fully automatic, so that the engine no longer has to send suffixes. In SAN I would still prefer to explicitly indicate gating (through a '/H' prefix for Hawk, etc.), just to enhance human readability.

Because it is implemented as an engine-defined variant, the engine will determine through its 'setup' command which pieces participate, in the pieceToCharTable part. WinBoard will then only allow promotion to one of the participating pieces. Since in Musketeer Chess this is only known after the players have selected a piece type, the final setup command is only sent after this (and the gating locations) is decided. To not run into complaints of WinBoard for not getting a setup command as immediate response to the 'variant' command, WinBoard now implements a mechanism to allow the engine to defer the setup command to a later time, by sending a 'non-final' setup command that specifies parent variant 'prelude', a dummy variant with unspecified rules. The FENs in such prelude setup commands can be used to present arbitrary board positions to the user, which can be used as 'graphical menus' for selecting pieces or squares (clicks on them fed back to the engine through the 'lift' command of the highlight protocol). KingSlayer uses this possibility for conducting the negociation phase in human-engine games.

[Ferdy]

But there is a rule that a musketeer piece loses its right to gate if its to_square is no longer a virgin.
Example (see image below) black to play and would like to play f5b1 capturing the knight at B1 square, in this case the white cannon at b file loses its right to gate for the rest of the game. So the engine may only send b1c3 or b1a3 like a normal move, or if after f5b1 white replies with a1b1, later when that rook at b1 moves, it could not gate a cannon at b file too

Here is what I don't understand. A musketeer piece has only one chance to enter the game i.e. the _first_ time the back-rank piece moves.

Yes.

It is advantageous to always drop the musketeer piece as far as I can see, even if it will be captured immediately. When you play b1c3 without entering the cannon, you loose the cannon forever, right?

Right.

Wait there could be misunderstanding on the following.

It is advantageous to always drop the musketeer piece as far as I can see, even if it will be captured immediately.

First of all, the musketeer piece has to be dropped at 2nd or 3rd move, on rank 0 or 9. So it cannot be captured as it has not entered the regular 8x8 board yet.

Here is an example game sequence.
1. white selects cannon, black selects elephant
{both has cannon and elephant}
2. white drops its cannon at b file, black drops its cannon at d file
3. white drops its elephant at f file, black drops its elephant at g file
4. white plays b1c3c { a gate move, cannon gates at b1 square which was vacated by the move b1c3, this is only a single move }

Example b1c3c move and cannon gates at b1 square.

[hgm]

I think that what Daniel meant is that if b1 gets attacked, and your Cannon is at b0, you would not gain anything by playing Nc3 without gating the Cannon, (even if that was allowed, which I think it isn't), as this would surely make you lose the Cannon without compensation, as it could never be gated again. So gating at all times is automatic. This is why one can think of the Cannon as being already on c1 from the start, stacked under the Knight, both being captured at the same time when an enemy moves to b1. In the face of such a threat you can escape with the Knight, but the Cannon is a sitting duck until it is 'uncovered'.

[Ferdy]

I think that what Daniel meant is that if b1 gets attacked, and your Cannon is at b0, you would not gain anything by playing Nc3 without gating the Cannon, (even if that was allowed, which I think it isn't), as this would surely make you lose the Cannon without compensation, as it could never be gated again. So gating at all times is automatic. This is why one can think of the Cannon as being already on c1 from the start, stacked under the Knight, both being captured at the same time when an enemy moves to b1. In the face of such a threat you can escape with the Knight, but the Cannon is a sitting duck until it is 'uncovered'.

All right, it is white to move and black has a threat on B1 square. White can play b1c3c gating the cannon to B1 see image below, and after that move, black can capture the cannon by f5b1. Reading the rules again you are right, gating is mandatory . Black can get the cannon at B1 and white can get the bishop by Rxb1.

[Daniel Shawul]

@HG My implementation was rather limited because I assumed that the fairy pieces are already in play. I did not even
implement how they get into play properly. It is my understanding that ranks 0 and 9 are "water" and can not be moved to
with other pieces. I have a holdings area just like that but is not file-restricted. So are there represented in the FEN as
e.g [C2D1c4d3] where they are preceded by file numbers? The drop rule is not a regular one and I probably need to implement a
special rule for it ( Not moved piece + drop-to-from square -- I like Ferdy representation with promotion letters but since I have a combo move
capability it may be easier for me to do "move b1c3 move C@b1" )
Edit: In a way the drops of pieces is square-restricted because it can only go to first/last rank. So the first time the target square becomes
empty, I drop it or lose it forever. In the latter case, do we just remove the piece from the holdings list forever?

Indeed, declining gating is not even allowed, so gating can be fully automatic. You can still lose a gating posibility when the original piece on the gate gets captured before it moves. The situation is actually more like 'stacking' than like gating: it is like two pieces are stacked on the same square, and only the topmost piece is allowed to move, thereby uncovering what was underneath. For this reason one of the proposed FEN formats would use a general notation for stacked pieces, by enclosing the occupants of a square in parentheses when there is more than one. E.g.

rn(bc)q(ku)bnr/pppppppp/8/8/8/8/PPPPPPPP/R(NU)BQKB(NC)R w KQkq - 0 1

Note that this then would be an 8x8 FEN again.

Thanks that all makes sense. I would rather implement features that could be used in other variants as well, and a "stacked" piece is one such case. I think it is best to keep the board 8x8 and treat the musketeers as stacked pieces ready to be uncovered or special type of holding pieces. The GUI can display it as it wants but for engine programmers it adds more complexity to treat it as 8x10 -- already had a bug that the musketeer piece moves directly into play without gating since i treated rank 0 and 9 as part of the board.

But GUIs would in general not be able to display stacks of pieces, and a straightforward work-around for that is to add dummy 0th and 9th ranks to the board display, on which the pieces could be shown directly above/below the location where they gate. Like you say, these dummy ranks are 'water', and moves into them from the proper (8x8) board should not be allowed. When a piece is gated, the off-board 'square' it came from should also revert to water rather than empty. As a GUI designer I would also stop displaying pieces that lost their gating possibility because the piece at the gate was captured. Ferdy, however, would consider it important to keep such pieces on display. (This seems mostly a hypothetical problem, as no sane player would ever allow his gating opportunity to be destroyed that way; Musketeer pieces are all so valuable that even together with a minor they would be worth more that a Queen. Gatings are also likely to occur very early in the opening, long before any complex tactics can develop, as (unlike in Seirawan Chess) there is no benefit in postponing the gating when the opponent already knows where it is going to occur.)

When a musketeer piece gates, I do replace the from-square with 'water'. But if the musketeer piece is out of action because the piece in front gets captured I don't take care of it, for efficiency reasons at the moment. I guess this is no problem as long as nebiyu is not used as a referee engine.

The current WinBoard + KingSlayer implementation of Musketeer Chess plays this as an engine-defined variant 8x10+0_seirawan, and I made some modifications in WinBoard that cause special handling of 'holdingless' seirawan: in that case the extreme ranks of the specified board are treated as holdings instead, but unlike the normal holdings, these then are file-specific holdings, where the location in the holdings implies the location where the piece must gate. I did not make any modifications in the FEN parser and generator (yet), so it still uses the 'natural' (WYSIWYG) representation

**c*u***/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*U****C* w KQkq - 0 1

for the same position as given above.

As for the move format, WinBoard still uses (and requires) the normal Seirawan notation, where a promotion suffix on a non-Pawn move is interpreted as gating. But as the gating is implied it ignores the actual value of the suffix, and always gates what is on the 0th/9th rank behind it. Without gating suffix it declines gating, though, so the engine must suffix gating moves, and will receive suffixed moves from WinBoard on a gating. I will probably still fix this, making gating fully automatic, so that the engine no longer has to send suffixes. In SAN I would still prefer to explicitly indicate gating (through a '/H' prefix for Hawk, etc.), just to enhance human readability.

I think I will wait till you implement winboard to accept moves without suffix. Also, nebiyu will probably crash if it gets the gating move with promotion letter, do you also plan to send plain b1c3 for the engine as well? I understand the need to suffix it in PGN for clarity though ..

Because it is implemented as an engine-defined variant, the engine will determine through its 'setup' command which pieces participate, in the pieceToCharTable part. WinBoard will then only allow promotion to one of the participating pieces. Since in Musketeer Chess this is only known after the players have selected a piece type, the final setup command is only sent after this (and the gating locations) is decided. To not run into complaints of WinBoard for not getting a setup command as immediate response to the 'variant' command, WinBoard now implements a mechanism to allow the engine to defer the setup command to a later time, by sending a 'non-final' setup command that specifies parent variant 'prelude', a dummy variant with unspecified rules. The FENs in such prelude setup commands can be used to present arbitrary board positions to the user, which can be used as 'graphical menus' for selecting pieces or squares (clicks on them fed back to the engine through the 'lift' command of the highlight protocol). KingSlayer uses this possibility for conducting the negociation phase in human-engine games.

If the engine is used for analysis of a random position, how is it to know which pieces it can promote to? In shogi you can promote to a subset of all pieces, but musketeer is the first variant that has promotion pieces depending on start position. Right now nebiyou promotes only to the standard pieces (QRBN) because I am not sure how to handle all cases properly ...

[hgm]

If the engine is used for analysis of a random position, how is it to know which pieces it can promote to? In shogi you can promote to a subset of all pieces, but musketeer is the first variant that has promotion pieces depending on start position. Right now nebiyou promotes only to the standard pieces (QRBN) because I am not sure how to handle all cases properly ...

This is currently an unsolved problem. One approach would be: just paste the game from a positon where all pieces were still present, rather than the position you want to analyze. Then the engine can see the pieces before they were gated. This would also be what you had to do in cases where repetitions would interfere with optimal play, (pasting from the last irreversible move on), so it is not unheard of.

An alternative would be to encode this in FEN, by introducing a promotion-choice field in those. Like "=NBRQCU".

A very kludgy approach would be to use an already existing aspect of FEN notation that normally means something different for this, when the normal meaning makes no sense. E.g. show the two 'guest' pieces as if the are in the hand (i.e. between [] after the board), while no holdings are defined. Or stack them under the left-most Pawn with the () notation.

For now I think the game-pasting method will do. For that the engine just has to keep track of which pieces that are not PNBRQK occur in the board-part of the FEN. These would then be enabled as promotion choice. We can always add enabling of other choices by yet-to-define FEN fields later.

[musketeerchess]

@Ferdy Thanks, I now understand how the piece selection rules work

@HG My implementation was rather limited because I assumed that the fairy pieces are already in play. I did not even
implement how they get into play properly. It is my understanding that ranks 0 and 9 are "water" and can not be moved to
with other pieces. I have a holdings area just like that but is not file-restricted. So are there represented in the FEN as
e.g [C2D1c4d3] where they are preceded by file numbers? The drop rule is not a regular one and I probably need to implement a
special rule for it ( Not moved piece + drop-to-from square -- I like Ferdy representation with promotion letters but since I have a combo move
capability it may be easier for me to do "move b1c3 move C@b1" )
Edit: In a way the drops of pieces is square-restricted because it can only go to first/last rank. So the first time the target square becomes
empty, I drop it or lose it forever. In the latter case, do we just remove the piece from the holdings list forever?

@musketeerchess Thanks for the piece values. King's value is just a placeholder ( is actually infinity ). Anyway, I may decide to train
a neural network for it if it turns out to be simple enough.

Hi Daniel

The NN idea is great.
If the drop is lost the piece is removed and can no longer be dropped again. It’s possible to have it back ehen a pawn promotes. It can promote to any piece than begun the game. Even though the drop was lost it’s still possible to promote to this lodt piece as many times as there are promoted pawns