💡📝H. G. Muller wrote on Mon, Jul 17, 2017 08:33 AM UTC:
> I can't get the wolf to move to the third square cpaturing both the pieces on square 1 and 2.
Good observation! The JavaScript code that powers the interactive diagram currently cannot handle more than a single locust-capture victim. (I still have to work on that; I still regularly make improvements to that code to enhance its abilities. Pieces that fly over arbitrarily many others, like the Tenjiku Shogi Great General, are also still on the to-do list.) Currently the moves are internally encoded by 3 squares and a final piece type: the square between which the piece moves (with possibly replacement capture as a consequence), plus one 'e.p. square' that must be evacuated as a side effect of the move. I will have to add a second e.p. square to the move encoding, and modify the move-entry procedure to allow the user to specify it. The latest WinBoard/XBoard version is already adapted to allow that.
> I can't get the wolf to move to the third square cpaturing both the pieces on square 1 and 2.
Good observation! The JavaScript code that powers the interactive diagram currently cannot handle more than a single locust-capture victim. (I still have to work on that; I still regularly make improvements to that code to enhance its abilities. Pieces that fly over arbitrarily many others, like the Tenjiku Shogi Great General, are also still on the to-do list.) Currently the moves are internally encoded by 3 squares and a final piece type: the square between which the piece moves (with possibly replacement capture as a consequence), plus one 'e.p. square' that must be evacuated as a side effect of the move. I will have to add a second e.p. square to the move encoding, and modify the move-entry procedure to allow the user to specify it. The latest WinBoard/XBoard version is already adapted to allow that.