Comments by ChessShogi
Sorry, I again misinterpreted HaChu's scoring. Which was indeed such that there was no mate in 16, but that the checks could only be kept up for 17 moves. So you are probably right about the Flying Ox/Whale copying mistake. The MSM clearly depicts a Flying Ox in the diagram for this tsume puzzle, though.
My guess is that the designer did not anticipate the Flying Ox's diagonal move being problematic, rather than it being a copying error, since the kanji for the Ox and Whale are vastly different. Of course, what's important is that the problem is fixed and solved.
Not sure if you still update the hgm.nubati site anymore, but feel free to further discuss this problem in the MSM Errata B if you want (If you do, I'd recommend having a picture of the position).
P.S. I've updated the Applet, deleting the MD problems and solutions and adding B23, as well as citing our comments for B23's source (the MSM citation is already covered by the MSM Series B citation).
This page looks good enough to be approved, once I make a few changes (adding a setup image and images for the pawns).
I have changed all pieces with Lion Dog moves so that they actually move like the rules say they do. However, I did not include the forward-forward-back option for any of them. This usually won't matter, but it does matter if they capture multiple contageous pieces (DV/DS/TK/BS) at once with their Lion Dog move, in which case the piece promotes to the last piece captured, but such a situation is rare enough that this might not be needed in an actual game.
However, if I figure out how to tweak the promotion code so that this is possible without breaking the existing code, I may add the forward-forward-back option for completeness.
I fixed the incorrect piece moves and the promotion code bug in the diagram and changed the Furious Fiend to reflect its move in Maka Dai Dai Shogi.
If the morph could contain a symbol for forced non-promotion (which, unlike an indicated no-op, would then suppress any promotion specified in the captureMatrix), you could simply use that to suppress the capture-driven promotion on an arbitrary part of the board.
Perhaps this can just be a forced no-op, as a non-promotion would just leave the piece as is.
Also, having the forced Shogi promotion and promotion with choice parameters available in captureMatrix would be nice as well. However, you would need to use a different symbol for the forced Shogi promotion there, since ^ is already used for hopping restrictions (I think the # sign would be a good choice).
@Fergus,
A new month has started.
I see you have started to put links to supporting sites. However, it is not super clear to me that these links are separate from the name of the game, so I might do some editing to make things a little more organized and easier to read.
My plan is to put the supporting links in square brackets to separate them from the name, and add a legend explaining what .
P.S. Under the current rules for featured variants, I'm not sure if Seireigi qualifies. It satisfies rules 1, 2, and 4 easily, but I'm on the fence for if a "fairly strong computer" clause in rule 3 is satisfied. It depends on whether you consider Jocly a fairly strong computer oppoenent (Ludii plays terribly, so no need to consider it).
Oh...I forgot about that.
I just played my first game of Seireigi against Jocly, and I beat it easily. It played very poorly, which is to be expected given that this is coded in JavaScript, and Shogi-like games are already more difficult for a computer program to play thanks to drops greatly increasing the moves to consider.
I suppose this is why it plays such one-sided games of Chu Seireigi against itself...
Okay, you could try that.
I know I get caught up in my own projects and don't remember to do the featured variant until the last minute or later. It would help to have more nominations of eligible games or for people to work on adding support for games that are not fully eligible yet. Let's start thinking about what we can do for next month now.
We could make that last part easier, by having some sort of database and a script for adding featured variants. It's only an idea though, so I'll stick to editing the page in WinSCP.
[Edit] Added square brackets encapsulating supporting links.
It seems to me that capturing a protected lion by a lion is an available move as long as the diagram understands. Anyway I won't do it and I imagine the AI does not do it either.
I am working on making display of Lion trading restrictions possible in the diagram as a side project. I recently found a way to get the coordinates and pieces from the last move of a game, which will allow enforcement of the counter-strike rule. Still not sure how to do the bridge-capture rule though...
[Edit] Successfully implemented the counter-strike rule in my prototype.
Turns out my code was causing bugs with Gote's Whale highlights. So I removed the Anti-Lion-trading code and cleaned up extraneous code in my applet.
It would be nice if we could add a gray highlight for the illegal Lion trading moves for the Chu diagram on this page, but I am not sure how to go about doing that.
Not sure how that is possible since the diagram clearly defines the Tokin has having the p2 image instead of the p image.
Maybe refresh your browser cache?
I tried to load the Seireigi engine you put a link to, but I wasn't able to get it to work. It said it couldn't find the variants.ini file upon loading.
Yeah...I think it's better to just leave it as-is, except maybe passing the full move to the AI, rather than just the origin and destination...but that's a topic for another day.
You got most of it. However, I did find a few bugs involving the counterStrike highlights.
In this game, after the Soaring Eagle takes the Queen and then the Lion, the gray highlights are not displayed at all (General Case: double capture that captures non-Lion piece and then Lion):
1. e5 h8 2. De4 Dh9 3. Df5 Dg8 4. Dxf9+ Dxg4+ 5. +De8 +Dh5 6. Qg4 Qf9 7. +Dxf9xg10
In this game, the counter-strike highlight doesn't happen for all the Lions, but only for the piece type that was just captured:
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Og9+ Of4+ 6. Ng5 Nf8 7. Ng7 Nf6 8. Qxf4 or fxf5
In this game, the counter-strike highlight highlights don't show at all for piece that have the option of proomoting after capturing a Lion:
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Ne5 Nh8 6. Og9 Of4 7. j5 c8 8. Hk5 Hb8 9. h5 e8 10. Dh4 De9 11. Dg5 Df8 12. Dh6 De7 13. Di6 Dd7 14. Dxi8 Dxd5 15. Dxi9 Dxd4 16. Hxh8
Otherwise, thank you so much! This saved me a heck of a lot of time.
All the cases I mentioned are fixed. I did find a couple more bugs though:
In this game, after the Soaring Eagle takes the Lion and then moves to a non-Lion square, the counter-strike highlights do not appear.
1. e5 h8 2. De4 Dh9 3. Df5 Dg8 4. Dxf9+ Dxg4+ 5. Gd2 Gi11 6. Ke1 Kh12 7. +Dg8 +Df5 8. +Dh9 +De4 9. +Dxg10xf11 or +Dxg10xh9
However, if Sente makes a random move (i.e. advancing the left edge Pawn w/ 9. a5) and Gote tries the same thing w/ 9... +Dxf3xg2 or +Dxf3xe4, the counter-strike highlights are displayed correctly.
In this game, after a Kirin takes a Lion and promotes to Lion, the counter-strike highlights erroneously appear on the newly promoted Lion:
1. Ne5 Nh8 2. f5 g8 3. Of4 Og9 4. Of6 Og7 5. Of8 Og5 6. Og9 Of4 7. Oxh8+
In this game, after moving the Lions adjacent to each other, the bridge-capture highlights still show even though the Lions are adjacent:
1. Ng5 Ng8 2. Ni6 Ni7
Looks like everything is fixed as far as highlights go (The important part is that all illegal Lion-trading moves are highlighted as such). I have copied the updated betzaNew code to my Chu Shogi Applet.
[Edit] I added the line morph=| after the Pawn definition to allow Pawns to promote on the last rank on a non-capture.
There's a visual bug with CountRoyals() where it counts a piece with the protected/counterStrike property as royal if there are no true royals of the same color on the board. This probably has something to do with how values in the royalness array are interpreted within the function.
As per your recommendations, I did some testing with the AI, and I encountered a bug where the counter-strike rule is not being followed by the AI at all.
Case 1: Normal pieces
1. Nh5 Ne8 2. Ni7 Nd6 3. Ixd6
Responds with 3... Ixi7
Case 2-5: Multi-movers
1. e5 h8 2. De4 Dh9 3. Df5 Dg8 4. Dxf9+ Dxg4+ 5. +Dg8 +Df5 6. +Dh9 +De4 7. Gd2 Gi11 8. Ke1 Kh12
Case 2: Normal move
9. +Dxg10
Responds with 9... +Dxf3xe2
Case 3: Igui
9. +Dxg10xh9
Responds with 9... +Dxf3xg2
Case 4: Double capture, Lion captured on first move
9. +Dxg10xf11
Responds with 9... +Dxf3xg2
Case 5: Double capture, Lion captured on second move
9. +Dxi8 +Dxd5 10. He4 Hh9 11. +Dxh9xg10
Responds with 11... +Dxe4xf3
Case 6: Capturing two Lions
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Og9+ Of4+ 6. +Og7 +Of6 7. +Og6 +Of7 8. +Of4 +Og9 9. h5 e8 10. Hxd8 Hxi5 11. He9+ Hh4+ 12. +Hf8 +Hg5 13. +Hxg8 +Hxf5 14. Gd2 Gi11 15. Ke1 Kh12 16. +Hxg9xg10
Responds with 16... +Hxf4xf3
Case 7: Kirin promotion exception
1. f5 g8 2. Of4 Og9 3. Of6 Og7 4. Of8 Og5 5. Ne5 Nh8 6. Og9 Of4 7. Oxh8+
Responds with 7... Oxe5+
Thanks for fixing this! Now the ID's AI plays Chu Shogi properly.
I did notice a visual bug with CountRoyals() where it counts a piece with the protected/counterStrike property as royal if there are no true royals of the same color on the board. This probably has something to do with how values in the royalness array are interpreted within the function.
Not a big deal for normal diagrams, but may affect highlights of diagrams where one side has no royals, like those of tsume problems. Fixing it is not really a high priority for me, but I figured I should let you know anyway.
Actually every move should be marked as illegal for a player that has no royal in a game where royals are defined. It is just that the absence of royalty is only tested when a piece with special (royalty, baring, anti-trading) properties is captured, as the AI assumes royalty still exists before the move, or the search branch would already have been terminated earlier. So it only tests it when it could have changed.
[Edit] For the purpose of highlighting the legality test now assumes a royaltyCount of 1 in the current position when in reality royaltyCount <= 0. In terms of scoring this fakes a single royal for the side that has none.
Technically you are right about that first point. I guess it was less of a visual bug and more of an inconvenience for tsume diagrams that would cause confusion for the solver, especially for large libraries of tsume problems like what I have in my Applet. Thanks for fixing it anyway, though.
It appears that this Jocly preset for Chu Shogi is not invoking the counter-strike rule in the following cases:
- for the first part of a non-Lion multi-move after any type of Lion capture.
- if a Lion is captured only on the first part of a non-Lion multi-move
Managed to make a tsumeshogi (mate in 17) involving a Kirin promotion deferral due to the bridge-capture rule.
lishogi.org/analysis/chushogi/1k+s3g5/v1n9/3iXo6/12/1O10/1+L+S+g8/12/2+t9/2x9/12/12/12_b_-_1
I have approved this page, as it does its job well enough to be eligible. Sure, some improvements could be made, but for now it is good enough.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
I'm trying to figure out the solution to this Chu Tsumeshogi (MSM B45) so I can include it in my Chu Shogi Applet. Any help would be greatly appreciated.
FEN: 12/5+P6/1m5g3r/3+v+B1s1t+M2/1N4k5/m2etP3p2/7p+T3/2Px8/+p+A1+o7+M/1T2P+i2+p1n1/4+r7/12 w - 0 1
I am assuming that the grey Pawn is there.
There is a solution on the MSM Errata B page, but it leaves out the first 10 moves per player:
11... K-9k (11... K-8j 12. +BT-8h K-7k 13. Lnx9i K-6l 14. +SM-11l K-5k 15. Ln-7i K-4k 16. Ln-5i mate) 12. Lnx9i K-8l 13. Ln-10j K-7l 14. +BTx7j +Rx7j 15. Ln-9l K-6k 16. +SM-10k K-6j 17. Ln-8l K-6i 18. +SMx12i K-6h 19. Lnx7j K-6g 20. +SM-8i K-6f 21. Ln-6h K-7e 22. Lnx5g-5f K-8d 23. Ln-6f K-8c 24. +SM-5f K-9c 25. Ln-7d K-10d 26. +SMx8f K-11e 27. Lnx9d K-12f 28. Ln-10d K-12g 29. +SM-7g DE-9g 30. Ln-10e K-12h 31. +SM-10j K-11h 32. Ln-9g K-12i 33. Ln-10i mate
[Edit] I managed to find one that got the Gote King to 9k in 9 moves: 1. +Bg7 Kxg7 2. +Mxd4 Xxd4= 3. +Tih7 Kxf7 4. +Tg6 Ke6 5. +Tf5 Kd5 6. +Ab7 Mxb7 7. Tc4 Kxc4 8. Na6 Kd3 9. Nb5 Kd2
25 comments displayed
Permalink to the exact comments currently displayed.
I ran the position throu Hachu, and it wasn't able to find a mate with the FEN you provided, even after the Kirin move. After
1. +Ah9 Mxh9 2. +Pi11 Rxi11 3. +Lh11 Gxh11 4. +Hd12 Nxd12 5. Oh10= Xxh10 6. Qxd12 +Vxd12 (I think this is right, please correct me if I am wrong),
Gote's +VM guards the d12-l4 diagonal preventing a mate from occuring, resulting in
7. Nf11 Ki12 8. Nxg11,g12 Kj12 9. Nxh11,h12 Kk11 10. Nxi11 Kl10 11. Nxk12 Kl9 12. Nxl11,k11 Kk8 13. Nxk10,j10 Kj7 14. Nxk9,l8 Ki6 15. Nk7 Kh5 (keeps the Lion away from the vital SM guarding the 9-rank) 16. Nj7 Kg6 17. Ni8 Kf7 (guards all possible checking squares that would result in mate, with help from the +VM and PH) 18. Nh7 Ke8 19. Nxg8 Kd9 20. Nf7 Kc10 21. Ne8 Kb11, after which no mate is possible.
However, if the +VM on d4 is replaced with a +RC, it works!
4+A1gk2f1/6s2+P1l/1+H1n4r1e1/5N3mp1/5xpO4/11+L/9Q2/12/3+a8/12/12/12 w - 0 1
My guess is there was a copying error when you went to copy the FEN code for B23. The new position results in
1. +Ah9 Mxh9 2. +Pi11 Rxi11 3. +Lh11 Gxh11 4. +Hd12 Nxd12 5. Oh10= Xxh10 6. Qxd12 +Axd12 7. Nf11 Ki12 8. Nxg11,g12 Kj12 9. Nxh11,h12 Kk11 10. Nxi11 Kl10 11. Nxk12 Kl9 12. Nxl11,k11 Kk8 13. Nxk10,j10 Kj7 14. Nxk9,l8 Ki6 15. Nk7 Kh7 16. Ni5 Kh8 17. Ni6 Kg9 18. Nh7 Kf10 19. Nxg8 Ke11 20. Nxh9,g9 Kd10 21. Ne8 Kc11 22. Nc9 Kc12 23. Nc10 mate.