Ratings & Comments
A. M. DeWitt wrote on Fri, Jul 12, 2024 06:37 PM UTC in reply to H. G. Muller from 03:18 PM: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.
Seireigi. Variant of standard Shogi with promotable Gold Generals, as well as more varied and animalistic promotions. (9x9, Cells: 81) [All Comments] [Add Comment or Rating]💡📝A. M. DeWitt wrote on Fri, Jul 12, 2024 06:47 PM UTC in reply to Daniel Zacharias from Sat Jul 6 05:57 PM: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?
💡📝A. M. DeWitt wrote on Fri, Jul 12, 2024 06:50 PM UTC in reply to Michael Taktikos from Sat Jul 6 05:51 PM: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.
Chu Shogi. 
Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]📝H. G. Muller wrote on Fri, Jul 12, 2024 08:45 PM UTC in reply to A. M. DeWitt from 06:37 PM: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.
If it was easy I would already have done it...
The AI already pays attention to the Lion-capture rules and other legality issues, so the easiest way is to reuse the AI components. When using the NewClick() move entry routine the entered moves are already performed by the same routine NewMakeMove() as that the AI uses.
The AI uses a recursive routine Search(), which uses the move generator GenAll() to create a move list for the side that is on move. It then loops through the moves in that list to find the best/a satifactory one. To do that it first evaluates the direct gain of the move, through a routine ScoreMove(). This calculates the value of what the moves captures, checks if it destroys opponent or own royalty, and adds some info to the move that was not in the 'raw' moves coming from the move generator. (Such as identifying pieces that have to be burned, and remembering the original occupants of mutated squares, identifying the pieces that are made temporary royal or iron by the move and adapt the score for moves that capture those.) After 'cooking' the move with ScoreMove() it can be applied to the current position by NewMakeMove(), and later taken back with UnMake();
Both GenAll() and ScoreMove() make use of the preceding ply, e.g. to generate e.p. captures, and applying trading restrictions.
Currently NewClick() uses GenAll() to create the list of pseudo-legal moves, and then uses mouse clicks to eliminate those from the list that would not be indicated by those, until a single move is left. This raw move is then cooked by ScoreMove(), and performed by NewMakeMove(). As long as there are still multiple moves in the list, the squares corresponding to the next click these need to be selected will be highlighted.
To do fully legal highlighting we would have to make every move, and then judge the position based on the possible replies in the resulting position. Not just the one that is finally selected. That means that ScoreMove() will have to be applied to each of the moves. So the call to it should be moved to within the loop that selects the moves to be highlighted. And then there should be a NewMakeMove(), GenAll(), {judge}, UnMake() sequence in that loop as well, where the 'judge' part would apply ScoreMove() to all replies, to see if there is an instant win amongst those (which then would make the move to be highlighted illegal). If there is the grey cross should be chosen as highlight marker.
Overload Chess. Private Missing description (16x16, Cells: 256) [All Comments] [Add Comment or Rating]Since this comment is for a page that has not been published yet, you must be signed in to read it.
Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]A. M. DeWitt wrote on Sat, Jul 13, 2024 01:43 PM UTC in reply to H. G. Muller from Fri Jul 12 08:45 PM: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.
📝H. G. Muller wrote on Sat, Jul 13, 2024 02:48 PM UTC:I think I managed it! There were all kinds of problems, because ScoreMove() only work if the AI tables (such as piece values) are initialized. Which only happened when you actually started playing against it. Otherwise it returns undefined results when pieces get captured. And it was not only that the tables needed to be defined; they actually had to contain the correct values. Otherwise the bridge-capture rule could not be correctly applied.
But I think it works now: pseudo-legal moves that the AI would consider illegal are now highlighted with a grey cross. This applies to intrinsically illegal moves (blowing up your own royal, capturing an iron piece or making a counter-strike) as well as to moves that can be punished in the reply (exposing your royal to capture, or capturing a protected Lion).
In the Chu-Shogi Diagram there are no restrictions on royal exposure, as it specifies royal=100, but as far as I tested the Lion-capture rules are now correctly indicated with the highlights.
Frog/Hannibal/Waffle chess with Gryphon/Manticore and falcon. Expansions of Kevin Pacey's Frog/Hannibal/Wafle Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]H. G. Muller wrote on Sat, Jul 13, 2024 02:53 PM UTC:Note that you declared the Pawn royal in your Diagram. (Holes are not counted; they do not appear in the table.)
Elven Chess. 10x10 variant with 4 new pieces, of which one can double-capture. (10x10, Cells: 100) [All Comments] [Add Comment or Rating] Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]A. M. DeWitt wrote on Sat, Jul 13, 2024 03:36 PM UTC in reply to H. G. Muller from 02:48 PM: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.
Overload Chess. Private Missing description (16x16, Cells: 256) [All Comments] [Add Comment or Rating]Since this comment is for a page that has not been published yet, you must be signed in to read it.
Frog/Hannibal/Waffle chess with Gryphon/Manticore and falcon. Expansions of Kevin Pacey's Frog/Hannibal/Wafle Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]Thanks for the heads up!
Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]📝H. G. Muller wrote on Sat, Jul 13, 2024 09:05 PM UTC in reply to A. M. DeWitt from 03:36 PM:Ummm... I intentionally implemented the counterStrike ban to declare a particular type 'temporary iron', rather than just any type that has the counterStrike property. This to allow multiple types to have it. This appears to backfire in case Ln and +Kn are defined as different types. The other cases I will examine tomorrow.
We should see here what the AI does, so we are now debugging the AI...
Friend. Moves as any friendly piece that guards it.[All Comments] [Add Comment or Rating] Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]I hope there are no errors in the piece movement.
Edit: They're now centered properly, Fuddyduddy image is now used instead of Dumbo
It mostly looks good, but there are a few issues. The pieces are not centered properly, the board is tiled a bit, and you're using the Dumbo image instead of the Fuddy-Duddy image. Also, I'm wondering if there is a way to not have the whole space highlighted when I click on a piece.
Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]📝H. G. Muller wrote on Sun, Jul 14, 2024 04:44 AM UTC in reply to H. G. Muller from Sat Jul 13 09:05 PM:There are several ways to cure this. The simplest would be to switch to making all types with the counterStrike property temporary iron after one of those is captured by a piece without this property. A more subtle (and more versatile) approach would be to assign piece types to 'groups', and make all types in the group that was captured temporary iron. This could be done by introducing a parameter group=N, which would then put pieces of that type in group N. (With as default every type being in a group of its own, so that in Chu Shogi only the +Kn would have to be assigned the type number of the Lion.)
I could also use the counterStrike parameter itself for this, giving it a different meaning when used after pieces have been defined: currently counterStrike=N would endow type N with the property, but after a piece definition it could assign the preceding type to group N. This method is already used for antiTrade (which defines relative ironhood), so it might be the best solution.
📝H. G. Muller wrote on Sun, Jul 14, 2024 09:38 AM UTC in reply to A. M. DeWitt from Sat Jul 13 03:36 PM:All problems you pointed out should be solved now. (Thanks for finding those!)
The problem with promotable pieces was caused by promotion scoring to take place after royalty checking in ScoreMove; because of that the 'immediate loss' score of -15000 was increased by the promotion gain, and no longer recognized as such. It should have returned the losing score immediately when it was found. (This should not have hurt the AI very much, as the score would still be extremely low, so that it would only count on the forbidden move in positions where getting checkmated was the only alternative.)
I implemented type groups for counter-striking, assigned by counterStike=N behind a piece type that should be added to another group N than its own type number (and added that behind the Kirin to map it to the Lion's type, N = 20).
The problem that the final victim of a double capture was not noticed as having to be declared temporary iron, is solved in a fragile way: ScoreMove was adding the anti-trade codes of all victims, and (if one of those was subject to a counter-strike rule) would then check the type group of the last-handled victim (the locust victim) to see if it belongs to the temporary iron type group. I now added code to test whether this victim actually has the counter-strike property; if not, the other victim must have been responsible, and it substitutes the replacement victim for it before doing the type-group test. This solves the Chu-Shogi case, but could fail if there are more than two victims, if there are two locust victims, or if both victims have the counter-strike property, but belong to a different type group. (And there is currently no method for declaring more than one type-group temporary iron.)
I also fixed the moving into check highlighting; I had forgotten to call CountRoyals() in the betzaNew.js here on CVP.
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]H. G. Muller wrote on Sun, Jul 14, 2024 10:01 AM UTC in reply to Fergus Duniho from 02:04 AM:I must admit that it appears to work, but it should count as heavy abuse of XBetza notation. (Which is used to define all moves with detours to measure the location of the piece.) But it is true that the more conventional solution, of morphing th epiece to a type that has the proper moves on the square where it lands, is also no joy, because of the large variety of squares, and the huge number of types this would require. There must be more convenient methods of handling variants of this type...
Chu Shogi. Historic Japanese favorite, featuring a multi-capturing Lion. (12x12, Cells: 144) (Recognized!)[All Comments] [Add Comment or Rating]A. M. DeWitt wrote on Sun, Jul 14, 2024 01:46 PM UTC in reply to H. G. Muller from 09:38 AM: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
📝H. G. Muller wrote on Sun, Jul 14, 2024 06:44 PM UTC in reply to A. M. DeWitt from 01:46 PM:OK, I solved the 'promoting Kirin' bug. This was due to the AI comparing the capture square with the origin of the previous move, rather than the destination.
The adjacent case is partially due to a 'calculated risk': the exemption of adjacent Lions from the protection rule is motivated by the fact that you would never want to capture a protected Lion by replacement if you could capture it throug hit & run. Making the same exception for a piece not capable of locust capture makes no sense. To make the rule also useful for such pieces, I dropped the adjacency condition from the implementation of the rule in the Interactive Diagram. The AI might erroneously believe it was illegal, but it would virtually never want to play it anyway. And when the highlights were still only pseudo-legal, it would not make any difference there either.
The other part of the problem might be solvable in the highlighting: even though it thinks the replacement capture is illegal, it thinks locust capture is allowed, so there also is a cyan start highlight on that square. (Which overrules the red triangle for the direct capture because of the order of these in the XBetza spec.) I guess I should in any case refrain from overruling the star marker by a cross. The cross then would still appear in the highlights for the second leg, for the click that would select termination after the first leg, though. But that is the move you would almost never want to play, so this might be excusable. After all, moving the King in check is also highlighted by a cross now, and that is not strictly forbidden in Chu Shogi either. So the meaning of the cross should be taken a bit liberally, as 'not recommended', rather than strictly forbidden.
The third case was due to forgetting to strip off the color bit when looking up the anti-trade properties when testing whether the replacement victim had to be replaced by the locust victim when setting the temp-iron type.
Storm the Ivory Tower. A Smess adaptation of Chinese Chess. (9x10, Cells: 90) [All Comments] [Add Comment or Rating]Is it possible to define properties for spaces, then to define movement in terms of the properties of the space it moves from?
H. G. Muller wrote on Sun, Jul 14, 2024 09:34 PM UTC in reply to Fergus Duniho from 07:47 PM:Well, move sets are 1-on-1 associated with piece types. So if a square must somehow affect the move, it must affect the type. I suppose that it could be called a property of a square how it would change one piece type into another, and such a property can be assigned by the 'morph' parameters for each piece type, which for each (type, square) combination defines the type that would result from a piece arriving there.
The way how piece types (repeatedly) change into each other defines a network, and this network can consist of a number of disjoint sub-nets. Such a sub-net could then be considered a 'meta-type'. If the sub-net has the property that every closed path that brings you back to the same square results in the same type, the meta-type could be considered the same piece moving differently depending on where it stands. In other cases it would be considered a promotion. E.g. a Pawn can reach last rank, promote to Queen, and then return to its starting square as Queen.
A trivial case for a meta-type always manifesting itself as the same type on a given square occurs when all types that belong to the meta-type morph to the same type on arriving on that square. This is the case we have here. Currently it would have to be defined in the I.D. by explicitly defining all the types, one for every possible move set, and then for each specify the same morph parameter to indicate how they change into each other. This is a bit repetitive, and you might easily run out of letters to designate the types.
Perhaps it should be possible to define meta-types directly, by allowing a piece definition (which now consists of name, ID, image, move and starting squares) to contain not one, but a list of moves. For each move a type would then be created, but all these types would have the same name, ID and image. Such a meta-type definition could then be followed by a morph parameter to indicate which move from the list should be used on which square. E.g. by designating the moves in the list by a single letter a, b, c, ..., and using these letters in a FEN-like string for associating squares with the moves of the preceding meta-type definition.
I have never used morphing, though I assume it involves changing the type of a piece. What you are suggesting strikes me as no less of a kludge than what has already been done, as each solution handles movement in a way that is not strictly in alignment with the rules. If this were done strictly by the rules, the Numskull would have the same definition in this game as in Smess, and the identity of a piece would remain the same everywhere on the board. If there were a way to define space properties, it could be done strictly by the rules. One way to simulate board properties might be to have an invisible layer with stationary pieces that affect the directions the mobile pieces on the visible board can move. Another alternative would be to surround each space with eight other spaces for each possible direction, put an invisible stationary piece in any direction movement is not allowed, and require each move to go over its closest neighbor in whichever direction it moves. While piece movement would not be in strict conformity with the rules, this would at least separate the piece definition from the particulars of the terrain and avoid the expediency of changing the type of a piece.
25 comments displayed
Permalink to the exact comments currently displayed.
The way I had in mind for indicating illegality of pseudo-legal moves in the NewClick highlighting routine was to make each move, and then generate all replies, and determine their scores. A king-capture score (15000) amongst these replies would mean the original move was illegal. This would then cause the grey cross to be used to highlight it.