H. G. Muller wrote on Wed, Dec 20, 2023 02:37 PM UTC:
Minjiku Shogi now also seems to work. It makes use (and is the first real test) of the support for burning in fairy-move-model.js, and for brouhaha squares in the base-model.js. It uses the cbSkiGraph function in fairy-move-model.js for the ski slide of the Ninja. It was also the first test for having a hierarchy of flying pieces, like in Tenjiku Shogi. (In Makromachy they all blocked each other.)
BTW, I improved that function a bit, so that it can now also be used for pieces like Osprey (B after D). It accepts a bend angle (in units of 45 degree), and separate modality flags for the corner square and the remainder of the path. This allowed specifying the corner square as FLAG_STOP for a lame ski-slider (such as the Tamerlane picket) or as -1 for skipping it (true ski slider, or Grant Acedrex Unicorno if you specify a bend angle). Or give it the same modality as the remainder (e.g. for a Griffon). What is new is that it now also would accept -2, -3, ..., which puts the corner 2, 3, ... steps away from the origin, and gives it the same modality as the remaining path. So orthogonal starting steps, a bend angle 1 and corner flags -2 now produces an Osprey graph.
The only thing I had to program in the minjiku-shogi-model.js itself was the area move. (Which in minjiku Shogi fortunately consists of only 2 King steps, rather than the 3 of Tenjiku Shogi.) I provided a customGen routine for that, which is triggered by giving the pieces equiped with an area move a null-step self capture as special move (a graph with step [0,0] and modality FLAG_CAPTURE_SELF). This reveals their location to customGen, and from there I follow a Knight graph, checking if one of the two squares over which the destination could be reached (these will automatically be on board!) is empty as a necessary condition for accepting the move.
Minjiku Shogi now also seems to work. It makes use (and is the first real test) of the support for burning in fairy-move-model.js, and for brouhaha squares in the base-model.js. It uses the cbSkiGraph function in fairy-move-model.js for the ski slide of the Ninja. It was also the first test for having a hierarchy of flying pieces, like in Tenjiku Shogi. (In Makromachy they all blocked each other.)
BTW, I improved that function a bit, so that it can now also be used for pieces like Osprey (B after D). It accepts a bend angle (in units of 45 degree), and separate modality flags for the corner square and the remainder of the path. This allowed specifying the corner square as FLAG_STOP for a lame ski-slider (such as the Tamerlane picket) or as -1 for skipping it (true ski slider, or Grant Acedrex Unicorno if you specify a bend angle). Or give it the same modality as the remainder (e.g. for a Griffon). What is new is that it now also would accept -2, -3, ..., which puts the corner 2, 3, ... steps away from the origin, and gives it the same modality as the remaining path. So orthogonal starting steps, a bend angle 1 and corner flags -2 now produces an Osprey graph.
The only thing I had to program in the minjiku-shogi-model.js itself was the area move. (Which in minjiku Shogi fortunately consists of only 2 King steps, rather than the 3 of Tenjiku Shogi.) I provided a customGen routine for that, which is triggered by giving the pieces equiped with an area move a null-step self capture as special move (a graph with step [0,0] and modality FLAG_CAPTURE_SELF). This reveals their location to customGen, and from there I follow a Knight graph, checking if one of the two squares over which the destination could be reached (these will automatically be on board!) is empty as a necessary condition for accepting the move.
I uploaded the result to my website: http://hgm.nubati.net/jocly/jocly-master/examples/browser/control.html?game=minjiku-shogi.