Comments/Ratings for a Single Item

I do occasionally come across a piece that's "poisonous" -- to capture it is automatically a kamikaze move. I even have a couple of such pieces in my own reportoire. Can "poison" be added as a property? Or is there already a way to express it? (Something like spell=burn and spellZone=0 -- though I'm pretty sure that 0 is currently not a valid spellZone.)

I already started working on this (mainly for debugging purposes) for the captureMatrix; this is shown below the legend that you get on clicking 'here' twice. There could also be additional info there. It would only be shown if it is indeed defined (e.g. Minjiku Shogi).

Properties like royal, iron etc. are already shown, behind the piece values when you display those by clicking the table's 'move' column header. But only as hexadecimal mask (their internal representation), so I am the only one that can understand it. But this is a general problem anyway; either it would have to be displayed as a (potentially very long) text, or there would have to be some legend explaining things. The capture matrix is now displayed in a form that might be obvious to the creator of the Diagram, but would still be obscure to others.

Another problem is that properties like iron, antitrade, contageous, ... have really become obsolete now that the capture matrix can specify those on a type-specific basis. And as to the spells: the implementation of this might still completely change, for allowing multiple spells in one Diagram, and combination of spells on one piece. So designing something to display them now might be a waste of time.

Another consideration is that these things are used only very rarely. It would be much more useful to indicate promotion rules somehow.

Could the ID be set up to show a piece's spells and/or properties? Perhaps a bit of text (say, black against a pale yellow-orange [FFC950] background) for a spell, or against a pale magenta [FF94FF] for properties such as royal, iron, contageous, etc., appearing either just above or (more likely) just below the board. (Or maybe that magenta just for royal, and other colors for other properties.)

Perhaps some time soon you can work the new property of the quote (technically, in this context, an apostrophe) as well as an example using the Troll. :)

The latest version of the betzaNew.js script now implements this exemption from effects specified by morph and captureMatrix by suffixing a move in the XBetza descriptor by a quote. This makes it possible to limit special effects like promotion to a subset of the moves of a piece. It is still not possible to define different special effects for different moves, but it should be extremely rare that this is needed.

The quote should go between the capitals describing the leap, and a possible range indicator. I don't really consider this a property of Betza notation; just a trick in the way the Interactive Diagram uses XBetza notation. (As morph and captureMatrix only have meaning in this context.) So it is described in the ID article, not in the XBetza article.

Perhaps it is a good idea to make a small extension to XBetza notation, to distinguish moves that must be subject to the effects specified by morph or captureMatrix, and those that will ignore these instructions. This could solve many cases where unusual effects are only limited to a subset of the moves. Such as in case of the Troll, which appears in many 'Cazaux variants': this has the move GHfmWfcF, but only the Pawn-like moves would allow it to promote when reaching last rank.

If in G'H'fmWfcF the quotes would mean the G and H components ignore the morph, then defining morph=* for the piece (implying normal promotion choice on reaching last rank) would allow implementation of the Troll without using any custom-made JavaScript.

I have upgraded the betzaNew.js script by some of the features proposed earlier, all related to promotions.

• promoChoice can now be used to define multiple 'choice sets', separated by slashes.
• Promotion through the zone parameters maxPromote and promoZone, or through an asterisk in the morph board use the first choice set, as before.
• A digit 1-9 in the morph board for a piece can be used to trigger a promotion according to the additional sets.
• A vertical bar in the morph board or captureMatrix will make the event trigger a Shogi-like promotion to the piece implied by promoOffset, which can be deferred.
• Chess-style and Shogi-style promotions can be used in the same Diagram, by defining a non-zero promoOffset, and set maxPromote=0, relying completely on morph boards to specify which piece uses what promotion on each square independently.

I also have been working for making it possible to use comma separation in the morph and captureMatrix definitions, but this has not been tested yet. In fact I am starting to wonder whether this still is necessary, now that the vertical bar can indicate the corresponding promotion piece, so that you don't have to put the actual ID there. (Which might be a multi-character ID like +P.)

The problem appears to be that the order in which atoms are parsed is different for each system. From what I can see, the piece overview highlights are parsed left-to-right while the on-board highlights are parsed right-to-left.

I now changed the NewClick routine for move entry so that it always preserves the order in which the moves were generated, (which is the order they appear in the XBetza move spec), when applying the highlights. This should remove inconsitencies between the move diagram and move-entry highlights, so that you can control what symbol will prevail in case of moves to the same square with different rights. (And m and c rights stemming from different atoms will be cmbined, in the move diagram.)

Of course it remains best to avoid true duplicats altogether, as they would slow down the AI, which would not notice they are the same, and search both. E.g. with QfmcamK there would be a lot of overlap between the fmamK part and the Q part to empty squares, and it would be better to specify QfcamKfafsmK, which would only add the non-capturing forward Mao moves, which don't overlap with Q.

The move diagrams are still using the old highlight routine, the move entry the new one (with newClick=1). They both use the list of vectors produced by the Betza compiler (as would show up as the legdefs array in GAME code), which retains the ordering. But the move entry works from the move list that is generated from this, by deleting moves that are not compatible with the click sequence so far, and then generating highlights for the remaining moves.

I guess the problem is the way I delete moves that are ruled out: I replace those by the last move of the list, and shorten the list by one. Since it starts by generating moves of all pieces (to also get induced moves), the first click must delete a lot. And when the clicked piece was not the first for which any moves were generated, this typically leads to reversing the order. This is definitely undesirable. I should delete moves by shifting the tail of the list one place down. That would preserve the order. It is much less efficient, but for move entry speed is irrelevant.

The problem appears to be that the order in which atoms are parsed is different for each system. From what I can see, the piece overview highlights are parsed left-to-right while the on-board highlights are parsed right-to-left.

The destinations of a locust capture would normally not be shown, unless you materialize a victim on the locust square by hovering. The problem here is that you also defined lame leaps to the same target squares (fmcamK instead of fcamK), which are already possible without any victim, and thus are initially shown. And which all except the Mao and nD part collide with the Queen moves. Wou would want the normal slides to eclipse those. But you would want the locust capture to exclude the slides.

The solution is to split the lame leaps from the locust capture: famKfsRBfcamK. Or, to avoid duplicats, fafsfmKfsRBfcaK. This way you decide the hierarchy yourself, which is more flexible than a preprogrammed hierarchy.

The problem of moves eclipsing each other has always existed. Usually it can be ameliorated by reordering the moves in the XBetza descriptor. E.g. DR would show the same move diagram as a plain R, and if you want the possibility to show that the 2nd square can be jumped to you would have to write RD. I recently improved this slightly by combining m moves from one atom with c moves from a later atom, to show up as normal destinations. so that mQcK would show the K targets as having both m and c.

The Seireigi Falcon and Eagle are also outlier cases. Their move-only parts are part of a locust capture, so I was unable to eliminate the problem completely.

Perhaps the Highlight function can highlight squares based on a hierarchy, such that if the program is told to highlight a square, it will replace the current highlight color if the highlight has a in precedence, or keep it the same if the highlight is of lower presence. Such a system would all but eliminate this problem, regardless of what move generator is used. A few outlier cases may remain, but they would be very few and very far between.

The problem of moves eclipsing each other has always existed. Usually it can be ameliorated by reordering the moves in the XBetza descriptor. E.g. DR would show the same move diagram as a plain R, and if you want the possibility to show that the 2nd square can be jumped to you would have to write RD. I recently improved this slightly by combining m moves from one atom with c moves from a later atom, to show up as normal destinations. so that mQcK would show the K targets as having both m and c.

That was before you fixed the parentheses parsing. It probably got fixed as a happy side effect.

While I'm still here, I did notice that the highlighting of moves pieces is somewhat inconsistent between the on-board pieces and the movement display from the piece overview. For example, in Dai Seireigi and Chu Seireigi, the Horned Falcon and Soaring Eagle (promoted Kirin and Phoenix, respectively) have stinging moves that replace their Lion moves, but the move-only part of these moves seems to suppress the move-and-capture parts of the move. It's a fairly minor bug, and the hovering works fine, but it can be a bit misleading in some cases. My guess is that the piece overview still uses the old highlight generator, which works differently from the new one.

Yes, but in your comment before that you said that the use of h was broken.

I'm simply pointing out the h modifier's usefulness on K and Q atoms, because your last comment made it seem like this combination wasn't working as you intended.

Well, the plain shQ seems to work as you desire. So what exactly isn't working?

As it is now, the h modifier on K and Q atoms are very useful for compacting certain atoms, since it can be used to specify a unique set of directions. For example, it allows the Suzumu Fire Demon's ranging burn to be expressed as a single atom (shy(mpacab)2Q), rather than having to define it as two separate atoms (y(mpacab)2Bsy(mpacab)2R).

