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
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.
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.
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.