Comments/Ratings for a Single Item

I don't know if you have time to work on jocly at the moment, for my part I was looking at how chu shogi works.
I was wondering:
Would it be possible to combine the fairy move model with the drop model to make locust captures on shogis with drops?
For example, could the lion, falcon and eagle locust move from chu seireigi work with jocly?
 

Hello HG, A few weeks ago I noticed you contemplated writing a C++ code for the AI of the interactive diagram. Anything from this contemplation?

This is not something that can be achieved in just a few weeks. But yes, I have been working on it. (Sadly interrupted by an emergency that we have to move the TalkChess server before the end of the month, because the current one will get off line then.) I have started a kind of blog on it on takchess.com, to report the progress, and occasionally receive feedback.

The plan is to write a compiled C program that, when started by the user, installs itself as a HTTP server, so that you can surve to it through the browser. The Interactive Diagram on a page you view on this server could then request moves from it, instead of using the JavaScript that is running in the browser. I have already tested out this setup, by using the MicroSoft model program for a TCP/IP server, and adding the code needed to serve ordinary files from the directory it was started in. The idea is to define one filename (say "engine") as special, and not treat it as a file, but as a command to run the engine code, and output a move.

I am still busy designing a sufficiently powerful engine. I could have just translated the existing JavaScript code to C, counting on the larger speed, but the JavaScript AI has many design characteristics that would also slow down a C program. For that reason, as well as to make the project interesting, I wanted to try a completely different design:

Every piece would get all its potential moves tabulated. That is, every leg of a move would get the squares it visits (indicated relative to the piece) put in a table when the variant is initialized, with the maximum length it could have on a board of the given size. (So on 8x8 a Rook would get 4 moves, each consisting of 7 squares.) During play these tabulated moves will get associated with a board square, depending on where the piece stands, or, for a continuation leg, on where that leg starts.

This data structure takes the place of a conventional move list; retrieving captures from it will be done via the square they are associated with. This way you only have to change the moves of the pieces that were involved in a move (re-associating or deleting their moves, and those of pieces that were discovered / blocked), while most pieces will keep the same moves. That becomes particularly advantageous in large variants.

Cool!

I agree with Aurelian: Cool!

It sounds like, once it's done, it may make the ID capable of some things that it can't do right now.

Actually I expect something along the same lines but better, meaning a stronger engine! I am aware of the fact that it can take many months, though!

Happy Birthday.

This link is to a game I'm playing. It seems the Fast Castle routine still has a bug. A moved king has (?forcibly) castled with the other rook.

Any idea when you continue the work on this project? I'm restarting my apothecary project. I got stuck a bit but with the help of chatGTP I managed to go all the way to the search. But then I figured than I'm not doing the moves well. I am using a hybrid piece center- board centered representation so there is a bit of work. I'm saying this because probably I can, in theory at least, write a program that being specific to a certain game is probably faster. On the other hand you have massive experience compared to my own. But I'm thinking about certain situations like for pieces like nDnH where a general program probably check the wazir square for occupancy twice. Anyway good luck!

OK, I see. The move Ki10-h10 is ambiguous, as it can both be a fast castling and a normal King move. And the preset doesn't let you resolve that ambiguity. I suppose the fact that it thinks it can be a castling is an additional bug, as the King has already moved. I will have a look at it soon.

I now fixed the FastCastle routine in the betza.txt include file, so that it only generates the move if the King is still virgin. As it was it only tested that for the Rook. Normally the presence of an i in the XBetza castling definition would automatically suppress the move, but because of the way I encoded fast castling in betza.txt the original modifiers are no longer available in the preset. But I suppose it is safe enough to assume there will never be any need for a fast castling for a non-virgin piece.

This would have solved the problem in your game, because only one of the generated moves would have matched your K h10-i10 input. It does not solve the general disambiguation problem yet, when a virgin King would attempt a single step. This problem could also arise with O1 normal castling. I suppose 'capturing' your own Rook could be used to enter the castling, in that case.

Ok. Thank you, HG!

The 1-step fast castling should now work too: if the square next to the King is empty, it will be highlighted, but the Rook in that direction will also be highlighted (if both K and R are virgin). Clicking the Rook would then do the fast castling, clicking the empty square would just move the King there.

Great work!

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

The first 10 moves were already given in the MSM, where it is said that these are the only moves given in the historic source, which at that point just says that "a Lion mate follows":

1. +B-6f, K-5d; 2. +Bx4d, K-6e; 3. +B-6f, Kx6f; 4. +SMx9i, Phx9i=; 5. +BT-5f, Kx7f; 6. +BT-6g, K-8g;
7. +BT-7h, K-9h; 8. +RC-11f, SMx11f; 9. BT-10i, Kx10i; 10. Ln-12g