It seems that the code for handling parentheses is broken, as when I click on a Fire Demon or any jumping General in this Tenjiku Shogi diagram, it is shown to move like a normal slider, without any jumps or area moves. The Suzumu Shogi diagram also shows that the code for certain directional modifiers (such as the h in shQ (equivalent to BsR)) is broken as well. as when I click on a Fire Demon, it shows that piece moving like a Queen with this weird burning side effect.

I fixed the parentheses parsing. Giving an error message for non-existing Atoms in betzaNew.js had broken it, because the digit following the parentheses tested as upper case.

I am not sure that shQ should be equivalent to BsR. 'Half' sets are only defined for oblique atoms. Three moves out of eight is not really half.

It seems that the code for handling parentheses is broken, as when I click on a Fire Demon or any jumping General in this Tenjiku Shogi diagram, it is shown to move like a normal slider, without any jumps or area moves. The Suzumu Shogi diagram also shows that the code for certain directional modifiers (such as the h in shQ (equivalent to BsR)) is broken as well. as when I click on a Fire Demon, it shows that piece moving like a Queen with this weird burning side effect.

The number of a piece is determined by the order of the pieces in the piece table.

Indeed there is no possibility to have non-involved pieces promote.

A couple of questions:

1. I'm not quite clear on how to apply some of these parameters. My guess, from reading this, is that making a royal Prince (symbol Pr) I'd just have a line royal=Pr, but the text here says it should be a number for the piece type, and I have no clue how to find that. Or is it something that I add to the piece description?

2. Is it even possible to set up a rule that "if piece A is captured, piece B immediately promotes to A"? (It looks to me that it is not.)

Thanks!!

At the stage of the Design Wizard where you have to define the pieces you have to type the name of the piece, the name of the image, and how you want it to move. You can type anything there, including names with spaces. If you don't type anything in any of those fields, the Diagram will use the default for that item. (Which for the image name is the same as the name, and only well-known piece names have a default move.)

Of course the name you type for the image (or that used by default) should be the name of an existing image file of the correct graphics type, otherwise the piece won't show up in the Diagram when your browser tries to display it. And none of the filenames from the standard piece sets have spaces in their name. So if you specify a name like "asian pawn", you should specify the name of the image you want to use for that (probably 'chinesepawn'). To know which images exist you should look on the page that describes the piece set that you have selected for use in the first step of the Design Wizard. Of course when you are using a piece set that you uploaded yourself, you could have given those images any name you wanted.

This is a bit cumbersome, and this is why I later constructed the Play-Test Applet, which shows you which images are available in the Alfaerie set in the applet itself, often with a name and move specified, so that you can simply drag those to the board instead of first having to define the piece table. It still offers the opportunity to change the name and the move used in the table.

But the Play-Test Applet doesn't offer you the freedom to use other piece sets than Alfaerie, or control the square colors.

I am confusing to use 'start design wizard' of Interactive diagrams. How can I use pieces which have space in their name such as 'asian pawn' or 'dragon king'?

I made some enhancements to the Diagram script, directed at better servicing the Ultima page:

* A custom initialization script can now be provided, by defining a function with the name given by the satellite parameter suffixed with 'Init'. It will be called immediately after the definition of the Diagram has been processed. This can be useful for adding dedicated initialization code that must be exectuted only after the normal creation of the Diagram, (static embedded code would be executed before that), or for properly associating initialization code with the Diagram it belongs with when there are multiple Diagrams on the same page (each with their own value for satellite).

On the Ultima page I now embedded a function ultimaInit(), which does what before was done by pressing the 'Change' button to toggle between trampler and burner mode for entering the moves, so that that button could be removed. (And all pieces are now always treated as burners, meaning the side effects are implied by the click on the destination.)

* The highlighting of burner moves now uses the (red) capture highlight to indicate empty destinations that would result in a capture elsewhere as automatic side effect.

I tried to start working on the rewriting of the move-notation generator and parser in the newClick=1 mode. This is still not based on the AI's move generator, with as a consequence that it is limited to moves with at most a single locust square (which can also be used for indicating unloading the captured piece, when it refers to an empty square, or for castling, when it refers to a friendly piece). AI-based move generation, though, allows an arbitrary number of locust squares, and an explicitly indicated piece for unloading on one of those. Incorrect notation is generated for the new possibilities this offers.

But I ran into the problem that I am not sure how I would want the notation of these moves to look!. The Diagram uses 'Standard Algebraic Notation' for normal chess moves, i.e. ID of the moved piece followed by the coordinates of the destination square, possibly with one or both coordinates of the square of origin in between as disambiguator, if multiple moves matched the simple description. And an 'x' in front of the destination if the move was a capture.

I had already extended that notation for locust captures, by treating the piece as a 'trampler', which first moved to the locust square, and then continued to its destination, fully mentioning both. E.g. Lxe4-e5 for a Chu Shogi Lion on e3 that made a hit-and-run capture of the piece on e4, and then moved on to e5, or Lxe4xe5 if it also captured a piece on its destination.

It seems undesirable to always mention all locust squares when there are many, and omitting those would not lead to ambiguity, because the captures are not optional. E.g. if a Tenjuku Fire Demon would move to h12, burning g12, i12, g13, h13 and i13, the notation FDxg12xi12xg13xh13xi13xh12 does not seem very productive. For one, many other notations could be used for the same move, as the order of the locust victims is arbitrary. So to get a unique notation extra rules would be needed to order the victims, or in absence of those parsing would become more difficult, as the parser would have to handle cases where the order is not how the move generator does it. I'd much rather write FDxh12, as burning is not optional, so that there is no ambiguity is possible with moves (of a Fire Demon) that go to h12 without burning that same set of pieces. In the same spirit as that we don't explicitly mention the victim in e.p. capture, but just fxg6 when white captures f5. It would be a possibility to introduce a new symbol for capture through burning, if we don't consider FDxh12 explicit enough. Like FDx!h12, FDxh12! or FDxx12.

There could be multiple moves to the same square, which imply different locust captures. Such as in the case of two Advancers, on b1 and e1, which could both move to e4. Then one would capture f5, the other would capture e5 in this move. But I would rather disambiguate these moves by (partial) mention of the square of origin (e.g. Abxe4) than by explicitly mentioning the victim (Axe5-e4). Because that is also what SAN would do if there was no victim at all.

In general the principle of SAN is to leave out as much as you can, other than the piece ID and the full destination. For tramplers this would often be convenient. E.g. the Ultima Long Leaper on a4 could jump over enemies on d4 and f4 to land on g4. LLxf4 would unambiguously specify this move; there is no need to explicitly mention d4 and f4, as in LLxd4xf4-g4. I would not go so far as to use the presence of the capture indicator 'x' to disambiguate moves, though: if a Lion on e4 stands next to an enemy on f5, and can move to (empty) g6 either with or without capturing that enemy, I would not want to make this clear by writing Lg6 vs. Lxg6, but require Lxf5-g6 for the latter instead.

So I suppose the rule must be that if there are multiple moves with the same origin and destination, differing in the number of locust captures, all of those should always explicitly mention all locust victims. And the locust squares should always be mentioned in full; no quirks like Lxf-f6 to distinguish the capture of a piece on e5 or f5.

This still does not seem very satisfactory for 'shooters' like the Odin's Rune Chess Forest Ox, which is a Knight that can optionally capture one enemy adjacent to its destination. Moves like FOxe4-f3 for a Forest Ox coming from g1, to contrast it from the noncapturing FOf3, look a bit unnatural, as we don't envision the Ox reaching f3 via the more distant e4. A more intuitive description has the Ox moving to f3, and picking a neighbor to shoot down from there. We could adopt a system for this like is used in International Draughts notation, where the pieces captured by the move are written as a comma-separated list after a semicolon behind the move. Like FOf3;e4. This could also be used for burning, if we adopt the convention that mandatory victims can be omitted from the list. The Fire-Demon move discussed earlier would then become FDxh12; .

That still leaves the issue of pure rifle captures. For a piece that normally is a trampler, such as the Lion, it would make sense to write it as a back-and-forth two-leg move: Lxe5-e4 for a Lion that started on e4. For Rifle Chess itself it would make less sense to always write the redundant return leg. It would be more logical there to just write Rxe7 (for a Rook on e1), and understand from the rules that this implies return to e1. This would make the move notation inconveniently rule-dependent, though. That problem would not exist if another symbol than 'x' would be used to indicate this kind of capture. In fact R;e7 would be a generalization of the shooter notation, where omission of the destination square would imply the piece stays/ends up on its square of origin.

