Ratings & Comments
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.
Ah, of course. The problem is that the Tinker script you wrote does not test the color of the pieces. So the Lion sees itself in case of igui. The capture matrix does distinquish friendly capture from enemy capture, and normally you would only define a shock on the latter. Of course you could also have the Tinker script test for return to the starting square, and refrain from modifying kind in that case.
I think your suggestion is the better idea. In any case, thank you for your help. Now I can use the same code for Reiwa Dai Shogi, which I am making as a pure Dai Shogi variant. It makes the trading rules much simpler while achieving the same effect.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Way back on March 8, 2005 I posted a Zillions file for a Shatranj game ending in a blockade stalemate after twenty moves. Four days ago I posted a seventeen move blockade stalemate on the (standard) CHESS page. It now looks like sixteen moves is the shortest possible Shatranj example. H. G. Muller has posted an applet in the Shatranj Comments (May 3, 2021). Clicking "Play it!" and copypasting the game below will show all the moves.
1. a3 a6 2. Nc3 a5 3. Be3 a4 4. Ra2 Ra6 5. Kc1 Rf6 6. Kb1 Rxf2 7. Ka1 Rxg2 8. Nf3 Rxh2 9. Qf2 Rxf2 10. Bh3 Rxf3 11. Rb1 Rxh3 12. Bc1 Nf6 13. d3 Rxd3 14. Ne4 Nxe4 15. c3 Rxc3 16. e3 Rb3 stalemate victory for Black.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Note that it is possible to pre-load an Interactive Diagram with a game, through the parameter moveList. This would save the reader the trouble of copy-pasting the game into the Diagram.
So a Shatranj Diagram with the extra line
moveList=1. a3 a6 2. Nc3 a5 3. Be3 a4 4. Ra2 Ra6 5. Kc1 Rf6 6. Kb1 Rxf2 7. Ka1 Rxg2 8. Nf3 Rxh2 9. Qf2 Rxf2 10. Bh3 Rxf3 11. Rb1 Rxh3 12. Bc1 Nf6 13. d3 Rxd3 14. Ne4 Nxe4 15. c3 Rxc3 16. e3 Rb3
would enable the reader to start navigating through the game immediately, by using the button bar in the AI panel opened by the Play It! link. Like below:
potential unforseen consequence of this rule: making it harder to checkmate in the middlegame with the queen (now general)
in regular chess, it usually doesnt matter if a queen is protected as you should not expose it to capture either way... however you are perfectly content to "expose" a protected queen to capture by the enemy king as the king cant capture it
in this variant, you are not content to expose the general to the enemy king, as the enemy king can just igui
the queen is often directly adjacent to the king in middlegame checkmates, but a general would often just be captured in that situation
Good point. This could be fixed by exempting the King from gaining an extra move when he captures a Queen.
The rule that non-Q x Q gives an extra move basically serves to implement the 'counter-strike rule', making indirect trading impossible. But there is no need for a counter-strike when your Queen gets attacked by a King: the Queen would simply capture that King rather than trying to set up a Queen trade.
Moose Pawn appeared in Universal Chess-170-17.
Rex Exclusive Shock Chess960
Does this mean I can create an Interactive Diagram for Chess but the King in check cannot travel?
Edit: It does!
I added a feature to make it easier to debug or copy an Interactive Diagram: there now is a button 'Source Code' under the legend (which you open by clicking the 'here' link twice). When you press that, the definition of the Diagram is displayed below it.
Does this mean I can create an Interactive Diagram for Chess but the King in check cannot travel?
Not sure what the 'this' in your message refers to.
Petrifying Check Chess
King in check can't travel. Castling is illegal.
Has this been invented before?
I don't get it. The Diagram is preloaded with a long game, which seems to consist exclusively of illegal moves. When not shown in isolation something goes disastrously wrong (probably because it then uses betzaNew.js from a later Diagram in the Comment listing), and Kings appear everywhere.
What is the purpose of all the holes? Why iiK?
The Diagram as defined would not do what the title suggests: check has no effect on its ability to move at all. It can move from e1/e8 even when in check, and cannot move without capture elsewhere even when in check.
I also don't understand what it has to do with Shatranj...
[Edit] OK, I see: the pre-loaded game tries to capture all the Kings. For some reason this doesn't work with betzaNew.js. You try to make use of the fact that initial moves on royals are forbidden when in check. Inventive, but awful.
[Edit2] Pre-loading games doesn't appear to be Diagram-specific, so it tries to pre-load the wrong game when not viewed in isolation.
[Edit3] The latter is now fixed; it was caused by the fact that the game specified with moveList was loaded with a delay, like it was pasted, but by that time another Diagram on the same page could already be the 'active' one. The script now first sets the active Diagram to the one it uses the move list of.
It is a good idea to publish these pictograms. I confirm that the Chu Shogi applet is a success
I fixed something that was broken. The n modifier on a W or F step, which is not useful in the normal meaning of non-jumping, was 'overloaded', and supposed to indicate that the step 'leaves behind' an e.p. square on the square it came from. This way the path of lame leapers explicitly specified as a multi-leg move could precisely indicate whether and where the piece could be e.p. captured.
The Diagram furthermore applies the rule that royals can be e.p. captured by normal capture (c) moves; the capturing piece does not need to have an explicit e mode for that, like it would need to e.p. capture non-royal pieces. This is for instance how the ban on castling out of or through check works: the castling creates e.p. squares on the King's origin, and the square it passes through. So that castling through check exposes the King to e.p. capture, and would thus be illegal.
I used this to make a Diagram for Caissa Brittania, where the royal Queen cannot move through check (nQ). Each step in the slide then created an e.p. square. But also on the origin, which would forbid moving out of check. But in Caissa Brittania moving out of check is allowed, so I suppressed generation of an e.p. square on the origin, and only left it for later steps in the slide.
This, however, broke the use of n on non-sliding W or F, where it became a complete no-op. I now fixed this. So nK would now be a King that cannot move out of check without getting e.p. captured, but moving a royal nQ out of check would still be legal.
[Edit] I am now starting to doubt the wisdom of this (irregularity-introducing) convention. If nQ would also create an e.p. square on the origin, one could still write [K?nQ] (= KyafnK) when this is not desired. OTOH, with the convention you would need [nK?nQ] (= nKnyafnK) for a royal Queen that cannot move out of check. [K?Q] is after all just synonymous for Q, but allows you to tinker the properties of the first step separately from later steps. I suppose that neither of these is particularly more complex than the other. But it bothers me that nW and nR would be treated differently as to moving out of check is concerned.
Spider Rider Chess on Game Courier.
25 comments displayed
Permalink to the exact comments currently displayed.
HaruN Y, thanks so much for the info. You have indeed listed pieces I couldn't find games for, I'll have to add here and then add to the zrf which is ready to upload, well, it was ready, before you posted, lol. I still need also to check the info Bob Greenwade gave me the other day too, just been unexpectedly busy last few days.
HaruN Y, with your games you listed, I think a couple of them I couldn't find, anyways, I'll check it all out more deeply and if I have any questions, which I will, I'll ask you, thanks again to you both.