Engines playing Musketeer Chess, good price

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Ferdy
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Engines playing Musketeer Chess, good price

Post by Ferdy » Thu Jan 23, 2020 7:59 am

Daniel Shawul wrote:
Wed Jan 22, 2020 2:02 am
One thing I do is to allow king captures ( I seem to get 2x larger nps with it) so you may see king captures in its PV.
Encountered a position where we differ in perft 1, perhaps this is because of allowing king capture.


The white piece at D6 is a fortress. The pieces at A0 and A9 are hawks.
Nebiyu gives:
perft 1

Code: Select all

c7d6  1
f8d6  1
e8e7  1
nodes 3
This one e8e7 1 allows king capture and is illegal.

Ferdy
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Engines playing Musketeer Chess, good price

Post by Ferdy » Thu Jan 23, 2020 8:09 am

hgm wrote:
Wed Jan 22, 2020 3:42 pm
Ferdy wrote:
Tue Jan 21, 2020 11:48 pm
hgm wrote:
Tue Jan 21, 2020 4:55 pm
Ferdy wrote:
Wed Jan 15, 2020 11:59 am
hgm wrote:
Tue Jan 14, 2020 4:41 pm
The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.
There is an issue in sending a move to the engine. Gating suffix is not required but winboard sent a move with suffix.

KingSlayer(first) - aiM(second)

White to play and played,

Code: Select all

131764 <first : move c1c3
Image

Then winboad sent

Code: Select all

131764 >second: c1c3f
and was correctly rejected as illegal.

Code: Select all

131873 <second: Error (Illegal move): c1c3f
Well, this is what I wrote. WinBoard will still add gating suffixes. I want the SAN for such moves to contain suffixes, for clarity. E.g. Rc3/F. Stripping them off the move in coordinate notation would then be a bit inconsistent. On input WB considers suffixes optional.
The fortress piece on square C0 can no longer be gated. The correct move here is only c1c3 or normal move Rc3. The first engine is correct in sending the move c1c3. Winboard should just send c1c3 to the second engine. If you are not interested in fixing this, I will just let the engine ignore such move format.
Non-gatable pieces should not be on display. So the error is here that it was not blacked out after the piece in front of it was captured?
If you look at the log, winboard clearly sends c1c3f to second engine even if the first engine only sends c1c3 to winboard.

Daniel Shawul
Posts: 3974
Joined: Tue Mar 14, 2006 10:34 am
Location: Ethiopia
Contact:

Re: Engines playing Musketeer Chess, good price

Post by Daniel Shawul » Thu Jan 23, 2020 1:46 pm

Thanks, that turned out to be an actual bug in my attacks subroutine for fortress moves.
It shouldn't affect play though since I allow king captures. Set "allow_king_captures 0" when doing perfts otherewise it gives wrong results
for most of the positions. Here is the perft results after the fix upto perft 6, hope i got it right.

Code: Select all

daniel@dani-s-xp:~/nebiyu/bin$ ./NebiyuAlien variant musketeer allow_king_capture 0 setboard h*******/rfbqkbnr/pppp1ppp/n2Fp3/8/8/2N5/PPPPPPPP/R1BQKBNR/H******* b KQkq - 3 2 d perft 1 perft 2 perft 3 perft 4 perft 5 perft 6 quit
feature done=0
Number of cores 4 of 4
treeht 18641351 X 720 = 12800.0 MB
processors [1]
ht 1048576 X 48 = 48.0 MB

	    a b c d e f g h 
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	 10 h * * * * * * * * * * * * * * * * * * * * * * * * * * * 10  
	  9 r f b q k b n r * * * * * * * * * * * * * * * * * * * * 9   
	  8 p p p p . p p p * * * * * * * * * * * * * * * * * * * * 8   
	  7 n . . F p . . . * * * * * * * * * * * * * * * * * * * * 7   
	  6 . . . . . . . . * * * * * * * * * * * * * * * * * * * * 6   
	  5 . . . . . . . . * * * * * * * * * * * * * * * * * * * * 5   
	  4 . . N . . . . . * * * * * * * * * * * * * * * * * * * * 4   
	  3 P P P P P P P P * * * * * * * * * * * * * * * * * * * * 3   
	  2 R . B Q K B N R * * * * * * * * * * * * * * * * * * * * 2   
	  1 H * * * * * * * * * * * * * * * * * * * * * * * * * * * 1   
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    * * * * * * * * * * * * * * * * * * * * * * * * * * * *     
	    a b c d e f g h 
 
		[Material: 8330 8290 ]
