Acording to the rules of the game, first white has to place it's two gating pieces behind. Then black his two. I got stuck while trying to do both move in the same turn. I have tried using continuemove, but I get into infinite loops no matter what I had done.

The only thing I am still in doubt about is whether the current betza.txt include file on which the PTA-generated code relies tests for a move being the final one in a safe and reliable way. Because it uses mln for the test rather than turn.

I have just added thismovenum and maxmovenum. These will return $mline[$mln]->movenum and $mline[$maxmln]->movenum. It's likely that maxmovenum will be returning the same value as movenum, which returns $movenum, but using it will add clarity to your code.

No matter I have made some progress!

It is definitely not that easy.

One thing is that when I try to make the move to a1 (for example), which would be an eligible brouhaha square I get an error saying that said move it is not even a pseudo legal move. By the way for now I have disabled the brouhaha squares and left the whole board intact (meaning no ----). But I could not comment the set brouhaha instruction in the pregame code.

Another thing is that the regular moves of all pieces are still displayed despite the fact that they are not legal anymore (i have setsystem the legalmoves array to () or even to null).

If I understood Fergus correctly all that is needed to do it is compare the value of turn instead of mln. Like

if == 1 turn:
... // code for first prelude step
elseif == turn 2:
... // code for second prelude step
else:
  gosub HandleMove true;
  ... // code for performing the gating if needed
endif;

The only thing I am still in doubt about is whether the current betza.txt include file on which the PTA-generated code relies tests for a move being the final one in a safe and reliable way. Because it uses mln for the test rather than turn. But that would affect every preset automated through the PTA, and I have never encountered a case where it did not work.

@Fergus & @ H.G.

So basically it can't be done yet!

if == 0 $mline[$mln]->movenum:

That is mixing GAME Code with PHP. GAME Code does not support classes with properties or write out array elements with brackets, and it doesn't provide read access to $mline. But you can use the value of turn with your knowledge of which side you're concerned with to determine where you are in a game.

OK, so the betza.txt code, which thus aims to test for whether the move is the one that was just entered, would work fine even in the presence of comments?

And the code to test for whether we are in prelude should look like

if == 0 $mline[$mln]->movenum:

?

set all == mln $maxmln;          // indicates last move

Note there is no $ there, so we might be talking about different things, and this one might be a legacy variable.

This operator just outputs the value of $mln.

I cannot image how this would work if mln was not the current move number.

It works because you are comparing mln with its maximum value. When there are comments, $maxmln will be greater than any move number, but it will be no higher than mln will eventually reach.

It does not. I have made that mistake too and had to correct it. To use $mln to get the move number, you need to get $mline[$mln]->movenum.

This is somewhat important, because the first things that the HandleMove routine does in the betza.txt include after the move is parsed is:

  set all == mln $maxmln;          // indicates last move

Note there is no $ there, so we might be talking about different things, and this one might be a legacy variable. The purpose here is to determine whether the subsequent move generation needs to generate all pseudo-legal moves, and compare the input move against those for testing its legality. Or whether it can simply assume the move is legal, because it is not the final move of the stored game, and thus must already have passed the legality test on the turn where it was entered. If the latter is the case only the moves with implied side effects are generated, (e.g. e.p. capture or castling), for the purpose of reconstructing the side effect, and apply it to the board together with the entered move.

I cannot image how this would work if mln was not the current move number.

I think the variable 'mln' gives you the current move number in the Post-Move sections.

It does not. I have made that mistake too and had to correct it. To use $mln to get the move number, you need to get $mline[$mln]->movenum. $mline is an array with a separate entry for each line of the movelist, but besides containing actual moves, it contains comments. $mln is the index that a line has in this array, but when some lines are comments, it will go out of sync with the move number.

GAME Code has turn, which will return $mline[$mln]->turn, but it doesn't currently have anything returning $mline[$mln]->movenum.

Thanks, I look into it soon!

But some hints to where I put my code and what that code should be are very welcomed.

I think the variable 'mln' gives you the current move number in the Post-Move sections. What you want is special treatment for the first few ('prelude') moves, and then the normal procedure possibly followed by gating when this would be required. So something like:

if == mln 0:
  ... // do what has to be done for the first prelude turn
elsif == mln 2:
  ... // do what has to be done for the third prelude turn
else:
  gosub HandleMove true;
  set waiting where #ori 0 -1; // square behind moved piece
  if not flag #ori and == 1 rank #ori != @ space #waiting: // virgin first-rank piece with something behind it
    add space #waiting #ori; // gate the piece
    empty #waiting;
  endif;
endif;

You stil would have to suppress normal moves for the pieces waiting to be gated. I suppose the easiest way to do this define an alternative version of those that looks the same but does not have any moves, and put those on 0th rank. When its turn comes to be gated you then put the version with moves on the board.

@HG Muller & @Fergus Duniho

I have looked through the musketeer chess preset and recapped a bit of the programmer's guide. I have also tried a few things. But still I have no true clue on how to do the gating. Any help with clues is welcomed. Don't bother too much though. I know you guys are busy. But some hints to where I put my code and what that code should be are very welcomed.

Very little succes s far though. This is what I have so far:

https://www.chessvariants.com/play/pbm/play.php?game%3DFrog+Chess+with+Gryphon+and+Falcon%26settings%3Ddefault

Indeed!

I have just read that thismove does not work in premove

All the more reason to not do anything there.

I have just read that thismove does not work in premove

I am not sure it would ever make sense to add code in the Pre-Move section, when you automate through the PTA. Because Game Courier is configured to "not add moves" in that case, you should be in the same state at the start of the Post-Move section as you are in Pre-Move.

Not it. I can write some echo there!

It seems I cannot add code to the premove section!

That thought has crossed my mind, too. Thanks!

