how to play with this programs

[raphaeleliekakou]

hi i'm interested in chess and variants. i like particularly this one as i met with the inventor and he shared with me many of his ideas and choices. find it incredible. how can i use this porgram to play it? also i see a server pychess to play chess and variants. why this variant doesn't exist there? how to make it exist there as i saw that stockfish is behind pychess website. thank you RAPHAEL

[ianfab]

Hi, currently the only way to use this engine is via its command line interface (also see https://github.com/ianfab/Musketeer-Stockfish/wiki/Interface). However, I am working on two things for integration with GUIs:

• make this fork compatible with the Winboard FEN format for Musketeer chess, see https://github.com/ianfab/Musketeer-Stockfish/issues/3
• support Musketeer chess in Fairy-Stockfish (this is the fork with support for plenty of variants that is used for pychess), see https://github.com/ianfab/Fairy-Stockfish/issues/32

However, both require quite some work (the former less than the latter), and since I in parallel also work on many other variants and features for Fairy-Stockfish it is hard to predict when these will be finished.

[ianfab]

I had time today so I decided to tackle the first point. Musketeer-Stockfish should now be compatible with XBoard/Winboard. Just make sure to add it as an XBoard engine and not as UCI. The implementation in Fairy-Stockfish will be much more work though, since I can not reuse as much code as I could in this case.

[raphaeleliekakou]

Hi ianfab, thanks for this update. i wish your work succeeds rapidely. looking it. downloaded winboard and waiting for fairy stockfish update with musketeer variant. thanks again. great to have poeple like you here. i wanted also to send an encouragement message to Dr Haddad who's fighting againt the virus helping critically ill patients. hope all of you will remain safe and hope our doctor will succeed in his mission, with the help of divinity.

[musketeerchess]

Hi Fabian, thanks for this outstanding work. came through it after a difficult night shift at the hospital. There is a small bug related to winboard that doesn't display correctly all the gating squares. It's probably because the Leopard and Cannon are gating by default at a1 / a8 b1/b8 squares. Will see this with HG. Also after gating the pieces that gated remain visible on Gating squares. This reminds the engine which pieces can be promoted, but in terms of game playability for a human it's a problem. This is probably related to a particular way the engine is communicating with the GUI and should be fixed easily discussing with HG. I will ask him.

By the way how it's possible to change the piece combination that will begin the game? Best regards Zied

[ianfab]

Hi Zied. For me the gating works fine in XBoard, the gated piece disappears from the original square (e.g., b0) and the square turns black. Do you use an up-to-date version of Winboard?

In order to change the choice of gating pieces or squares, the starting position needs to be edited (ctrl+shift+e). You should be able to move the gating pieces to any square on the 0th/10th rank and you should also be able to select all other possible gating pieces. Just make sure that both sides use the same set of gating pieces, otherwise it might crash.

[musketeerchess]

Hi Fabian I use winboard 4.9.1 there were many releases recently so i'm unable to tell which version it is really as HG have done some small changes each time.

Anyway the mentioned issues are far from being vital. The most important is to have Something decent and working. By the way, the promotion of the new pieces works fine and the engine choses when promoting a piece a Cannon (and not a Queen) as the Cannon can mate a bare king alone and faster !! Really important to know such small tricks as this will help improve the engine evaluation during the endgames (and also middle games) to help make the most important décisions concerning which pieces to trade and which to keep.

At first when i thought about the variant, my evaluation of the cannon was barely Superior to a Rook. But after playing many games with it i noticed the importance of this piece as a defender, but also as a roller coaster especially in the endgames as it attacks relentlessly and can mate alone.

Can you tell me which evaluation features you used for the pieces and their relative values programmed?

Thanks alot for your tremendous and valuable work.

I cannot wait to see it merging with Fairy-Stockfish to be able to play it on pychess server.

Best regards Zied

Le sam. 28 mars 2020 à 17:07, Fabian Fichter notifications@github.com a écrit :

Hi Zied. For me the gating works fine in XBoard, the gated piece disappears from the original square (e.g., b0) and the square turns black. Do you use an up-to-date version of Winboard?

In order to change the choice of gating pieces or squares, the starting position needs to be edited (ctrl+shift+e). You should be able to move the gating pieces to any square on the 0th/10th rank and you should also be able to select all other possible gating pieces. Just make sure that both sides use the same set of gating pieces, otherwise it might crash.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605467564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HKVL2TTS6ESXXCNUGDRJYOFLANCNFSM4LUVHSDA .

[ianfab]

When I finished the initial implementation I ran an automated tuning (using SPSA) of piece values, and I did not change the piece any more since then. You can find them in the code (Mg and Eg mean middlegame and endgame, respectively): https://github.com/ianfab/Musketeer-Stockfish/blob/0cd871b0ef3cce1df27d7a030d7a68696f9459b3/src/types.h#L198-L212

I also tried to normalize those values to the typical piece value scale and got this:

Piece	midgame	endgame
Pawn	0.66	0.92
Knight	2.94	3.26
Bishop	3.18	3.43
Rook	4.93	5.28
Queen	9.62	10.27
Cannon	6.58	8.61
Leopard	6.34	7.75
Archbishop	7.83	8.47
Chancellor	8.66	9.02
Spider	8.93	10.45
Dragon	12.62	10.65
Unicorn	6.09	6.82
Hawk	5.91	6.00
Elephant	6.81	7.69
Fortress	7.52	8.08

[raphaeleliekakou]

Hi Fabian Very interesting and the results for the Cannon confirm my first thoughts. It's very very strong in the endgame as it défends well and controls many many adjacent squares making the opponent king worthless to attack it.

Probably attackability by the opponent king is a parameter that can be Added for fairy pieces ti refine their relative value. Anyway, i read an article about the SPSA method of tuning and it's among the Tools that can be used. What astonishes me is the value of the Dragon (or Amazon) almost as strong as the queen. That's because Amazon vs Queen endings are certainly a draw !!

Le sam. 28 mars 2020 à 17:52, Fabian Fichter notifications@github.com a écrit :

When I finished the initial implementation I ran an automated tuning (using SPSA) of piece values, and I did not change the piece any more since then. You can find them in the code (Mg and Eg mean middlegame and endgame, respectively): https://github.com/ianfab/Musketeer-Stockfish/blob/0cd871b0ef3cce1df27d7a030d7a68696f9459b3/src/types.h#L198-L212

I also tried to normalize those values to the typical piece value scale and got this: Piece midgame endgame Pawn 0.66 0.92 Knight 2.94 3.26 Bishop 3.18 3.43 Rook 4.93 5.28 Queen 9.62 10.27 Cannon 6.58 8.61 Leopard 6.34 7.75 Archbishop 7.83 8.47 Chancellor 8.66 9.02 Spider 8.93 10.45 Dragon 12.62 10.65 Unicorn 6.09 6.82 Hawk 5.91 6.00 Elephant 6.81 7.69 Fortress 7.52 8.08

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605487747, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO6TGWML2PPHLPFJFZX2PBTRJYTOJANCNFSM4LUVHSDA .

[musketeerchess]

Hi Raphael, dear Fabian I agree with both of you.

Raphael: I see that not only you understood extremely well our discussions concerning the pieces and their relative value, you now got your own ideas after some practice. The King attackability is in deed a good idea !

It's been a long time since we played our last game (almost a month) and during this last game, i tricked you and won it, but you improved your level of play a lot and i think you are becoming a though opponent.

Let's wait for the Pychess server with Musketeer Chess, we'll then can ply some live games and test our understandings of the game.

I count on you testing Musketeer Stockfish, reporting eventual bugs, but most importantly learn from these games and share this knowledge. Use Winboard as planned.

The results published by Fabian concerning the relative value are outstandingly interesting and could sometimes be interpreted as quite "astonishing". But if you think about them they are not astonishing just logical.

The less we know pieces the more we over or Under estimate them.

Till now i have had an own assessment of their relative value that Evolved with the help of Ferdinand Mosca. The methodology we used to have an idea concerning the piece value will certainly be reviewed and further improved.

The Dragon and Queen value at the endgame is quite the same, but there should be additional parameters to take into account. The Amazon will lose value vs Queen the more pieces are traded. As the strongest piece, it is attacked easier by the other less valuable pieces making it's use and manoeuvring difficult. The Amazon is a beast when it come to attack the king, forking (16 different forking directions etc). It needs an empty board to exploit these extra ordinary forking capabilities but it also needs a few remaining pawns, pieces that will be targeted by these forking capabilities. The best forking attacks are when attacking the king or Queen at the same time without being attacked by other pieces. This needs certainly to be studied when making EGTB for 5-7 Men using King + Amazon + 1 or 2 other man vs King + Queen + 1 other man. Making statistics from these endings and seeing the positions where the Amazon will prevail will give certainly a good appreciation of the positional characteristics for the Amazon to bring the advantage.

Fabian: Can you share the tool used for SPSA. I'd like to use ot for many other Fairy pieces. Also i'd like to make a bigger work on other variants using other boards especially the 10x8 and 10x10 boards. My goal after this work is to comeup with a mathematical formula approaching the change in the relative value of the pieces for bigger boards than the 8x8.

Thanks again

Zied

Le sam. 28 mars 2020 à 21:33, raphaeleliekakou notifications@github.com a écrit :

Hi Fabian Very interesting and the results for the Cannon confirm my first thoughts. It's very very strong in the endgame as it défends well and controls many many adjacent squares making the opponent king worthless to attack it.

Probably attackability by the opponent king is a parameter that can be Added for fairy pieces ti refine their relative value. Anyway, i read an article about the SPSA method of tuning and it's among the Tools that can be used. What astonishes me is the value of the Dragon (or Amazon) almost as strong as the queen. That's because Amazon vs Queen endings are certainly a draw !!

Le sam. 28 mars 2020 à 17:52, Fabian Fichter notifications@github.com a écrit :

When I finished the initial implementation I ran an automated tuning (using SPSA) of piece values, and I did not change the piece any more since then. You can find them in the code (Mg and Eg mean middlegame and endgame, respectively):

https://github.com/ianfab/Musketeer-Stockfish/blob/0cd871b0ef3cce1df27d7a030d7a68696f9459b3/src/types.h#L198-L212

I also tried to normalize those values to the typical piece value scale and got this: Piece midgame endgame Pawn 0.66 0.92 Knight 2.94 3.26 Bishop 3.18 3.43 Rook 4.93 5.28 Queen 9.62 10.27 Cannon 6.58 8.61 Leopard 6.34 7.75 Archbishop 7.83 8.47 Chancellor 8.66 9.02 Spider 8.93 10.45 Dragon 12.62 10.65 Unicorn 6.09 6.82 Hawk 5.91 6.00 Elephant 6.81 7.69 Fortress 7.52 8.08

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605487747 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AO6TGWML2PPHLPFJFZX2PBTRJYTOJANCNFSM4LUVHSDA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605515977, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HIZBHTRYLJHAQBDEODRJZNLDANCNFSM4LUVHSDA .

[ianfab]

Yes, there is a lot of room for improvement regarding considering the fairy pieces in the evaluation, since I so far only tuned the piece values, whereas mobility, king safety, etc. are not adjusted yet. After further evaluation improvements the piece values might need to re-tuned.

For tuning I used https://github.com/ianfab/spsa, which I also use for other Stockfish variant forks.

In Fairy-Stockfish I also use a scaling formula for piece values depending on board size, so you can also have a look how it is working there (but I am currently re-working the formula, the tests on fishtest are already ongoing): https://github.com/ianfab/Fairy-Stockfish/blob/eb6b76cd69eb89639ea484907ddd811f9b70b894/src/psqt.cpp#L142-L149

[musketeerchess]

I will definitely take a close look at it. Nice and impressive work.

This is inspiring to refine the relative value and i'll use it to further refine simpler methods we worked on when first thinking about the piece value so this simple method can be used (even though less precise) by persons that cannot program to have a simple way to approach the relative value of their invented fairy pieces.

So Method SPSA = Fabian

And method: Simple Assessment of Relative Piece Value by Mosca / Haddad = SiARPiV or find another cuter name for this method. I'll ask Ferdy to clean it and publish it.

Le sam. 28 mars 2020 à 22:03, Fabian Fichter notifications@github.com a écrit :

Yes, there is a lot of room for improvement regarding considering the fairy pieces in the evaluation, since I so far only tuned the piece values, whereas mobility, king safety, etc. are not adjusted yet. After further evaluation improvements the piece values might need to re-tuned.

For tuning I used https://github.com/ianfab/spsa, which I also use for other Stockfish variant forks.

In Fairy-Stockfish I also use a scaling formula for piece values depending on board size, so you can also have a look how it is working there (but I am currently re-working the formula, the tests on fishtest are already ongoing): https://github.com/ianfab/Fairy-Stockfish/blob/eb6b76cd69eb89639ea484907ddd811f9b70b894/src/psqt.cpp#L142-L149

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605519206, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HONBRU6WSVDTBPJPHTRJZQZLANCNFSM4LUVHSDA .

[ianfab]

Neither the SPSA algorithm nor the original SPSA implementation for Stockfish was written by me, I only slightly adjusted it to be able to use it for chess variants. It is just a very convenient way of re-using the machinery that was developed for official stockfish and apply it to Stockfish forks.

[musketeerchess]

Hi Fabian, GHM Musketeer Stockfish is Simply awesome. I personally learn alot when seeing him play matches and how he uses the new pieces. Unlike other engines, it doesn't really trade the Fairy pieces rapidly.

I'm frustrated of only one thing, it's impossible to load FEN positions in it to change the Fairy piece default choice which is Always Leopard and Cannon. I'm using the 4.9.2020.114 winboard version. Don't know if it's the latest one.

Only able to play engine vs engine a single game Editing the initial position but i must do the procedure before each game !

[ianfab]

If you let the engine play a tournament you can select a "File with start positions" and if you put your starting FEN into a file and select it there, the tournament games should be started from that position. Or are you also referring to human vs. engines?

[musketeerchess]

Hi I'm just referring for engine tournament. My version is winboard 4.9.2020.114 what's yours?

Can you send me a download link?

Zied

Le dim. 29 mars 2020 à 16:41, Fabian Fichter notifications@github.com a écrit :

If you let the engine play a tournament you can select a "File with starting positions" and if you put your starting FEN into a file and select it there, the tournament games should be started from that position. Or are you also referring to human vs. engines?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605647097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HPONBU3HFLOVHK2EO3RJ5MYHANCNFSM4LUVHSDA .

[ianfab]

I use XBoard under Linux compiled from the most recent version at http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=xboard.git;a=shortlog;h=refs/heads/v4.9.x. However, I was now able to reproduce the issue even using an opening book. This has to be a bug in Winboard/XBoard.

[musketeerchess]

I think so.

sent an email to HG asking him to check the issue. I'm really having.

Hope you can add it soon to fishtest and merge with fairy stockfish so i can enjoy playing with humans again.

Le dim. 29 mars 2020 à 17:05, Fabian Fichter notifications@github.com a écrit :

I use XBoard under Linux compiled from the most recent version at http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=xboard.git;a=shortlog;h=refs/heads/v4.9.x. However, I was now able to reproduce the issue even using an opening book. This has to be a bug in Winboard/XBoard.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605650812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HPAX7YISTQOASQUSJDRJ5PVFANCNFSM4LUVHSDA .

[musketeerchess]

Hi Fabian, HG

I got the latest winboard edition (Always downloadable from the same URL HG delivered to us).

Here are some bugs between GUI and Engine communication. The Winboard i use is the 4.9.2020.207 you can find here: http://hgm.nubati.net/WinBoard-AA.zip

There are still bugs.

In the Following game, i edited the position that started with Cannon on b0/b9 and Leopard on a0/a9 I have chosen instead a Hawk c0/c9 and Elephant e0/e9.

After beginning the game, white have gated a Hawk in b1 (supposed to gate only in c1): First bug. The white elephant gated correctly on e1 square after castling.

For black it was the same: Hawk gated on b8 square. Elephant on e8 square after castling. After that, the GUI crushed after black played an illegal move f8-e8 (engine forgot about the elephant that exists in e8 square).

[image: Error with Musketeer Stockfish after editing the starting position.png]

I liked the feature offered by Fairy Max playing Musketeer Chess where a first window with the 10 pieces are showed first.

[image: Fairy Max window that opens at the beginning of the game to chose the first fairy piece by white.jpg]

And Following choice of the engine choice: Here i made of the choice of a Unicorn and the engine have chosen an Amazon.

Is it possible to correct the following: Make the white pieces appear on White territory. I'm used to this but it is a bit confusing for someone that begins the game without really mastering the rules.

[image: After that the engine choses the second fairy piece and the following window appears where whote have to place his Unicorn as first fairy piece.jpg]

Here is the final position which is very fine and then the game can begin.

[image: Then i chose Amazon on c9 and engine chose amazon on f9.jpg]

Musketeer Stockfish seems to behave as follows: Considers Musketeer Chess as a Seirawan version chosing by default the Leopard and Cannon and chosing the gating squares by default to a0/a9 for Leopard and b0/b9 for Cannon.

Till now what i saw is that the Musketeer Stockfish is absolutely bug free when handling the fairy pieces.

So the only issue is related to switching the fairy piece choice and the initial gating square.

In my opinion, this is to be fixed naturally by working together with HG. It seems that Musketeer Stockfish and Winboard doesn't communicate adequately when changing the piece choice and initial gating square location.

But the most urgent is certainly to merge Musketeer stockfish with Fairy Stockfish to be able to put it in the server.

Thanks for all the persons that helped and made this possible ( i think about Ferdinand Mosca, Daniel Shaul also and others with minor contributions).

Zied

Le dim. 29 mars 2020 à 17:15, Musketeer Chess musketeerchess@gmail.com a écrit :

I think so.

sent an email to HG asking him to check the issue. I'm really having.

Hope you can add it soon to fishtest and merge with fairy stockfish so i can enjoy playing with humans again.

Le dim. 29 mars 2020 à 17:05, Fabian Fichter notifications@github.com a écrit :

I use XBoard under Linux compiled from the most recent version at http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=xboard.git;a=shortlog;h=refs/heads/v4.9.x. However, I was now able to reproduce the issue even using an opening book. This has to be a bug in Winboard/XBoard.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-605650812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HPAX7YISTQOASQUSJDRJ5PVFANCNFSM4LUVHSDA .

[musketeerchess]

[musketeerchess]

I liked the feature offered by Fairy Max playing Musketeer Chess where a first window with the 10 pieces are showed first.

And Following choice of the engine choice: Here i made of the choice of a Unicorn and the engine have chosen an Amazon.

Here is the final position which is very fine and then the game can begin.

[ianfab]

I think I found the issue regarding the gating on wrong squares. The problem is that if you manually edit the starting position, then the empty squares do not turn black. In that case those squares are represented like empty squares in the FEN instead of like holes, e.g., 2h*u***/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/2H*U*** w KQkq - 0 1 instead of **h*u***/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/**H*U*** w KQkq - 0 1. Musketeer-Stockfish only counts the number of asterisks/pieces and treats the 2 like one square. I will fix this in the evening after work.

The setup phase for Winboard as you showed definitely is on the agenda, but it is something that is not essential for game play (although a very nice convenience feature of course), so it does not have the highest priority for now. I will open a separate issue for it.

Edit: I split out the bug and the feature request to #5 and #6.

[HGMuller]

I guess the Edit Position mode of WinBoard allows too much freedom to the user, making it too easy to create invalid positions. In particular, it allows arbitrarily many pieces on the gating ranks, and also allows the user to put empty squares there. It leaves the responsibility for blacking out the squares again to the user. The way to create black squares is to drag an empty square off the board. But the user could also do this for squares on the proper board, creating holes. I guess more restrictions should be put on the creation of holes in Edit Mode. E.g. only when legality testing is off. Since the parent variant here is 'holdingless seirawan', WinBoard can know that empty squares on the gating ranks are never allowed. So it should black those out automatically when a piece is moved away, and not leave it to the user to do that.

I don't think you have to adapt Stockfish' FEN parser to handle this. It should be considered a user error invited by a WinBoard bug, and I will fix it in WinBoard by more sensible handling of black squares in Edit Position mode.

[ianfab]

Thanks, I was not aware that it is possible to black out squares manually. I agree that this should also be fixed in Winboard, I just thought it anyway does not hurt to make the FEN parser more robust.

[HGMuller]

Well, Edit Position is supposed to be a way to move things around without being restricted by the game rules. But I suppose editing a position is still a lesser-degree offense than editing the board...

[musketeerchess]

[image: loading the engine some options.png] Hi Fabian Each time i tried to edit the position i was very careful. Always i made the choice of the same combination of pieces for both sides. Sometimes gating squares are not symmetric.

It seems that in these cases, each time i change the colour of the gatable squares, stockfish identifies them as possible alternate gating squares. So the engine will behave as if it plays a game of Seirawan (sometimes without all possible gating squares available) with different combination of fairy pieces. The bug comes from the engine that is unable to recognize the new squares used to gate apart from the a and b squares (these are recognised by default). When loading the engines from the list of engines, there is a window that opens allowing to install new engines but also there are command lines and special winboard options that could be written. May be this is one of the ways to resolve the problem, but this seems only possible to specify one piece combination and probably only one FEN position.

I Don't know which command lines possible?

Le lun. 30 mars 2020 à 17:26, HGMuller notifications@github.com a écrit :

Well, Edit Position is supposed to be a way to move things around without being restricted by the game rules. But I suppose editing a position is still a lesser-degree offense than editing the board...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606068243, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HPO5T3STI4SXKGVO73RKC22LANCNFSM4LUVHSDA .

[HGMuller]

I uploaded a new version of the WinBoard-AA package, which automatically blacks out empty squares on the 0th and 9th rank during Edit Position, when you move away one of the gatable pieces. The previous version was broken anyway. (The prelude no longer worked.) Fixed that too.

I think Edit Position should give fewer surprises now, although it is still possible to create illegal setups. (Like with more than 2 pieces on the gating ranks, or with different gating pieces for each player. Or with black squares on the board.)

Download from http://hgm.nubati.net/WinBoard-AA.zip (as always)

[HGMuller]

Turns out there also was a bug in KingSlayer-Aramis: it would only correctly accept a new position in the first game it played. Because it says 'reuse=0' at startup it was never supposed to play more than one game, and the GUI should launch a new instance for evey new game. At least that is what I thought. But it turns out that WinBoard doesn't count a game where the engine was never set thinking as a game, and will send a second 'new' command before loading a position into an engine that never moved. KingSlayer was not prepared for this, and effectively switched back to normal Chess because it did not redo the final step of the prelude (placing all gatable pieces on its internal board). I put a fixed KingSlayer version (0.5) in the WinBoard-AA package now.

[raphaeleliekakou]

Hi tried your new GUI with Stockfish. I have now an ongoing tournament of 20 games and each time the game loads with the FEN position i wanted it to be used.

I'll try a file with different FEN positions to see what happens. But your recent work seems to be fine for the moment.

Le lun. 30 mars 2020 à 20:28, HGMuller notifications@github.com a écrit :

Turns out there also was a bug in KingSlayer-Aramis: it would only correctly accept a new position in the first game it played. Because it says 'reuse=0' at startup it was never supposed to play more than one game, and the GUI should launch a new instance for evey new game. At least that is what I thought. But it turns out that WinBoard doesn't count a game where the engine was never set thinking as a game, and will send a second 'new' command before loading a position into an engine that never moved. KingSlayer was not prepared for this, and effectively switched back to normal Chess because it did not redo the final step of the prelude (placing all gatable pieces on its internal board). I put a fixed KingSlayer version (0.5) in the WinBoard-AA package now.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606165901, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO6TGWIRWTD75DRF464NXZTRKDQGHANCNFSM4LUVHSDA .

[musketeerchess]

Hi I confirm what Raphael said. I can run games from one FEN position. It's not possible to use multiple FEN positions as the choice will be Always the first FEN of the loaded file. When i save the FEN positions as games and then try to build a book there is an error message saying bad FEN positions.

Here is winboard debug file for check.

Great progress concerning running games from a single different position to play many games;

Seems that the problem is more GUI than engine to GUI communication.

I think so because it's not possible right now to make books from FEN starting positions. Haven't tried to make a few moves (apart from placing the pieces in gating squares).

Le lun. 30 mars 2020 à 20:31, raphaeleliekakou notifications@github.com a écrit :

Hi tried your new GUI with Stockfish. I have now an ongoing tournament of 20 games and each time the game loads with the FEN position i wanted it to be used.

I'll try a file with different FEN positions to see what happens. But your recent work seems to be fine for the moment.

Le lun. 30 mars 2020 à 20:28, HGMuller notifications@github.com a écrit :

Turns out there also was a bug in KingSlayer-Aramis: it would only correctly accept a new position in the first game it played. Because it says 'reuse=0' at startup it was never supposed to play more than one game, and the GUI should launch a new instance for evey new game. At least that is what I thought. But it turns out that WinBoard doesn't count a game where the engine was never set thinking as a game, and will send a second 'new' command before loading a position into an engine that never moved. KingSlayer was not prepared for this, and effectively switched back to normal Chess because it did not redo the final step of the prelude (placing all gatable pieces on its internal board). I put a fixed KingSlayer version (0.5) in the WinBoard-AA package now.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606165901 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AO6TGWIRWTD75DRF464NXZTRKDQGHANCNFSM4LUVHSDA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606167390, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HIXB7C4KF2FX3WYB7DRKDQRFANCNFSM4LUVHSDA .

[HGMuller]

You never can make books from FEN positions. Books contain moves. FENs don't. You need games in PGN format to create a book. Haven't tried that for Musketeer Chess, though. What WinBoard should be able to do is use a file that contains a number of FENs (one per line) as starting positions for games in a match. You have to specify the file in the Options - Tournament dialog, and tick the checkbox that you want to step through them (and optionally whether you want each to be used once, or twice with reversed colors). And specify after how many FENs to rewind, if you want more games thean there are positions in the file. Haven't tried that either, but I will test now if that works.

[HGMuller]

OK, I see that (at least with KingSlayer) stepping through a file with FENs does not work. The problem is that after receiving the first FEN KingSlayer limits the participating Musketeer pieces to those occurring in the FEN (to prevent the non-participating pieces will become available as promotion choice for the human user). But when the second FEN then uses other Musketeer pieces, WinBoard does not recognize their pice IDs in the FEN. Apparently the order in which WinBoard does things in a match it the reverse from what we would need it to be: it tries to read the next FEN before it has restarted the engine for a new game. Only the latter would reset the participating pieces to all possible choices. So WinBoard should not try to parse the FEN before it has received the 'setup' command from the engine that defines all the pieces. I have to think a bit about how this could be fixed.

[musketeerchess]

Found 2 bugs in winboard:

When castling, the piece behind the Rook doesn't gate. After castling he Canon h9 doesn't gate. Note that the Following position is 2 moves after castling (black castled, then played Re8).

[image: Small Winboard bug, when castling the piece behind the rook doesn't gate.jpg]

I can begin a tournament from a FEN position after Gate Selection and playing one move for example. Still impossible to see if winboard can manage to modify the initial position (only put 2 different FEN positions in the file i used).

Engine crushed unexpectedly at each game for the Following Reason: illegal move.

It doesn't allow covering for a check playing Bishop d2 and gating the corresponding piece in c1.

[image: Another bug, winboard doesn't allow white to play Bishop d2 gating Leopard on c1 - tells illegal move -.jpg]

Le lun. 30 mars 2020 à 22:31, HGMuller notifications@github.com a écrit :

You never can make books from FEN positions. Books contain moves. FENs don't. You need games in PGN format to create a book. Haven't tried that for Musketeer Chess, though. What WinBoard should be able to do is use a file that contains a number of FENs (one per line) as starting positions for games in a match. You have to specify the file in the Options - Tournament dialog, and tick the checkbox that you want to step through them (and optionally whether you want each to be used once, or twice with reversed colors). And specify after how many FENs to rewind, if you want more games thean there are positions in the file. Haven't tried that either, but I will test now if that works.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606232399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HJASZNDH26CJMAVQC3RKD6RXANCNFSM4LUVHSDA .

[HGMuller]

When does the piece at the Rook not gate? For me it does gate, both when I enter the castling by moving the King with the mouse, or type it (with KingSlayer). Is it when the engine plays the move?

[musketeerchess]

It doesn't gate when castling. It's supposed to gate on h8 but it remains in the "water"

Le mar. 31 mars 2020 à 00:07, HGMuller notifications@github.com a écrit :

When does the piece at the Rook not gate? For me it does gate, both when I enter the castling by moving the King with the mouse, or type it (with KingSlayer). Is it when the engine plays the move?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606276764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HJ3OYX2YW2WZHKBSZTRKEJ3JANCNFSM4LUVHSDA .

[musketeerchess]

i checked the PGN files, winboard notes the move Kg8. So for me it not exactly a castle !!

Normally the move should be ….o-o / Ca

Le mar. 31 mars 2020 à 00:11, Musketeer Chess musketeerchess@gmail.com a écrit :

It doesn't gate when castling. It's supposed to gate on h8 but it remains in the "water"

Le mar. 31 mars 2020 à 00:07, HGMuller notifications@github.com a écrit :

When does the piece at the Rook not gate? For me it does gate, both when I enter the castling by moving the King with the mouse, or type it (with KingSlayer). Is it when the engine plays the move?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606276764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HJ3OYX2YW2WZHKBSZTRKEJ3JANCNFSM4LUVHSDA .

[HGMuller]

Well, one problem is that the images contained in your postings do not show up for me. Neither here on the github website itself, nor in the e-mail copies I automatically get from github. Even with images I would probably not be able to reconstruct what you are doing.

You started WinBoard WinBoard with KingSlayer as first engine, selected 'musketeer' from the New Variant menu, went through the prelude to get an initial position with some Musketeer piece on h9, switched to Edit Game mode, and then played moves for both sides until you finally used the mouse to move the black King from e8 to g8. And then h8 got empty, the Musketeer piece stayed at h9, and the move was recorder in the PGN as Kg8? Are you sure you were using WinBoard 4.9.2020.330? (Look in WinBoard' s Help - About menu.) Because when I do this, the piece on h9 is gated as expected, and the move recorded in PGN as O-O/S (if the piece was a Spider).

[HGMuller]

OK, I solved the starting-FEN problem in matches, in a bit of a dirty way. The problem was that WinBoard would parse the next FEN and send it to the engine before giving the engine the opportunity to tell it what the piece IDs used in the FEN meant. I now have WinBoard remember the first set of piece IDs the engine sends at the start of the previous match game (which for Musketeer Chess contains all Musketeer pieces, to allow selection of one), and use that for interpreting the FEN for the next game. This seems a safe-enough method, as the variant should never change during a match or tournament. (It would fail for variants that randomize the participating piece types, though. But I don't know any variant that does that.)

In the process I also discovered that my patch to make KingSlayer accept underpromotions (which should not be nearly as rare in Musketeer Chess as in orthodox Chess) broke the ability to play his own promotions. I fixed that too.

The zip file at http://hgm.nubati.net/WinBoard-AA.zip now contains the fixed WinBoard (4.9.2020.331) and the fixed KingSlayer-Aramis (0.6).

[musketeerchess]

The methodology was as follows:

Load Musketeer Stockfish, then edit the positions with new fairy pieces and new gating squares. Then save the FEN positions.

[image: initial position, the cannon on e0 always gates, the cannon on h9 never gates after castling.jpg]

PGN is here and start position is here: See that when castling, the white castle move is written Kg1 / C means that the Cannon on e0 gated (normally castling is o-o not Kg1. For black it's Kg8, as the piece that gates is behind the Rook h8, gating isn't considered.

PGN is here:

1. Nf3 {+0.55/16} Nc6 {-0.14/16} 2. d4 {+0.40/18} exd4 {-0.10/15} 3. Nxd4 {+0.45/15} Nf6 {-0.07/16} 4. Nxc6 {+0.51/16} bxc6 {-0.12/18} 5. e5 {+0.82/14} Nd5 {-0.06/18} 6. c4 {+0.46/17} Bb4+ {+0.20/18} 7. Bd2/L {+0.44/17} Bxd2+ {+0.10/16} 8. Qxd2 {+0.45/18} Ne7 {+0.06/19} 9. Bd3 {+0.39/18} Kg8 {-0.08/18} 10. Kg1/C {+0.32/16} d6 {-0.18/15} 11. exd6 {+0.42/15} Qxd6 {-0.14/17} 12. Ce3 {+0.56/16} Re8 {+0.00/15} 13. Nc3 {+0.55/15} Bf5/L {+0.00/13} 14. Cf3 {+0.47/17} Bxd3 {+0.01/17} 15. Lxd3 {+0.50/15} Ng6 {-0.21/17} 16. Rfe1 {+0.33/16} Ld7 {-0.15/16} 17. Lc2 {+0.47/16} Qxd2 {-0.13/17} 18. Cxd2 {+0.41/15} f6 {-0.17/15} 19. Ne2 {+0.72/15} Le5 {-0.49/16} 20. Ce3 {+0.89/13} Rad8 {-0.57/16} 21. Rad1 {+0.80/15} Rd6 {-0.53/16} 22. f4 {+0.80/17} Ld7 {-0.30/13} 23. Cf3 {+0.62/15}

debug is here:

Le mar. 31 mars 2020 à 09:52, HGMuller notifications@github.com a écrit :

Well, one problem is that the images contained in your postings do not show up for me. Neither here on the github website itself, nor in the e-mail copies I automatically get from github. Even with images I would probably not be able to reconstruct what you are doing.

You started WinBoard WinBoard with KingSlayer as first engine, selected 'musketeer' from the New Variant menu, went through the prelude to get an initial position with some Musketeer piece on h9, switched to Edit Game mode, and then played moves for both sides until you finally used the mouse to move the black King from e8 to g8. And then h8 got empty, the Musketeer piece stayed at h9, and the move was recorder in the PGN as Kg8? Are you sure you were using WinBoard 4.9.2020.330? (Look in WinBoard' s *Help

• About* menu.) Because when I do this, the piece on h9 is gated as expected, and the move recorded in PGN as O-O/S (if the piece was a Spider).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606461771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HM56HFYR6OBRPWQYADRKGOMBANCNFSM4LUVHSDA .

[musketeerchess]

Downloaded the latest patch.

The problem is still the same.

Winboard doesn't manage well when the gatable piece is in the rook file and the manœuvre is to castle.

It handles well gating a piece on king file.

Winboard considers castling as a king move (records it on the PGN file as Kg1 when it's short castle and Kc1 when it's long castle). That's the problem !!

Le mar. 31 mars 2020 à 11:47, Musketeer Chess musketeerchess@gmail.com a écrit :

The methodology was as follows:

Load Musketeer Stockfish, then edit the positions with new fairy pieces and new gating squares. Then save the FEN positions.

[image: initial position, the cannon on e0 always gates, the cannon on h9 never gates after castling.jpg]

PGN is here and start position is here: See that when castling, the white castle move is written Kg1 / C means that the Cannon on e0 gated (normally castling is o-o not Kg1. For black it's Kg8, as the piece that gates is behind the Rook h8, gating isn't considered.

PGN is here:

1. Nf3 {+0.55/16} Nc6 {-0.14/16} 2. d4 {+0.40/18} exd4 {-0.10/15} 3. Nxd4 {+0.45/15} Nf6 {-0.07/16} 4. Nxc6 {+0.51/16} bxc6 {-0.12/18} 5. e5 {+0.82/14} Nd5 {-0.06/18} 6. c4 {+0.46/17} Bb4+ {+0.20/18} 7. Bd2/L {+0.44/17} Bxd2+ {+0.10/16} 8. Qxd2 {+0.45/18} Ne7 {+0.06/19} 9. Bd3 {+0.39/18} Kg8 {-0.08/18} 10. Kg1/C {+0.32/16} d6 {-0.18/15} 11. exd6 {+0.42/15} Qxd6 {-0.14/17} 12. Ce3 {+0.56/16} Re8 {+0.00/15} 13. Nc3 {+0.55/15} Bf5/L {+0.00/13} 14. Cf3 {+0.47/17} Bxd3 {+0.01/17} 15. Lxd3 {+0.50/15} Ng6 {-0.21/17} 16. Rfe1 {+0.33/16} Ld7 {-0.15/16} 17. Lc2 {+0.47/16} Qxd2 {-0.13/17} 18. Cxd2 {+0.41/15} f6 {-0.17/15} 19. Ne2 {+0.72/15} Le5 {-0.49/16} 20. Ce3 {+0.89/13} Rad8 {-0.57/16} 21. Rad1 {+0.80/15} Rd6 {-0.53/16} 22. f4 {+0.80/17} Ld7 {-0.30/13} 23. Cf3 {+0.62/15}

debug is here:

Le mar. 31 mars 2020 à 09:52, HGMuller notifications@github.com a écrit :

Well, one problem is that the images contained in your postings do not show up for me. Neither here on the github website itself, nor in the e-mail copies I automatically get from github. Even with images I would probably not be able to reconstruct what you are doing.

You started WinBoard WinBoard with KingSlayer as first engine, selected 'musketeer' from the New Variant menu, went through the prelude to get an initial position with some Musketeer piece on h9, switched to Edit Game mode, and then played moves for both sides until you finally used the mouse to move the black King from e8 to g8. And then h8 got empty, the Musketeer piece stayed at h9, and the move was recorder in the PGN as Kg8? Are you sure you were using WinBoard 4.9.2020.330? (Look in WinBoard' s *Help

• About* menu.) Because when I do this, the piece on h9 is gated as expected, and the move recorded in PGN as O-O/S (if the piece was a Spider).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-606461771, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HM56HFYR6OBRPWQYADRKGOMBANCNFSM4LUVHSDA .

[HGMuller]

Indeed, this is strange in multiple ways. It is strange that it writes a King move instead of O-O when generating SAN, and it is strange that it doesn't gate when reading back a game from PGN when the move has no gating suffix, but it perfectly gates in Edit Game mode when I type in the move without a gating suffix (or play it on the board). The created SAN then does have a gating suffix. I will look into it this evening.

[HGMuller]

I uploaded a new package to http://hgm.nubati.net/WinBoard-AA.zip (WinBoard 4.9.2020.401). I hope this fixes the problem, which seemed to be due to a combination of factors, in which operator error might also have contributed. Debugging was furthermore hindered by the fact that I also stumbled into a bug in KingSlayer, that didn't recognize the capture of a King that was standing on a gate as a King capture, because the combined value was interpreted as a signal requesting research of the move later, which kept it haning in an infinite loop. The package also included the fixed KingSlayyer-Aramis (0.7).

• That castlings were printed as a King move was due to the fact that the routine to generate SAN would only recognize a King move with a step > 1 as a castling when it started on the back rank, and here we use that for the gateable pieces. This should now be fixed, but had no other bad consequences than that it looked a bit weird.
• The 'PGN' game you posted above should be considered faulty: in SAN gatings should always be explicitly indicated by a gating suffix, and there is no '/C' on 9... Kg8. WinBoard was not designed to be resistant to missing gating suffixes in SAN, and I'd like to keep it that way.
• The wrong move notation was most likely caused by a bug on parsing the move WinBoard received from the engine in coordinate notation. At some point there was a discussion on TalkChess where we came to the conclusion that gating was always automatic, so that gating suffixes were really redundant. (But I still wanted to keep them in SAN, which is meant for human consumption, as a visual aid.) So we decided that we should not bother engine authors with the need to add these redundant suffixes, and I expanded the code in WinBoard for adding missing suffixes (which it also does for promotions, assuming a default choice) to handle also the 'holdingless Seirawan' case. The test for this was not complete, however: it missed the case of gating at the Rook on castling. This is how the gating could be 'lost'. This should be fixed now.
• Another problem was that WinBoard first reads a PGN, and only after the reading is complete, switches the engine to the relevant variant (which it has learned from the Variant tag of the PGN). During the parsing of the PGN it was thus not yet made aware of the game rules by the engine. This has a high chance to be fatal, because SAN can in general only be understood when you know how the pieces move. In Musketeer Chess there initially only is a single copy of each unorthodox piece, so there fortunately is never any confucion as to which Cannon or Leopard should be moved to the mentioned destination square. But there was confusion in identifying the castling, as WinBoard's default idea of a King is that it can only castle when it stands on the back-rank.

The latter problem is caused by the fact that the game posted above is not really PGN: it is just a sequence of SAN moves. A valid PGN game starts with tags, and for games with unorthodox pieces the VariantMen tag to describe how the pieces move should be considered mandatory. If I let WinBoard save the game as PGN, or copy it to clipboard, I get:

[Event "?"]
[Site "?"]
[Date "?"]
[Round "-"]
[White "?"]
[Black "?"]
[Result "*"]
[Variant "musketeer"]
[VariantMen "C:KDsN;L:B2N;K:KisO2"]
[FEN "**l****c/rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR/**L*C*** w KQkq - 0 1"]
[SetUp "1"]

{--------------
. . l . . . . c
r n b q k b n r
p p p p . p p p
. . . . . . . .
. . . . p . . .
. . . . P . . .
. . . . . . . .
P P P P . P P P
R N B Q K B N R
. . L . C . . .
white to play
--------------}
1. Nf3 {+0.55/16} Nc6 {-0.14/16} 2. d4 {+0.40/18} exd4 {-0.10/15} 3. Nxd4
{+0.45/15} Nf6 {-0.07/16} 4. Nxc6 {+0.51/16} bxc6 {-0.12/18} 5. e5
{+0.82/14} Nd5 {-0.06/18} 6. c4 {+0.46/17} Bb4+ {+0.20/18} 7. Bd2/L
{+0.44/17} Bxd2+ {+0.10/16} 8. Qxd2 {+0.45/18} Ne7 {+0.06/19} 9. Bd3
{+0.39/18} Kg8/C {-0.08/18} 10. Kg1/C {+0.32/16} d6 {-0.18/15} 11. exd6
{+0.42/15} Qxd6 {-0.14/17} 12. Ce3 {+0.56/16} Re8 {+0.00/15} 13. Nc3
{+0.55/15} Bf5/L {+0.00/13} 14. Cf3 {+0.47/17} Bxd3 {+0.01/17} 15. Lxd3
{+0.50/15} Ng6 {-0.21/17} 16. Rfe1 {+0.33/16} Ld7 {-0.15/16} 17. Lc2
{+0.47/16} Qxd2 {-0.13/17} 18. Cxd2 {+0.41/15} f6 {-0.17/15} 19. Ne2
{+0.72/15} Le5 {-0.49/16} 20. Ce3 {+0.89/13} Rad8 {-0.57/16} 21. Rad1
{+0.80/15} Rd6 {-0.53/16} 22. f4 {+0.80/17} Ld7 {-0.30/13} 23. Cf3
{+0.62/15}

This will inform WinBoard about how the pieces move, even in the absence of any engine, while the board size follows from the FEN. In particular it makes WinBoard aware that the King can castle (and how, the isO2 part), despite its unusual location. Pasting just the move part into WinBoard is not guaranteed to work. For other variants it sometimes does, if WinBoard was already switched to the variant, but not in Musketeer Chess.

[HGMuller]

Note that the forum software messed up the FEN as it disn't like the asterisks, but you will get the idea.

[ianfab]

I put the PGN into a code block to ensure that it is displayed verbatim. You just need to put the text between two sets of three backticks.

[musketeerchess]

Hi HG, Fabian This is fantastic.

The current PGN / SAN Notation, it's perfect. It gives a clear idea of everything !!

I just need now to test the updated winboard version !

Le mer. 1 avr. 2020 à 12:31, HGMuller notifications@github.com a écrit :

I uploaded a new package to http://hgm.nubati.net/WinBoard-AA.zip (WinBoard 4.9.2020.401). I hope this fixes the problem, which seemed to be due to a combination of factors, in which operator error might also have contributed. Debugging was furthermore hindered by the fact that I also stumbled into a bug in KingSlayer, that didn't recognize the capture of a King that was standing on a gate as a King capture, because the combined value was interpreted as a signal requesting research of the move later, which kept it haning in an infinite loop. The package also included the fixed KingSlayyer-Aramis (0.7).

• That castlings were printed as a King move was due to the fact that the routine to generate SAN would only recognize a King move with a step > 1 as a castling when it started on the back rank, and here we use that for the gateable pieces. This should now be fixed, but had no other bad consequences than that it looked a bit weird.
• The 'PGN' game you posted above should be considered faulty: in SAN gatings should always be explicitly indicated by a gating suffix, and there is no '/C' on 9... Kg8. WinBoard was not designed to be resistant to missing gating suffixes in SAN, and I'd like to keep it that way.
• The wrong move notation was most likely caused by a bug on parsing the move WinBoard received from the engine in coordinate notation. At some point there was a discussion on TalkChess where we came to the conclusion that gating was always automatic, so that gating suffixes were really redundant. (But I still wanted to keep them in SAN, which is meant for human consumption, as a visual aid.) So we decided that we should not bother engine authors with the need to add these redundant suffixes, and I expanded the code in WinBoard for adding missing suffixes (which it also does for promotions, assuming a default choice) to handle also the 'holdingless Seirawan' case. The test for this was not complete, however: it missed the case of gating at the Rook on castling. This is how the gating could be 'lost'. This should be fixed now.
• Another problem was that WinBoard first reads a PGN, and only after the reading is complete, switches the engine to the relevant variant (which it has learned from the Variant tag of the PGN). During the parsing of the PGN it was thus not yet made aware of the game rules by the engine. This has a high chance to be fatal, because SAN can in general only be understood when you know how the pieces move. In Musketeer Chess there initially only is a single copy of each unorthodox piece, so there fortunately is never any confucion as to which Cannon or Leopard should be moved to the mentioned destination square. But there was confusion in identifying the castling, as WinBoard's default idea of a King is that it can only castle when it stands on the back-rank.

The latter problem is caused by the fact that the game posted above is not really PGN: it is just a sequence of SAN moves. A valid PGN game starts with tags, and for games with unorthodox pieces the VariantMen tag to describe how the pieces move should be considered mandatory. If I let WinBoard save the game as PGN, or copy it to clipboard, I get:

[Event "?"] [Site "?"] [Date "?"] [Round "-"] [White "?"] [Black "?"] [Result "

*"] [Variant "musketeer"] [VariantMen "C:KDsN;L:B2N;K:KisO2"] [FEN "l c/rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR/LC** w KQkq - 0 1"] [SetUp "1"]

{-------------- . . l . . . . c r n b q k b n r p p p p . p p p . . . . . . . . . . . . p . . . . . . . P . . . . . . . . . . . P P P P . P P P R N B Q K B N R . . L . C . . . white to play --------------}

1. Nf3 {+0.55/16} Nc6 {-0.14/16} 2. d4 {+0.40/18} exd4 {-0.10/15} 3. Nxd4 {+0.45/15} Nf6 {-0.07/16} 4. Nxc6 {+0.51/16} bxc6 {-0.12/18} 5. e5 {+0.82/14} Nd5 {-0.06/18} 6. c4 {+0.46/17} Bb4+ {+0.20/18} 7. Bd2/L {+0.44/17} Bxd2+ {+0.10/16} 8. Qxd2 {+0.45/18} Ne7 {+0.06/19} 9. Bd3 {+0.39/18} Kg8/C {-0.08/18} 10. Kg1/C {+0.32/16} d6 {-0.18/15} 11. exd6 {+0.42/15} Qxd6 {-0.14/17} 12. Ce3 {+0.56/16} Re8 {+0.00/15} 13. Nc3 {+0.55/15} Bf5/L {+0.00/13} 14. Cf3 {+0.47/17} Bxd3 {+0.01/17} 15. Lxd3 {+0.50/15} Ng6 {-0.21/17} 16. Rfe1 {+0.33/16} Ld7 {-0.15/16} 17. Lc2 {+0.47/16} Qxd2 {-0.13/17} 18. Cxd2 {+0.41/15} f6 {-0.17/15} 19. Ne2 {+0.72/15} Le5 {-0.49/16} 20. Ce3 {+0.89/13} Rad8 {-0.57/16} 21. Rad1 {+0.80/15} Rd6 {-0.53/16} 22. f4 {+0.80/17} Ld7 {-0.30/13} 23. Cf3 {+0.62/15}

This will inform WinBoard about how the pieces move, even in the absence of any engine, while the board size follows from the FEN. In particular it makes WinBoard aware that the King can castle (and how, the isO2 part), despite its unusual location. Pasting just the move part into WinBoard is not guaranteed to work. For other variants it sometimes does, if WinBoard was already switched to the variant, but not in Musketeer Chess.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-607169148, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HJZ24C5PV5BYITF4ELRKMJWJANCNFSM4LUVHSDA .

[HGMuller]

Well, I still have to address the issue of recording the prelude. It turns out that WinBoard already does put a comment with a more human-friendly representation of the position in the FEN tag before the first move. (I was not sure whether the PGN standard would allow comments there, but apparently it does.) We could slip in an additional line at the top of that comment, like

white: L, black: C

to indicate who chose what. (From which the entire history of the prelude follows.) The question is: "what should trigger WinBoard to add this line?". I would like this feature to be of general use for all variants that have some kind of prelude. But that would mean WinBoard has no idea what to put there, unless the engine tells it that. One way to solve this would be to allow engines to add any text as comment to the PGN. In fact CECP already supports many commands for relaying text messages. But most of these target communication with users of Internet Chess Servers that play against the engine, or watch its games. Only 'telluser' and 'tellusererror' work in local mode, and present the text to the user as a popup. I could extend the meaning of some of the ICS-only commands to also cause an action in local mode. E.g. 'tellothers' could be made to add a comment to the PGN, and 'tellopponent' could be made to relay something to an opponent that has declared the capability to receive it by outputting 'feature chat=1' at startup. An engine that had conducted a prelude dialog with the user could then cause the summary of that prelude to be added at the beginning of the PGN by (after the final prelude action) sending

tellothers white: L, black: C

before it started thinking on its first move.

[HGMuller]

Oops, it turns out WinBoard already does this. It has a command-line option -autoComment true|false, which cause comments to be logged in the PGN before the move during which they were received with a 'tellothers' command. We could simply make sure that option is switched on when playing Musketeer Chess. Only difference with what I proposed above is that the text sent by the engine would appear in a separate comment as the position diagram, placed after the latter. I will now patch WinBoard to make an exception for a command on the first move that starts with the word "prelude"; it will then put what came after that in the same comment as the position diagram, just above the first ----- line. It is up to the engine to decide what is printed there.

[musketeerchess]

Hi The prelude in Musketeer Chess is quite unique and not so flexible for strategic reasons i spoke about in many previous messages. The most important is as follows: The information concerning the chosen pieces!

If someone choses first Chancellor and the other Archbishop in one game and in another game the first begins choosing Archbishop and the second choses Chancellor, the combination finishes by being the same. The only difference is "some finesses concerning tactics etc". And if these players chose the same GS squares the combination isexactly the same even if the path isn't the same;

Naturally, being precise concerning the order is what should be done for the historic importance when replaying the game.

In the PGN adding the suggested information White: L, Black; C is an excellent idea.

We can imagine the Following:

[Event "?"] [Site "?"] [Date "?"] [Round "-"] [White "?"] [Black "?"] [Result "

"] [Variant "musketeer"]

• [VariantMen "C:KDsN;L:B2N;K:KisO2"]*

[VariantMenSelectionOrder "C;L"] which is supposed to mean White choses C and Black L

• [FEN "lc/rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR/LC w KQkq - 0 1"] [SetUp "1"]

{-------------- . . l . . . . c r n b q k b n r p p p p . p p p . . . . . . . . . . . . p . . . . . . . P . . . . . . . . . . . P P P P . P P P R N B Q K B N R . . L . C . . . white to play --------------}

1. Nf3 {+0.55/16} Nc6 {-0.14/16} 2. d4 {+0.40/18} exd4 {-0.10/15} 3. Nxd4 {+0.45/15} Nf6 {-0.07/16} 4. Nxc6 {+0.51/16} bxc6 {-0.12/18} 5. e5 {+0.82/14} Nd5 {-0.06/18} 6. c4 {+0.46/17} Bb4+ {+0.20/18} 7. Bd2/L {+0.44/17} Bxd2+ {+0.10/16} 8. Qxd2 {+0.45/18} Ne7 {+0.06/19} 9. Bd3 {+0.39/18} Kg8/C {-0.08/18} 10. Kg1/C {+0.32/16} d6 {-0.18/15} 11. exd6 {+0.42/15} Qxd6 {-0.14/17} 12. Ce3 {+0.56/16} Re8 {+0.00/15} 13. Nc3 {+0.55/15} Bf5/L {+0.00/13} 14. Cf3 {+0.47/17} Bxd3 {+0.01/17} 15. Lxd3 {+0.50/15} Ng6 {-0.21/17} 16. Rfe1 {+0.33/16} Ld7 {-0.15/16} 17. Lc2 {+0.47/16} Qxd2 {-0.13/17} 18. Cxd2 {+0.41/15} f6 {-0.17/15} 19. Ne2 {+0.72/15} Le5 {-0.49/16} 20. Ce3 {+0.89/13} Rad8 {-0.57/16} 21. Rad1 {+0.80/15} Rd6 {-0.53/16} 22. f4 {+0.80/17} Ld7 {-0.30/13} 23. Cf3 {+0.62/15}

Le mer. 1 avr. 2020 à 19:53, HGMuller notifications@github.com a écrit :

Well, I still have to address the issue of recording the prelude. It turns out that WinBoard already does put a comment with a more human-friendly representation of the position in the FEN tag before the first move. (I was not sure whether the PGN standard would allow comments there, but apparently it does.) We could slip in an additional line at the top of that comment, like

white: L, black: C

to indicate who chose what. (From which the entire history of the prelude follows.) The question is: "what should trigger WinBoard to add this line?". I would like this feature to be of general use for all variants that have some kind of prelude. But that would mean WinBoard has no idea what to put there, unless the engine tells it that. One way to solve this would be to allow engines to add any text as comment to the PGN. In fact CECPa already supports many commands for relaying text messages. But most of these target communication with users of Internet Chess Servers that play against the engine, or watch its games. Only 'telluser' and 'tellusererror' work in local mode, and present the ext to the user as a popup. I could extend the meaning of some of the ICS-only commands to also cause an action in local mode. E.g. 'tellothers' could be made to add a comment to the PGN, and 'tellopponent' could be made to relay something to an opponent that has declared the capability to receive it by declaring 'feature chat=1' at startup. An engine that had conducted a prelude dialog with the user could then cause the summary of that prelude to be added at the beginning of the PGN by (after the final prelude action) sending

tellothers white: L, black: C

before it started thinking on its first move.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-607399292, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIIE4HPVUSDT74MJNO3S3HDRKN5RVANCNFSM4LUVHSDA .

[raphaeleliekakou]

Good news. I now tested the latest Winboard update and it handles perfectly gating through a Rook square when castling but also after a normal rook first move !

Good job

Le mer. 1 avr. 2020 à 20:22, HGMuller notifications@github.com a écrit :

Oops, it turns out WinBoard already does this. It has a command-line option -autoComment true|false, which cause comments to be logged in the PGN before the move during which they were received with a 'tellothers' command. We could simply make sure that option is switched on when playing Musketeer Chess. Only difference with what I proposed above is that the text sent by the engine would appear in a separate comment as the position diagram, placed after the latter. I will now patch WinBoard to make an exception for a command on the first move that starts with the word "prelude"; it will then put what came after that in the same comment as the position diagram, just above the first ----- line. It is up to the engine to decide what is printed there.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ianfab/Musketeer-Stockfish/issues/4#issuecomment-607414574, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO6TGWPEHH3ZFDKNL23F7Q3RKOA6XANCNFSM4LUVHSDA .

[HGMuller]

I uploaded a new version again (same link). In this version WinBoard is pre-cofigured to have the 'autoComment' mode switched on. The version of KingSlayer in there (0.8) will use the 'tellothers' command after conducting a prelude to send the prelude info. I modified WinBoard (4.9.2020.402) to recognize comments on the initial position starting with 'prelude', and put this in the PGN as a tag instead. This leads to PGN games like:

[Event "Computer Chess Game"]
[Site "MAKRO-PC"]
[Date "2020.04.02"]
[Round "-"]
[White "Makro"]
[Black "KingSlayer-Aramis 0.8"]
[Result "*"]
[TimeControl "60+1"]
[Variant "musketeer"]
[VariantMen "U:NC;L:B2N;K:KisO2"]
[FEN "l****u**/rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR/*L****U* w KQkq - 0 1"]
[SetUp "1"]
[Prelude "white: L, black: U"]

{--------------
l . . . . u . .
r n b q k b n r
p p p p p p p p
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
P P P P P P P P
R N B Q K B N R
. L . . . . U .
white to play
--------------}
1. e4 Nc6 {-0.53/10 1.3}
*

I don't want this tag to have a very specific name, as other variants must be able to use it for information that is important to them, which might be something completely different from selection of a piece type. VariantMenSelectionOrder is too specific, and would limit the usefulness. OTOH, the value of this tag is just verbatim what the engine printed between the "tellothers prelude " and the end of the line. So if we feel that the meaning of the tag must be more self-explanatory, the explanation could be put in there (like "white chooses L, black chooses U"). It is up to the engine to decide what is printed there,. But some GUIs might want to interpret this tag (although WinBoard doesn't; on loading this PGN it would simply consider it a game starting from the given FEN), so we should decide on a standard for this to which Museteer engines that orchestrate a prelude should stick.

[HGMuller]

I now made a small change in WinBoard, so that things work as above, but even if the option -autoComment is not switched on.