Comments/Ratings for a Single Item

All right, Thanks Fergus, I'll try it.

How do I create a directory?

Also, How do I upload images?

If you create an article, this automatically creates a directory /membergraphics/MSarticle-name/ for any files you upload. So you could upload all the images you want to use to such a directory, and specify that as graphicsDir in the Interacive Diagram definition. You have to make sure the squareSize, graphicsType and white/blackPrefix match that of the uploaded graphics.

You cannot use sets that are scattered over several directories. Because the diagram builds the image filenames as prefix + root name + exetension (where the exension is the specified graphicsType). So giving the root name as a pahname, like subdir/quagga, would no work, because it will prefix the directory name with the color ('wsubdir/quagga.gif') rather than the image name ('subdir/wquagga.gif'). This should be easy to fix, btw; I could make the diagram split any given roo name at the slashes, prefix the last part with the color, and then put them together again.

Thanks for the input, HG!

Honestly HG, I'd prefer that you manage to do the relative path. It would be very helpful!

Greg, Can you help me by drawing a ferz-alfil-trebuchet? I tried using my own tools but it goes kind of bad.

Oh, I see that the Diagram already supports a way to include 'custom graphics' for the pieces. I had forgotten all about that.

To include an image that doesn't use the specified graphicsDir or graphicsType, just write the full URL of the image, but with the color prefix replaced by a % sign. The script will replace that % sign by the whitePrefix or blackPrefix, as needed. So you are still limited to image names that use the same color prefixes. E.g. if you specify as image name in the piece definition:

/membergraphics/MSelven-chess/%cobra.png

you could use the cobra image there, no matter what graphics you specified for the other pieces. Note you should also explicitly mention the file exension.

Ok HG, I'll get to work. Thanks!

Thanks HG!

I still could not make work. I cannot add the wazirzebra here:

https://www.chessvariants.com/invention/grand-apothecary-chess-alert

from here:

bzebrawazir.gif (49×49) (chessvariants.com)

OK, my bad. I was wrong about adding the file exension; this was already done at an earlier stage, before replacing the % by a color prefix. This means you should NOT specify an extension in the 'custom image', and that it then will always use the same extension as the regular images. That means you cannot use the cobra from the se in the Elven-Chess directory with alfaerie (because it is png, and alfaerie is gif). But you should not have problems using an alfaerie image from another directory. When you do not put the .gif in the custom name.

BTW, if it doesn't work, you can open the piece legend of the diagram, and right-click the 'missing image' symbol in it, and select 'View Image' from the context menu. This will give a 404 error, but in the adress bar of your browser you should then be able to see what the filename was that it finally made from the parameters you supplied. Which often tells you what went wrong.

Ok, for some reason when trying this: graphics.dir/alfaeriemisc/compounds/%zebrawazir it results in this: https://www.chessvariants.com/rules/graphics.dir/alfaeriemisc/compounds/bzebrawazir.gif

put a forward slash at the beginning of your url

Yes Greg. Now it works!

HG, May you add on this article some info about how to save games, especially with shuffle variants? I know this can be found in comments section, but that is not always easy to find!

HG, May you add on this article some info about how to save games, especially with shuffle variants? I know this can be found in comments section, but that is not always easy to find!

There doesn't seem to be very much to say about that. It displays the game, and you can copy that elsewhere, or back.

It is true that the diagram has many functions now, which are not always obvious. So I expanded the introduction of the article with a short description of what the diagram can do. (The article was almost exclusively about how to create such diagrams yourself, rather than how to use existing diagrams.)

Hello again HG. In the game I'm currently working, the king has the following Betza notation: KisO3isO4isjO2isjO3 I have only seen O-O and O-O-O for notation but there are 8 types of castling. For all of them the notation must be unambiguous. otherwise the game cannot be loaded. Thanks!...

Standard notations for castling cannot deal with such ambiguity. An alternative notation that is used in UCI protocol is KxR (e.g. e1h1 or Kxh1 for O-O in orthodox Chess). But this would be problematic in the context of  a very general system, where capture of a friendly piece might be allowed. Furthermore, the KxR notation is sometimes also used for resolving ambiguity between castling and normal King moves, in games with flexible castling, to indicate the castling where the King makes a single step (i.e. O1 castling).

Your variant poses the problem that both the King destination and the castling partner have multiple options. This requires specification of two squares. A possibility would be to let the empty square where the King should move to capture the Rook. (Or have the castling partner capture itself, when the King would end there.) Perhaps Greg has ideas of how to best solve this.

