The Jocly chessbase model works by tabulating all possible paths that go from each square, and assuming the pieces slide along those paths. It has a special provision for hop capture, but it does not appear to support hop non'capture. This makes it easy to support arbitrary trajectories, such as those of Griffon, Rose and Crooked Bishop. Partly coinciding paths can be made a bit more efficient by treating the duplicat as moved over by a lame leap, so that the duplicat path can be blocked there, but doesn't generate the same move twice. For a Crooked Bishop this would not be feasible, though, as you canot know in advance which of the two paths to distant targets on the orthogonals is blocked. Generating moves for pieces with long coinciding paths, such as hook movers or Sissa, would get very inefficient. For those it would help if move graph would be stored as trees, being able to branch after it has been established that the path to the fork is clear.
So perhaps I should enhance the base-model.js first, by adding a new flag to indicate the mentioned square is not a potential target, but an index in the array of targets where an alternative continuation of the path is described, next to the normal continuation that continues in the next mentioned square. And something to support hopping non-capture. That would allow full support of the original betza notation, and even support of multi-leg moves with m non-final legs for indicating complex bent paths for sliding or lameness.
Testing for attackers of a given square might become complex, though.
The Jocly chessbase model works by tabulating all possible paths that go from each square, and assuming the pieces slide along those paths. It has a special provision for hop capture, but it does not appear to support hop non'capture. This makes it easy to support arbitrary trajectories, such as those of Griffon, Rose and Crooked Bishop. Partly coinciding paths can be made a bit more efficient by treating the duplicat as moved over by a lame leap, so that the duplicat path can be blocked there, but doesn't generate the same move twice. For a Crooked Bishop this would not be feasible, though, as you canot know in advance which of the two paths to distant targets on the orthogonals is blocked. Generating moves for pieces with long coinciding paths, such as hook movers or Sissa, would get very inefficient. For those it would help if move graph would be stored as trees, being able to branch after it has been established that the path to the fork is clear.
So perhaps I should enhance the base-model.js first, by adding a new flag to indicate the mentioned square is not a potential target, but an index in the array of targets where an alternative continuation of the path is described, next to the normal continuation that continues in the next mentioned square. And something to support hopping non-capture. That would allow full support of the original betza notation, and even support of multi-leg moves with m non-final legs for indicating complex bent paths for sliding or lameness.
Testing for attackers of a given square might become complex, though.