Not if the move is a leap. Imagine, for example, a Flame-ingo with [CX;KD].Or, probably more to point, a piece with K[T;K] -- or should that be K[T;abK]?
In the former the burn would go to all 12 squares, as none of the KD steps is perfectly aligned with CX. In the second case one of the moves would go exactly in the backward direction. Although it doesn't seem a disaster having to write ab, I guess it shows that there really is no reaason to forbid moves with another stride. So I will change the definition to that it should not go back to the previously visited square on the path.
That reminds me that in XBetza at some point I defined it as not being allowed to return to any previously visited square, to prevent that aaK could make a turn pass by triangulating. Of course this was pretty much unimplementable. Now as the Ubi-Ubi (which basically has an unlimited-range area move with Knight steps) shows, area moves really need a dedicated generator if you want to treat those efficiently. (As is very important for the AI.) There is just too much overlap between them. (a)2K has 456 possible realizations, but these reach only 49 squares. So each move is generated some 9 times on average. A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.
In the former the burn would go to all 12 squares, as none of the KD steps is perfectly aligned with CX. In the second case one of the moves would go exactly in the backward direction. Although it doesn't seem a disaster having to write ab, I guess it shows that there really is no reaason to forbid moves with another stride. So I will change the definition to that it should not go back to the previously visited square on the path.
That reminds me that in XBetza at some point I defined it as not being allowed to return to any previously visited square, to prevent that aaK could make a turn pass by triangulating. Of course this was pretty much unimplementable. Now as the Ubi-Ubi (which basically has an unlimited-range area move with Knight steps) shows, area moves really need a dedicated generator if you want to treat those efficiently. (As is very important for the AI.) There is just too much overlap between them. (a)2K has 456 possible realizations, but these reach only 49 squares. So each move is generated some 9 times on average. A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.