Page 9 of 17
Re: Engines playing Musketeer Chess, good price
Posted: Thu Jan 23, 2020 8:59 am
by Ferdy
Daniel Shawul wrote: ↑Wed Jan 22, 2020 3: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.
[d]h*******/rfbqkbnr/pppp1ppp/n2Fp3/8/8/2N5/PPPPPPPP/R1BQKBNR/H******* b KQkq - 3 2
The white piece at D6 is a fortress. The pieces at A0 and A9 are hawks.
Nebiyu gives:
perft 1
This one e8e7 1 allows king capture and is illegal.
Re: Engines playing Musketeer Chess, good price
Posted: Thu Jan 23, 2020 9:09 am
by Ferdy
hgm wrote: ↑Wed Jan 22, 2020 4:42 pm
Ferdy wrote: ↑Wed Jan 22, 2020 12:48 am
hgm wrote: ↑Tue Jan 21, 2020 5:55 pm
Ferdy wrote: ↑Wed Jan 15, 2020 12:59 pm
hgm wrote: ↑Tue Jan 14, 2020 5: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,
Then winboad sent
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.
Re: Engines playing Musketeer Chess, good price
Posted: Thu Jan 23, 2020 2:46 pm
by Daniel Shawul
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
Re: Engines playing Musketeer Chess, good price
Posted: Thu Jan 23, 2020 5:36 pm
by hgm
Ferdy wrote: ↑Thu Jan 23, 2020 9:09 am
hgm wrote: ↑Wed Jan 22, 2020 4:42 pm
Ferdy wrote: ↑Wed Jan 22, 2020 12:48 am
hgm wrote: ↑Tue Jan 21, 2020 5:55 pm
Ferdy wrote: ↑Wed Jan 15, 2020 12:59 pm
hgm wrote: ↑Tue Jan 14, 2020 5: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,
Then winboad sent
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?
Re: Engines playing Musketeer Chess, good price
Posted: Fri Jan 24, 2020 4:18 am
by Ferdy
hgm wrote: ↑Thu Jan 23, 2020 5:36 pm
Ferdy wrote: ↑Thu Jan 23, 2020 9:09 am
hgm wrote: ↑Wed Jan 22, 2020 4:42 pm
Ferdy wrote: ↑Wed Jan 22, 2020 12:48 am
hgm wrote: ↑Tue Jan 21, 2020 5:55 pm
Ferdy wrote: ↑Wed Jan 15, 2020 12:59 pm
hgm wrote: ↑Tue Jan 14, 2020 5: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,
Then winboad sent
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.
Re: Engines playing Musketeer Chess, good price
Posted: Fri Jan 24, 2020 4:40 am
by Ferdy
Daniel Shawul wrote: ↑Thu Jan 23, 2020 2: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.
Re: Engines playing Musketeer Chess, good price
Posted: Fri Jan 24, 2020 4:16 pm
by hgm
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?
Re: Engines playing Musketeer Chess, good price
Posted: Fri Jan 24, 2020 5:40 pm
by Ferdy
hgm wrote: ↑Fri Jan 24, 2020 4:16 pm
Was the white Bishop on c1 captured? And did the Fortress not disappear on that move as a side effect?
Yes.
Re: Engines playing Musketeer Chess, good price
Posted: Fri Jan 24, 2020 7:06 pm
by musketeerchess
hgm wrote: ↑Wed Jan 22, 2020 4:42 pm
Ferdy wrote: ↑Wed Jan 22, 2020 12:48 am
hgm wrote: ↑Tue Jan 21, 2020 5:55 pm
Ferdy wrote: ↑Wed Jan 15, 2020 12:59 pm
hgm wrote: ↑Tue Jan 14, 2020 5: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,
Then winboad sent
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
Re: Engines playing Musketeer Chess, good price
Posted: Sat Jan 25, 2020 5:48 pm
by hgm
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.