I was afraid of that but it makes sense.

You could copy the relevant parts from musketeer chess

This would only be possible with significant additional GAME-code programming. For one, you would have to program enforcement of the 'prelude', as the HandleMove routines in the Post-Move sections only handle normal board moves. So the code should first test the move number, and do something else for the first few moves.

Apart from that you would also have to add code after the call to HandleMove, in order to automatically step the piece on board that is gated.

Is there a possibility of creating the preset with gating, especially when players gate their pieces in different places?

well it works now so I guess I was doing something wrong

Is the Paste Diagram description here: input broken?

Not that I know; for me it still works. What are you trying to paste?

Is the Paste Diagram description here: input broken?

HaruN Y, Thank you so much. you are great nice person. best wishes to you. . sincerely, Adella.

You can click the word "revised" in "Last revised by H. G. Muller" to see the previous version.

_____ @ H.G.Muller, Could you keep both the previous version, and the new

version ( if you like it), on Playtest Applet page? Could you

show two links: Functional efficiency previous version, and 2.0 version? That will be wonderful. Keeping previous version's fast efficiency and great functionality and beauty. Meanwhile, use new version to do some testing.
_____ Thamks again, respected h.g.muller. sincerely,

Adella.

================== @H.G.Muller,

Respected H.G.Muller, Your Playtet Applet new version is

not working well, or if I could modestly say, it destroys a lot of

stuff, which took me so much time to compose and attention on

it.

       Could you do me a favor, by reverting to the previous    

PlayTest applet version, which is fast, efficient, and functioning

stable?

 Thanks so much.   Thanks for your contribution to  the  

playtest applet work. Could you write the link or applet page to me , that will be

greatly helpful.

Thank you. sincerely, Adella

The spells do not work yet in the PTA itself, because this is still using betza.js instead of betzaNew.js, and spells are only supported in the latter. Bot they do occur in the spell description that appears when pressing the Show HTML button, so this could be used with betzaNew.js. I will upgrade the PTA to using betzaNew.js shortly.

What is worse is that the interface doesn't allow you to specify spellZone and blastZone yet.

I like that bug.

I have now upgraded the content of this article to the new version, which also allows you to define morph and captureMatrix by filling the corresponding cells with pieces from the table. Other differences with the previous version is that under "Specify more rules" you can also define what are the royal types, and select a spell.

Note, however, that the generated GAME code does not support capture matrices or spells yet, and morphing only to other piece types. (No confinement or win squares.)

Interesting. This is probably a bug; it should not be able to 'pick up' empty squares, but the highlighting might create the impression that the square is not empty.

BTW, I did some more work on the Play-Test Applet 2.0. It is now possible to also place win squares on the morph board (through the red and orange buttons). And I tried to make it clearer through background coloring what elements on the page belong together.

Move a piece then click the square which the piece is moved from then click the piece you want to remove.

You can move pieces from the table to occupied squares, to replace what was there. If there are too many pieces in total, you could capture the surplus. But only through legal moves on the board.

Is it possible in the PTA to remove pieces from the board that have been moved from the table to the board?

And another question: Is it possible to start the PTA with an empty board (without kings)?
Thanks.

It appears that trajectories that go temporarily off board (the XBetza o mode) are not yet implemented in the GAME code. And the Advancer is defined through such a trajectory, as a multi-leg move that first overshoots its destination by one step, and then takes that step back. This as part of the test that there is no enemy there that should be removed; empty squares, friendly pieces and the step going off board would all be OK; they are not enemy pieces. But the GAME code does not implement the off-board case, so the furthest destination of an Advancer move that hits the edge would not be considered valid, as there is no room for the extra back-and-forth.

In the context of the Interactive Diagram this was easy, as squares are specified by coordinates, which automatically describe an infinite plane. In the context of GAME code this is a bit harder, as squares are specified by arbitrary labels, and there are no labels for 'virtual locations' beyond the board. So there is no instruction for stepping back onto the board, because there is no way to specify from where you should step back.

This means I can not literally translate the JavaScript code of the ID that handles this to GAME code, in order to fix the problem. A work-around would be to have the GAME code process the step-off, step-on legs at the end of the Advancer move as a pair instead of one by one: if it sees that the first of these allows o mode, and would stray off board, it should not try to make the step, but look ahead one leg, combine the two steps (which then should lead to an on-board square), and take that to continue.

This is not a trivial fix, so I will think more about it when I return from shopping.

[Edit] OK, I made a temporary fix, which allows you to fully use the Advancer: I made the betza.txt include file assume that any attempt to step off board by a move with o-mode would be the first leg of a back-and-forth step at the end of the move, and approve the move to the start square of that leg. This obviously would not work for cases where the move travels further, such as a reflecting Bishop.

@ H.G.:

Joe Joyce, my opponent, reported he made a move, but first tried to make a legal advancer move (to e10) that was refused by the preset:

https://www.chessvariants.com/play/pbm/play.php?game=Butterfly+Chess&log=panther-joejoyce-2024-10-868

When you talk about changing the notation I suppose you mean that in the article.

Yes, in the article proper, so it shows up in a search. :)

On a separate note, I've discovered (somewhat to my surprise) how to create the Zigzag Nightriders, as seen in Nachtmahr.

There was already an Interactive Diagram in the Comments to that article; I think the notations I used there were somewhat more compact, because they exploit the default assignment of oblique moves as l or r. In fact the 'repeat parentheses' in XBetza where implemented just to make that Diagram.

When you talk about changing the notation I suppose you mean that in the article.

Yeah. But it isn't very urgent...

Agreed. :)

On a separate note, I've discovered (somewhat to my surprise) how to create the Zigzag Nightriders, as seen in Nachtmahr.

