The problem with using nN as a separate move is that this move will also be available when the distant N2 square does contain an enemy piece, and thus makes the capture optional. The verbal description suggests that the capture should be a mandatory side effect.
To force the capture if one is possible only moves that make the detour should be available. But you must also make sure the move is not blocked if the detour is off board, or hits a friendly piece. This can be achieved by explicitly allowing these, by granting o rights next to the c rights for the leg that hits the detour square, (which takes care of the off-board case), and allow it to hop over a friendly piece. Unfortunately the Betza p modifier does not distinguis friend or foe, but friendly hopping can be achieved through the kludge of specifying d mode (for friendly capture), with an unload u on the following leg to undo this. But the necessity for this u prevents combining it with the move that must capture an enemy, as you would not want that to be put back. So you end up with something like afcoabNafdabuN.
This is of course awful, which is why I suggested to introduce cc as a shortcut for such 'mandatory if possible' locust captures, so the above could be written as afccN. But I did not implement that yet.
As it is, moving the Bowman crashes the ID. This probably has to do with the way I implemented n on oblique atoms; I will look into that later.
[K?K]NAD would include a lot of duplicat move specifications. Which is not really an error as far as XBetza goes, but undesirable for the ID as it slows down the AI (which would search all duplicats as well). For clarity I would recommend KNAD[cK-K][mcK-bK]. This would separate normal, hit-and-run and rifle capture/turn pass, which people tend to percieve as independent modes of capture.
[F?fW3] or even [F?fsW3] do not work (yet). The bracket notation, which strictly speaking is not XBetza but Betza 2.0, is still in development, and the ID only implements it in the most rudimentary form. (Where it ignores the direction implied by the atom of a continuation leg, purely relying on the directional prefixes, and only allows range 1 or infinite.)
The problem with using nN as a separate move is that this move will also be available when the distant N2 square does contain an enemy piece, and thus makes the capture optional. The verbal description suggests that the capture should be a mandatory side effect.
To force the capture if one is possible only moves that make the detour should be available. But you must also make sure the move is not blocked if the detour is off board, or hits a friendly piece. This can be achieved by explicitly allowing these, by granting o rights next to the c rights for the leg that hits the detour square, (which takes care of the off-board case), and allow it to hop over a friendly piece. Unfortunately the Betza p modifier does not distinguis friend or foe, but friendly hopping can be achieved through the kludge of specifying d mode (for friendly capture), with an unload u on the following leg to undo this. But the necessity for this u prevents combining it with the move that must capture an enemy, as you would not want that to be put back. So you end up with something like afcoabNafdabuN.
This is of course awful, which is why I suggested to introduce cc as a shortcut for such 'mandatory if possible' locust captures, so the above could be written as afccN. But I did not implement that yet.
As it is, moving the Bowman crashes the ID. This probably has to do with the way I implemented n on oblique atoms; I will look into that later.
[K?K]NAD would include a lot of duplicat move specifications. Which is not really an error as far as XBetza goes, but undesirable for the ID as it slows down the AI (which would search all duplicats as well). For clarity I would recommend KNAD[cK-K][mcK-bK]. This would separate normal, hit-and-run and rifle capture/turn pass, which people tend to percieve as independent modes of capture.
[F?fW3] or even [F?fsW3] do not work (yet). The bracket notation, which strictly speaking is not XBetza but Betza 2.0, is still in development, and the ID only implements it in the most rudimentary form. (Where it ignores the direction implied by the atom of a continuation leg, purely relying on the directional prefixes, and only allows range 1 or infinite.)