Comments/Ratings for a Single Item

I don't understand how to use morph for optional promotions. I have promoChoice=W/PH/PF/PQ/PS/VH/VF/VQ/VS and two pieces, P and V, with morph=*/5/6/7/8 and morph=*/1/2/3/4 but it won't work right. What I expect is that each piece would have one optional promotion on each of the 4 ranks before the last. Instead, they either get all the promotion options at the same time or none.

I have now done that too. But betzaNewer.js is experimental, and sooner or later will replace betzaNew.js and disappear itself (because it is fully compatible).

Let's not forget about betzaNewer.js (the one with the experimental Shogi promotion system).

It would be really nice if you could deselect a piece that you have just selected in the holdings.

OK, I now implemented this both in betza.js and betzaNew.js. (Every click in the holdings was treated as a first click, to prevent you could move pieces into the holdings, or between holdings squares. But a click on the already selected piece there indeed deserves to be an exception.)

@Fergus: I can no longer upload these .js scripts through the File Manager page of the Interactive Diagrams article. I get this error message:

Upload of /home/chessvariants/public_html/membergraphics/MSinteractive-diagrams/betza.js was allowed but failed! The cause of failure is unknown.

Upload through WinSCP still works.

It would be really nice if you could deselect a piece that you have just selected in the holdings. Currently this is not possible without selecting another piece in the holdings or dropping the selected piece on the board.

I must've misunderstood from an earlier conversation that multiple spells were possible if spell=defensatrate (or whatever) was put on a line after a piece listing. My mistake. (Maybe that was just something you were contemplating or considerring.)

Currently you cannot even have more than one spell in the entire game. So anti-spell spells would not be useful.

Is it possible for a single piece to have multiple spells? I've been trying to come up with an ultima variant, and I had a few ideas that might be good as spells.

• unfreeze - unfreezes frozen friends
• neutralize - disables spells of affected enemy pieces (two overlapping neutralizers would have no affect on anything but each other)
• empower - enables affected friendly pieces to capture protected enemies

So if I were to implement a parameter transparency=N, I would implement that by just filling the entire column of the capture matrix for piece number N with the code for transparency.

If that's the result, that's fine. (It'd be only on the "friendly" side, of course.)

I have grown an aversion agains specifying pieces by number, though; it is a frequent source of bugs when you decide to add or remove a piece later. So it would be better to allow a (possibly comma-separated) list of piece IDs here.

I agree 100%. I've run afoul of that several times while building the larger Kagamigi variants.

Comma-separated, yes, please. Not all games can be handled with single-letter codes (see Short Sliders).

So if I were to implement a parameter transparency=N, I would implement that by just filling the entire column of the capture matrix for piece number N with the code for transparency.

Does it mean that Re-Ghost Chess with ghosts transparent for sliders is implementable here?

Well, unlike features such as contagion and ironness tranparency cannot be implemented as a filter on the generated moves, but would have to be implemented within the slider loop of move generator. In this respect it is similar to the already implemented ban on hopping. (As the final move does neither show what you hopped over, nor what empty squares you passed through.)

But wherever it is implemented, it has to test whether the slider loop should terminate or can continue after skipping the square, based on the piece type of the encountered piece. And in that case it might as well check the piece type of the moving piece as well, by looking in captureMatrix[attacker][victim] rather than in some newly created table transparency[victim]. So if I were to implement a parameter transparency=N, I would implement that by just filling the entire column of the capture matrix for piece number N with the code for transparency.

I have grown an aversion agains specifying pieces by number, though; it is a frequent source of bugs when you decide to add or remove a piece later. So it would be better to allow a (possibly comma-separated) list of piece IDs here. That is a bit harder to implement, because you can interpret it only after al pieces have been defined, but I already did something like that for the royal parameter.

The problem with an interface that shows the entire capture matrix at once is that for a large game it might not fit the screen. And usually capture matrices are quite sparsely populated. There are only a few special pieces, that either have their colun or their row set to something (possibly with some exceptions). But I am always open to good interface ideas.

I'm not against the captureMatrix, but without a good captureMatrix builder (one that shows a complete table and not just one piece at a time, as the Beta PTA gives) it's a little hard to use. From a user standpoint, at least, it would be easier to have something like transparent=N as a parameter alongside iron, antiTrade, and others in that group. Even so, I'm not sure from a programmer's standpoint whether it'd be easier to implement it that way, or build a full-scale Capture Matrix Wizard (which I'd adore in any event).

