hgm wrote:
aK is not good enough for two reasons:
1) the default modality of the leg before an 'a' is 'm', and not 'mc'. So aK means mamcK = mamKmacK, which misses the camKcacK part. The compact notation would be mcaK to indicate the 'Lion power' (= capturing on a non-final leg).
2) the default direction set for a leg after 'a' is not 'all', but 'all except exactly backwards'. This was chosen because intuitively moving exactly back is a bit different from moving on, and in verbal descriptions 'igui' is usually mentioned separately from hit-and-run captures. I could imagine some pieces would not allow the 'exactly-back' direction, and it would be very cumbersome to sum up all other directions.
So you would have to write mcaKmcabK to include the 'return to starting square' path. The advantage is that you don't have to include the 'm' part in the first atom, as it was already covered by the KNAD. You could of course also leave out the KNAD, and write mcpaKmcabK. The mpaK part of the first term would then cover any KNAD move, as you could always get to those squares in two K steps if you are allowed to pass over both empty and (non-destructively) over occupied squares. The mcabK term then has to be singled out, because it must exclude the pabK: you are not allowed to null-move when all adjacent squares are occupied.
KNADcaKmcabK
is probably the cleanest and most intuitive description: it explicitly mentions all direct steps (move or capture), then the hit-and-run and double captures, and finally igui and conditional turn passing. There is no overlap between any of these, as there would be in mpaK, where most squares can be reached in a number of ways.
Ok, I've added some extra post-processing to the Betza generator.
The way it works is by making Betza strings for the normal and capture moves separately (these are independent things in SjaakII's piece description), the Betza generator doesn't know whether it's processing a move, a capture, or both (was slightly easier to do at the time, perhaps I'll rewrite it at some point).
It then does a common element extraction on the strings to extract "shared", "move only" and "capture only". So when it extracts "aK" for move and capture, what it really means is "mamK" and "macKcacKcamK". Due to the way its double-step move generator works (only works for leapers, by the way, not for sliders), "p" and "mcabK" are also implied (the origin square would need to be explicitly disallowed, the Lion move is defined as a double-step non-lame leaper). So I've added a post-processor that translates the "aK" produced by the string generator to "mcpaKmcabK".
I agree "KNADcaKmcabK" is probably the neatest way to describe a lion move, but it requires a bit more context for the generator to do it. As long as XBoard can work out what move targets are for the pieces that it gets told about, that's good enough for now.
In other news, Elven Chess seems to work as well as it should, but SjaakII gets forfeited in about 50% of the games because it does Lxprotected L, which it doesn't know about yet.
I also need to fix the highlight command for double-leg moves.
