Comments by ChessShogi

I completely forgot that the promotion rule was different. I'll get to fixing that right away.

The rule-enforcing preset now properly enforces promotion rules.

I also agree that Tenjiku Shogi's promotion rule should be the same as that of Chu Shogi. But for Lions, Horned Falcons, and Soaring Eagles, these rules are a bit vague. Of course, Chu Shogi is of no use to us here since these pieces don't promote in that game. So I decided to follow H. G. Muller's interpretation, which makes the most sense in my opinion.

In his interpretation of the first rule, the piece must start its move outside the promotion zone and end its move inside it. If a piece moves multiple times, the intermediate square(s) would not be considered since the piece did not start or end its move there.

In his interpretation of the second rule, the piece must start in the promotion zone and capture something with its move. It's well established at this point that a capture is any move that removes an enemy piece from the board. This presumably means that if a piece makes a capture on its first step and a non-capture on its second, this would still count as a capture since the piece captured something.

Now let's consider the effects of this interpretation on these scenarios suggested by dax00:

• A Lion that enters the promotion zone on a non-capture and then exits the zone while capturing a piece should be able to promote
• An unpromoted piece that starts in the promotion zone, captures a piece in the promotion zone on its first step, and makes a non-capture on its second step should not be allowed to promote

The first scenario is flawed because it breaks both rules. The Lion did not enter the promotion zone - both its starting square and its destination square are outside of it. This makes the capture on the Lion's second step meaningless.

The second scenario is flawed because it meets the criteria in the second rule. The piece started its move inside the promotion zone and captured something on the way to its destination, so it has the option of promoting on that turn.

I also made a rule-enforcing preset for Nutty Shogi.

You can find it here: https://www.chessvariants.com/play/pbm/play.php?game%3DNutty+Shogi%26settings%3Dnutty

Everything should be in order apart from the restrictions against indirect trading of Lions (and the repetition rules, which i won't implement because it's way too complex). All I really did was copy the Tenjiku Shogi preset's code to this preset and modified the code to suit the needs of the Chu Shogi preset.

The preset has been posted, and everything seems to be working properly.

You can find it here: https://www.chessvariants.com/play/pbm/play.php?game=Chu+Shogi&settings=chu

It may be rare that you would skip a turn in a Shogi variant, but there are those instances where that is useful.

If you were to implement such a feature, I would suggest keeping the deselection of pieces the same, but having the squares where locust captures are possible trigger the 2nd leg code even when those squares are empty. However, it's important to differentiate between multi-moves that can br triggered by moving to an empty square and those that can only be triggered by capturing (i.e. the Lion's lion power vs. the Heavenly Tetrarch's igui move).

I think adding the Y extension and repeatable suffixes is a good idea. It might also be a good idea to allow the X and Y extensions to be combined in case there is a leap that one extension cannot simplify on its own. It may not be a perfect solution, but it should be good enough to suit the needs of most variants.

There might not be much to show on an empty board, but xK does not show move highlights when actually moving pieces on the board.

I'm glad you got the move borrowing fixed, but there is one small problem. When a piece borrows from another piece that has a borrowing move in the same vector as the vector that the piece is using to borrow the move from, the diagram takes unusually long to render the move when the piece is selected and gets stuck in a frozen position when you try to move it.

For example, lets say that a piece with the move RbxW is directly behind a piece with the move sRfR2bxW. Notice that both have the bxW for borrowing moves. If I click the piece in front and then try to move it, the diagram will freeze.

I think what is happening is that when a piece with x on a final leg borrows a move, it always borrows all the moves of the piece it's borrow from, including borrowing moves. Since the pieces in the example above have the same borrowing move (bxW), when the piece in front borrows the move of the piece in the back, the diagram will generate that move on top of the original, but since the borrowed move included the same borrowing move as the original move and neither piece had moved, the diagram will repeat this procedure over and over, resulting in an infinite loop.

Fortunately, the fix for this little problem is simple. Either don't include any move with x on a final leg when adding the borrowed move to the original, or include an additional condition in the loop for generating moves that prevents the infinite loop.

Well, as it turns out, I'm an idiot. All I needed to do was to change the graphics type for the interactive diagram from png to png?nocache=true. Whoops.