What am I doing wrong here?

How would you do a piece that hides itself, though?

Pieces don't hide themselves; they just are transparent. Unfortunately transparency is currently not supported, other than making all sliders also hoppers, and then use the captureMatrix to forbid them to hop over anything except the transparent piece. It would of course be more convenient if there was a special symbol in the captureMatrix to tell that one type can slide through another. This might be implemented some day.

As to the spell zone: pieces are always immune to thir own spell, specifying a zone of only the square they stand on would have no effect. How would you imagine a piece that (passively) burns itself? Or freezes itself, or brakes itself, or protects itself? The latter three already exist as pieces without moves, steppers and iron pieces.

How would you do a piece that hides itself, though?

(I see the problem with the freeze -- though I still wish there could be a KAND option somehow. Or at least K2.)

You can do that through the captureMatrix. Just fill the entire column for the contageous piece with its own ID, except in its own row. The capture matrix has basically  made the contageous and anti-trade parameters obsolete; it can do all that in a much more precise way.

[Edit] I suppose the question was for if you had various contageous types, so you would have multiple columns with automatic promotion to the captured type, and you would just leave the rows of the pieces that are immune to this blank; That could also be the pieces that are contageous. You can even make them immune to some, but not to others.

Is there a way to have a piece be both contageous and immune to contageon?

Indeed. The Ko Nets are problematic, as are other Gorgon type of pieces. Because the don't really cast the spell as a fixed zone, but as a sliding move that can be blocked. So the zone doesn't only change on their own move, which is what the Diagram's implementation of spellZone assumes. The Gorgon effect is similar to the rule that you cannot castle out of check, which is again related to e.p. capture; one could say that the latter is en depart capture. Castling creates e.p. rights not only on the squares the King passed through, but also on the square it came from. And any piece type can use those rights, not just Pawn. This is how the Diagram's AI implements the ban on castling out of check; it makes it look like exposing the King to (e.p.) capture.

Gorgons could be implemented in a similar way, by adopting the rule that a Gorgon move to the origin of the preceding move must be scored as an immediate win. The square of origin becomes a kind of e.p. square for exclusive use by Gorgons, while a thus captured piece counts as absolute royal. I guess this could be specified in the captureMatrix as a new symbol, so that you could specify in a type-selective way which pieces are paralyzed by a Gorgon. An alternative is adding 'Gorgon capture' as a new mode to XBetza.

As to the spell zone: pieces are always immune to thir own spell, specifying a zone of only the square they stand on would have no effect. How would you imagine a piece that (passively) burns itself? Or freezes itself, or brakes itself, or protects itself? The latter three already exist as pieces without moves, steppers and iron pieces.

The spellZone is defined as a bitmap held in an integer, so the number of squares is limited. The N option was in fact already extra, since I didn't know any variant that would need anything else than K. or a subset thereoff. In absence of variants that actually use it, I would not extend it. (And that doesn't count variants that are intentionally designed to break the limit, as that could be done for any limit...)

Hm. So I guess I'm out of luck if I want a two-space perimeter for a spellZone -- much less the Skyward Net and Earthward Net in Ko Shogi.

Spells do not affect the piece that casts them, and I don't see why they should. The piece is always in the spell zone, so whatever the spell does simply becomes a piece property.

"Affects only itself" is basically the effect I was looking for. I just don't know how to shut down the other spaces. spellZone=0?

The spellZone is defined as a bitmap held in an integer, so the number of squares is limited. The N option was in fact already extra, since I didn't know any variant that would need anything else than K. or a subset thereoff. In absence of variants that actually use it, I would not extend it. (And that doesn't count variants that are intentionally designed to break the limit, as that could be done for any limit...)

Spells do not affect the piece that casts them, and I don't see why they should. The piece is always in the spell zone, so whatever the spell does simply becomes a piece property.