Unloading of pieces is still another matter. Perhaps a special symbol should be used for legs of a move that swap a piece with what was on its destination, like the tilde. So S~e4 could be the move of a 'Swapper' on e2 that 'captures' to e4, and relocates the victim to e2. The Valkyrie of Odin't Rune Chess can relocate a 'friendly victim' to any square on its path, which can be written as a move that visits the unload square virst, and then swaps from there: coming from e1 this could be V-e3~e7 to capture on e7 and relocate the old occupant to e3. I already introduced the symbol ~ for indicating flexible castling, but in that case the destination square of the King is usually empty, so it cannot mean swapping there. (There is the case of a castling where the King ends on the Rook square, though, so perhaps we should introduce different symbols for swapping and castling. Or we could adopt the convention that for pieces that can castle the ~ always means castling.)

Thanks.

The navigation code was still a bit of a mess in the betzaNew script. (Like the SAN generator and parser...) I hope I fixed it now. The problem was that burning is encoded in the move in a different way before and after it has gone through the AI's scoring routine, and that processing it with the scoring routine twice would first make the promotion piece non-virgin, and the second time interpret that as a burn. Now all moves should be processed by that routine only once, irrespective of whether they are hand-played or AI-generated.

Thanks.

I also noticed another bug where the King seems to be deleting Pawns to its bottom-right (from white's perspective) after moving to its destination when navigating through the game. For example, in the previous comment's diagram, 1. Ke9e8 will delete the Pawn on f7, and 1. Ke1e4 will delete the pawn on f3 after clicking < and then >|.

This was apparently a case where 'undefined' as value for the promotion piece in the move was not the same as when it was 0 (to indicate no promotion). It should be fixed now.

I noticed a bug affecting drops in betzaNew.js. If you use the navigation bar to go through the game, dropped pieces will turn into empty spaces.

Here's an example from Seireigi: 1. c4 g6 2. Bxh8+ Sxh8 3. B@c3

Click '<' and then '>|'. The captured Bishop will be dropped on c3 and then turn into an empty space.

Perhaps there could be a way to allow usage of the special characters in piece IDs in parameters like morph and captureMatrix? Maybe using {} curly brackets to enclose IDs using one of these special characters (e.g. {+P} for a Tokin (promoted Shogi Pawn))? In particular, the +[A-Z] ID is quite common in certain Shogi variants.

I noticed a minor bug that makes the jump highlights for black pieces yellow instead of orange.

Thanks, fixed. Testing whether a move was the first leap of a slide with stride > 1 did not come very natural in the AI's move generator, (so initially NewClick did not use orange at all), and I made the destinction by testing whether destination = origin + step. But I forgot that for black all steps are flipped compared to the tabulated moves, which use white POV.

I noticed a minor bug that makes the jump highlights for black pieces yellow instead of orange.

I also discovered that demotion of promoted pieces doesn't occur for captured pieces going into the hand when using Shogi-style promotions. Perhaps this can be parameterized to account for variants with different drop rules than Shogi.

Ah yes. When I implemented updating the holdings in the AI, it was purely for the purpose of selecting a promotion piece from your own captured pieces (holdingsType=1), as the AI cannot handle drops (yet). But now that the NewClick system uses the AI also for performing the moves at game level, this spoiled the holdingsType=-1 case.

For efficiency's sake I had changed the treatment of the holdings, by never flipping the color of pieces on capture, so that at game level it had to be flipped on dropping (or for displaying the number of pieces available for dropping). This was implemented, but I forgot to do the demotion. It seems best to also do that during dropping, so that it does not burden the AI in games without piece drops. To correctly display the counts for pieces with drops I added some code after performing the move at game level through the AI's move routine. This runs through the hand, and removes all promoted pieces from it, adding those to the counts of their demoted form.

For Shogi-style promotion all piece types larger than promoOffset are demoted by subtracting the promoOffset. For chess-style promotions all piece types available as promotion choice are demoted to type 1 (supposed to be the pawn). This is only done when the holdings type equals -1. This means it can be suppressed by setting holdingsType=-2, which would still flip the color on capture.

I also fixed the problem with e.p. capture in out-of-turn moves. When a piece of the same color is selected as the one that last moved, the memory of that last move (which contains the e.p. squares the move created) is suppressed during move generation for the purpose of highlighting and move selection. But immediately restored afterwards. So that you can still change your mind after a misclick, and move a piece that was on move after all, without having spoiled its e.p. rights.

I also discovered that demotion of promoted pieces doesn't occur for captured pieces going into the hand when using Shogi-style promotions. Perhaps this can be parameterized to account for variants with different drop rules than Shogi.

I guess this is an unintended side effect of the way it treats the ban on castling through check as an e.p. capture. This doesn't work if you play two moves in a row for the same side, as the e.p. rights created in the first move will create spurious e.p. captures of friendly pieces in the move list for the second. A similar effect occurs on Pawn double pushes: after e2-e4, clicking d2 will show a capture to e3, and if you select that as destination, remove e4.

In a game (and while thinking ahead) this will of course never happen. But when setting up a position this could be annoying. I suppose the Diagram should detect 'out of turn' moves, and refrain from updating the 'previous move' (which will specify the e.p. squares) for those. Or perhaps clear it. Another solution would be to test the color of the specified e.p. victim, and suppress the generation of it when this is a friendly piece. (Like it suppresses c-mode captures in that case.)

Castling seems to have this weird bug where the diagram thinks it can make an unloading move with the castled Rook (or King (?)) if another move hasn't been made since.

Me too with Safari, similar messages, "load cannot follow more than 20 directions"

When I try to view this page, or the play-test-applet page or others by H. G. Muller, I get a TOO MANY REDIRECTS error.

Ah, the new routine for performing moves at game level was not setting the variable 'movedPiece', from which the button derives who's turn it is. This should now be fixed.

If you press the Move button repeatedly in any diagram using betzaNew.js, the AI will only move one side's pieces.

I cannot reproduce any of this. If I enter the second game by hand up to 11. Ce4, switch on the AI and then play Cxe4, it replies with a double capture, and both victims disappear.

It doesn't seem to happen in Chrome, but it does occur in Microsoft Edge. Strange. But like I said, the bug seems to be a niche case, apparently more so than I was expecting.

Edit: It does happen in chrome, but under different circumstances. So strange...

I agree that the SAN needs reworking. As it is now, it also gets stuck on castling moves when the move has a tilde (~) in it.

I cannot reproduce any of this. If I enter the second game by hand up to 11. Ce4, switch on the AI and then play Cxe4, it replies with a double capture, and both victims disappear.

I cannot paste the game into the Diagram, though; it produces illegal/ambiguous move alerts after a few moves. But I have not adapted the SAN generation and parsing to the newClick system yet. This is also the reason why the notation of the capture (d3xe4xd7) is wrong; the SAN generation only considers a single locust victim. It will have to be rewritten to take an arbitrary number of victims into account.

This time I made it so you can toggle between the two movesets I am considering for the Shima (more test cases basically). The bug seems to only occur when the AI makes a zigzag pair of forward jump captures.

• Original Shima (KaK): 1. Ca3 cd6 2. Cf3 Ce4 3. cd3 Cc5 4. Sb3 Cc6 5. hg3 Cg4 6. de3 h6 7. h3 Cc6 8. d4 Ce6 9. c3 b6 10. Sb4 a5 11. Sb5 Cc7 12. Gd2 Cxb5=S 13. Cxb5=S a6 14. Sc4 Gb7 15. Gg2 de6 16. b3 Sb6 17. Ch2 Kd8 18. Cg4 hg6 19. Cxc6 Gxc6 20. Sxa5 b5 21. Sa3 Rxa3=S 22. Rxa3=S f6 23. a4 Ge7 24. axc6 Sxc6 25. g4 d5 26. Ge3 e6 27. f3 Sb6 28. Sb4 Sc6 29. de4 Sc4 30. Gd3 gf5 31. Gxc4=S f5xg4xf1=G
• Multi-capturing Shima (Kmca(b)1K): {2053676357} 1. Ca3 cd6 2. Cf3 Ce4 3. cd3 Cc5 4. Sb3 Cc6 5. hg3 Cg4 6. Cc2 Cf6 7. Cb4 Cxb4 8. Sxb4xb3 Gg8 9. Cg5 de6 10. bc3 ef6 11. Ce4 Cxe4 12. d3xe4xd7

The last move of each only captures one of the victims it intended to capture. It appears that this bug is a niche case.

Edit: The AI has also gone completely out of whack. It will only move the black pieces as of right now.

KaK

I cannot reproduce this. For one, there is no piece called L. If I assume it stands for Shima, enter the game, and click the Move button, it captures the Cavalier with the Shima. And the game makes no sense, as the Shima was worth much more than a Cavalier, and it was not traded for one.

Now, however, the move of the Shima seems to have changed, so that I cannot even paste the game anymore without illegal-move complaints.

While looking at interactive diagrams on my phone, I noticed that they did not resize properly to fit the smaller screen. While the spaces would get narrower, the height would not adjust to match, making the spaces rectangular. Instead of resizing, the pieces would be cropped. In Eurasian Chess, which uses its own board image, the board image would be cropped instead of resized. Perhaps something could be done with the CSS to allow boards to resize on small screens. I saw the same effects on my desktop by resizing the window.

I've noticed that the betzaNew.js file seems to be inflating the images for certain diagrams.

Correct, I added the style property background-size:contain to the cells. This in order to allow the use of 'oversized' piece images, which would allow reasonable zooming without loss of quality. E.g. the animated Fire Drragon in the Minjiku Shogi Diagram is 100x100, for square size 50x50. (I did this because the gif did not seem to support partial transparency, and thus had non-anti-aliased edges; demagnifying those partly restores the transparency, by averaging with the actuial background after rendering.) To prevent the blurring in the image you show you should set the squareSize to 33.

The idea has always been that the piece images should have the size of the square they were designed for. When these images were still displayed as cell content this did not entirely work, as the alignment algorithm reserved a few pixels below the image for 'true descenders' of the currently valid font specifications. But making those background solved the problem.

Before I forget, I gave you that Mitsugumi Shogi link for the Variants playable against the diagram's AI page.

OK, done. I still had to add lots of variants for which I made Diagrams lately.

Before I forget, I gave you that Mitsugumi Shogi link for the Variants playable against the diagram's AI page. It's in the top comment.

Is there a way to tell if a piece is protected or not in the custom scripts when using the new move generation system?

Good question. I am not sure how this rule officially is: ban capture of any protected piece, or just of a protected royal. To implement such a rule capture of a royal should not be an immediate winning condition, but a delayed one, to give the opponent the opportunity to invert the result in the after-move. So you would have to specify it as baring, where only the 'royals' count in the baring (i.e. royal=-1, baring=N, baring=M, baring=J where N, M and J are the sequence numbers of the King, Prince and Emperor). Counterbaring should then not be a draw, but a win. Problem is that when you have Prince + Emperor, the recapture of the Emperor would not counter-bare you.

Another way of looking at it is that Emperor x royal should be subject to a rule like Lion capture in Chu (activated by protect=N). Currently multiple pieces can be protected by this, but they then would all be forbidden to capture each other (when protected). And we don't want that here for KxK. (This would have been avoided if the rule excluded adjacent squares, such as it really should for Lions, but currently doesn't.)

