Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

how to play with this programs #4

Open
raphaeleliekakou opened this issue Mar 27, 2020 · 55 comments
Open

how to play with this programs #4

raphaeleliekakou opened this issue Mar 27, 2020 · 55 comments

Comments

@raphaeleliekakou
Copy link

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
Copy link
Owner

ianfab commented Mar 27, 2020 •
edited
Loading

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:

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
Copy link
Owner

ianfab commented Mar 27, 2020

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
Copy link
Author

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
Copy link

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
winboard doesn't display correctly the remaining squares

@ianfab
Copy link
Owner

ianfab commented Mar 28, 2020

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
Copy link

musketeerchess commented Mar 28, 2020 via email

@ianfab
Copy link
Owner

ianfab commented Mar 28, 2020

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):

Musketeer-Stockfish/src/types.h

Lines 198 to 212 in 0cd871b

PawnValueMg = 171, PawnValueEg = 240,
KnightValueMg = 764, KnightValueEg = 848,
BishopValueMg = 826, BishopValueEg = 891,
RookValueMg = 1282, RookValueEg = 1373,
QueenValueMg = 2500, QueenValueEg = 2670,
CannonValueMg = 1710, CannonValueEg = 2239,
LeopardValueMg = 1648, LeopardValueEg = 2014,
ArchbishopValueMg = 2036, ArchbishopValueEg = 2202,
ChancellorValueMg = 2251, ChancellorValueEg = 2344,
SpiderValueMg = 2321, SpiderValueEg = 2718,
DragonValueMg = 3280, DragonValueEg = 2769,
UnicornValueMg = 1584, UnicornValueEg = 1772,
HawkValueMg = 1537, HawkValueEg = 1561,
ElephantValueMg = 1770, ElephantValueEg = 2000,
FortressValueMg = 1956, FortressValueEg = 2100,

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
Copy link
Author

raphaeleliekakou commented Mar 28, 2020 via email

@musketeerchess
Copy link

musketeerchess commented Mar 28, 2020 via email

@ianfab
Copy link
Owner

ianfab commented Mar 28, 2020

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
Copy link

musketeerchess commented Mar 28, 2020 via email

@ianfab
Copy link
Owner

ianfab commented Mar 28, 2020

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
Copy link

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
Copy link
Owner

ianfab commented Mar 29, 2020 •
edited
Loading

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
Copy link

musketeerchess commented Mar 29, 2020 via email

@ianfab
Copy link
Owner

ianfab commented Mar 29, 2020

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
Copy link

musketeerchess commented Mar 29, 2020 via email

@musketeerchess
Copy link

musketeerchess commented Mar 30, 2020 via email

@musketeerchess
Copy link

Error with Musketeer Stockfish after editing the starting position

@musketeerchess
Copy link

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

Fairy Max window that opens at the beginning of the game to chose the first fairy piece by white

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

After that the engine choses the second fairy piece and the following window appears where whe have to place his Unicorn as first fairy piece

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

I chose unicorn in g0 and engine chose unicorn on b9

Then i chose Amazon on c9 and engine chose amazon on f9

@ianfab
Copy link
Owner

ianfab commented Mar 30, 2020 •
edited
Loading

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.

This was referenced Mar 30, 2020
Closed
Open
@HGMuller
Copy link

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
Copy link
Owner

ianfab commented Mar 30, 2020

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
Copy link

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
Copy link

musketeerchess commented Mar 30, 2020 via email

@HGMuller
Copy link

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
Copy link

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
Copy link
Author

raphaeleliekakou commented Mar 30, 2020 via email

@musketeerchess
Copy link

musketeerchess commented Mar 30, 2020 via email

@HGMuller
Copy link

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
Copy link

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
Copy link

musketeerchess commented Mar 30, 2020 via email

@HGMuller
Copy link

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
Copy link

musketeerchess commented Mar 30, 2020 via email

@musketeerchess
Copy link

musketeerchess commented Mar 30, 2020 via email

@HGMuller
Copy link

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
Copy link

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
Copy link

musketeerchess commented Mar 31, 2020 via email

@musketeerchess
Copy link

musketeerchess commented Mar 31, 2020 via email

@HGMuller
Copy link

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
Copy link

HGMuller commented Apr 1, 2020 •
edited by ianfab
Loading

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
Copy link

HGMuller commented Apr 1, 2020

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

@ianfab
Copy link
Owner

ianfab commented Apr 1, 2020

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
Copy link

musketeerchess commented Apr 1, 2020 via email

@HGMuller
Copy link

HGMuller commented Apr 1, 2020 •
edited
Loading

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
Copy link

HGMuller commented Apr 1, 2020

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
Copy link

musketeerchess commented Apr 1, 2020 via email

@raphaeleliekakou
Copy link
Author

raphaeleliekakou commented Apr 1, 2020 via email

@HGMuller
Copy link

HGMuller commented Apr 2, 2020

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
Copy link

HGMuller commented Apr 2, 2020

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

@musketeerchess
Copy link

musketeerchess commented Apr 2, 2020 via email

@raphaeleliekakou
Copy link
Author

Hello friends, hope all are safe.
Are there news when musketeer will be in fairy stockfish and pychess?
Thank you
Raphael

@ianfab
Copy link
Owner

ianfab commented Apr 7, 2020

The corresponding thread for the implementation in Fairy-Stockfish is in fairy-stockfish/Fairy-Stockfish#32. I am working on it, but it is hard to predict when it will be ready. Considering that I basically can not reuse any code from this fork but have to reimplement it from scratch, it definitely is not a small task.

@raphaeleliekakou
Copy link
Author

GOOD EVENING FABIAN.
I'm back after a few weeks suffering from the horrific Covid-19. It weakened me and i'm happy to be breathe again.
Have not followed you for a long moment. do you improved in finding solution for musketeer chess and add it to fairy stockfish?
I tried to play a new variant i discoved in pychess. It is Seirawan House ! Very nice.
What about Musketeer House also?

I'm happy to be alive and it's great to be back. Hope all of you are safe and in good health.
Raffa the survivor. (i will think about a chess variant i will call it survivor chess !)

@musketeerchess
Copy link

Hi Raphael
Glad you are back. I think that Fabian is working on it but it's not right now his top priority.
Hope he will merge Seirawan and Musketeer Variants allowing for a simple programming choice; in fact, the right way to distinguish between both variants seems to be as follows: apart from different and additional pieces used in Musketeer Chess, the Gating process is the only remaining difference. So may be the code should be as follows: When chosing Musketeer or Seirawan, additional piece choice is activated, which allows additional pieces. Then the choice between Seirawan and Musketeer triggers the rules concerning Piece Selection and Gating Selection for the drop rules of the pieces.
In my opinion, Making Musketeer Regulations default as the regulations is the easiest way, and Seirawan will be a Short Cut as the Piece Selection can be shunted (the Pieces are Known so there is no choice) and the Drop is made without need for Gating Pre-Selection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ianfab @HGMuller @musketeerchess @raphaeleliekakou