Two quick questions; I suspect the answer to both is (or boils down to) "not currently, but perhaps some time in the not-too-distant future."

1. Can blastZone or spellZone be something like (for example) KNS? or AXNX?

2. Can the hide spell be used to make the piece itself "hoppable"?

In the promoChoice the pieces must optionally be separated by commas. That is, if there is a comma anywhere in the string, the string is split at the commas to get the piece IDs. If not, strange things could happen if the piece IDs are not single letters. (It then just looks if the ID occurs as a substring, while otherwise it looks whether the ID sandwidched between commas is occurs as a substring of promoOffset sandwidched between commas.)

It is on the to-do list to use the same system in individual rows of the morph and captureMatrix. So that you would not have to use commas throughout the entire matrix if you need it in just a few rows. (Usually these matrices are pretty sparse.) If you really need this I could give implementation of this priority.

A * refers to the first set in promoChoice, a 1 to the second. (Or one could imagine counting of the sets starts at 0.) This is partly historic accident, as a 0 in the captureMatrix was already defined as kamikaze capture before alternate sets were introduced and the the promotion zone was indicated by *.

There is a subtlety here that I did not foresee, and yet has to be resolved: would you promote on entering the zone, or in every case where you end the move in it. This becomes important when you can defer promotion, (which is standard in shogi variants), or in a more general case whenever you can promote to pieces that themselves can promote. It seems undesirable to have different behavior here on promotions specified by morph=* and those controlled by promoZone/maxPromote, as the main reason for introducing * in the morph boards was to handle irregular promotion zones (e.g. on diamond-shaped boards, or in diagonal variants). But I don't think this is currently the case. (The current rules for the normal zone are complex anyway, and depend on promoOffset and holdingsType, to get the desired behavior in regular Shogi, Chu Shogi and Grand Chess.)

Since 0 has no meaning yet in the morph boards (defining squares where pieces would disappear seemed pointless; no one would move there, and you might as well make them inaccessible), it could be made to refer to the first promoChoice set, but with alternative rules w.r.t. where you came from.

[Edit] It appears the comma notation was already implemented for morph. I now also implemented it in captureMatrix. (All untested, though, and only in betzaNew.js.)

I have two questions. Is there a way to group letters for games that need piece ids longer than a single character? And, does 1 in the morph section refer to the first promotion set or the second?

I didn't realize that the apostrophe could be used for that! Cool! It doesn't cover all cases where that'd be used (such as if the piece also promotes under other circumstances), but it's a big start.

Immunity is not a property in itself, but just the absence of contagion for all captures of that piece, even when other pieces might suffer contagion (which again is a particular form of automatic promotion on capture) when capturing some victims. It seems to me that the move-dependent immunity that you want can already be achieved by specifying promotion to the contageous victim for the capture of it in the captureMatrix, and then exempt the move that you want to have immunity through an apostrophe.

Something to consider, long-term*:

Right now there's no way to make a piece only susceptible/immune to things like contagion or "poison"** depending on what sort of move it uses to capture. It does seem to me, though, that it should be possible; for example, if a piece has both a normal displacing capture and a rifle capture, these this should affect it if it uses the displacing capture, but not the rifle capture (depending on what each is supposed to represent, of course). If there was some way to represent this, such as is done with the apostrophe/single quote (') to mark moves that cannot be used to promote, that would be excellent.

*Actually, I'd use this right now if I could; I just recognize that it could take a while, since this seems like it'd be fairly complex to implement, especially compared to how often it'd probably be used.

**Treating the effect as if it was a piece property, just for the sake of discussion.

I did not take account of maxPromote, so it also wanted to promote non-promotable pieces to nonexisting ones. It should work now.

It does indeed. Thank you very much! :)

I did not take account of maxPromote, so it also wanted to promote non-promotable pieces to nonexisting ones. It should work now.

If you click the base piece in the pieceList a second time it will show the promoted version. (And a greenish text above the board invites you to do this when you show the base piece.) This should be automatic when promoOffset > 0.