BTW, I seriously wonder how the castling choice that you propose can be any good: castling was invented for bringing the King to safety without trapping the Rook. If you can castle with an 'inner' piece through the jO castlings, you would trap the outer piece. Unless that piece can develop by jumping over the Pawn shield (as it can in Omega Chess). But then castling with it serves no purpose. You would have to get rid of the inner piece first before the second becomes available for castling. And if that inner piece is a Rook, you would have to compromise the Pawn shield for that, in such a way that you would not want to castle in that direction anymore. While when both the corner piece and the inner piece were capable of jumping over the Pawns, involving them in a castling serves no purpose. In that case the only beneficial effect is to speed up the travel of the King towards a corner. But you could have achieved that by just giving the King an isR move.

In my game on the edge files there there are berolina pawns. In the corner there is a chinesse cannon and on the 2 adjacted ortoghonal fields, rooks. The shorter castle is with rook, the longer one is with cannon.Here is an example:

<div style="float:left;margin:0 40px 20px 0;">
  <div class="idiagram">
    files=12
    ranks=14
    symmetry=none
    holdingsType=1
    promoZone=4
    promoChoice=!P!X*N*B*C*W*Z*R3*Y3*F3*J3*G2*Q2*D2*L2*T2
    graphicsDir=../graphics.dir/alfaerie/
    whitePrefix=w
    blackPrefix=b
    graphicsType=gif
    squareSize=54
    hole::::a1-l1,,a14-l14
    pawn:P:mfW*fceF:pawn:b4-k4,f5,g5,,b11-k11,f10,g10
    berolina:X:mfF*fceW:berolinapawn:a4,l4,d5,i5,,a11,l11,d10,i10
    king:K:KisO3isO4isjO2isjO3:king:g2,,g13
    rook::::a3,l3,b2,k2,,a12,l12,b13,k13:1
    queen::::f2,,f13:1
    bishop:B:B:bishop:c3,j3,,c12,j12:2
    knight:N:NmHmA:knight:b3,k3,,b12,k12:1
    wizard:W:FL:mage:d2,i2,,d13,i13
    champion:C:WAD:champion:e3,h3,,e12,h12:1
    cannon:Z:mRcpR:cannon:a2,l2,,a13,l13
    knightrider:Y:NN:nightrider:c2,j2,,c13,j13:1
    sangoma:S:BZ:/graphics.dir/alfaerie/%zebrabishop:f1,g1,,f14,g14
    vulture:F:afafafsKafsafafKafafraflKafaflafrKafraflafKaflafrafKmD:bird:d3,i3,,d12,i12
    joker:J:fI:fool:e1,h1,,e14,h14
    Dragon:D:FyafsF:dragon:f3,,f12
    Griffin:G:WyafsW:gryphon:g3,,g12
    Lyon:L:DB2afyasfF:lion:h2,,h13
    Tiger:T:AR3afafyasfW:tiger:e2,,e13
    symmetry=mirror
    shuffle=:B:N:C:F,QLT,DG,:W:Y
    maxPromote=2
    royal=3
  </div>
</div>

By the way, Indeed castling is not that useful. Because of the 2 layer of pawns the king is quite safe in the middle. There would be situations where is useful, even if rare. Nevertheless it is an option for the player.

Your variant poses the problem that both the King destination and the castling partner have multiple options. This requires specification of two squares. A possibility would be to let the empty square where the King should move to capture the Rook. (Or have the castling partner capture itself, when the King would end there.) Perhaps Greg has ideas of how to best solve this.

I don't really consider this a "castling" problem.  What we have here is a rule where multiple combinations of pieces can move to multiple combinations of squares.  There could be use in addressing this for any game might want to do this, but if we want to support this, I think it should be done in a general way, not forced into the context of castling.  (So, I am not at all in favor of empty-space-captures-rook.)  I think the robust way to address is as two separate moves, like "a1a2,b1b2".  Doesn't the interactive diagram have a similar issue with the Forest Ox from Odin's Rune?  It also must record a third square.

Also, if we're going to do an a1a2,b1b2 kind of thing, it makes sense to me to consider a separate delimiter for multi-move games such as Mersaillias.  I think our life would be easier if "single moves" that consist of different parts are delimited differently than the separate moves of multi-move variants.  For example, if a double move variant has, as it's first move, one of these moves that requires two different annotations, perhaps something like "a1a2,b1b2;c1c2"