h*******/rfbqkbnr/pppp1ppp/n2Fp3/8/8/2N5/PPPPPPPP/R1BQKBNR/H******* b KQkq - 3 2

c8d7  1
f9d7  1
nodes 2
time 0.06 sec
c8d7  22
f9d7  22
nodes 44
time 0.10 sec
c8d7  614
f9d7  721
nodes 1335
time 1.62 sec
c8d7  14725
f9d7  17196
nodes 31921
time 28.47 sec
c8d7  429065
f9d7  568672
nodes 997737
time 824.90 sec
c8d7  11047729
f9d7  14576004
nodes 25623733
time 21505.15 sec

User avatar
hgm
Posts: 24651
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Engines playing Musketeer Chess, good price

Post by hgm » Thu Jan 23, 2020 4:36 pm

Ferdy wrote:
Thu Jan 23, 2020 8:09 am
hgm wrote:
Wed Jan 22, 2020 3:42 pm
Ferdy wrote:
Tue Jan 21, 2020 11:48 pm
hgm wrote:
Tue Jan 21, 2020 4:55 pm
Ferdy wrote:
Wed Jan 15, 2020 11:59 am
hgm wrote:
Tue Jan 14, 2020 4:41 pm
The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.
There is an issue in sending a move to the engine. Gating suffix is not required but winboard sent a move with suffix.

KingSlayer(first) - aiM(second)

White to play and played,

Code: Select all

131764 <first : move c1c3
Image

Then winboad sent

Code: Select all

131764 >second: c1c3f
and was correctly rejected as illegal.

Code: Select all

131873 <second: Error (Illegal move): c1c3f
Well, this is what I wrote. WinBoard will still add gating suffixes. I want the SAN for such moves to contain suffixes, for clarity. E.g. Rc3/F. Stripping them off the move in coordinate notation would then be a bit inconsistent. On input WB considers suffixes optional.
The fortress piece on square C0 can no longer be gated. The correct move here is only c1c3 or normal move Rc3. The first engine is correct in sending the move c1c3. Winboard should just send c1c3 to the second engine. If you are not interested in fixing this, I will just let the engine ignore such move format.
Non-gatable pieces should not be on display. So the error is here that it was not blacked out after the piece in front of it was captured?
If you look at the log, winboard clearly sends c1c3f to second engine even if the first engine only sends c1c3 to winboard.
Sure, so what? If an engine sends e7e8 when there is a pawn on e7, WinBoard would also promote the pawn, and send e7e8q to the other engine. This is by design. WinBoard will replace missing promotion suffixes by a default when parsing the move. What is important is what happened in the display. Was the Fortress gated on receiving c1c3?

Ferdy
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Engines playing Musketeer Chess, good price

Post by Ferdy » Fri Jan 24, 2020 3:18 am

hgm wrote:
Thu Jan 23, 2020 4:36 pm
Ferdy wrote:
Thu Jan 23, 2020 8:09 am
hgm wrote:
Wed Jan 22, 2020 3:42 pm
Ferdy wrote:
Tue Jan 21, 2020 11:48 pm
hgm wrote:
Tue Jan 21, 2020 4:55 pm
Ferdy wrote:
Wed Jan 15, 2020 11:59 am
hgm wrote:
Tue Jan 14, 2020 4:41 pm
The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.
There is an issue in sending a move to the engine. Gating suffix is not required but winboard sent a move with suffix.

KingSlayer(first) - aiM(second)

White to play and played,

Code: Select all

131764 <first : move c1c3
Image

Then winboad sent

Code: Select all

131764 >second: c1c3f
and was correctly rejected as illegal.

Code: Select all

131873 <second: Error (Illegal move): c1c3f
Well, this is what I wrote. WinBoard will still add gating suffixes. I want the SAN for such moves to contain suffixes, for clarity. E.g. Rc3/F. Stripping them off the move in coordinate notation would then be a bit inconsistent. On input WB considers suffixes optional.
The fortress piece on square C0 can no longer be gated. The correct move here is only c1c3 or normal move Rc3. The first engine is correct in sending the move c1c3. Winboard should just send c1c3 to the second engine. If you are not interested in fixing this, I will just let the engine ignore such move format.
Non-gatable pieces should not be on display. So the error is here that it was not blacked out after the piece in front of it was captured?
If you look at the log, winboard clearly sends c1c3f to second engine even if the first engine only sends c1c3 to winboard.
Was the Fortress gated on receiving c1c3?
If you look at the image, the fortress was not gated. The rook at square C1 cannot gate the fortress at square C0.

Ferdy
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Engines playing Musketeer Chess, good price

Post by Ferdy » Fri Jan 24, 2020 3:40 am