This, I did notice already. The "suggestion [I] made elsewhere" was clearer, and while I thank you very much for implementing it, I think there's a typo or something that's broken it; in Kagamigi the ID now comes up as a blank grid (right-clicking brings it to normal) and the pieceList doesn't show up at all.

A suggestion/request/query regarding the pieceList function (see Embedding a Diagram in your HTML Page): could there be some way to toggle an option to show the promoted piece from each base piece? It seems to mee that it should be automatic when promoOffset > 0, though I may be missing something there.

If you click the base piece in the pieceList a second time it will show the promoted version. (And a greenish text above the board invites you to do this when you show the base piece.) This should be automatic when promoOffset > 0.

But as per a suggestion you made elsewhere, I have now already mentioned the promoted type directly in the pieceList, in brackets, also clickable for summoning its move diagram immediately. This should work both with betza.js abd betzaNew.js. (Refresh browser cache!) I only tested it on the former, though (for the Diagram in the Tamerlane Chess comments, where all non-Pawns are promoted types, which gave a very stupid pieceList).

If it's too much trouble, then it's too much trouble. I thought it might be. I won't worry about it.

It seems a bit over the top to me to have fen2 do that. This could be very easily solved by just having a gflame.svg that aleady has the color you desire, and make a compond with that. There hardly seems any application for it.

Only one color in the SVG file is ever affected by fen2. For Alfaerie that is #f9f9f9. (It can be set in a defaults.ini file in the theme's directory what color that is.) Any other color would be rendered 'as is'.

Compound pieces are made up of two SVG files. I built the White Flaming Chariot by defining it as w=F9F9F9&b=FF8000&p=wchariot-bflame. Thus:

I'm just saying, it'd be nice to be able to do the same thing with something like w=F9F9F9&b=666666&p=chariot-gflame&g-FF8000 so I could have both a White Flaming Chariot and a Black Flaming Chariot, with orange flames, using fen2. (Obviously, of course, I can make png icons for them the way I already have.)

Only one color in the SVG file is ever affected by fen2. For Alfaerie that is #f9f9f9. (It can be set in a defaults.ini file in the theme's directory what color that is.) Any other color would be rendered 'as is'.

OK, it's an issue to handle with fen2, then. My mistake (and, admittedly, a rather obvious one).

I have learned that the color can be specified after the piece, so a piece's color can be changed on the fly in the ID's list (for example, in Seireigi, where promoted pieces in the Greenwade set are green). In this case, I want to specify only the color of the Flame, so the flaming chariots shown could be described with p=chariot-gflame&g=FF8000 (or something like it).

Of course, if it can't be done, then it can't be done, and that's that; I'll not worry about it.

(And of course the use of "grey" pieces that either player can move is more of a matter for rules-enforcing Game Courier presets.)

The Interactive Diagram doesn't mess with the color of the images; it displays them just as you put them in the graphicsDir folder.

And since the ID does not enforce turn order each player can move any piece anyway. As to neutral pieces in the AI: this is complex, because a rule that allows both players to move the same piece cannot work on its own: if a move was good, then the opponent would just move the piece back the next turn. So you need additional rules to prevent that, which will likely differ from case to case.

Wish-list: allowing for a "third" color, not just to allow for "neutral" pieces that either player can move, but also for colorful icons like these Flaming Chariots:

Another thing: I do wish that spellZone could have any value. A KAND spellZone seems like it'd be a logical possibility, for pieces that affect anything within two spaces. For that matter, I have a piece called a Peacenik that would affect a charm spell at NXAX.

A suggestion/request/query regarding the pieceList function (see Embedding a Diagram in your HTML Page): could there be some way to toggle an option to show the promoted piece from each base piece? It seems to mee that it should be automatic when promoOffset > 0, though I may be missing something there.

It seems to me that the promochoice is actually numbered from 0 to 5.

I suppose it is, but the first set should be indicated by *. In the captureMatrix 0 would mean kamikaze capture, not promotion. (And other choice sets are not available there, as numbers indicate the layout of the matrix.) I suppose it works by accident, because having a piece morph to emptiness did not seem an option that would ever be needed.

But I am in the wrong anyway regarding the fact that the joker still imitates the double step. At least in the normal case- the one where I was using i - I think the joker only when unmoved got the double step. And this seems normal to me, from a game rules point of view, when I'm thinking it through.