Thanks.

B45 was the only MSM problem from your Errata where I couldn't get a solution from HaChu that satisfied the line provided before now. But now that I have the MSM solution, it will be a piece of cake. In hindsight, I feel kinda silly for not considering 1... K-6d, though the actual first 10 moves of the solution was quite different from what HaChu thought.

HaChu has a hard time on this. I am now trying it through back-solving, but it doesn't really behave like it makes good use of what is left in the hash table from the previous position. Which it should if I untick the "full analysis PV".

Hi, I found your very nice svg versions of piece variants for a lot of pieces here on chessvariants.com - I'm referring to http://winboard.nl/alpha/

I have played on Yucata.de for some time, and they recently released Grand Chess with a lot of pieces (81 extra) which originated from chessvariants.com. Then I had the idea to do a print-and-play for myself with the same graphics as on Yucata.

Unfortunately their piece images were very small gifs, so that's why I was happy to find your svg files. Anyway, I have started to do an AI file using the same color for the black pieces as on Yucata, mostly I can use your svg files and some extra work is needed.

I just wanted to thank you for making your work downloadable, and if you have any use of the extra work I did just tell me. I might want to do an online version on futureskill.com at some point, please tell me if this is ok for you.

/Henrik

@H. G. Muller,

I am making a new chess variant, Reiwa Dai Shogi, that is basically Dai Shogi with better piece balancing, replacing the weak pieces with stronger ones with stronger promotions.

However, I am struggling to make a good power piece for the game. Ideally, I want something that is stronger than the Lion but still has difficulty mating.

I figured it would be a good idea to have you weigh in on this, since you know a fair deal about Chu Shogi and the historical variants.

Here's a diagram of my first in-dev version. Lion is currently subject to trading rules due to lack of a stronger power piece ATM. The only new pieces are the Ram's-Head Soldiers on c1 and m1.

Well, I suppose that part of the reason a Lion is so valuable is that it can so easily checkmate on its own. That makes it hard to predict the value relative to pieces that cannot. The most obvious method for taking away the mating potential would be to keep the piece devoid of Knight moves.

The Lion Dog in the interpretation where it can do 2-out-1-in locust captures might be more valuable. (But I don't really like that piece, as there seems no defense against this.) The Tenjiku Free Eagle might qualify on 15x15 (where the Lion loses importance due to its slowness, and the ability to move as Queen is worth quite a lot). You could even beef it up to a 'Super Eagle' by allowing also two Wazir moves per turn (QcaWcaFcabK, possibly also adding DA). Even QcabK could be pretty strong.

It would be hard to achieve the desired value without locust captures. Perhaps with hook moves (diagonal to avoid lone mating), but Tengu Dai Shogi already exists. If you plan to allow entirely new moves, AD rifle captures could be a useful building block. Unlike the Lion's igui these can attack steppers with impunity. And unlike the Lion Dog, you can defend against the igui forks by attacking the square it is on, as all igui moves end on the same square.

I intend to keep all pieces that appear in Chu as they appear in that game, with the exception that the Lion-trading rules would be applied to the new power piece (PP for short). I was considering including a Lion Dog and Hook Movers. The 2-out-1-in move can be pretty easily defended against by placing a ranging piece behind the victim. But since that piece is pretty similar to the Lion and Tengu Dai Shogi already had that, I wanted something new.

I was initially thinking about doing some sort of short-range Ko Shogi-like rifle capture where the normal move cannot capture and the capturing move is an igui move, but also allowing both to be done once per move in any order. This creates the desired power gap between the Lion and the PP (power piece) when the non-capturing move is mKmNmAmD (Full Betza: KmNmScafmFcaba(mpa)1mK(mpa)1mpacabmK).

However, that raises a question: For locust movers that capture only once, do you need a bridge-capture-threshold exception like the Lion does in Chu Shogi?

Bridge capture is a rule for double captures, so it would never apply to pieces that cannot make those.

Thanks.

I was thinking about having a short-range burning piece, which burns diagonally adjacent pieces, like what the Fire Dragon does in Minjiku Shogi. This creates the desired power gap while still allowing adequete defense against the power piece, even without jumping sliders. An example is shown below.

Also, I noticed a weird bug where for burning pieces the diagram would stop generating moves early on normal board with no holes if the burning piece gets close enough to the board edge. For an example, go to the Tenjiku Shogi page move one of Sente's Fire Demon towards the top board edge. With enough messing around you should see the highlight generation fritz out when a Fire Demon is highlighted.