Daniel Shawul wrote:
Thu Jan 23, 2020 1:46 pm
Thanks, that turned out to be an actual bug in my attacks subroutine for fortress moves.
It shouldn't affect play though since I allow king captures. Set "allow_king_captures 0" when doing perfts otherewise it gives wrong results
for most of the positions.
This "allow_king_captures 0" is what I had missed.

Nebiyu is doing ok (randomly run on different positions [after PS and GP phases only] covering all piece combo) on the perft 4 data that I have from 45 piece combo (cannon/leopard, dragon/hawk and so on) at https://github.com/fsmosca/musketeer-ch ... ster/Perft

Will generate perft data later targeting promotion and castling moves.

User avatar
hgm
Posts: 24651
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Engines playing Musketeer Chess, good price

Post by hgm » Fri Jan 24, 2020 3:16 pm

The image is from before the move, so I cannot see whether c1c3f gated the fortress or not. But I guess I should have realized this is not Musketeer960, so that the Rook on c1 is not an original piece. So the shown position is an invalid one, displaying a Fortress that is no longer gateable. The question thus is how that situation could arise in the first place. Was the white Bishop on c1 captured? And did the Fortress not disappear on that move as a side effect?

Ferdy
Posts: 4270
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Engines playing Musketeer Chess, good price

Post by Ferdy » Fri Jan 24, 2020 4:40 pm

hgm wrote:
Fri Jan 24, 2020 3:16 pm
Was the white Bishop on c1 captured? And did the Fortress not disappear on that move as a side effect?
Yes.

User avatar
musketeerchess
Posts: 161
Joined: Sun Apr 21, 2013 12:02 pm
Location: Paris, France
Contact:

Re: Engines playing Musketeer Chess, good price

Post by musketeerchess » Fri Jan 24, 2020 6:06 pm

hgm wrote:
Wed Jan 22, 2020 3:42 pm
Ferdy wrote:
Tue Jan 21, 2020 11:48 pm
hgm wrote:
Tue Jan 21, 2020 4:55 pm
Ferdy wrote:
Wed Jan 15, 2020 11:59 am
hgm wrote:
Tue Jan 14, 2020 4:41 pm
The WinBoard-AA package now contains a WinBoard version that no longer needs a gating suffix to the move in holdingless Seirawan. WinBoard already had code that made it resistant to missing promotion characters, supplying a default in that case (usually Q). So I just had to make the legality test recognizing first-rank moves with something behind it as a promotion. The promotion character was not as insignificant as I thought, so I now set it to the piece behind it, in a bit of a kludgy way. (It would not work with an odd number of ranks.) But for now that should do.

It will still add a gating suffix in the moves it sends to the engine.
There is an issue in sending a move to the engine. Gating suffix is not required but winboard sent a move with suffix.

KingSlayer(first) - aiM(second)

White to play and played,

Code: Select all

131764 <first : move c1c3
Image

Then winboad sent

Code: Select all

131764 >second: c1c3f
and was correctly rejected as illegal.

Code: Select all

131873 <second: Error (Illegal move): c1c3f
Well, this is what I wrote. WinBoard will still add gating suffixes. I want the SAN for such moves to contain suffixes, for clarity. E.g. Rc3/F. Stripping them off the move in coordinate notation would then be a bit inconsistent. On input WB considers suffixes optional.
The fortress piece on square C0 can no longer be gated. The correct move here is only c1c3 or normal move Rc3. The first engine is correct in sending the move c1c3. Winboard should just send c1c3 to the second engine. If you are not interested in fixing this, I will just let the engine ignore such move format.
Non-gatable pieces should not be on display. So the error is here that it was not blacked out after the piece in front of it was captured?
Hi HG
I'm testing your work.
Nice the Fairy Max implements Musketeer chess Now.

Only concern, the Qd1 is in a dark square (probably related to the "fantom line where the Musketeer Pieces are gated).

Maybe i have an old version of your work and this was fixed.

Please let me know.

Zied
inventor of Musketeer Chess. A modern commercial chess variant.

www.musketeerchess.net

Pieces are available on Houseofstaunton.com or Paypal

User avatar
hgm
Posts: 24651
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Engines playing Musketeer Chess, good price

Post by hgm » Sat Jan 25, 2020 4:48 pm

The square colors or textures in WinBoard are configurable. Like the piece images. So you would simply have to swap the images used for light and dark-squre backgrounds through the View -> Themes menu dialog to make it suitable for the Musketeer display. I assume a software package for Musketeer Chess that bundles WinBoard would also include its own piece images, and configure WinBoard to use those.

Post Reply