I have replaced six with P and it worked. What I am baffled by is that 0 is working too. It seems to me that the promochoice is actually numbered from 0 to 5.

What does the 6 mean? I would have expected a P. And 0 is not a valid character in a morph board. How does your promoChoice look?

I have replaced this:

  pawn:P:mfWfceFimfnnD:Pawn:a3-j3,,a8-j8
  value=95
  morph=2/1/0/././././././.

with that:

  intialpawn:I:mfWfceFmfnnD:Pawn:a3-j3,,a8-j8
  value=95
  morph=6/6/6/6/6/6/6/././.
  pawn:P:mfWfceF:Pawn:
  value=95
  morph=2/1/0/././././././.

I think the AI has trouble putting together pawns structures or something.

I am not sure what you are comparing. Morphing should not be very costly.

But it seems this thing makes the AI really slow. It probably does not worth it. I expected slower, but not that much.

Oh, I have discovered another feature given by the usage of morph rather than i for games that include an imitator. The imitator does not get the initial double move in the morph way. This is how I want them. This is a really, really small issue but it helps!

Ok, thanks!

More like centi-Pawns. But you should open the piece table and click on the header of the 'move' column to see all the value guestimates; then you can think of a value that fits well with the other pieces.

Is N normalized to 1 pawns?

Oh, I have forgotten about that! Thanks!

This is indeed hard for the AI to understand. Since the fmnnD move is not an i move, it thinks that the piece can use it everywhere, and that significantly increases the value, probably by more than the better centralization after pushing it will gain. What it does not realize is that the type that has this move is bound to the 2nd rank, which is only a small fraction of the board, which would be a reason to strongly devaluate it.

Not recognizing area bindings is already a general problem in the value guestimating; on a large board it would evaluate vR as more valuable than R2, because it has more moves. But, being bound to a file, the vR is almost useless, while R2 even has mating potential on 8x8. I suppose I could have the piece make a few hundred random moves on an empty board, and count unvisited squares. For pieces that morph it is even more tricky, but I suppose I could count the morphing squares as inaccessible.

Anyway, the ID already has a solution for valuable aspects (or liabilities) of a piece that it cannot recognize itself: by writing value=N directly after the piece line you can overrule the automatic guestimate, and set it by hand to the given number N.

This solution has a small inconvenience. I named spearman the mfWmfeFmfnnD starting on rank 2 and footman the mfWmfeF after having left rank 2. The AI is inclined to not promote to a "weaker" piece, but the general idea is that pawns need to be pushed. This is just a small inconvenience. I'm just saying the solution is not perfect. But this is to much to handle for such a general program.

@HG: you're fantastic. I guess Aurelian is going to like this ii!

The ii does not work for the reason you mentioned. I was interested in finding out if there's an alternative to morph. As it is not I'll do it the way you have said. Thanks!

In general any kind of location-dependent moving can be achieved by defining several versions of the piece, and morphing those into the version that is needed on their destination. So in this case you would need separate types for the 2nd rank and elsewhere. (Which also means you can do it entirely transparently, giving the types the same image and ID, as the morph parameter will never make a specified type morph into itself, and will thus always pick the other type with that ID. If that still leaves choice it will pick the type that occurs last in the piece table.)

There could be an alternatie here: for the benefit of Crazyhouse I once defined ii to mean 'repeated initial move', i.e. a move available when the piece is in its initial location. This is defined as any location on which a piece of that type started. So if the 2nd rank is initiall entirely filled with pieces of that type, the ii move would be reactivated each time the piece returns to 2nd rank.

OK I understand. I don't know how to do, I guess with "morph" indeed.

No, it can move laterally and keep the ability to move twice ahead!

Then fsmWfceFfimnnD no?

@ Jean-Louis,

It is just that the D move should work only from rank 2. The rest is indeed what I am searching for.

Hi Aurelian. I have fsmWfceFfmnnD in Bigorra and some others. Isn't what you're looking for?

