Comments by ChessShogi
I wonder if there is a way to delete old presets? If so, I would like the presets listed below deleted (TLDR - All of the presets listed here that redirect to something). All of them are mine, so you do not need someone else's permission to delete them.
- All of my presets for Chess on a 10x10 Board
- All of my presets for Decimal Chess
- My alfaerie preset for Dragon Chess
- My preset for Futaskikana Shogi
- My alfaerie preset for Hectochess
- My alfaerie preset for Ryugi
- My preset for Single-Capture Suzumu Shogi
- My promotest preset for Suzumu Shogi
- The alfaerie, blackabstract, blackalfaerie, whiteabstract, and whitealfaerie presets for Yangsi
- All of my presets for Yangsi (Black)
- All of my presets for Yangsi (White)
Yes, I would like the description for that article changed to "A tutorial on how to create variants with multi-move pieces in them."
Also, I personally think that the old system where the What's New Text and the article description are the same was a much better system. I have no idea why someone decided to separate them.
When I try to update the description for my upcoming tutorial on programming variants with multi-move pieces in Game Courier, the description still reads what it originally said when I first posted the article. It seems like the description is refusing to update even after I change the text in the What's New Text field. Any idea as to what's causing this?
Your welcome. In case your wondering how I made the preset, I mostly copied code from the Tenjiku Shogi preset (which was based on the Suzumu Shogi preset) and modified it to suit the needs of Chu Shogi and the its sets. The hardest part was implementing the Lion trading rules. For those, I used a variable to check whether a Lion was captured or not, and then tested moves based on its value. For allowing a Kirin that had just captured a Lion to be taken, I simply used a flag to mark its spot and created an exception to allow it to be recaptured.
Did you get my message?
The diagram seems to be having problems rendering anything larger than 8x8. The image is fine, but the diagram seems to freak out when rendering any board size larger than 8x8.
Great idea, but how would you even go about implementing that? For a game like Yangsi or regular Chess, it would be fairly simple, but for a game like Chu Shogi or Suzumu Shogi, or even regular Shogi, things become really complicated really quick. Chu Shogi and Suzumu Shogi have multi-moving pieces, which required specialized code to enforce properly, namely a modified version of the code in Extra Move Chess that can enforce single and double moves, as well as a special subroutine that determines if a piece moved to a square that allows it to move again. In Chu Shogi, even more specialized code is needed to enforce the Lion-trading rules. Same for regular Shogi, except the specialized code handles drops rather than multi-moving pieces. Thanks to this and the fact that XBetza notation and GAME Code are two wildly different things, it would be incredibly difficult to properly implement the full version of your idea. Still, adding a button that, at the very least, prints out GAME Code functions for each piece, would be a great addition to this page in my opinion.
@Greg Strong Sorry for the late response, but I just added a link the Alfaerie Style preset, so you are welcome to rename my page to 'Chu Shogi' and hide the other two pages with (non-rule enforcing) Chu Shogi presets.
Perhaps you could add a function (i.e. IsPawn(p)) to allow certain pieces to promote on the last rank? That way you can still keep the option off but allow certain pieces to promote on the last rank if need be.
Seems like the comment system received an update - an update that removed an option to delete comments that are empty strings, which could be problematic, since there are no easy ways to delete comments now. Also, I do not like the fact that we now have a simple text field rather than an HTML editor. This is a straight up downgrade from the old and much better system, since you now have to enter HTML tags by hand - tags that the old system took care of for you.
The newest diagram script has a script error. Here is the error message I got when putting a diagram using the new script into the repl.it IDE for HTML: > Script error. >
@Ilya Novikov I recently uploaded some Mnemonic and Pixilart Shogi pieces. Also, I removed the rule against perpetual check in both Futashikana Shogi and Shosu Shogi, so it might be a good idea to update the Zillions of Games pages about these games.
Edit: I also restored the original moves for the Side Soldier and Vertical Soldier and renamed a few pieces.
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.
I am confused... When I clear my browser cache and wait a few days after updating my Shogi piece graphics, in some places, the graphics appear in their current form, and in others they appear in their original form. It seems like the images are refusing to update in some places. I've noticed the latter with the interactive diagrams on my articles for games I created (i.e. Suzumu Shogi, where the images in the Pieces section are up to date but the images in the interactive diagram are not) and when copying the image address and looking at the image that way. Any ideas as to what's causing this?
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.
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.
The modifier x does not seem to work when used on a final leg, at least when it comes to highlighting a selected piece's moves. For example, when I give a piece the move xK and press its name to show its moves, it will show red capture moves, but that's it.
I have one question about the rules regarding check. A few sources (i.e. the English Wikipedia page on Shogi) mention a rule against perpetual check, namely making perpetual check four times, or something similar. Yet most of the sources I found do not mention such a rule. So is this supposed rule against perpetual check really a thing?
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.
Is there a way to have a piece jump 4 squares diagonally? As it is now, the diagram doesn't appear to have that option as a single move/atom.
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).
The new AI is pretty impressive. But I must ask you something. As far as I know, there is no easy way to skip a turn with a multi-move piece has this ability. Can this be implemented?
The new file upload script is way better than what it was in the past, but whenever I try to delete an old image and upload a different image with the same name, the old image reappears instead.
25 comments displayed
Permalink to the exact comments currently displayed.

In an earlier comment you said you could build an AI that plays much stronger than the one you currently have implemented into the diagram. I know the AI in the diagram is intended to be weak, but maybe you could implement the stronger AI as a separate option and have an option to switch between weak and strong AI in the AI bar?