• Diagonal Wide Crooked Nightrider ((1,1)-Zigzag Nightrider): Nabl(abz)N
• Straight Wide Crooked Nightrider ((2,0)-Zigzag Nightrider): Nabr(abz)N
• Diagonal Narrow Crooked Nightrider ((3,3)-Zigzag Nightrider): Nafr(afz)N
• Straight Narrow Crooked Nightrider ((4,0)-Zigzag Nightrider): Nafl(afz)N

I just thought it'd be good to post them somewhere. :)

Maybe Jörg or an editor can go into that article to change the notation.

Yeah. But it isn't very urgent, as in the PTA the definition aid only serves to fill the Betza text entry, and you can type anything that the aid cannot make directly there.

[Edit] While at it, I also expanded the capabilities of the Move-Definition Aid to understand leaps to the 4th ring. (As I already did yesterday in the Checkmating Applets.) Originally the 4th ring was only there for seeing when you had defined a rider, or for cutting the range of a slider. Perhaps I should increase the size of the panel, so that you could also see or enter 5th-ring moves.

Given my love of Fifth-ring pieces, I'd consider this a boon. ;)

Umm, I see now what the problem is when you try to paste a Diagram specification directly from the Page Source into the PTA. It contains a lot of HTML tags that do not produce any visible output, which I could make show up by first replacing the < character by the escape sequence for it. I then got this as the pasted definition against which the PTA complained:

<span>satellite=conquer
<span id="line401"></span>files=9
<span id="line402"></span>ranks=8
<span id="line403"></span>maxPromote=0
<span id="line404"></span>promoZone=1
<span id="line405"></span>promoChoice=NBRQ
<span id="line406"></span>graphicsDir=/graphics.dir/alfaeriePNG/
<span id="line407"></span>squareSize=50
<span id="line408"></span>graphicsType=png
<span id="line409"></span>symmetry=none
<span id="line410"></span>baring=0
<span id="line411"></span>pawn (nasty neighbours):P:fWfcnD:pawn:a2,c2,e2,g2,i2,b7,d7,f7,h7,,b2,d2,f2,h2,a7,c7,e7,g7,i7
<span id="line412"></span>double knight:N:N2:knight:b8,h8,,b1,h1
<span id="line413"></span>double step bishop:B:nA7:bishop:c1,g1,,c8,g8
<span id="line414"></span>double step rook:R:nD7:rook:a1,i1,,a8,i8
<span id="line415"></span>double step queen:Q:nD7nA7:queen:d8,f8,,d1,f1
<span id="line416"></span>king:K:KisO3:king:e1,,e8
<span id="line417"></span></span><span></span>

I suppose the best counter measure would be to scan every line for the occurence of the substring 'span>', and then retain only everything that is beyond the last occurrence of that. I do that now, and it appears to solve the problem: I can directly copy-paste Diagram definitions from a Page Source. I also improved the error reporting: when the Diagram script gets a specification it does not understand, it will now first replace all < caharacters by their HTML escape sequence, so that the browser will no longer recognize any HTML tags in it, and display these as encountered in the error message.

[Edit] While at it, I also expanded the capabilities of the Move-Definition Aid to understand leaps to the 4th ring. (As I already did yesterday in the Checkmating Applets.) Originally the 4th ring was only there for seeing when you had defined a rider, or for cutting the range of a slider. Perhaps I should increase the size of the panel, so that you could also see or enter 5th-ring moves.

It actually was specifically because of this lack of clarity that I created my own, distinctive High Priestess icon for Alfaerie:

I have a very similar icon (which I only just now realized is upside-down) in my SVG set.

I still don't like it. The problem of poor visibility of the thin lines has been addressed here by changing the fill color, but this is out of style with the rest of the Alfaerie set.

If such different coloring were to be used, I would want to reserve it for indicating divergency (as I believe the pieces in Desert Pub do).

@ H.G.:

The Alfaerie:Many piece set is at least one set that has the High Priestess with a Ferz symbol on it, so there is room on such an image (in this set it's labelled with _CBJ_HPF):

Well, the SVG pieces are a 'work in progress', and if there is demand for Alfaerie pieces that have not yet been converted to SVG, we usually add those. In particular, putting a cross on an existing SVG piece is almost no work at all.

And once the piece exists as SVG we render it as 50x50 and 35x35 PNG to expand the repertoire there too. And whatever appears in those directories, will automatically appear in the auto sets; that is why they are called auto sets.

[Edit] The existing High Priestess image seems wrongly labeled, because (as you say), there is no Ferz cross on it. By Alfaerie logic it should thuse be a representation of the NA, and the High Priestess (which is FAN) should get a symbol with diagonal cross. But there seems to be no room for the cross. (Which is of course the reason it isn't there in the first place.)

In fact, I don't like this kind of symbol at all, with a demagnified version of one piece inside another. (And in this particular case, to a needlessly small size; the Knight could have been at least 50% larger.) Especially when there was no effort to preserve linewidth, and it was demagnified together with the overall size, so that visibility really suffers if the entire symbol gets rendered at a small size like 35x35. If it was up to me we would get rid of such symbols.

Now the fen2.php renderer used by the Diagram Editor with Scalable Graphics allows you to create on-the-fly compounds of two existing SVG images. So I did not even have to make new SVG pieces to create these:

I added those to the alfaeriePNG and alfaeriePNG35 directories under the name b/welephantknight.png . I checked that they also appeared in the corresponding automatic sets, with the name ELEPHANTKNIGHT / elephantknight. I picked these rather than those with the Knight in front, because the Elephant is wider, so that it covers the place where the bottom of the Knight image was cut off; with the Knight in front the bottom of the Elephant would stick out in an ugly way.

I like this way of combining pieces better, and it is more in line with what we do for BN and RN. I think the High Priestes symbol should really be replaced by this with an extra cross; the ear of the Elephant provides ample room for that.

I went with the Alfaerie: All SVG piece set, and after redoing the Applet diagram and Game Code, the preset now seems to work, based on just some testing in Move Mode:

https://www.chessvariants.com/play/pbm/play.php?game=Hybrid+Chess&settings=enforced

@Kevin: I don't know if it may help you. With Bigorra I have more than 26 different pieces, so I have to use some blocks of 2 letters. I could made an ID and from the ID with the PTA tool, it was rather direct to make a GC.

The Auto Alfaerie PNG set has almost everything I want, in a way. It has the knightferz (one word label), the badger (new word for Bede that I might need to explain), but no knightalfil (although the highpriestess is available and it does show no ferz symbol, but that is kind of understood by its history on GC/CVP - I could explain it as just my substitution, though).

I will continue to look. Also, I don't know if there is a limit to the number of alphabetical characters an ID in the Applet table can have (I hope it's quite long, if need be).

edit: The Alfaerie: All SVG set has NF and Bede but no NA (but has high priestess) and the piece labels are quite short, all alphabet characters. I'm happier, but I will look for something even better still. Note that this set oddly(?!) labels the high priestess figurine with AN, which one might think it is at first sight (other set[s] I've seen show the ferz portion on the elephant's portion of the figurine).

I'll see if I can find a Diagram Designer piece set that just uses letters for the labels of the various piece types that I need (if the set has them all), though somehow I am not too hopeful.

It indeed behaves very strange. King and Queen are allowed to capture their own Bede.

I think it is not able to recognize to whom the pieces belong when you use non-alphabetic characters in their labels. Piece IDs are supposed to be letters. When you ask for trouble, you usually get it...

@ H.G.:

Thanks for the help.

However, when I made an Applet generated preset for Hybrid Chess, I tested it in Move Mode and was not allowed to move a knight-alfil compound piece at i1 on move one at all, without getting an error message if I tried. When I made the diagram with the Applet, I used the Tiger figurine in the table for that piece type, giving it the new ID .NE and the Betza NA, before placing all four of those on the diagram board and later pressing Start Position, before pressing on the Game Code Button.

I used Set Group Unique and piece set Alfaerie: Many, and the right piece type figurines all showed up in the preset before and after editing, after I used the Game Code's FEN (without using Custom specifications, as you prviously advised it was possible to do). Don't know if using Alfaerie Many caused the fatal error, but I would have guessed that this time it did not (in a previous test I moved a White pawn on move one successfully in Move Mode):

https://www.chessvariants.com/play/pbm/play.php?game=Hybrid+Chess&settings=enforced

Flexible castling is nothing else but multiple castling moves with different ranges on the King. E.g. KisO2isO3isO4. It is not a special way of castling, such  as fast castling or free castling would be. So it has always been supported, ever since a notation for castling was added to Betza notation.

@ H.G.:

Are there any plans you have to soon allow for Flexible Castling (like used in Fergus' 12x12 Gross Chess), with the use of the Applet and it's generated Game Code? I looked for a way to do it with the Applet, but there seemed to be no way available, currently at least.

At the moment I have two CV invention ideas (each having a settings file) that use flexible castling:

https://www.chessvariants.com/play/pbm/play.php?game=Hybrid+Chess&settings=default

https://www.chessvariants.com/play/pbm/play.php?game=Hybrid+Decimal+Chess&settings=default

I edited my previous post, in case anyone missed it.

Ok, thanks H.G.; I've now made an Applet generated rules enforcing preset for each of my SOHO Chess and Wide SOHO Chess inventions, while following your latest advice, about using the Play-Test Applet table.

Note to Fergus:

Strangely, someone had my checkering pattern for board of non-rules-enforcing Wide SOHO Chess preset reversed, so that queens stood on their own colour (as in chess' setup) in the setup. Don't know if I did it accidently, an editor did it, or someone guessed my password, but today I put the checkering pattern to be usual, so that lower right hand square was a light square (as on my rules page), before also having Applet generated preset's board to be that way, too.

You should not use pieces with the same ID when making GAME code; Game Courier does not accept that. Change the ID of one of the pieces in the PTA before pressing the GAME-code button. Just type an ID not in use by any of the other pieces in the text entry under the table, and then click the move of the piece.

@ H.G. (or Fergus):

When I tried to make a Play-Test Applet generated diagram for my SOHO Chess CV settings file, the game code produces the same symbolic character representation for White or Black Champions and Cannons (i.e. a 'C') when I look at the Applet's offered Custom set representation (meant for the Custom code box at the start of a preset's code boxes, when in Edit Mode).

Just to be sure it wouldn't work for me, I tried using the Custom specifications offered by the Applet in my preset's Custom code box (without saving it as the latest version), used Custom Group and Complete Custom Set in the preset itself, and got images of Champion figurines in place of the Cannons in the Edit Mode diagram, besides still having Champion figurines for the Champions in that diagram).

Thought I'd let you know, even though I can later try to make such an Applet generated preset without using a Custom Set, as H.G. described for me how to possibly do it, earlier. Here is unaltered non-rules enforcing SOHO Chess settings file, if that will shed any further light:

https://www.chessvariants.com/play/pbm/play.php?game=SOHO+Chess&settings=default

Yes, I am aware of this problem, and I will soon fix it. This is purely a problem of the PTA; theDiagram or preset you generate with it through the buttons won't have this problem. The Omega and Wildebeest Pawns use W* as XBetza notation for their multi-push. Originally such a move would always generate e.p. rights, but at some point that apparently proved inconvenient when I wanted to use it for other  pieces than Pawns, and I changed the Diagram script such that it only would generate these rights for the first piece in the table. But when you play in the PTA directly, the table is not 'cleansed' when you press Start Position, (to allow further addition of pieces not in the start position), so the Omega Pawn is not the first piece in the table.

The rule that only the first piece in the table generates e.p. rights when doing a W* move should be relaxed to the first N pieces, where N would be 1 by default, but large enough on the PTA page itself to include all Pawn types.

@ H.G.:

When I set the Applet diagram to 8 files and 10 ranks and then added a row of Omega Pawns to each side on the rank in front of their K, and pressed Start Position (but without using the AI engine), the pawns could take initial triple steps (as indicated by the diagram prior to moving) when I played a few moves against myself. However, there was no indication by the diagram that a legal en passant capture was possible, even if an enemy pawn was now on the same rank (and on a file right beside) a triple-stepping pawn.

FX5 (or whatever number you need) works

Yes, that'll do for now.

Edit: for some reason, though it didn't work last night, FX0 does the trick as well.

I thought I'd seen FXFX work previously (for a Girafferider), but it isn't now.

FX5 (or whatever number you need) works

Hm. There doesn't seem to be a way to make a Girafferider in this. (Or Anteloperider, Ibisrider, Bharalrider, etc.)

I thought I'd seen FXFX work previously (for a Girafferider), but it isn't now.

Argh! There's my problem! I meant to be using fen2. I copied from the wrong source.

I'll go get that fixed....

Many thanks.

I see that you are using showpiece.php. Are you sure this supports compounds?

OK, so clearly I need to fix that SVG (which I'll get to right away, for my next upload).

What's going on with the compounds? Edit: Do I have the same problem with the left and right arrows?

Well, your 'Purple Finch' shows up as a homogeneously colored square on the board. I gues this is because the image is so large that you only see a very small part of the middel. The natural SVG size is 749x749, if I 'inspect' the image in the piece table.

Hold on... what's wrong with this picture? Is it coming out normal to others?

It really should look more like:

Isn't the updated version about ready to be moved here? It does seem to work quite well -- better than this version, at times.

When I compare what I get for my variants with what I had coded before, it is unbelievable.

Well, that is basically cheating. Most of the program is in an 'include file', and the first line you paste into the Pre-Game section instructs Game Courier to prefix the entire program in that file to the GAME code. The one-liners in the Post-Move and Post-Game sections merely tell Game Courier which part of that included program to run, (and which player should be considered on move).

The secret is that you can always run the same program, no matter what pieces you have on the board. This is because of what the program does is controlled by tables, which for each piece type tell it how it can move (i.e. with which steps, and how many steps, and what must be in the destination square for the move to be valid). These are the tables you paste in the Pre-Game section; in the big table every line describes a range, and x- and y-step, and the move modalities (capture, move, hop, initial etc., all the XBetza stuff). The universal program just looks to the board for finding a the next piece, and then looks in the table what that piece can do, and then tries that all (e.g. for highlighting), or just checks whether one of those is equal to the input move (for rule enforcement)..

I have very limited knowledge in computer science, but what amazes me is how the set of instructions given by this Play-Test Applet are simple.

When I compare what I get for my variants with what I had coded before, it is unbelievable.

At this point I wonder why all these boxes Pre-Move 1 and 2, Post-Move 1 and 2, Post-Game 1 and 2, are necessary when the Play-Test gives 0 or 1 sentence to be copied here. And, it is always the same sentences that I get for all my variants!

I guess that these boxes are to described some particular cases that I have not met yet.

Thanks Fergus, I think I was given the wrong string by the Play-test applet.

There is currently an error in the Custom Set output. The line

"pieces: {"

should be

"pieces": {

OK, I swapped the order in which the sections are presented.

Very good. One thing I would recommend is putting it at the top to correspond with where it appears in the Edit form and to not break up the GAME Code sections.

I have now adapted the Applet to print the piece associations in JSON, rather than GAME code, under the header 'Custom Set'. I think I got it right.

I have not built in any provision for converting the Diagram's notation for extraneous pieces (a pathname with a % sign at the position where the color prefix should go). For one I am not sure how Diagram pathnames, which are for appending to the domain name in the URL, would have to be translated to work on the server (which I suppose calculates pathnames from the system root).

In the second place, since this is text that still must be copy-pasted into some text entry, it would be easy enough for people to provide pathnames of pieces not in the set by post-editing what the Applet suggests. The Applet would never generate extraneous pieces itself, an those who already put such a piece in a Diagram that they are converting to GAME code should know where to find the piece image. Or they would not have been able to put it in the Diagram.

I am afraid you lost me here. In your example I see you added a new field to the preset editing page, where one can deposit a JSON object as 'super-constant'.

I have decided to keep things simpler by just calling it Custom Sets. I will later move it up in the form by the Set elements. I don't think there is any use for a more general super constants, as regular constants are good enough for other uses they might be put to.

But why is the example defining four different sets? Is this to make it possible to switch between them using the Set Group/Set controls on the edit page? Normally you would not do that, right?

You might not, but I would. All your GAME Code generator has to produce is one set, but I wanted to make sure it was possible for people to add multiple sets if they wanted to. The ability to switch between multiple sets has been a normal part of Game Courier since the beginning. That's why sets are organized into groups. A group of sets are generally meant to be usable for the same games. While differences between what is available in each set mean that not all sets in a group are perfect matches for every game some of them are suitable for, groups are still made available so that players can choose between different sets for games that are supported by multiple sets in a group. Groups of sets have always been an integral part of Game Courier, and I wanted to make sure that support for custom sets would not break this important feature. I tested it with multiple sets to make sure this feature worked.

Presumably the Set Group would always have to be 'Custom' for this to be activated?

Yes, this allows custom sets to be supported without breaking the ability to use other sets.

How would the user know which set names correspond to the which setting of the Set control?

I have now put that information in a tooltip for each option. I also plan to write some documenation.

I suppose that custom-greenwade in the JSON correspond to the setting "Custom set of Bob Greenwade's pieces", but it is not evident at all how you would have to address the selected set in a blank preset.

If you know the set names, and I did provide them in an earlier comment, it's not difficult to match them up with the descriptions. For generating code, you would choose an appropriate set name based on the source of the images. If one wasn't available, you could use "custom" and make sure it includes a value for "dir" and any other values it needs.

All specified filenames will be assumed to refer to files in the directory specified by $dir? And $dir has a default in all sets other than "custom"?

That is the general convention, but it's not a strict law.

About allowing 'extraneus pieces': would it be possible to indicate somehow that a piece must not be sought in $dir, but that the name is a pathname? If this is not possible obvious work-arounds would be to specify $dir as "/" and specify each piece as a full pathname. Or specify the extraneus piece with a pathname relative to the specified $dir, such as "../../membergraphics/MSxxx/piecename.png".

Those are ways in which it is possible. Because the original Alfaerie pieces are in multiple directories, I have sometimes added "../" and an alternate directory name to some file names in some sets.

But both these method probably should be considered a security risk, so I can very well imagine that we do not want to allow image names with slashes in them.

I hadn't thought of that before. While this is not an issue for URLs provided in SRC in an IMG tag, it is for images that get accessed as files on the server before being displayed by a script. In tests I ran, showpiece.php and the PNG rendering methods could access images in places below the root of the site and in other websites I have on the same server. I plugged this hole by using the PHP realpath() function to give me the real path to an image, which I then compared with ROOT or CVP_ROOT to tell whether the file was on this website. Thanks to using an expression like !str_contains(realpath($imgfile), CVP_ROOT), Game Courier and showpiece.php should now work only with images located on this website, and they should not work with images at lower levels of the server or on my other websites.

Here is a test preset using images on one of my other websites, and you should be able to see that it is not displaying the pieces in any combination of shape and rendering method.

https://www.chessvariants.com/play/pbm/play.php?game%3DChess%26settings%3Dsecurity-test

So I suppose what I have to do now is let the Play-Test Applet display the piece assignment in this new JSON format (which is very similar to what it now displays in GAME code), where it now displays "Additional Pre-Game code (only needed with non-standard piece set):"? And change the text above that display to "JSON super constant (only needed with a 'Custom' Set Group):"?

Yes, expect as I mentioned above, it is now Custom Sets. And since JSON stands for JavaScript Object Notation, you may find a JavaScript function to help you produce JSON.

To define a set, you should define a first-level value for the set name and assign its value to an array. In this array, you should then define the individual values you want to customize. Since pieces is an array, the whole definition will consist of nested arrays. There is no need to define variables common to a particular set, such as $dir, because these get defined in the set file.

I am afraid you lost me here. In your example I see you added a new field to the preset editing page, where one can deposit a JSON object as 'super-constant'. This JSON object describes several associative arrays (?), which appear to define piece sets, by specifying a filename for each piece label. What you write here is not GAME code, and takes effect even while editing. So far so good.

But why is the example defining four different sets? Is this to make it possible to switch between them using the Set Group/Set controls on the edit page? Normally you would not do that, right? There would be only one set defined in that JSON object, and you should use the name for it corresponding to the set you selected by means of the Set Group & Set controls.

Presumably the Set Group would always have to be 'Custom' for this to be activated?

How would the user know which set names correspond to the which setting of the Set control? I suppose that custom-greenwade in the JSON correspond to the setting "Custom set of Bob Greenwade's pieces", but it is not evident at all how you would have to address the selected set in a blank preset.

All specified filenames will be assumed to refer to files in the directory specified by $dir? And $dir has a default in all sets other than "custom"?

About allowing 'extraneus pieces': would it be possible to indicate somehow that a piece must not be sought in $dir, but that the name is a pathname? If this is not possible obvious work-arounds would be to specify $dir as "/" and specify each piece as a full pathname. Or specify the extraneus piece with a pathname relative to the specified $dir, such as "../../membergraphics/MSxxx/piecename.png". But both these method probably should be considered a security risk, so I can very well imagine that we do not want to allow image names with slashes in them. (In the Interactive Diagram this is not a problem, as it runs locally and the path is used for accessing files on the server.)

It would be safe to allow names with slashes if these start with "/graphics.dir" or "/membergraphics", and contain no substring "/../"; that would limit them to sub-trees that are public anyway. And then suppress prefixing of $dir + "/" in those two cases.

So I suppose what I have to do now is let the Play-Test Applet display the piece assignment in this new JSON format (which is very similar to what it now displays in GAME code), where it now displays "Additional Pre-Game code (only needed with non-standard piece set):"? And change te text above that display to "JSON super constant (only needed with a 'Custom' Set Group):"?

... but as far as I can tell, this page doesn't provide any option expect to use images from /graphics.dir/alfaeriePNG35/.

Indeed, this page focuses on game rules, not on presentations. (The Diagram Editor with Scalable Graphics served that purpose.) And I did not needlessly want to complicate the interface with non-essentials, as this might scare off people.

But one can paste an existing Diagram made by other means into it. And in that case it would inherit all settings of that Diagram, even those that it could not create through the user interface on the page.

Since the output of the page is text to be copy-pasted elsewhere it is always possible to post-edit it. It would even be possible to use a design cycle that consists of first requesting the Diagram HTML from the Applet, edit that in the window where it appears, e.g. to alter graphicsDir, and then paste it back and ask for GAME code.

It looks nice! (I do have a dedicated Hawk icon, but that's a quibble. Overall, a job well done.)

I have now tested the custom set with this preset:

https://www.chessvariants.com/play/pbm/play.php?game%3DExperiment%26settings%3Dfpd-experiment1

I have not tested it with svg pieces, but if it detects an svg set by testing the value of $dir or the filename of one of the pieces, it will set $svg to true. So, there is no need to set it explicitly.

I have now created, though have not yet tested, a custom set that is fully customizable. Unlike the more specific custom sets for different collections of pieces, it will let you set any value listed in this array:

$customvars = array("dir", "pieces", "width", "height", "originalblack", "originalwhite", "defaultwhite", "defaultblack", "flip", "flipped");

It can be used when none of the others can be.

Note that the Greenwade set has no Wildebeest piece, and I didn't bother to add a substitute. So, it shows up as a question mark.

Yeah, I figured "gnu" would be easier, with fewer letters -- even though I "gnu" it would cause other problems. (Sorry.)

A minor flaw is that the Diagram now allows the use of 'extraneous' pieces, i.e. with images from another directory than graphicsDir, and possibly of another image type, which are specified as an arbitrary filename / URL.

I know that's true of Interactive Diagrams in general, but as far as I can tell, this page doesn't provide any option expect to use images from /graphics.dir/alfaeriePNG35/.

I have now implemented a system for creating and using multiple custom sets. First of all, the set files have specific names, as each one uses its own set file. So far, these are custom-abstract, custom-alfaerie-png, custom-alfaerie-png35, custom-alfaerie-svg, custom-greenwade, custom-magnetic, and custom-motif.

Unlike other set files, these use a super constant to define the value of $pieces. $flip is initially set to false but may be set to true, and a value may also be provided for $flipped.

Super constants are defined in a new field as a single JSON object. The custom set files convert this to an array and use appropriate values.

To define a set, you should define a first-level value for the set name and assign its value to an array. In this array, you should then define the individual values you want to customize. Since pieces is an array, the whole definition will consist of nested arrays. There is no need to define variables common to a particular set, such as $dir, because these get defined in the set file. Here is an example I created and got working:

https://www.chessvariants.com/play/pbm/play.php?game=Experiment&settings=fpd-experiment1

{
   "custom-alfaerie-png": {
     "pieces": {
        "P": "wpawn.png", "p": "bpawn.png",
        "K": "wking.png", "k": "bking.png",
        "G": "wwildebeest.png", "g": "bwildebeest.png",
        "H": "wbird.png", "h": "bbird.png",
        "S": "wsquirrel.png", "s": "bsquirrel.png",
        "C": "wchampion.png", "c": "bchampion.png"
       }
     },
   "custom-alfaerie-png35": {
     "pieces": {
        "P": "wpawn.png", "p": "bpawn.png",
        "K": "wking.png", "k": "bking.png",
        "G": "wwildebeest.png", "g": "bwildebeest.png",
        "H": "wbird.png", "h": "bbird.png",
        "S": "wsquirrel.png", "s": "bsquirrel.png",
        "C": "wchampion.png", "c": "bchampion.png"
       }
     },
   "custom-alfaerie-svg": {
     "pieces": {
        "P": "wpawn.svg", "p": "wpawn.svg",
        "K": "wking.svg", "k": "wking.svg",
        "G": "wwildebeest.svg", "g": "wwildebeest.svg",
        "H": "wbird.svg", "h": "wbird.svg",
        "S": "wsquirrel.svg", "s": "wsquirrel.svg",
        "C": "wchampion.svg", "c": "wchampion.svg"
       }
     },
   "custom-greenwade": {
     "pieces": {
        "P": "wpawn.svg", "p": "wpawn.svg",
        "K": "wking.svg", "k": "wking.svg",
        "G": "wwildebeest.svg", "g": "wwildebeest.svg",
        "H": "wbird.svg", "h": "wbird.svg",
        "S": "wsquirrel.svg", "s": "wsquirrel.svg",
        "C": "wchampion.svg", "c": "wchampion.svg"
       }
     }
   }

Note that the Greenwade set has no Wildebeest piece, and I didn't bother to add a substitute. So, it shows up as a question mark.

If I set things up so that constants of @pieces and @dir automatically replace $pieces and $dir, then this would let the correct pieces show up even in Edit mode.

Using constants may not work, as they are stored in the log, and the case where using variables doesn't work is in Edit mode, where no log has been loaded.

Maybe I could create a new variable type of super constants, or I could use a @superconstants constant to designate constants that override system variables.

Adding super constants to the settings file might work, but I should probably create a separate field for that instead of doing it in the GAME Code program. I'm currently thinking of creating a new set that copies values from super constants instead of containing fixed values.

But instead of allowing just one set like this, I would like to allow the option of creating multiple custom sets that would belong to the same group. They could all start with the string customset, and any that exist could be placed in a Custom group, allowing players to switch between them. They could then be described as multi-dimensional arrays of the variables set in a set file.

Another possibility is to accept json-encoded arrays as values for $set. ... Even the json array might allow someone to change arbitrary variable assignments without some restrictions in place.

If I just create a new variable that takes a json encoded array as its value, this would not interfere with other settings, and it could be broken down into values that are selectively used. If it contains other extraneous values, they could be ignored.

What we need is a set that contains all piece images an Interactive Diagram could possibly contain....

But where would we ever find such a collection? ;)

If I set things up so that constants of @pieces and @dir automatically replace $pieces and $dir, then this would let the correct pieces show up even in Edit mode. However, this would break the ability to switch piece sets. I’m also concerned about making these special cases. Maybe I could create a new variable type of super constants, or I could use a @superconstants constant to designate constants that override system variables.

Another possibility is to accept json-encoded arrays as values for $set. One thing I don’t want to do is let users add arbitrary PHP code, because that would create a security hole. Even the json array might allow someone to change arbitrary variable assignments without some restrictions in place.

One more possibility is to have a section of GAME Code that runs all the time. However, this could make a game uneditable without a back door.

It would be less confusing for someone creating a preset if there was no discrepancy between how the board displays in Edit mode and how it displays while playing the game. ...

Well, the logical problem here is that the Applet does not know the association of piece labels and images used by the set, and doesn't know what set is going to be used in the preset. It only knows the piece IDs and image names used in the Diagram that is being converted, or coming from the ID assignment in the piece table if the user has been setting up the position from scratch. This is all a legacy from the time there were hardly any automatic sets, so people were mostly using sets with 1-letter piece labels, which, to cram as many images as possible in a single set, were often very unnatural, and not at all what the converted Diagram had been using. And the assignment would differ from set to set.

What we need is a set that contains all piece images an Interactive Diagram could possibly contain, and then require that the presets to be automated this way use this set and none other. Currently the GAME code generated by the Applet uses the piece IDs defined in the Diagram as piece labels. But it could just as easily be made to use the 'root name' of the image files as labels, converting to upper/lower case as necessary. Since the Applet's piece table uses the alfaeriePNG directory as a basis for what pieces to offer, the auto alfaeriePNG set would be suitable.

This approach relies on automatic sets being available for every theme that could have been used in the Diagram to be converted. It would not be a problem that we have no unity in image naming between themes, as long as people would use the auto set for the theme that was used in the Diagram they were converting.

A minor flaw is that the Diagram now allows the use of 'extraneous' pieces, i.e. with images from another directory than graphicsDir, and possibly of anothe image type, which are specified as an arbitrary filename / URL. The auto sets would not provide these pieces, which would drive people to using other sets, nagging editors to create those for them. Which then often would use names for the other pieces different from the full name in the auto set where most of the pieces were coming from.

One way around this would be to stop creating such dedicated piece sets, but instead service the request for a set with pieces not provided in the automatic set for that theme by expanding that automatic set with the requested 'non-automatic' piece.

I still think this is all a consequence of Game Courier not being able to directly associate piece labels with arbitrary image filenames (other than through GAME code, which causes the problems we are now dealing with), but uses this cumbersome indirect method of a (by now huge) number of package deals in the form of the sets.

If piece labels could be arbitrary URLs we could have a 'direct set', which is sort of a universal automatic set, which would not be limited to fetching the images from a fixed directory, but would derive the directory from the label on a piece-by-piece basis. But I suppose URLs contain characters not acceptable in piece labels. We could nevertheless define an escape convention for those. So that the set could serve any piece image on the website, without editor intervention.

You might have forgotten to press the 'Start Position' button after seting up the pieces.

I surely wouldn't forget to do something I never knew to do in the first place. But now I've done this, and it produced this fen code:

hgscksghpppppppp32PPPPPPPPHGSCKSGH.

I put this in this preset here:

https://www.chessvariants.com/play/pbm/play.php?game%3DExperiment%26settings%3Dfpd-experiment1

The board looks accurate when you click on the link, but if you click on Edit, the board will look very different. Here, without running the GAME Code, it has some question marks, and the only pieces it gets right are the Kings and the Pawns.

It would be less confusing for someone creating a preset if there was no discrepancy between how the board displays in Edit mode and how it displays while playing the game. This can be done by relying on a set instead of defining the pieces in the Pre-Game section without reference to a set. You could use an auto set, which makes it easy to calculate the label from the file name, or you could make your play-test applet more integrated with Game Courier sets, though that would require writing some PHP to find out what is in the set. So, using an auto set is probably the easier way to go. The general rule for an auto set is that each label is the piece name extracted from a file name after removing the side prefix and the image format extension, all in uppercase for White, and all in lowercase for Black.

Also, the FEN was inaccurate. It gave me this: 4k55K3.

As you can see, it omitted every piece except the King.

You might have forgotten to press the 'Start Position' button after seting up the pieces. The Applet allows you to put more pieces on the board after fixing the initial position, which will then be available as promotion choice in the Diagram / GAME code you produce from it without being included in the initial setup. If you don't press the button, the initial position stays what it was when you opened the page, i.e. just the Kings.

Since Kevin Pacey was having problems with a preset he generated with this applet, and I have never tried to generate a preset with it before, I generated one as a test to see what I would get, and I saw this in the generated code:

set mypieces assoc
  P "wpawn.png" p "bpawn.png"
  K "wking.png" k "bking.png"
  G "wwildebeest.png" g "bwildebeest.png"
  H "wbird.png" h "bbird.png"
  S "wsquirrel.png" s "bsquirrel.png"
  C "wchampion.png" c "bchampion.png";
setsystem dir "/graphics.dir/alfaeriePNG35/";
setsystem pieces #mypieces;

I strongly recommend against including code like this. Instead of this, I would recommend using one of the auto sets or a complete enough set, then adding aliases for any piece whose notation does not match the label provided by the set. The auto sets would be useful for this, because the auto labels, being based on piece names, are easy enough to calculate. In this case, you would want to use the auto-alfaeriePNG35 set with code like this:

alias 
P PAWN p pawn 
K KING k king 
G WILDEBEEST g wildebeest 
H BIRD h bird 
S SQUIRREL s squirrel
C CHAMPION c champion;

Also, the FEN was inaccurate. It gave me this: 4k55K3.

As you can see, it omitted every piece except the King. Using an auto set, you could correctly calculate the FEN. In this case, it would be something like this:

{bird}{wildebeest}{squirrel}{champion}{king}{squirrel}{wildebeest}{bird}{pawn}{pawn}{pawn}{pawn}{pawn}{pawn}{pawn}32{PAWN}{PAWN}{PAWN}{PAWN}{PAWN}{PAWN}{PAWN}{BIRD}{WILDEBEEST}{SQUIRREL}{CHAMPION}{KING}{SQUIRREL}{WILDEBEEST}{BIRD}