Comments by HGMuller
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.
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.
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.
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.
Indeed the Ajax Knight is 'potent', as the F move allows it to switch its attack from c1 to a1 in a single move (e.g. Nd3-c2). So it should be able to checkmate in combination with almost any piece.
Note that on 8x8 I never saw much effect of adding moves to a Bishop that lifted the color binding. Giving the Bishops of one player a single orthogonal non-capture step, and the other player that same move on the Knights, did not really swing the score away from 50%. If color binding is a handicap, it seems to manifest itself only for the unpaired piece, making its value less than half of that of the pair. This argues for the Knight gaining more from getting 8 moves than the Bishops gain from 4.
I also did some tests with multiple color-bound pairs (for evaluating the Color-Bound Clobberers CwDA army). The results were best explained by the theory that the intrinsic value of the pieces is half the pair value, but that you have to subtract a fixed penalty if the color bounds are not equally distributed over the two shades.
For the few divergent pieces I once tested the rule of thumb that their total value is the weighted average of the non-capturing and capturing components, where the later count twice as much as the former. So mQcN was around 5 (N=3, Q=9 scale), mNcQ around 7. The Tower and Cardinal can also be written as mQcR and mQcB, so I would expect values 6.3 and 5 for those.
Well, this one might already have been published, but the Diagram in it is awful: the board background image is not properly aligned with the pieces, and furthermore already has (oriental style) pieces on it.
It could be that I just uncovered this, as I finally managed to fix the use of background images in the Interactive Diagram. It appears that someone had installed a style file that globally broke all Diagrams on the site by defining a background color in table row (<tr>) elements. Which covered the background image the Diagram used for the <table>. I now discovered that explicitly specifying the <tr> background color as 'inherit' is a way to counter-act that. So all background images are now visible again.
Indeed, this is better. But the background image still has the pieces in it, and in orthodox Xiangqi version (i.e. without Vaos). I would think this still is a fatal flaw...
OK, fixed. I had added a style="background:inherit" to the <tr> elements of the board table, to counteract the new website-wide default, and make whole-board background images visible again. But in copy-pasting the similar fix from beta.js to betzaNew.js I missed the closing quote.
The featured variant textbox is defined near the bottom of login/header.php .
Home page still needs edited to reflect this, though. Not sure how to do that.
I made an attempt. It is in the file index.html. Because Atomic Chess has the same start position as orthodox Chess, just displaying that position did not seem very helpful. So I tried to give the image some atomic flavor by illustrating what would disappear on a capture.
Somehow the image refuses to center, though.
There's something wrong with the Chu Shogi diagram again.
Can you be more specific? I tried it, and at first glance it appeared to work.
I did not have such problem. Not even after refreshing the browser cache. But the Chu article does not use a ?nocache=true suffix on the betza script it loads. So ther might be some problem with the Cloudflare caching. I added that suffix now, and after refreshing the browser cache it still behaves normally for me.
The lack of a ?nocache=true suffix must have been the problem.
Apparently. Although I don't understand it. Because I did not have the problem either before adding the suffix or after, (refreshing the browser cache in both cases). So the version Cloudflare gave me in the first case must have been OK. But it gave you a faulty version, when you refreshed the browser cache. Can different versions of the same file be simultanously cached on different Cloudflare servers???
For me it works in FireFox (Windows 7). Have you tried flushing the browser cache? Edge and FireFox would have different caches.
I have never really used the tag system, so perhaps this is a dumb question. Which pages do get these tags? The purpose of the page we are commenting on here was to solve the problem that Diagrams in Comments often have been pushed very much backwards, so that you have to scan through several pages of Comments to find them. And even where this is not the case it could become like that in the future. The number of Comments preceding them can only increase. When using the overview page it would open the relevant comment directly, in isolation, so that there can also be no interference with Diagrams that might have been posted close to it, and are displayed on the same page.
If the tags would only bring you to the main page of the article, it would not really solve this problem.
Of course Diagrams could be moved to the main page. But there often is a reason that I posted those in a Comment. Usually because they could not implement the rules perfectly, or I considered them sub-standard in other ways. The long-term goal is to equip nearly every article with an I.D. on its main page, and then all problems would have vanished completely. We would not even need a tag, because it would go without saying that people can expect an I.D. in the article. But this would require still significant work to be done on the Diagram script.
Indeed, in combination with the tags this is a very good solution!
Well, promotion or royalty is never considered part of the move, and would not be imitated by an I atom. But this feature can indeed be used to suppress imitation of special moves, such as Pawn double-pushes or the King's castling.
I used a piece with the FD move in Megalomachy, under the name Spearman. It has the special property there that the 'flying pieces' (a special kind of multi-hoppers) that are also in that variant cannot hop over it. It is of course a matter of taste whether to consider this a special property of the Spearman or of these flying pieces, and in the absence of flying pieces it would just be a normal Kirin.
The names Kirin and Kylin are of course both western spellings of the same Japanese word, the Japanese not being able to hear the difference between L and R, and randomly mixing those up in pronunciation.
Indeed, the Ski-Rook is a major piece. You can practice checkmating with it here.
If it only has a D move in one of the dimensions it is more problematic, whether it skips the first square in the other dimension or not. Because in that case it is bound to even or odd ranks or files. On an even-size board there than always is one edge it cannot attack, and if the bare King can reach there it has a fortress draw. If not, it is a forced win.
But the Ski-Rook can reach the entire board.
This is the only ID where the ID seems to undervalue Rose. Other IDs assign Rose at higher values.
This is probably because it is not really a Rose (which can make up to 7 Knight jumps), but a Half-Rose, which can only do up to 4. I suppose the other Diagrams you refer to use genuine Roses.
Nice! Perhaps I should submit a mini version of Onslaught. The regular version is 12x12, which is beyond the capacity of Fairy Stockfish. On 10x10 there could be 30 pieces in the array, and with a closed Pawn rank and the FIDE army that leaves room for 12 fairies. This could be RN, BN plus 5 pairs. Throw in the Omega Champion as a Rook-class piece, then we can have four extra minor types. E.g. Elephant, Camel, Zebra and Frog. The latter would be be a replacement for the 2nd-rank Pawns in the 12x12 version, its F move still being functional on its own board half, like that of the Elephant.
I am not convinced that what this Daniel Lee says makes sense. Demotion isn't really a different mechanic from promotion; it is just another name for the same thing, depending on whether we percieve the origial piece as more or less valuable. Which is a strategic consideration rather than a game rule. If stockfish allows multiple pieces to promote, each according to their own rule and with their own zone, you just make type A promote to B in one zone, and type B to A in the remainder of the board.
The issue could be the "with their own zone" part. When all pieces use the same zone, it amounts to Shogi rules, and Fairy Stockfish does support Shogi.
25 comments displayed
Permalink to the exact comments currently displayed.
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: