I now wrote a function cbSymmetricGraph(geometry,specs,confine), which seems very generally useful. It generates moves for a totally symmetric piece (on a grid board), according to an array 'specs'. In principle everything it does can be done with the aid of the existing functions cbShort/LongRangeGraph. Which even can do asymmetric pieces. (Which outside of Shogi virtually never occur...) But the price for that is that you often have to call it with long lists of 'deltas'. This is not only annoying and makes the source code look cluttered, but also a frequent source of bugs. And then you have to use cbMergeGraphs to combine moves that could not be generated at once, because they had different range or flags.
This cbSymmetricGraph takes an array of numbers, where each number represents either a new flags setting to be applied to the moves that follow, or code for direction and range of a move. (Because all flags are > 65000 it can easily spot the difference.) Each symmetric move set is indicated by a single integer: the units indicate the y-step, the decades the x-step, and any higher digits (optionally) the range (which by default is 1, for a leaper). So specs=[21] indicates all Knight moves. A preceding minus means unlimited range, so for a Queen we pass [-10,-11]. So sliders and leapers can be mixed; Archbishop results from [21,-11]. For a 'Short Rook' (Betza R4) we pass [410], but there we already enter the realm of things that are almost never needed.
Divergent pieces are also easy; mRcB would require [FLAG_MOVE,10,FLAG_CAPTURE,11]. This is potentially easier than having dedicated functions like cbCardinalGraph, where you would have to know that it is Cardinal, and not Archbishop or Palladin. And for the rarer pieces you would have to know whether a function exists for it in the first place. So I regret now that I have added so many named graph functions in fairy-move-model, which almost all could have been replaced by this cbSymmetricGraph. (For pieces like Pawn, Griffon and Unicorn dedicated functions still make sense.)
It is a pity I did not think of this before:
I now wrote a function cbSymmetricGraph(geometry,specs,confine), which seems very generally useful. It generates moves for a totally symmetric piece (on a grid board), according to an array 'specs'. In principle everything it does can be done with the aid of the existing functions cbShort/LongRangeGraph. Which even can do asymmetric pieces. (Which outside of Shogi virtually never occur...) But the price for that is that you often have to call it with long lists of 'deltas'. This is not only annoying and makes the source code look cluttered, but also a frequent source of bugs. And then you have to use cbMergeGraphs to combine moves that could not be generated at once, because they had different range or flags.
This cbSymmetricGraph takes an array of numbers, where each number represents either a new flags setting to be applied to the moves that follow, or code for direction and range of a move. (Because all flags are > 65000 it can easily spot the difference.) Each symmetric move set is indicated by a single integer: the units indicate the y-step, the decades the x-step, and any higher digits (optionally) the range (which by default is 1, for a leaper). So specs=[21] indicates all Knight moves. A preceding minus means unlimited range, so for a Queen we pass [-10,-11]. So sliders and leapers can be mixed; Archbishop results from [21,-11]. For a 'Short Rook' (Betza R4) we pass [410], but there we already enter the realm of things that are almost never needed.
Divergent pieces are also easy; mRcB would require [FLAG_MOVE,10,FLAG_CAPTURE,11]. This is potentially easier than having dedicated functions like cbCardinalGraph, where you would have to know that it is Cardinal, and not Archbishop or Palladin. And for the rarer pieces you would have to know whether a function exists for it in the first place. So I regret now that I have added so many named graph functions in fairy-move-model, which almost all could have been replaced by this cbSymmetricGraph. (For pieces like Pawn, Griffon and Unicorn dedicated functions still make sense.)