In any event, this is a large can of worms, and I don't think we rush a poor solution just because this expiremental game has a crazy castling rule.

In Odin's Rune Chess (or Chu Shogi) the hit-and-run captures use notations like Fxh5-g4, while double captures are written as Fxh5xg5. (The interactive diagram, unlike the automatically generated presets for Game Courier, doesn't make a distinction between 'shooters' and double movers, so the extra victim of the Forest Ox should be entered and is written as an intermediate square.) But this only accounts for double-moves with the same piece, and castling doesn't fall in this class.

I guess the most natural notation for castlings for which O-O and O-O-O would be ambiguous is indeed as a double move. But now that I think about it, the fact that there is both jO castling (with the Rook) and O castling (with the Cannon) doesn't really cause any ambiguity: you can only castle with the nearest piece. The only problem here is the usual one for free castling, that you need to specify the King destination. It is sort of standard to make a sideway King move of more than one step imply castling in that case. In any case, O-O noation is no good for free castling. So I suppose I should make the diagram recognize the case where a piece has multiple O moves in the same direction and the same partner with different range. And in that case use the King's move for notation rather than O-O.

There still is the issue for how to distinguish O1 castling from an ordinary King move, and how to handle the case where the King ends on the Rook square. The KxR notation seems natural for the latter case, as it would indeed specify the square where the King ends. (There still is no need to specify the Rook move separately; it is fully implied.) But then KxR would not be available for O1. RxK doesn't seem such a bad way for indicating O1 castling, as you would specify a Rook move with a square where the Rook indeed ends up.

How about using a special separator for castling? We now have x for captures, and - (or nothing) for non-captures. We could adopt ~ for castling. So in the orthoChess setup Kd1 or K-d1 would be a normal King move to (empty) d1, but K~d1 would be Q-side O1 castling. K~h1 would be K-side O3 castling.

How about using a special separator for castling? We now have x for captures, and - (or nothing) for non-captures. We could adopt ~ for castling. So in the orthoChess setup Kd1 or K-d1 would be a normal King move to (empty) d1, but K~d1 would be Q-side O1 castling. K~h1 would be K-side O3 castling.

This makes a lot of sense to me.

OK, I implemented this new notation in the diagram script. (As yet untested.) The main difficulty was detecting when to use it; I don't want it to supercede the O-O notation in games with normal castling. And it must not be confused by asymmetric castlings as in Janus Chess, which do have two O atoms in the move descripion, but as rO and lO, so that they are still unambiguous. It also must not trigger it just because there is an sO and an sjO. So I wrote code to count the number of O moves for each of the sideway directions and each number of j modifiers separately. And if any of those on any piece exceeds 1, the game is flagged as having 'free castling', and will use the K~... notation for indicating any castlings. (Even those that might not be ambiguous.)

On input it will only treat the ~ as special in gemes that are flagged to have free castling; and input move that contains it will then only be matched against the castlings generated by the move definition in the current position, and will only match when the to-square of the King matches the square specified in the move.

P.S. I see no reason why the same noation couldn't be used also for Kevin's 'fast castling'. The castling rules (in particular for to how the Rook must move on castling) can be assumed to be known, so there isn't any reason to make those explicit in the move notation. They should be specified in the move definition. I don't think it would be useful to allow mixing of normal and fast castling, so if a move like K~b1 is encountered, it would unambiguously follow where the Rook (or other castling partner) ends up. Fast castling should be indicated in Betza notation by a different atom than normal castling. I am in doubt between V and OX. Perhaps it is better to reserve OX for Fischer castling. Which the diagram currently doesn't implement. An OX castling would then be specified just as an O castling, and define the result when it is performed from the nominal position. The extra X suffix would then indicate castling would also be possible in positions that shuffled K and R, but with the same result as from the nominal position.

Thanks HG for putting the effort into notating the castling in my game

Well, let me know if it causes any problems. It was not just for your variant; the existing notation system would have failed in any variant that had 'free castling', as it would have writen any castling as O-O or O-O-O into the game record, which then would be ambiguous. And in the process of fixing this I discovered that it was very sloppy in identifying castlings: it would also write O-O for a Valkyrie swapping move in Odin's Rune Chess! So it was really very helpful for bugfixing that you pointed out this ambiguity.

I'm glad I could help!