Comments by A. M. DeWitt
The lack of a ?nocache=true suffix must have been the problem. Thanks for checking though.
You may need to refresh your browser cache. For me the board is blank and the debug message 0y0y0 is displayed.
There's something wrong with the Chu Shogi diagram again.
I added a link to this page where the featured variant is on the homepage so people can access it directly.
Atomic Chess is the featured variant for November 2024.
Home page still needs edited to reflect this, though. Not sure how to do that.
Done.
Here's the link, if you are interested: https://www.chessvariants.com/graphics.dir/svg/DeWittChuShogi/
I would like to feature Atomic Chess as an example of what pieces with influence can do, but I am not sure how.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
There seems to be something wrong with the betzaNew.js script, as the diagrams with rims that use it (for example, this one) have their rims mauled, and Chu Shogi's diagram does not work at all.
Finalized version of Raichu Shogi.
Only differences from normal Chu Shogi are that the Lion-trading Rules are replaced by the shock rule (except King and Prince do not trigger it) and that Pawns and Lances must promote on the last rank due to not having any special abilities deriving from the shock rule.
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.
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.
It might have something to do with the locust captures, especially hit-and-run captures, since Chess has no multi-moves (except for castling and en passant, which do not affect Queens at all). Hit-and-run captures of a Lion would move it to either an empty square or a square with a non-Lion piece, so that might mess up the call stack a bit. However, since this works just fine in games that only have single captures affecting the target piece for forced turn passes, I'm currently stumped.
I do have a theory though. If AlphaBeta() repeatedly calls itself, it would also call Tinker() repeatedly. This would mean that when kind |= 64 is set, it is never unset if AlphaBeta() decides to do a move that doesn't capture a Lion. That might have something to do with it.
Well, as you said, custom scripting is always an option. I am having trouble though when it comes to custom scripting compatibility for the AI though, probably because I set the kind variable in the Tinker() function itself. Here's the code for Raichu Shogi I use, when allowing hit-and-run captures of Lions to trigger the forced pass.
function raichuTinker(m, d) { dest = board[m[3]][m[2]] & 511; midpoint = m[-2] > 2 ? (board[m[5]][m[4]] & 511) : 0; if(IsLion(dest) || IsLion(midpoint)) kind |= 64; // problem line, will be replaced with: return 5; return 0; } function IsLion(pieceType) { // Returns true if pieceType is a Lion return pieceType == 20 || pieceType == 31; }
Let's say that instead of setting it in the function, I want to return a value of 5 to indicate the forced pass, and set kind |= 64 elsewhere. Where should I set it?
When I tried in AlterMove(), and the Console gave the following error (this is in a local file),
Raichu Shogi.html:17 Uncaught RangeError: Maximum call stack size exceeded
at AlterMove (Raichu Shogi.html:17:19)
at StackMove (sourcecode.js:3068:10)
at NextLeg (sourcecode.js:3325:22)
at NextLeg (sourcecode.js:3328:9)
at NewInner (sourcecode.js:3357:7)
at NewGen (sourcecode.js:3368:3)
at GenAll (sourcecode.js:3404:41)
at AlphaBeta (sourcecode.js:3647:3)
at AlphaBeta (sourcecode.js:3678:19)
at AlphaBeta (sourcecode.js:3678:19)
, after I added an if statement telling AlterMove() to set kind |= 64 and return 0 for the normal move in the section with the Tinker() call.
if(alter & 16) { var tinker = CustomScript(m, piece & 1024 ? m[3] : ranks - 1 - m[3]); if(tinker > 0) { if(tinker == 5) { if(!(kind & 64)) { kind |= 64; } return 0; } else return tinker; } }
The captureMatrix only looks at the pieces on the origin and destination. For multiple capture it would have to be not a matrix but a multi-dimensional object.
But I did not see that as a problem.
BTW, it is still possible to handle more complex cases by scripting. By defining an xxxTinker() JavaScript routine you can examine the move it is passed as argument, and set the '64' bit of the variable 'kind' to let the move trigger the forced pass (kind |= 64;). Or the '32' bit to make it a prioritized move.
Well, to be fair, usually it isn't. The problem I was having was that hit-and-run captures weren't triggering the forced pass. I tend to prefer consistency in my rulesets. But thanks for letting me know about the scripting option.
Since I see that in the source code Tinker() still only takes two parameters, I'm assuming by kind you are referring to the in-source variable here.
Edit: I tried your recommendation by editing the diagram to my previous comment, and it works perfectly with all capture situations. Thanks.
In the current form the rule thus gives the closest approximation to the original Chu-Shogi rules. You can even allow bridge capture, by exempting the caKcabK moves from application of the capture matrix by suffixing those moves with an apostrophy. (No way to still forbid it when bridged by P or GB, though.)
You could just use the tradeThreshold=N parameter for that, and have the forbidden bridge-captures be the first N pieces in the list.
Considered by who? In my eyes it is more a hybrid. It keeps the pieces from Dai that were in Chu, but the large Shogi variants all do that. The pieces that distingush Dai from Chu were all thrown out. Although one might argue that the promotion-on-capture rule is the decisive difference.
But of course there is nothing against hybrids.
Buddhist Spirit is also an interesting power piece.
Well, now that I am back to inventing Chess Variants and being more involved in general, I think using only the Dai Shogi (-like) move types would make for a more interesting challenge. Especially now that the Shock Chess rule is implemented, which makes for a much simplet trading rule without making pieces basically immortal.
P.S. I posited a question about the shock rule in relation to multi-movers, which you can find here.
I have decided to end my break from inventing Chess Variants and try to be more involved as an Editor. I probably won't be as prolific though.
I have decided not to make the stand-alone Chu Shogi App I said I would make in the previous comment, since the Chu Shogi Appliet I made already fills the role I intended it to fill quite nicely. However, I have released the SVGs I made for such an app in a graphics.dir page page.
To the other Editors: Speaking of which, the graphics.dir index page could be improved, but more on that later.
P.S.S. If you do decide to use the Interactive Diagram, you will need to lean HTML in order to properly embed one in your pages.
That isn't really necessary.
It is the method that works best for me when embedding Interactive Diagrams on my pages, since if I use WYSIWYG (or another format for that matter) for the default format the Diagram gets mauled. Though you can just switch Source on and off for the other ones, as you said.
@Christine I guess for best results you should use HTML as the default format (the field at the top of the Edit Submission dialogue that lists the different formats), and then turn off Source for all the non-Diagram-housing sections.
H. G. and I fixed that during our discussions about the ScoreMove() function in his code. But thanks for pointing it out.
If it's any consolation, I plan on releasing the SVGs I made for Chu Shogi in a graphics.dir page, including the SVGs for the pictogams you sent me. I did make some slight modifications for the Generals though, by using the images you use in the Jocly graphics rather than the ones you provided, and making the promotion-exclusive pieces have no red highlights, for consistency reasons.
Now that I think about it. the index.html page for the graphics.dir directory deserves to be improved...
P.S. I've decided that I won't make a Chu Shogi App, and instead get more involved as an Editor. I think I've done a pretty good job with the Applet I made.
Is there a way to make it so that the forced turn pass only happens at the end of a move and doesn't force you to stop your piece on that square to get the extra move?
This is what happens with my current conception of Raichu Shogi (example shown below), a proof of concept for forced turn passes with multi-movers. I think this works fine, but would cause a nasty inconsistency with the rules of the game in my opinion, since promotion allows the forced pass but moving to a different square after does not.
'Fairy Pieces Part 3' and 'Fairy Pieces Part 4' etc will be MUCH smaller.
No doubt it's better to keep posts smaller when possible.
P.S. You can write blocks of code into your pages if they actually do something useful. The most common and useful of these on the site is probably the Interactive Diagram. This thing is awesome. It is way more flexible than Zillions of Games and is relatively easy to learn, at the expense of having a weak AI. Also, H. G. Muller will be happy to help you with any issues you have relating to the Interactive Diagram, since he made the underlying script.
P.S.S. If you do decide to use the Interactive Diagram, you will need to lean HTML in order to properly embed one in your pages.
The ZRF I don't care too much about. What is important is that the article is at least somewhat readable now.
Also, some more useful advice for your future posts. Keep the scope of your project manageable. That is, don't bite off more than you can chew. If I would have done this same thing, I would have split it into two or more parts to keep the size of the piece list manageable.
[Edit] I have upgraded this page to Members-Only, so other members besides you and us Editors can see it.
I have removed all code formatting from this page. It should at least be readable now.
25 comments displayed
Permalink to the exact comments currently displayed.
Perhaps. But what's important is that the diagram is working properly.