Comments/Ratings for a Single Item

I guess there has always ben a distinction between what the I.D. can do through configuring it, and what it can do through additional scripting. The latter was really never documented, as I considered scripting too difficult for the intended users anyway. So it was mainly a feature for making my own life easy. And it involved in a non-backward-compatible way. Documenting it sort of forces you to remain compatible with the documentation.

I did just get an idea, though. There could be a new symbol in the captureMatrix for indicating 'tentative' moves. These then would not be added to the move list right away, but be stored in a separate list. When this list is non-empty after the move generation completed, a custom routine would be called that could process them further. This would be useful for moves the legality of which would depend on a global condition. Such as mandatory capture: all non-captures would be marked as tentative, and the custom routine could copy them all to the real move list if the latter was still empty (i.e. if there were no captures), and discard them otherwise.

A multi-square piece would then be represented by a single 'master piece', and a number of dummies. The latter would have no move of their own. All moves of the master piece, as well as any capture of it, or of a dummy, would be defined as tentative in the captureMatrix. The custom routine could then judge (1) whether moves of the master piece have the required target occupance of th entire target area (and then modify the move by adding the moves of all dummies to it before accepting it), and (2) test for the captures whether the tentative moves include captures to all components of the piece, and only accept those if that is the case (and the add all components that were not on the target square as locust victims of the move).

I can see how that would work quite brilliantly, including using icons designed for multi-square figures. I know that some .PNG sets already have a few of those.

A couple of things to consider while building this*:

• How would it handle rotating pieces like the Wall? Yes, I mentioned using morph earlier, but there's also the matter of how to execute it, since it can involve moving either end of a Twofold piece while the other is stationary -- meaning the master could move around the dummy, or vice versa.
• From a user standpoint, would they be a single piece in the listing, or one for each square? If the latter, will the master attach to the dummies, or the dummies to the master? (Of the three options, it strikes me that a master attaching to dummies might be easiest -- again, from a user standpoint.)
• Could the "dummy" system be used for the Guard from Etchessera, and similar pieces?

You've probably thought of at least the first two; I just thought I'd mention them.

*Whenever you get around to it. There's no rush at all. I'm actually more eager to see the M implemented, for Friends, Orphans, etc.

Rotation of a two-square piece could be written as a pasW move on the master and dummy that is restricted by the captureMatrix to hop over its own master or dummy.

This is a first attempt. The page contains JavaScript wrappers for the routines that perform and take back moves and the handler for mouse clicks. The Giant is represented by Vizirs on every square it covers. A 'first click' (for origin selection) on a Vizir is rounded to the lower-left corner of the 2x2 area. The move wrappers test whether the moving piece is a Vizir, and if so drags the other 3 with it after saving the old occupants of the destinations (to restore those on take back).

The remaining part is controlled by a custom routine giantTinker. For Vizir moves it suppresses those that are not left-corner. Moves with the latter are suppressed if there are friends in the destination area, and get a burn zone covering that area added when accepted.

Captures of a Vizir by other pieces are initially rejected, but backlogged in an array of spares. After move generation a newly ntroduced custom routine AddSpares (requires browser cache flush!) makes two passes through the list of spares; first it records all attacked squares, and then it test for every move whether all squares covered by the giant it hits are under attack. If so, the move is copied to the normal move list.

I did not address the issue of Cannons jumping over a Giant yet.

Nice!

In case it helps, I found some icons made specifically for giant pieces here -- at least, giant Ferzes and Wazirs.

The problem with composit images is that flip view destroys them...

I think the hopper moves are now properly implemented too. I had to make an innocent extension to the standard script, making the move generation remember the location of the latest mount used by a hopper, so the Tinker routine could use it. (Only done when the captureMatrix contains a hop ban, so for most variants no slowdown at all.) I also had to alter the way 'primed' moves were exempted from morphing and capture matrix, so that it would not exempt them from a custom Tinker script as well.

This enabled the custom Tinker routine to test whether the proposed capture of a Giant was made by a hopper, and if so, whether the mount was that same Giant. If so, the move is rejected. This prevents the normal hops cpB and cpR to 'backstab' a Giant. To hop the Giant an extra move pyafpyafcB or pyafpyafcR was added, and the captureMatrix was used to ban hopping over other pieces than Giant (but priming the single hop so that this ban does not apply to it).

The only thing that still doesn't work is promotion to Dev. I am not sure this is worth worrying about. This promotion is a bit ill-defined anyway. (What if there are opponents in the area where the Dev should materialize? Are these captured by the Pawn move?)

Other issues: It is also unclear whether the pieces that provide 'capture assist' by threatening the Dev should do this by pseudo-legal or by legal moves. I assumed pseudo-legal. 'Castling as in orthodox Chess' is impossible, or at least ambiguous, as the Rooks are further away here. Does the King move as in FIDE (i.e. two squares), or the Rook (i.e. producing the same final position as in FIDE). I assumed the latter. Can both Rooks on the back-rank castle, or just those in the corner? (Again I assumed the latter.) Why promotion on the last two ranks? The Pawns only move in steps of 1 there, and they never can get to 16th if they already promote on 15th. Even if they would be allowed to defer there, no one would do that.

I must say, realizing that all this work was inspired by my posting of the Dev as a Piece of the Day a couple of weeks ago is rather satisfying. Hopefully some of the code from this Tinker will be usable with Double, Twofold, and other large pieces, including Walls and Great Walls.

Remind me, which variant had these (Great) Walls? I know I have seen those, but cannot remember the name.

Some of the code I had to add for getting the Devs to work is very specific for this variant. E.g. it uses the fact that the multi-square piece can only move in steps of its own size.

The Wall is in Ganymede Chess; Daniel pointed out Io Chess, which also has the Great Wall (which I'll probably post to PotD at a later date).

There's more oversized stuff to come with PotD, such as Twofold and Double pieces from David Howe's Growing and Shrinking article, and extensions thereof.

That capture of any of its 'components' can already capture the Wall makes its implementation simpler than that of a Dev, (all  moves can be judged on their own merits), but the fact that it has a sliding move makes it harder: one would not only have to test for blocking of other components on the destination area, but in the entire area swept by the move.

BTW, it is not clear to me how a Wall would capture when it moves in its long direction. I would say it can capture only a single piece then.

Multiple Walls would have to be represented as different types, to prevent that components of different Walls would be mistaken for a single Wall. (E.g. if one stands on e3-f3 and the other on e4-f4.

Remapping of clicks is not really necessary, if one uses the convention that each component can move only in the opposit direction as the other.

There would have to be wrappers for the routines that perform or take back moves, to drag along the companion component.

Testing for the blocking can be done with XBetza. For moving in its long direction there is nothing to worry; the activated component can hop over its companion with a back-and-fort W move, and then continue like a Rook (pabyafR, with a hop ban for all types other than its own). For the 'double-barrel' move you can make a detour that travels over both paths: first hop onto the companion, slide to the right, moving or capturing, take an 'iso' slide back to make that a rifle move, turn left to step back to the origin, and turn left again for another iso slide. So pyarmcaibpyalyailW.

As mentioned before, rotation could simply be pasW, again banned for hopping over all types except its own.

BTW, it is not clear to me how a Wall would capture when it moves in its long direction. I would say it can capture only a single piece then.

I tend to concur, given that it moves one square at a time on that axis as well as the short.

In most cases I would tend to agree, though a construction involving walls with planar moves could be taken to at least suggest the opposite