Comments/Ratings for a Single Item

I solved it by recognizing a new undocumented modifier in the XBetza parser, which sets the range for that particular step to 666. Further downstream in the compiling process this 666 is recognized as synonymous for 1 (i.e. a leap), but flags that this leg is a candidate for elimination (but otherwise, i.e. if a slide directly follows, would have mpo mode). The preprocessor that converts bracket notation to XBetza uses this new modifier for the intermediate steps it uses to make the initial leg commensurate with later legs.

Explicit use of this new modifier is not recommended; it might disappear once direct parsing of bracket notation is implemented.

Currently betzaNew.js only!

OK, I see. For the Alice960 you want the sliders to be flying w.r.t. piece on the 'other board', but ban the hopping for pieces 'on the same board'.

This looks like legitimate use of non-final mp legs. The issue is that the captureMatrix makes that the p in mp isn't what it looks like, and is no longer guaranteed to be allowed. So eliminating the test on the square occupancy by merging the leg is not justified.

I suppose the correct solution here is to consult the capture matrix before making the decision to merge. If there exists a p-ban for jumping over some types for the piece whose move is being treated, there should be no merging. This can be done, as the capture matrix is known at the time the XBetza move descriptors are compiled.

But this interferes with the case for which I really did this: auto-generated intermediate squares during expansion of bracket notations; the crux there was that I didn't want the p in those intermediates to be subject to the capture matrix, but explicitly written p in the bracket notation should be. I could cure that by using mpo as mode for these auto-generated intermediates, and only apply meging to mpo stepper legs. In theory this leads to the same problem, though; there might also be legitimate uses I am not aware of where one wants the p in an mpo leg to be subject to the capture matrix. I can only hope these would be more rare, as board with holes are not that common. (And forward-backward probes for an edge should be exempted from merging anyway, as this would result in a leg with zero step.)

The problem is that by the time the merging is done, it can no longer be seen whether an intermediate leg was auto-generated or explicitly written, due to bracket notation being handled by a pre-processor to produce XBetza first. In the XBetza all legs are then explicitly written.

I think for the time being I will switch to mpo merging only.

Note that using captureMatrix for restricting a p to friendly or enemy hopping is a good alternative to the dau/cau kludge, and might even be the preferred method as far as presentation to a non-expert reader is concerned.

My bad. I should've copied & pasted the link, instead of typing it manually. Fixed.

HaruN Y wrote on Sat, Apr 19 03:11 PM CEST in reply to H. G. Muller from Mon Apr 14 07:31 AM:

That seems to break some of my Interactive Diagrams (not just these).

https://www.chessvariants.com/index/listcomments.php?reply=60706

https://www.chessvariants.com/index/listcomments.php?reply=62621

https://www.chessvariants.com/index/editcomment.php?reply=64129

I guess I know what's my least favorite update now. Still my favorite tool though.

Edit: Replacing mpaf with mcdauf fixed this.

I completely missed this Comment. Unfortunately the links you give there don't seem to work anymore, so I have no idea what kind of moves you defined for which this could be harmful. Where these cases where the mpaf was supposed to make a move lame versus off-board squares / holes?

As I wrote elsewhere, the alternative would be to only perform the merging of legs on a step with mpo mode. Although the merging also can greatly improve efficiency of the move generator (XBetza like (mpaf)W for a flying Rook would effectively expand to WDHWXDXHXWXX instead of to WmpafWmpafmpafWmpafmpafmpafWmpafmpafmpafmpafWmpafmpafmpafmpafmpafWmpafmpafmpafmpafmpafmpafW, avoiding the need for needless tests that could not possibly fail of dummy intermediate squares), its main purpose was separation of auto-generated mpa legs during expansion of bracket notations like [N-B]. So that these would not be unintendedly subject to hop bans from the capture matrix, which you might want to have to make a move like [pN-B] type specific. If I make these bracket expansions use mpo intermediate dummies, and only merge these, it will likely do less harm to existing Diagrams.

I have updated the Piece Sandbox I made. Everything is in a much more compact space, and you can now hover over the current spell values to see what they do.

Also, I noticed a small bug affecting the blue header in the piece table in Dark mode causing the text to be nigh-invisible due to it being affected by the CSS for Dark mode. So I made a tiny change to all the relevant ID scripts to prevent that from happening anymore:

Now some interactive diagrams are not displaying.

There's a missing ) on line 408 of BetzaNew.js

I made some small refinements to the BetzaNew.js script:

• Putting an apostrophe on an atom in the XBetza descriptor now not only exempts the corresponding move from the effects of morph and captureMatrix, but also makes it ignore the spell. This seemed more logical, and I am not aware of any cases where a move should ignore morph or captureMatrix, but be sensitive to a spell.
• The apostrophe can now placed both directly on the atom, as well as behind the range indicator. So it doesn't matter anymore whether you write Q'3 or Q3'. (Before only the former was accepted, which was confusing, as in the bracket notation the apostrophy would go at the very end, behind the closing bracket (e.g. [W-F]').
• When a piece ID specified in the captureMatrix cannot be identified as a valid promotion piece (promotion to the type of the mover itself is always rejected), it is interpreted as a 'nothing happens', rather than being completely ignored (and cause the remainder of the row to be out of phase...). This makes it possible to represent the matrix for pieces that mimic the piece they last captured (and thus must be represented by a large variety of types) in a much more compact way, repeating the same row for each of those. (While otherwise all rows would have had to exempt a different sub-type from promotion.)

What I still might do is recognize a special symbol (say =) in a promotion set as the opportunity to defer promotion. This must now be done by including the ID of the piece that promotes as one of the choices in the promotion set. But that makes it impossible to share the same promotion set for optional promotion to the same piece between several types.

Ah! The problem is that you created the buttons yourself, having them call Switch(...). The recommended method is to write "set=Zebra-Queen" instead of "set=1" (etc.). Then the Diagram would have created the buttons by itself.

The difference is that the automatically created buttons call Twitch() instead of Switch(). And that is the routine that invalidates any existing piece values.

I obtained the same results in your example. So maybe I face a different problem. Ca you lend a hand: here ?

I just made a collection here. If I open the piece table, and click on 'Move', I get the piece values for Shako. If I then press the button for Grand Chess the table stays open, but shows different pieces for white. The last column has then switched back to displaying XBetza moves. If I click Move again, I get to see different piece values.

Are they also redisplayed properly? I can't see what you say!

It is supposed to do that automatically. The script keeps a variable that remembers for which Diagram on the page the values have been calculated. Which starts at the invalid value -1. When you then do something that requires piece values, and the current ones are not for the active Diagram, it calculates them. When you press a button it also sets that variable to -1.

Ok. But also, how do I make it recalculate piece values when a new set is loaded?

Perhaps there are some more parameters that should be made dependent on the selected setup. This would be very simple, I just have to put an "if(sel)" in front of the statement that is executed when the parameter definition is encountered, as the boolean variable 'sel' determines if the currently encountered line is within the requested set (or in set 0). The shuffle, royal and captureMatrix parameters might be good candidates for this, as these refer to pieces by their ID. And the IDs might be different in different sets. The royal parameter can also refer to piece types by number, but also there not all variants in a collection might use the same number of pieces. Other parameters that refer to pieces by number are baring, and the various anti-trading options like iron, antiTrade, protected, counterStrike...

Actually one could wonder whether it would be harmful to make all parameters subject to testing whether they belong in the currently selected set. The user can already place the definition lines that he wants to apply always in the default set (0).

Completely ignoring all lines (by just including a line "if(!sel) continue;" before the code that parses a line) would allow the auto-generated buttons to also be used for controlling the square shades and graphics type and directory, for switching between themes. There is a caveat there, though: some of the parameters for defining the look of the Diagram are only used when the page is first loaded, and would not be reprocessed when they are altered after that through a button. In particular these are the parameters that determine the board dimensions: files, ranks, squareSize, rimColor, and background. At the loading of the page these are used to create a table for representing the board, and after that the script only manipulates how the individual cells look.

I have managed to shuffle the initial position in multiple diagrams, but now I do not know how to recalculate piece values when the buttons are pressed!

Can you use the shuffle parameter within multiple diagrams? If so, how does it work?

That seems to break some of my Interactive Diagrams (not just these).

https://www.chessvariants.com/index/editcomment.php?reply=60706

https://www.chessvariants.com/index/editcomment.php?reply=62621

https://www.chessvariants.com/index/editcomment.php?reply=64129

I guess I know what's my least favorite update now. Still my favorite tool though.

Edit: Replacing mpaf with mcdauf fixed this.

You have to set the square colors to transparent, by including

lightShade=
darkShade=

Otherwise these will cover the background image. (Which is the background of the HTML <table> element, which is behind the colors and background of the individual <td> cells.)

It still does not work for me.

https://www.chessvariants.com/invention/xiangqi-with-various-new-pieces

Worked for me.

BaoQi by me

Unfortuneatly it seems I did not put in the right instruction. Here is what I have written: background=/play/pbm/backgrounds/chinese-blue-green.png

Thank you!

Here you are

Those images also have pieces already drawn. I need the image for the background variable of the interactive diagram.