Just like the captureMatrix can be used to specify ironhood more precisely than the parameter iron=N by use of ! symbols, we could introduce another symbol for banning the capture only if the destination is protected. The AI handles the protect parameter by making the capturer temporarily royal for one move, so that a recapture decides the game in favor of the opponent. This is now triggered based on the 'royalness' property of attacker and victim, but could be triggered in addition by consulting the captureMatrix. Making the capturing Emperor temporarily royal in a game where otherwise only baring decides the result would revert this result when the after-move recaptures that Emperor. Even when there still is a Prince.

I will work on it.

[Edit] OK, I now implemented the following features:

• Burn highlighting should occur for all pieces that can burn (i.e. have a @ in the captureMatrix), and only on moves where they would actually burn something (based on occupant of the destination, and the blast Zone).
• An = in the morph board of a piece puts a ban on friendly capture by that piece on the corresponding square.
• A % in the captureMatrix bans the corresponding capture when the victim is protected (i.e. pseudo-legal recapture is possible).

Note that the latter ban will not be indicated during move highlighting, as this is considered a matter of legality rather than pseudo-legality. And currently highlighting is done based on pseudo-legality. (Especially with NewClick, which doesn't even use a special symbol for moving a royal to an attacked square.)

Is there a way to tell if a piece is protected or not in the custom scripts when using the new move generation system? I just revived Hook Shogi, and I would like to include Maka Dai Dai Shogi's Emperor in the game, but I'm not sure how to do that using the custom script when using newClick=1.

Fergus Duniho wrote on 2023-02-14 UTC

I set up the 404 page to log 404 errors, and I'm getting one from this page for this URL:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/wDummy.png

I guess the Design Wizard in the Interactive Diagrams article is the culprit for that; it uses a piece called Dummy when it first brings up the specified board and allows you to start selecting pieces, because it would be considered an error to have a Diagram without any pieces. After selecting the first piece the Dummy would be removed from the list. I guess I should create an entirely transparent image for the purpose of displaying the dummy's image in the piece tabble.

Speaking of captureMatrix, I updated the Tenjiku Shogi Interactive Diagram to use it, and I noticed that the burn marker was only being used on the last piece that had burning abilities from captureMatrix. You can see it in action by clicking the link and promoting a Water Buffalo and clicking the newly gained Fire Demon, and then compare it to one of the original Fire Demons.

I set up the 404 page to log 404 errors, and I'm getting one from this page for this URL:

https://www.chessvariants.com/graphics.dir/alfaeriePNG/wDummy.png

Now I have it figured out. Thanks. I'll also redo the Tenjiku Diagram so it uses captureMatrix instead.

Now I've got it figured out. Thanks to this, I no longer need the modified NextLeg function (jumpClass is still needed to for the multi-captures though).

However, I do need help with captureMatrix.

Well, for one you have commas in there, which doesn't mean anything (these are just ignored the way the parsing of the matrix is implemented now). Also, a number indicates how many times the previous symbol should occur (so ^3 expands to ^^^). I get the feeling that you use the numbers as if they are coordinates. So that your

27^27,27^60,27^28,27^61,27^34,27^64,27^35,27^65,27^37,27^46

is intended to mean

...........................^^.....^^.^........^.............^^..^^

or in shorthand

.27^^.5^^.^.8^.13^^..^^

Since miscounting the number of rows was a frequent source of error I now made it such that " followed by a number N in interpreted as N rows containing " (i.e. repeating the previous row). For hop bans it was also an annoyance that you had to specify it both for enemy and friendly pieces if you don't want color discrimination. (For capture bans you can usually just ignore the friendly capture, as no XBetza move would allow it anyway.) So I introduced a new symbol =. When this is encountered the remaining enemy pieces in the row are skipped, and their values are copied to those for the friendly pieces. (You could still continue to specify values for the friendly captures/hop after the =, which would override the copy if not a dot.)

So the Suzumu captureMatrix can start with /"25/.27^^.5^^.^.8^.13^^..^^=/"//"4/.34^^.^.8^.17^^=/ .

I guess I don't really need the curly bracket enclosures.

However, I do need help with captureMatrix. I'm trying to use it to replace the modified NextLeg Function in Suzumu Shogi and Mitsugumi Shogi, and it works, but it seems to exclude certain cases where hops should be allowed (such as hopping over a lower-ranking friendly piece). Strangely, Minjiku Shogi does not have this problem. The captureMatrix value I have so far is this:

captureMatrix=//////////////////////////27^27,27^60,27^28,27^61,27^34,27^64,27^35,27^65,27^37,27^46/28^27,28^60,28^28,28^61,28^34,28^64,28^35,28^65,28^37,28^46//////34^34,34^64,34^35,34^65,34^37,34^46/35^35,35^65,35^37,35^46/////////////////////////60^27,60^60,60^28,60^61,60^34,60^64,60^35,60^65,60^37,60^46/61^27,61^60,61^28,61^61,61^34,61^64,61^35,61^65,61^37,61^46/././64^34,64^64,64^35,64^65,64^37,64^46/65^35,65^65,65^37,65^46
 

Would it be possible to implement a system to allow the inclusion of pieces with multiple-character IDs in the Diagram parameters that use them?

Which parameters did you have in mind? The promoChoice already allows a comma-separated list of piece IDs, which would remove the ambiguity that could exist if the commas were omitted, and it just test if the (possibly multi-character) piece ID is a substring of promoChoice. Having IDs like +L in Shogi variants is usually not a problem, as promoChoice is not used there, and the pieces are typically not in the initial setup, so you would also not have to indicate them in a shuffle parameter. The latter could be a problem; commas there are already used to separate subsequent shuffles, so if we would want to allow separators there we would have to use something else. Other parameters don't come to mind right away; most commands refer to pieces by sequence number (like royal, or track).

P.S. Those empty comments were me trying to insert this comment while I was not logged in, which may be the result of a bug.

Comments from non-(signed-in-)users display empty until an editor approves them, or a certain amount of time passes. They used to display a message to that effect; I'm not sure when or why that changed.

I deleted the copies of this comment.

Would it be possible to implement a system to allow the inclusion of pieces with multiple-character IDs in the Diagram parameters that use them? If you need suggestions for how to implement something like this, Fergus uses a system in his FEN parser for Game Courier that surrounds multi-character piece IDs in {} curly brackets (e.g. {+P} for promoted Shogi pawn).

P.S. Those empty comments were me trying to insert this comment while I was not logged in, which may be the result of a bug.

Well, the boards are HTML tables, so rotating them doesn't seem to be an option. I also don't see any point in it; just rotate the board back 45 degrees, and it becomes a normal board. You just have to keep in mind that the Betza angular specification have to be a bit different, for pieces that are not totally symmetric.

As to hexagonal boards: perhaps. It would be possible to build a table on a grid of half-width or half-height cells, an merge two cells bordering on their long side into one by colspan="2" or rowspan="2" parameters. And do that in a masonry-like pattern. That would give the same topology as a hexagonal board. By suppressing the borders and specifying transparent square shades, you could the use a whole-board image with true hexagons as background.

The script just refers to the table cells by HTML id of the <td> elements, and would not have to know about the 'skewed' layout. The only thing that would have to be changed is the routine that constructs the table. You might need more parameters than just files and ranks to describe the board. E.g. the files and ranks parameters could define the left and bottom sides of a diamond, and a third parameter could specify how many 'short diagonals' should be left in the center. (Where the default 0 would give you a rectangular board).

Move descriptions would of course look strange and asymmetric, like frblvvssQ for a rook-like move along 6 rays. AFAIK  there is no hexagonal Betza notation.

Is there any chance of having interactive diagrams for hexagonal or 45° rotated square boards?

I added three new spells:

• protect - makes friendly pieces in the spell zone uncapturable
• brake - suppresses enemy moves through or out of the spell zone
• hide - makes all pieces in the spell zone 'transparent'; i.e. friendly sliders can then hop over those

In the following Diagram the Queen casts the spell on the K squares. (Refresh browser cache!) You can use the button to try another spell:

Current spell is Burn

Current spellZone is K

You could increase the cap of instances of one type for trackPieces to four without much trouble.

Well, that is actually not so easy, because then you would have to examine all entries to see which one has to be replaced, as all others could contain valid data for the other pieces. With two I only have to examine the first entry, and if the piece is not there it must be in the second.

If pieces were numbered, rather than piece types, life would be easier. The piece encoding could consist of a color bit, a virgin bit, a number of bits for types (now 7, to allow 511 types, which is perhaps a bit generous), and 2 bits for an instance number. Then the type could still be examined by masking out the type bits, but type+color+instance number could be used to index the location[] array, where each instance would then have its private entry, which would be adapted when that instance moves. The spell-zone marking would then have to loop through all 4 instances, and check if the colored type is indeed in the recorded location (since we don't track capture), and mark its spell zone if it is.

The problem is that I use many of the bits in the board[y][x] elements to indicate markers; the old move-entry system used that to know whether a destination click would have to trigger a castling or e.p. move, or whether it was a locust square. So I would have to be careful not to collide with these bits.

The work-around of defining two (identical) types of Chariot Soldiers, promoting to two (identical) types of Tertarchs is an extremely simple one, though. It would only require that both types will get their spell zone marked. I could add a parameter trackedTypes=M for that, which in combination with trackPieces=N would put spell zones around type N to type N+M-1. And leave it to the user to make sure there are never more than two instances of each sub-type. That would only require me to put the spell-zone-marking code I have now in a loop (with M iterations) over these piece types.

BTW, the tracking, and thus the marking the spell zone of the indicated piece, currently only works correctly if there are not more than two pieces of that type in play. Otherwise it will loose track of some of the pieces. The current way I use for tracking just keeps two locations (in loc[coloredType] and loc[coloredType+512]), of the last two pieces of that type that were moved during the search. (And it then only marks the spell zones around those.) Now this is fine for Mitsugumu Shogi, but in Suzumu Shogi there can potentially be 4 Tetrarchs. This is of course unlikely to happen in a real game, so perhaps we should not worry about it at all.

I can switch to a more robust way of tracking, able of handling an arbitrary number of pieces of the same type. This would cause a slight slowdown, though. Which is a pity, as almost no game would use it. An cheaper alternative would be to allow requesting spell zones around more than one piece type, so that piece types of which there can be more than two instances can be artificially split into two identical types. The location of each piece is tracked anyway, it is just a matter of marking the squares around the designated types before every move generation, and pieces where only a single type cause spells would not experience a delay by this.

It would even be possible to mark the spell zones of different types differently, e.g. as nodes | (1<<(24+K)) for the Kth spell zone. This would allow, say, freezing and burning in the same Diagram. The test for being in the zone would than have to be (neighbors[sqrNr] & 0xFFFFFF) == nodes. I wonder if all that complexity would be worth it, though. I am not even aware of any variants that would need it.

You could increase the cap of instances of one type for trackPieces to four without much trouble. This would take care of the 3+ Tetrarches problem in Suzumu Shogi while leaving plenty of room to handle the vast majority of cases. However, the more robust tracking method would be preferred for games using Chess-style promotion (you could have up to (#startingSpellPieces)+(#piecesPromotableToSpellPieces) pieces with spell effects).

As for multiple spells, I agree would not worry about that right now, as I can't see any variants that will be using that either. Besides, there is also the frozen variable, the 251 kamikaze promotion, and the 512(+[bits]) promotion methods, which can be used to implement spells in the xxZone, xxxPromotion, and xxxTinker scripts withouts using the spell parameters.

@Adam: I see that you are using your own markers. Beware that I have added a new marker (markerFFF000.png), which the betzaNew.js script uses for indicating moves of a piece that has active burning defined for it through the captureMatrix in the move diagrams. It then also indicates the blastZone on hovering, by making the background of the burned squares around the indicated target grey.

Thankfully that's very easy to do, as my markers are all simple circles.

@Adam: I see that you are using your own markers. Beware that I have added a new marker (markerFFF000.png), which the betzaNew.js script uses for indicating moves of a piece that has active burning defined for it through the captureMatrix in the move diagrams. It then also indicates the blastZone on hovering, by making the background of the burned squares around the indicated target grey.

BTW, the tracking, and thus the marking the spell zone of the indicated piece, currently only works correctly if there are not more than two pieces of that type in play. Otherwise it will loose track of some of the pieces. The current way I use for tracking just keeps two locations (in loc[coloredType] and loc[coloredType+512]), of the last two pieces of that type that were moved during the search. (And it then only marks the spell zones around those.) Now this is fine for Mitsugumu Shogi, but in Suzumu Shogi there can potentially be 4 Tetrarchs. This is of course unlikely to happen in a real game, so perhaps we should not worry about it at all.

I can switch to a more robust way of tracking, able of handling an arbitrary number of pieces of the same type. This would cause a slight slowdown, though. Which is a pity, as almost no game would use it. An cheaper alternative would be to allow requesting spell zones around more than one piece type, so that piece types of which there can be more than two instances can be artificially split into two identical types. The location of each piece is tracked anyway, it is just a matter of marking the squares around the designated types before every move generation, and pieces where only a single type cause spells would not experience a delay by this.

It would even be possible to mark the spell zones of different types differently, e.g. as nodes | (1<<(24+K)) for the Kth spell zone. This would allow, say, freezing and burning in the same Diagram. The test for being in the zone would than have to be (neighbors[sqrNr] & 0xFFFFFF) == nodes. I wonder if all that complexity would be worth it, though. I am not even aware of any variants that would need it.

It would be a misconception to think editors communicate amongst each other by any other means than the comments you can read here...

Well, whatever the case, the issue is settled. I'll let you get back to working on the Interactive Diagram code.

It would be a misconception to think editors communicate amongst each other by any other means than the comments you can read here...

I don't know how to approve articles; I limit my activities as editor to inserting Interactive Diagrams in existing articles, and improving the infra-structure for doing this. I am the only editor working on this task, and it doesn't seem a good idea to reduce the time I can spend on it by also taking up tasks that other editors can do.

That's OK. I assume you passed that along to another editor, and they approved it themselves.

Also, can you approve the Rules pages for Suzumu Shogi and Mitsugumi Shogi?

I don't know how to approve articles; I limit my activities as editor to inserting Interactive Diagrams in existing articles, and improving the infra-structure for doing this. I am the only editor working on this task, and it doesn't seem a good idea to reduce the time I can spend on it by also taking up tasks that other editors can do.

That's a really nice feature. For example, it saves a huge amount of time in the diagrams for Suzumu Shogi and Mitsugumi Shogi from not having to check nearly as many locations for Heavenly Tetrarches (which which immobilize non-Tetrarch pieces) during move vetting. I've now implemented the new code in the Rules pages for these games.

Also, can you approve the Rules pages for Suzumu Shogi and Mitsugumi Shogi? I've been waiting rather patiently, and their corresponding GC Preset pages have been approved, but the editors haven't seemed to notice the Rules pages, possibly due to the new sorting method for the Review New Submissions page.

Yes, non-zero track always keeps track of the coordinates of all piece types, and type N is special by the adjacent squares getting the 'nodes' mark in the 'neighbor' array, so the user can  test it, and do whatever he wants with moves that touch the spellZone in some way. Defining a spell only makes the corresponding action already performed by the Diagram script itself.

I guess I should add some more spell flavors: protect could make pieces standing in the spell zone uncapturable. And hide could make them transparent, allowing any piece to hop over them..

Does trackPieces=N track the pieces around pieces of type N if spell is not set?

I changed the name of the parameter to specify burning or freezing from curse into spell, and added parameters spellZone and blastZone. The latter can be used to define the area on which the spell (e.g. passive burning) and the active burning works, relative to the tracked or moving piece. They can be given the value K (the default), W, F or N.

Hi Aurelian. I'm glad you have looked at that link (more than once, presumably) in the past. I meant to say I was pondering about making settings files/('unofficial' presets) for many CV invention ideas of mine, which I was thinking of not trying to publish at least for a while longer. I thought you might be a typical user of CVP site in some ways, so I asked you about the link (featuring a list of possibly played presets on GC) since I know you, and you are paying attention to the present thread (sorry my post is off-topic again).

I was hoping by people (e.g. one being me) playing at least one game with a given 'unofficial' (that is, unpublished) preset of mine, that preset might have at least a slim chance of being stumbled on by someone using that link I just asked you about (then such a someone could play or popularize said CV of mine, if I never got around much to either). Slim chance, yes, but better than if I just left said preset as an unplayed Settings File of mine (people might have an even slimmer chance of finding it that way, I thought, even though I am a known inventor). Publishing presets (plus rules pages) would be best, but that could take ages since for one thing I have over 20 CV invention ideas of mine stored away since 2019 (e.g. there was a limit of 9 submissions at a time [including a given preset or rules page] suddenly introduced during that period - so I just kept letting my ideas pile up).

I now improved the piece-value guessing of the Diagram. This used to be based on the 'raw' moves delivered by the move generator, as specified by the XBetza notation. But now that user scripts can add locust victims, either directly or through a promotion code that requests burning, it has become important to first subject the move to this script before determining its power. Before, the values of the Ultima Pincher Pawn, Coordinator and Immobilizer were estimated as next to nothing, because the guessing only saw the mR or mQ part, and the Chameleon was given the same value as the Long Leaper (because the XBetza description was the same, and it did not realize that the leap-capture part was restricted to capturing Long Leapers only).

Guessed values based on the 'cooked' moves were much better; only the Immobilizer was still considered worthless, as even the cooked move never has any captures. So I added an ad-hoc bonus for a piece that puts a spell on its neighbors: 1000 for freezing, 600 for charming and 300 for burning. This makes the Immobilizer the most valuable piece in Ultima. (Which I believe it should be.) The Chameleon might still be underestimated, as no account is taken of the fact that it can freeze an Immobilizer. (Which of course has the repercussion that it then also gets frozen itself. But since the Immobilizer is worth more, this should be worth something to the Chameleon.)

I wonder if I should also support an opportunity for affecting the evaluation through a user script (say xxxEval()). Of course there is already the value=N parameter, which can be used to tune individual piece values. But the current evaluation doesn't take into account whether pieces are frozen. It might be very hard to program something sensible for this, though.

I have not looked there in a while! Why do you ask?

@ Aurelian

Off-Topic, a quick question:

Have you looked at the following link in the past (hopefully extensively) when searching for CVs to play on Game Courier at some point in time? - I'm thinking if I have preset(s) out there, one day, that haven't been published, maybe, hopefully, there's at least a small chance people might find them by using this link (if not my personal Settings files link). That's since I have a large backlog of ideas for CVs that might take ages to publish:

https://www.chessvariants.com/play/pbm/listgames.php

There is something wrong with the diagram for Desert Pub Chess.

This is fixed now. (Flush browser cache!) I had already fixed a similar bug in the betzaNew.js. Actually it was two bugs. One that it used the last square in the move array as the center of a burn, while the destination is always the second square. This only manifests itself on moves with locust squares.

The more subtle bug is why it would think it has to burn here at all. This was because the 512 bit in the promotion code that is used to request burning is used in the on-board pieces to indicate the piece is non-virgin. At some point the 512 bit in a promotion code has to be translated into extra locust squares, and normal promotions have to get ther 512 bit set to prevent they have their initial moves. This is done just before execution of the move, in the routine that calculates the score gained by the move. The problem was that the moves obtained from the AI have already been performed once, during the search. While for moves entered by clicking this still have to be done after the move is selected. The result was that moves from the AI were scored twice. So that a normal promotion got its 512 bit set the first time, and the second time than made it into a burn. And the Pawns appeared because some of the burn squares were actually empty, which for locust squares is interpreted as an unload of teh captured piece...

There is something wrong with the diagram for Desert Pub Chess. When the AI moves, it seems to spuriously remove pieces from the board in unpredictable ways. Furthermore, this bug also affects the desert pieces, causing them to not capture properly when they capture more than once.

Normal Move Bug Replication

Move each pawn forward one at a time, you should see the opponent's pawns add locust squares (the dull red highlights) when moving. Eventually the AI will make a Knight move that removes a friendly pawn. 

Desert Piece Bug

Make the following moves manually:

1. e2e4 f2g4 2. Fc8d5

Then open the AI dashboard and move a white piece. You will see some very strange behavior (only one white pawn gets captured and the other is "moved" to a different square).

There are times I think you are a magician, HG!

An Interactive Diagram using the new scripting interface is now available in the alternative script betzaNew.js. (Which, after sufficient testing, will replace the current betza.js). As a test case I used it to create the Ultima Diagram in the previous posting.

Ultima required a fair amount of scripting. Only the Long Leaper and the Withdrawer can be done purely with XBetza. The Immobilizer can be done with the aid of the new trackPieces=N and curse=freeze parameters. Pinching is a kind of burning, but since it is dependent on the burn victim being sandwiched, this has to be tested in a script before a 'selective burn' promotion can be issued. Coordinator capture needs to be performed entirely by the custom script (using the coordinates of the tracked King), by adding locust squares to Coordinator moves.

The Chameleon is of course a disaster; it needs to be able to do what all other pieces do, but in a type-selective way. Only the replacement capture can be implemented in XBetza, as kK, because the King happens to be royal. The other captures that can be described with XBetza need to be vetted for whether they capture the correct victim. I only did that for Long Leapers, and add capture of a Withdrawer as an extra locust square 'by hand'. The standard script now supplies the routine AddVictim(move, file, rank, mask, target) to facilitate that; the mask and target arguments are optional, and when omitted the square (file, rank) is only added if it contains an enemy piece. By setting mask = 0x4FF you can test for a specific colored piece type (the test is (board[rank][file] & mask) == target), and other pieces would not be affected.

The curse=freeze option would only freeze enemy neighbors of an Immobilizer, not the Immoblizer itself (of course). But if a Chameleon is frozen, it reciprocates the favor. So the custom script has to test the board for adjacent enemy Chameleons, and mark the Immobilizer square as freezing too when any are found. Al in all this gave me the following custom script:

  var myNodes = 1e8;
  function ultimaTinker(m) {
    var s, p, v, k, x, y, xx, yy, type = m[-6] & 511, col = m[-6] & 1024; // mover and its color
    if(nodes != myNodes) { // new node; update burn map first
      myNodes = nodes;
      var q = loc[col+6], x = q & 7, y = q >> 7;       // friendly immobilizer?
      if(q >= 0 && (board[y][x] & 0x4FF) == col + 6) { // yes!
        var l = (x ? x-1 : 0), r = (x == 7 ? 7 : x+1); // left and right boundary of surrounding
        for(var i=l; i<=r; i++) { // detect enemy chameleons next to it
          if((board[y][i] & 0x4FF) == 1029 - col) neighbor[q] = nodes;            // on same rank
          if(y && (board[y-1][i] & 0x4FF) == 1029 - col) neighbor[q] = nodes;     // on next-lower rank
          if(y < 7 && (board[y+1][i] & 0x4FF) == 1029 - col) neighbor[q] = nodes; // on next-higher rank
        }
      }
      if(neighbor[q] == nodes && type == 6) { freeze = 100; return 1; } // the current move should have been frozen
   }
   if(type == 1) {        // pincher moved
     var p = 0, x = m[2], y = m[3], xcol = 1024 - col; // destination and enemy color
     if(x > 1 && (board[y][x-1] - 1 & 0xC00) == xcol && (board[y][x-2] - 1 & 0xC00) == col) p |= 0x40; // W
     if(x < 6 && (board[y][x+1] - 1 & 0xC00) == xcol && (board[y][x+2] - 1 & 0xC00) == col) p |= 0x04; // E
     if(y > 1 && (board[y-1][x] - 1 & 0xC00) == xcol && (board[y-2][x] - 1 & 0xC00) == col) p |= 0x10; // S
     if(y < 6 && (board[y+1][x] - 1 & 0xC00) == xcol && (board[y+2][x] - 1 & 0xC00) == col) p |= 0x01; // N
     if(p) m[-1] = p | 512; // request a selective burn through the promotion code
   } else if(type == 5) { // chameleon moved
     // long-leaper victims
     for(k=2; k<m[-2]; k++) { // at this stage all locust squares are long-leap captures
       v = board[m[2*k+1]][m[2*k]];
       if((v & 0x4FF) != 1027 - col) return 1; // victim not long leaper; reject this move
     }
     // withdrawer victims
     x = m[0] - m[2]; y = m[1] - m[3];         // calculate unit step (should really be table lookup...)
     k = (x ? x : y); if(k < 0) k = -k;
     xx = x/k + m[0]; yy = y/k + m[1];
     if(!((xx | yy) & 8)) AddVictim(m, xx, yy, 0x4FF, 1026 - col); // add withdrawer victim if on board
     // pincher victims
     if(!(x & y)) { // only on orthogonal moves
       p = 0, x = m[2], y = m[3], xcol = 1024 - col;
       if(x > 1 && (board[y][x-1] - 1 & 0x4FF) == xcol && (board[y][x-2] - 1 & 0xC00) == col) p |= 0x40; // W
       if(x < 6 && (board[y][x+1] - 1 & 0x4FF) == xcol && (board[y][x+2] - 1 & 0xC00) == col) p |= 0x04; // E
       if(y > 1 && (board[y-1][x] - 1 & 0x4FF) == xcol && (board[y-2][x] - 1 & 0xC00) == col) p |= 0x10; // S
       if(y < 6 && (board[y+1][x] - 1 & 0x4FF) == xcol && (board[y+2][x] - 1 & 0xC00) == col) p |= 0x01; // N
       if(p) m[-1] = p | 512; // request a selective burn through the promotion code
     }
     // coordinator victims
     k = loc[col + 7];  // king location (128*rank + file)
     AddVictim(m, k & 7, m[3], 0x4FF, 1028-col); // add locust square for coordinated coordinator
     AddVictim(m, m[2], k >> 7, 0x4FF, 1028-col);
   } else if(type == 4) { // coordinator moved
     k = loc[col + 7];  // king location
     AddVictim(m, k & 7, m[3]);  // add locust squares for coordinated enemies
     AddVictim(m, m[2], k >> 7);
   }
   return 0;
  }

Issues in the interface that could still be improved:

• The standard script tests for freezing / burning before the custom script is consulted. So when the custom script adds a freezing or burning square, like it does here when the freezing is 'reflected' by a Chameleon, the move that consulted the script would have already passed the test if it happened to be the first move generated. The Ultima script above has to explicitly test for that.
• The standard script now automatically marks the 'blast zone' around the tracked piece (controlled through trackPieces=N). But it now always uses K steps for that. It might be useful to make this user-configurable, through an option blastZone, so that the default burning could take place only on W or only on F squares, or perhaps even on N squares.
• It could be useful to define the meaning of the bits in the promotion code for a selective burn (and the marking of the blast zone) relative to the player. That would allow asymmetric burning (e.g. only forward) to work the same for black and white.
• Perhaps it should be possible to specify 'shooters' expicitly. Entering the Withdrawer and Coordinator moves in the Ultima Diagram below feels a bit queer, as you have to specify the victim first. This will always happen with locust victims added by the script; you will have to click those in the reverse order from which they were added. The Long Leaper obviously is a 'trampler', so it is less strange there (and the locust squares were generated from the XBetza move). But since all these capture are all implicit side effects, it is silly they would have to be clicked at all. Perhaps there should be a third class of pieces ('burners'), that can only be defined by the user, which would then autocomplete after origin and destination are clicked.

To make life easier for those who want to extend the Interactive Diagram with custom JavaSCript, I added a second argument to xxxTinker(): this gets passed the distance to last rank, corrected for piece color. Almost every WeirdPromotion() function I have ever written required calculation of that.

I added functions in the standard script to aid with other tasks: AddVictim(move, x, y) adds a locust square (x, y) to the specified move. And VetChoice(promoPiece, d) tests whether chess-like promotion to promoPiece would be allowed (as per promoZone and promoChoice) when you are d steps removed from last rank. You might want to fake a d within the zone in cases where the user script requests a promotion outside the zone.

The moving piece will always be stored in move[-6]. As an example, when you want to allow piece type 2 to promote when it arrives on last rank from the fore-last one, but not from a larger distance, you could use

function xxxTinker(m, d) {
  if(d != 0) return 0;             // not to last rank
  if((m[-6] & 511) != 2) return 0; // not piece type 2
  if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
  if(!m[-1]) return 4;             // choice not yet made, request one
  return VetChoice(m[-1], 0);      // return whether choice is forbidden (1) or not (0)
}

If under the same conditions a shogi-like promotion to piece type 12 (different from what promoOffset would specify) should take place, things are simpler:

function xxxTinker(m, d) {
  if(d != 0) return 0;             // not to last rank
  if((m[-6] & 511) != 2) return 0; // not piece type 2
  if(m[3] != m[1] + 1 && m[3] != m[1] - 1) return 0; // not a single step
  m[-1] = 12 | m[-6] & 1024;       // specify promoted type (adding color)
  return 3;                        // request choice between this and deferral
}

Scripts like this are only needed to make the promotion dependent on the move; if it is just dependent on the square you move to, or what you capture there, the standard parameters morph and captureMatrix take care of the promotion for you. The way I have implemented it now these would have precedence over the user-supplied scripts. That is, when these specify a promotion, ban or game termination, this will be applied without question, and the xxxTinker() script will only be invoked when they don't specify anything special. So the script only has to handle the non-standard cases.

Although the script could now add as many locust victims to a move as it wants, and wherever it wants those, the trick to request burning or atomic capture through promotion code 512 will still work, and the standard script will add the locust squares in that case.

I think I will implement the following interface for extending the Interactive Diagram with user-supplied scripts:

The user can supply a JavaScript function xxxTinker(m), where xxx is the satellite name for the Diagram (default value: 'piece'), and m is an array describing the move. This array will contain the board coordinates (which always start counting at 0) for the squares involved in the move, the rank number following the file number of each square. The first square (in m[0] and m[1]) will be the origin, the second (m[2] and m[3]) the destination, and after that will come the locust squares in the reverse order as the XBetza description visited them. The element m[-2] will specify how many squares will be altered by the move. (So if there are no locust squares this will be 2: the origin and destination.) After the locust squares can come squares where e.p. rights are generated; these are not counted in m[-2]. It is not specified how many there are of those, and most moves do not have them.

The element m[-1] contains the promotion piece for the move (i.e. the piece that will appear on the destination square), but it might or might not be initialized.

This xxxTinker() funtion can then modify the m array in any way it wants. Likely modifications are altering or supplying a promotion piece in m[-1], or adding locust squares by writing those in the appropriate m[] elements, and increasing m[-2] correspondingly. When it is done tailoring the move, it should return a value to indicate to the standard script what it should do with that move. Possible return valueas ar:

-2 Terminates game immediately, as a win for the player that can do the move (as if the move captured a King).
-1 Terminates the game as a win if the player making it survives the reply of his opponent (as with Shatranj baring).
 0 Take the move as we now prepared it (which could be unaltered).
 1 Discard the move; it is forbidden (e.g. due to zonal confinement, or improper promotion piece).
 2 Suppress deferral of normal Shogi promotion (as per maxPromote and promoOffset).
 3 Take the promotion we specified in m[-1], but also add a move that defers.
 4 Perform a Chess-like promotion. Moves with every possible promotion type will be subjected to xxxTinker(), and can be
   rejected or accepted by it in the normal way (returning 1 or 0).

The value 4 should only be returned when the value of m[-1] was undefined (if(!m[-1])...), to make a move that otherwise would not promote at all offer a Chess-like promotion choice. If m[-1] does have a value > 0 the promotion choice has already been made, and we must only reject or accept it.

I am getting less and less happy with the WeirdPromotion() and BadZone() extension system for the Interactive Diagram. It is inconvenient that these are two different functions, and a shortcoming of WeirdPromotion() is its limited power for adding side effects to the move, and that it gets passed only a single locust square (while the NewClick entry system allows arbitrary many locust victims). This has been somewhat ameliorated by the kamikaze and burn/atomic pseudo-promotion codes, but there still remain lots of things that cannot be done.

It would be much better to have a single user-supplied function AlterMove(move), which gets the internal move representation passed as the single argument. This move representation is an array, which contains the coordinates of all involved squares (origin, destination, all locust squares, all squares where e.p. rights are generated, the promotion piece...). And what is even better: AlterMove() could make changes in that, (like adding locust squares), which would affect the original. As, unlike scalar objects, when an array gets passed to a function it will be the real thing, not a copy. So it could directly alter the promotion choice in the move, rather than returning it as a result, and leaving it for the standard code to incorporate it in the move.

The return value then could be reserved for signalling only. Like indicating that the move or promotion choice is forbidden, so that the move should be deleted from the move list. Or that the move is winning (e.g. by reaching a goal square). Or that a move thought to be a non-promotion should unexpectedly offer promotion choice (making the standard script duplicate the move, this time with other promotion choices, subjecting these again to AlterMove() to test whether these are allowed, and add those to the  move list when they are).

This would for instance also allow implementation of pieces like the Ultima Coordinator, which might need locust captures on distant squares at the intersection of its coordinate lines and those of the King. By switching the Diagram's tracking function on, the location of the King would be easily available, and the AlterMove() routine would just have to combine these with the coordinates of the destination on a Coordinator move, test whether there is an enemy there, and if there is, add it as a locust square to the move.

For backward compatibility the standard script could contain a default function for AlterMove(), which it invokes if the user has supplied a WeirdPromotion() or BadZone(), to call the latter two for the move in question, and translate the return values to the actions these request. (Like altering the promotion piece, or return the 'forbidden' code.) This seems a simpler and more powerful system. Perhaps some standard routines could be offered to simplify writing AlterMove(), like AddLocustSquare(move, x, y).

I am also wondering if I should devote some attention to configurable use of the trackPieces functionality in such a standard version of AlterMove(). Passive effects on adjacent pieces are not that uncommon in variants, especially immobilization. So where trackPieces=N now just serves to switch on the tracking for non-zero N, I could have N indicate a piece type for which the adjacent squares should automatically be marked in a neighbors[] array indexed by square number. And supply a new Diagram parameter neighbors, which could be given the values immobilize, pacify or burn, which then would activate to either forbid all moves with a piece standing on a marked square, forbid all its captures, or make moves to a marked square kamikaze moves, respectively. Then these rules could be implemented purely by configuration, without writing any script.

This Diagram lets the Queen burn both actively and passively. It uses trackPieces=1 to track the Queen, so WeirdPromotion() can efficiently get her location, and mark the adjacent squares as the burn zone, to destroy all pieces that land there.

(Refresh the browser cache, as there was a bug in the standard script w.r.t. kamikaze moves: these did set the 'non-virgin' flag on the resulting empty square, so the Diagram would treat it as an invisible white piece rather than an empty square. For now I solved that by making all pieces resulting from promotion virgin. Which is of course incorrect, but much less harmful.)

The Diagram I posted only does active burning. Sorry I was unclear about that.

Adam implemented the burning by embedding a custom script for WeirdPromotion. Where he first tests whether a piece lands next to a burner (and in that case returns 251 as promotion code to make it a kamikaze move), and otherwise returns 512 when the moved piece is a burner.

I only used the captureMatrix parameter in my Diagram. There is no formalized way yet to specify passive burning by Diagram parameters; you would have to supply a JavaScript extension.

The Queen burns like a Fire Demon here

Did you mean including passive burning as well? Only active burning is working for me (though Adam's Tenjiku diagram seems to implement passive burning too so clearly it's implementable as you described)

It works now.

The Queen burns like a Fire Demon here.

Strange. I had not tried it for WeirdPromotion, but I did now, and it works for me. The version on the CVP website has exactly the same size as the one I am using locally.

[Edit] Try refresshing the browser cache. Before I did that I had the same behaviour as you describe in the Diagram above.

Sounds awesome. Only problem is that returning 512 for the promomtion it doesn't work like it should. Instead of burning adjacent pieces it simply burns the moving piece as if you returned 251 for the promotion.

Unfortunatey a general t modifier is a bit hard to implement. Which is a pity, as with the unload modifier it would make it possible to describe magnetic pieces and catapult pieces.

So for now I added capture of pieces adjacent to the destination as a standard feature, controllable through the capture matrix and from WeirdPromotion(), as internally it uses the promotion element of the move array to trigger it. An @ in the captureMatrix orders promotion to piece number 512 for that particular combination of attacker and victim (wher the latter can also be an empty square). Now this is an invalid piece number, and used as a kludge to indicate 'burning'. How exactly this burning works depends on a new parameter atomicCapture=N. For N=0 it does Tenjiku-type burning: only enemies get burned, and the capturer survives. For larger N is gives you explosion like in Atomic Chess: all adjacent pieces are destroyed, friend and foe alike, but the first N piece types from the table survive, while the capturer always selfdestructs.

Now this works the same when you return 512 from WeirdPromotion(). But you have additional control there. By returning 512+C (0 < C < 256) you also trigger the burning. But in that case it burns only the squares selected through the bits of C, where 1 = N, 2 = NE, 4 = E, 8 = SE, etc. So WeirdPromotion() could do additional testing on the board to decide whether an adjacent piece should be burned or not. This could for instance be used to implement Ultima Pincher Pawns, by checking whether there is a friendly piece behind the adjacent one.

All this only works with newClick=1, which unfortunately means that the move diagrams (using the old highlight code) would not show the burning. It is not easy to cure that, as the move generator doesn't know about it (as far as that it is just a promotion), and no clicks on the burn victims are required . (During hovering over the move diagram the highlighting is as if the hovered square had received the second click, and it shows where the third can go.)

BTW, I now added a link to the Extended Betza article.

Speaking of XBetza (or rather, IBetza), you should really consider adding a link to your page on Extended Betza Notation to this page. Even if it is not strictly identical to the one used in the interactive diagrams it would be a very helpful edition. I did check for a link to that page before writing this, and I couldn't find one.

The new definition for t could be quite interesting. It also helps that kc covers the old function of t (excluding capture of royals).

True. But I have always had the feeling that XBetza notation should be the vehicle to specify that, not the promotion. What I am missing in XBetza is the possibility to specify a side effect that is mandatory when possible, but not blocking the move when impossible.

How about this: the modifier t is a leg separator like a, except that the actual piece move terminates at that point, and the remaining legs only describe the path of its 'influence'. If this is not a unique continuation, all possible realizations will be combined with the move. So where yacabQ would describe a Queen that (by virtue of the y) does a single King-like burn of an enemy, ytacQ would burn every enemy adjacent to the square it lands on, and can even land there if there is no adjacent enemy at all. An Ultima Pincher Pawn would be ytacfapR, where the captureMatrix would be used to forbid the piece (and its influence) to hop an enemy. Unlike actual moves, the last leg of the influence can be a 'hop-on' leg.

If you are prepared to use JavaScript there are many ways you could interfere with the standard operation of the Diagram. There is for instance a routine ScoreMove(move, predecessor), to prep the 'raw' moves coming out of the move generator by determining the piece types of the capture victims, storing those in the array describing the move, and calculating the effect these captures (and promotions) would have on the score. ('predecessor' is the move preceding it, only used to enforce anti-trading rules). Interfering there to add a few burn victims is not very difficult; you just replace the function by a wrapper for it, like:

var OriginalScoreMove = ScoreMove; // remember the standard routine
var burnX = [ 1, 1, 1, 0, -1, -1, -1, 0 ];
var burnY = [ 1, 0, -1, -1, -1, 0, 1, 1 ]; 
function ScoreMove(m, last) { // and redefine it
  var x = m[0], y = m[1];     // origin
  var piece = board[y][x];    // moving piece
  if(IsBurner(piece)) {
    var n = 4; // 0-3 are the coordinates of origin and destination
    for(var k=0; k<8; k++) {
      var xb = x + burnX[k], yb = y + burnY[k]; // coordinates of neighbor square
      if(IsEnemy(xb, yb)) { // this is assumed to return 0 when (x, y) is off board
        m[n++] = xb; m[n++] = yb; // add a locust victim
        m[-2]++; // this counts the number of squares in the move
      }
    }
  }
  return OriginalScoreMove(m, last); // call the standard routine on the modified move
}

I now also made promotion to empty square ('kamikaze capture') possible; it can be specified in the captureMatrix by a 0 (zero), and requested from the WeirdPromotion() custom script by returning 251 for the promotion piece. This means that it would now also be possible to implement the passive burning ability of a Tenjiku Shogi Fire Demon, by detecting in WeirdPromotion() whether a move lands next to an enemy Demon, and return 251 in that case.

Now all that is needed to successfully implement a interactive diagram for Tenjiku Shogi is to give WeirdPromotion the ability to affect other squares.

Edit: I tested this in an interactive diagram of Tenjiku Shogi, and the piece does get removed, but the diagram still thinks there is a piece there.