I figured out what was wrong. The problem was that if a shock piece (whose capture grants an extra turn) had a move stopping on its starting square, that would set kind |= 64, and then the code would fritz out due to this being done on the moving piece.
Remember Raichu Shogi (the Chu Shogi equivalent of Shock Chess)? When I set the Lion's move to KNScaK (as it is set to now), the diagram works perfectly, but if I introduce even a single move that stops on the starting square, it fritzes out. The diagram at the link uses a custom script for forcing the turn pass.
I can't think of any reason to think that a move to the starting square from a shock piece should trigger a forced turn pass (except when it captures another shock piece of course), except when an unloaded shock piece gets placed there, and the moving piece then lands on the starting square, capturing said piece after it is placed on the starting square. But of course it would always be more efficient in such cases to simply capture the shock piece without moving. So unless there is something I am missing, I think all we need to do to fix this is make sure the code doesn't set kind |= 64 when looking at the starting square.
I figured out what was wrong. The problem was that if a shock piece (whose capture grants an extra turn) had a move stopping on its starting square, that would set kind |= 64, and then the code would fritz out due to this being done on the moving piece.
Remember Raichu Shogi (the Chu Shogi equivalent of Shock Chess)? When I set the Lion's move to KNScaK (as it is set to now), the diagram works perfectly, but if I introduce even a single move that stops on the starting square, it fritzes out. The diagram at the link uses a custom script for forcing the turn pass.
I can't think of any reason to think that a move to the starting square from a shock piece should trigger a forced turn pass (except when it captures another shock piece of course), except when an unloaded shock piece gets placed there, and the moving piece then lands on the starting square, capturing said piece after it is placed on the starting square. But of course it would always be more efficient in such cases to simply capture the shock piece without moving. So unless there is something I am missing, I think all we need to do to fix this is make sure the code doesn't set kind |= 64 when looking at the starting square.