I need a piece that moves like the mfsWcfF. But if and only if on rank 2 it can move twice ahead if not blocked (like an orthodox pawn). The ii modifier does not apply here as there are other pieces on the rank. I have tried morph, and I think I can get it to work, but this has the inconvinience of naming the piece differently after it has moved from the second rank. Is there a better solution? Maybe an offset promotion?

Recoloring of pieces is only possible if you render them through the fen2.php scipt

Or the /play/pbm/showpiece.php script.

Recoloring of pieces is only possible if you render them through the fen2.php scipt. When rendering the PNG images you are limited to whatever images happen to exist.

This does not really have to do anything with the Interactive Diagram; this just uses the URLs that you specify through graphicsDir, graphicsType, the color prefixes and the piece names.

I'm using Utrecht. That does it!

Is it possible to use different colours for the black pieces?

Yes, if the piece sets are compatible (i.e. use the same names for all the pieces, the same color prefixes, and the same graphics type) then it is always easy. You only have to assign graphDir the path of the directory they are in, and call Display() to make the change show up. You can of course achieve all that by copying the piece images to a directory of your own, and renaming them. This is what I did for Chu Shogi, where I renamed the XBoard pictogram set to conform to the Mnemonic set naming.

I've been trying to figure out how to implement a choice of graphics sets for IDs

ID is an unfortunate acronym for Interactive Diagram, because it is one we commonly use for something else. The general way of supporting multiple piece sets is to create buttons that switch to each set by changing some of the JavaScript variables used by an Interactive Diagram. The simplest way of all, which requires changing the fewest variables, makes use of Game Courier sets.

Multiple piece sets is a feature of Game Courier, and I have designed the showpiece.php script to make use of it in Interactive Diagrams. The showpiece.php script allows you to identify a piece by its set and its label. In a demonstration I made for Chess in Comment #50843 on the homepage, I made buttons that change the piece set by changing some JavaScript variables used by the Interactive Diagram. The main one I changed was graphDir. This is the internal variable that initially gets set to the value of graphicsDir, and it is normally intended to be the path of the directory that the graphic images are in. Instead of giving it a mere path value, though, I gave it a script with an incomplete query string. This is doable, because this value is simply going to be concatenated to what is usually expected to be the piece's filename. Here are the values I passed to this variable:

graphDir='/play/pbm/showpiece.php?set=abstract%26piece='

graphDir='/play/pbm/showpiece.php?set=alfaerie%26piece='

graphDir='/play/pbm/showpiece.php?set=magnetic%26piece='

graphDir='/play/pbm/showpiece.php?set=motif%26piece='

The only difference between these is the name of the set used. These four sets are compatible for Chess, because each uses the same labels for the same pieces in Chess. In the section of the Interactive Diagram where it defines the pieces, each piece is defined by multiple values separated by colons. The 4th value is used to construct the file name.

    Pawn:P:ifmnDfmWfceF:P:a2,b2,c2,d2,e2,f2,g2,h2,,a7,b7,c7,d7,e7,f7,g7,h7
    Knight:N:N:N:b1,g1,,b8,g8
    Bishop:B:B:B:c1,f1,,c8,f8
    Rook:R:R:R:a1,h1,,a8,h8
    Queen:Q:Q:Q:d1,,d8
    King:K:KisO2:K:e1,,e8

This value is normally the piece name used in a filename, which is constructed by concatenating it with a prefix to indicate its side and an extension to indicate its file type. Instead of putting the piece name there, I have put an uppercase piece label. This is going to result in filenames like BQ.png and WR.png. These are not proper piece labels or filenames, but the showpiece.php script is going to translate these pseudo-filenames into proper piece labels. It chops off the prefix and the extension, and it uses the prefix to tell whether it should convert what remains to uppercase (for W) or lowercase (for B).

In my example, I have also changed the board colors, though this is not essential to changing the piece set. Here is what the code for these look like:

<input type="button" value="Abstract" onclick="graphDir='/play/pbm/showpiece.php?set=abstract%26piece=';light='#CCCC11';dark='#339933';Display();">
<input type="button" value="Alfaerie" onclick="graphDir='/play/pbm/showpiece.php?set=alfaerie%26piece=';light='#DDDDD0';dark='#559933';Display();">
<input type="button" value="Magnetic" onclick="graphDir='/play/pbm/showpiece.php?set=magnetic%26piece=';light='#EEEECC';dark='#226822';Display();">
<input type="button" value="Motif" onclick="graphDir='/play/pbm/showpiece.php?set=motif%26piece=';light='#CCCC11';dark='#339933';Display();">

