On the vertical line of movement, it shows the King able to make normal moves like a Lance, and when the Pawn is moved to the last rank, the King gets an extra capturing move. But the King's ability to move forward is only a checking power against the other King and does not allow it to actually move.
I finally understand what you mean now! This was all a problem of obsolete versions of the script. When I nowadays create Interactive Diagrams, I am careful to always append a ?nocache=true to the URL of the betza.js script. But the Eurasian Chess ID was posted long ago in a comment, and I just moved it into the article without scrutinizing it. It did not have the nocache attribute in the script URL. So it was not using the version from the CVP website, but the one at CloudFlare. Initially I was looking at it from a computer that did have a more recent version of betza.js (without nocache attribute) in its browser cache, and there the problem you described did not occur. But now that I looked at the page from another computer, that did not have the script cached, and thus was using the CloudFlare version, it exhibited the problem. So the solution was just to append the nochache=true argument to the URL in the article, to make it use the latest version of the script (which was already in my browser cache; the latter considers the file with and without nocache attriobute as different files).
I did make some modifications in the betza.js schript, though:
For moves that can only be used to deliver check, but not to actually move or capture there, I let the move diagram now display the X marker, which was already in use for pseudo-legal moves of a royal piece that stumbled into check. The explanation of this marker symbol in the legend has been modified to reflect this meaning.
The move diagrams are now able to combine captures and non-captures to the same square that resulted from a different atom in the XBetza description (rather than using the marker symbol corresponding to the last-encountered atom). So when you write mQcK the adjacent squares get highlighted by the yellow circle, rather than the red diamond. (The distant moves of course all remain green squares, for 'non-capture only'.) This only works when the captures follow the non-captures in the XBetza move definition. A nice example is the Diagram on Divergent Chess, where Knights move as Maos, but capture as Moas.
I finally understand what you mean now! This was all a problem of obsolete versions of the script. When I nowadays create Interactive Diagrams, I am careful to always append a ?nocache=true to the URL of the betza.js script. But the Eurasian Chess ID was posted long ago in a comment, and I just moved it into the article without scrutinizing it. It did not have the nocache attribute in the script URL. So it was not using the version from the CVP website, but the one at CloudFlare. Initially I was looking at it from a computer that did have a more recent version of betza.js (without nocache attribute) in its browser cache, and there the problem you described did not occur. But now that I looked at the page from another computer, that did not have the script cached, and thus was using the CloudFlare version, it exhibited the problem. So the solution was just to append the nochache=true argument to the URL in the article, to make it use the latest version of the script (which was already in my browser cache; the latter considers the file with and without nocache attriobute as different files).
I did make some modifications in the betza.js schript, though:
For moves that can only be used to deliver check, but not to actually move or capture there, I let the move diagram now display the X marker, which was already in use for pseudo-legal moves of a royal piece that stumbled into check. The explanation of this marker symbol in the legend has been modified to reflect this meaning.
The move diagrams are now able to combine captures and non-captures to the same square that resulted from a different atom in the XBetza description (rather than using the marker symbol corresponding to the last-encountered atom). So when you write mQcK the adjacent squares get highlighted by the yellow circle, rather than the red diamond. (The distant moves of course all remain green squares, for 'non-capture only'.) This only works when the captures follow the non-captures in the XBetza move definition. A nice example is the Diagram on Divergent Chess, where Knights move as Maos, but capture as Moas.