Check out Symmetric Chess, our featured variant for March, 2024.

Enter Your Reply

The Comment You're Replying To
H. G. Muller wrote on Tue, Jan 31, 2023 10:01 AM UTC:

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.


Edit Form

Comment on the page Interactive diagrams

Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

Top level header: <H1>

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: <H2>

  • Unordered list item
  • Second unordered list item
  • New unordered list
    • Nested list item

Third Level header <H3>

  1. An ordered list item.
  2. A second ordered list item with the same number.
  3. A third ordered list item.
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

Alt text for a graphic image

A definition list
A list of terms, each with one or more definitions following it.
An HTML construct using the tags <DL>, <DT> and <DD>.
A term
Its definition after a colon.
A second definition.
A third definition.
Another term following a blank line
The definition of that term.