Note that the Chess and Ultima pages include more complex examples that involves changing internal representations of filenames. This is because they use sets whose images have different filenames. You should be able to see how these are done by examining the source code. If you used sets with the same filenames that differed only by the directory they were in, you could do it more simply, similar to what I've described here, but with /cgi-bin/fen2.php or just the directory name instead.

Dang. Well, maybe I'll try to figure something out, or maybe I'll just wait for one of my submissions to be approved so I can start entering new stuff. (Or maybe I'll abandon and delete the Icon Clearinghouse.)

There aren't really. This is not a standard feature of the ID, and basically a hack. One has to improvise by adding buttons that execute extra script. Which then changes parameters that the ID script is using, in particular the graphics directory, color prefixes ans sometimes individual image filenames. This requires some knowledge of how the ID stores this data.

How much you have to change depends on how compatible the sets are. Good examples to copy from are Maka Dai Dai Shogi, and the somewhat more involved Ultima Diagrams. You can look at these by viewing the Page Source in the browser. Much more complex is Chess for Different Armies, as it was necessary to combine two armies of different color there; it just generates a new Diagram definition, and calls the code to remake that from scratch.

The Diagram Editor is even more complex. As it wants not only to change the set for a given game, but wants to adapt the entire list of participating pieces to everything that was in the graphics directory, each time you change that.

I've been trying to figure out how to implement a choice of graphics sets for IDs, and Desert Dust seems like a good candidate for it (since I have to wait for something to be approved before I can add anything new). I can't seem to find any guidance, tutorials, or such for that, though.

The falcon is evaluated by the interactive diagram pretty low.

No, it isn't. Even on the 12x12 board of the XBetza Sandbox it evaluates nCnZ as 452 and a Bishop to 395, while the Bishop should benefit from the large board much more than the Falcon. If it trades Falcon for Bishop there must be some deeper tactical reason (which could of course be a blunder due to insufficient search depth).

The interactive diagram displays castling out of chess as legal. Is this by design?

Indeed, the ID highlights all pseudo-legal moves. Perhaps a future version will highlight pseudo-legal moves that are not legal with grey crosses, rather than the normal symbols (as the version with newClick=0 would do for moves of royal pieces). I am not entirely sure whether I implemented the 'no moving out of check' rule for fast castling, but if I didn't, it should be considered a bug in the AI, not in the highlighting.

Hello HG,

1. The falcon is evaluated by the interactive diagram pretty low. It exchanges it for a bishop. We have had a similar trouble with the vulture if you remember.
2. The interactive diagram displays castling out of chess as legal. Is this by design? That in a fast castling context. I not bothered by this unless the AI understands the proper rule.

Neat explanation! Thanks!

The AI of the ID does not use a fixed-depth search, so 'search depth' is only an approximate notion. It classified moves depending on how logical they are in the context of the immediately preceding moves. Based on this it decides whether the move should be counted as 0, 0.5, 1 or 2 ply. E.g. capturing the piece that last moved is considered a perfectly logical thing to try, and is not counted towards the depth at all. This means that long exchanges on the same square are always followed to the end. Capturing a higher-valued piece with a piece that was moved on your previous turn, or passes over a square that was evacuated on that turn, is counted as half a move. Other captures are counted as 1, non-captures that were already possible on the previous turn of the same player are counted as 2. If they turn out to be the best move, this is corrected to 1, though. Similarly, if a move counted as 0 turns out to be stupid (i.e. a high-valued piece captured a lower-valued, but it turns out the latter was protected) is corrected to 1, which could lead to it being ignored (pruned) after all if not enough depth remains.

So in the principle variation (the sequence of best moves) there are at least as many moves as the nominal depth, but can have an arbitrary number of additional recaptures in it. Increasing the depth from 3 to 3.5 ply can make room for an extra arbitrary move if there already was a move that counted for 0.5 in the line, or create room for finding some more complex tactics (e.g. trading away a protector, and then capturing what it was protecting).

The interactive diagram displays an option that sets the depth of the search tree. What 3.5 ply means?

I am very glad for that!

I solved the problem now in a bit of a shaky way, in the sense that combining auto-gating with moves that do locust captures or other unloads probably would give strange effects. But at least it now sees the value of capturing the Manticore in the gating move with the Elephant.

As I am writing code for my new apothecary games, which is not even general, I came to appreciate a lot what programmers involved in CVs do. You, HG, Greg, Fergus are really deserving appreciation for this. Good luck! Live long and prosper!

Nice effort, Good luck!

The current way the immediate gain of a move is calculated uses too many assumptions. One of those is that when a piece is unloaded it would be the piece that is captured, so that the total gain of the move is just the positional score of the displacement of this piece. Since in the case of gating it is another piece, (there is replacement capture of an enemy and locust capture of the gated piece, and it is this 'locust victim' that is unloaded), this overwrites the gain due to the capture. I suppose this could be cured by scoring every capture and unload with the piece value, and add or subtract those depending on the color.

I detected another problem as well, though; capturing your own royal is now forbidden (i.e. scored as an immediate loss), irrespective of you unload it later. This would prevent a Swapper to act on a friendly royal.

I will need some time to redesign all this in a more consistent way, which doesn't rely on any assumptions. I might even have to change the encoding of gating moves.

That is great!

Not yet. But I copied your Diagram to my PC, so that I can debug it without upsetting other IDs on the CVP website.

Hello HG,

Just a friendly remainder. Have you had time to solve the AI's bug when gating?

Thanks!

I suspect this has something to do with the fact that the only way to recapture that Manticore is a gating move. If I let white play after Mxi3 it doesn't capture the manticore. I also have to enter the gatings in a strange way, as if the gated piece is locust captured. Perhaps the AI scores this as if you really lose the gated piece. I will have a look at it when I am done creating SVG pieces.

In the following: 1. F@h1 M@c1 2. M@c11 F@d11 3. e5 c7 4. c5 Bxd11-b8 5. f5 d7 6. d5 g8 7. Exc1-e4 Exc11-d9 8. Be3 Mxi3 in the following interactive diagram:

https://www.chessvariants.com/rules/hannibalchesswithmanticoreandfalcon, the AI has just sacrificed a manticore to a pawn. Why?

Yes, that did it!

Perhaps it only works with the betaNew.js script and newClick=1.

Well, HG, there is a new problem.

I have defined the king with the Betza string KispO5 which is probably correct. But the rook does not move. Have I missed something? I am not aware of any examples where both fast castling and gating are involved. Can there be a bug here?

My knowledge of the interactive diagram has became a little rusty. The king needs to be last and those places were taken by the holes :)!

And that solved all the problems!

@Bob,

I solved that. The king was not in it's proper place!

I don't know about you, H.G., but when I go in to play any of these, I make the first move and the AI declares that it already lost.

What exactly breaks? The autogating seems to work.

Fast castling is pO.

I am trying to implement gating in some games but it seems that the autogate option breaks my diagrams:

https://www.chessvariants.com/rules/wafflechesswithmanticoreandfalcon https://www.chessvariants.com/rules/wafflechesswithgryphonandfalcon https://www.chessvariants.com/rules/hannibalchesswithmanticoreandfalcon https://www.chessvariants.com/rules/hannibalchesswithgryphonandfalcon https://www.chessvariants.com/rules/frogchesswithmanticoreandfalcon https://www.chessvariants.com/rules/frogchesswithgryphonandfalcon

And a question. Is fast castling supported?

Ok, thanks!

Can there be multiple diagrams in one article?

That is not ideal. Originally the ID script was written for handling only a single Diagram. And although specifying a different satellite value for them separates them to a large extent (allowing it to know which custom scripts and external HTML elements belong to which diagram), there still appear to be some situations where confusion occurs, and clicking an element of one diagram that should make something happen actually makes it happen in the other diagram.

Can there be multiple diagrams in one article?