Comments/Ratings for a Single Item

@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}

Thanks yet again! :)

http://chessvariants.com/index/hgmsubmission.php

I suppose you are referring to the submission page with a provision for diagrams?

Wouldn't you know, but that I've lost track of the link to that.

I suppose you are referring to the submission page with a provision for diagrams? I have not really considered what would be needed to edit an existing submission that contains a Diagram. I suppose this would be hard, as the final product of this is the HTML code for the diagram in the Setup section. I suppose I could peel that out (in case other text was added to that section), and treat it like it was pasted in the Play-Test Applet. This would limit the piece table to the pieces in the diagram, though, so you could not add additional pieces. So it would not provide full editing capability.

Actually, no; I was referring to pasting a diagram's definitions on the new-version Applet page, and then editing it to include a Capture Matrix.I have all the pieces in place, so that's not an issue.

As to writing out the captureMatrix manually, I'll give it a shot. (The explanation in the article is OK, but I'd prefer an example so I can feel confident in getting it right.) Because of the single-letter issue, I'll write it out with the comma-delimited feature you mentioned and wait for you to implement that before giving Short Sliders its Diagram.

Are morph variables limited to one character?

Currently they are. But it is my intention to allow comma separation of multi-character piece IDs. In that case, if a row of the matrix contains a comma, it would split the row by comma, and take the n-th string of the split rather than the n-th character of the row as the piece ID.

After a long period of selecting all the pieces, I saved the setup to come back and build the Capture Matrix later. It won't let me do that! I can load it, but I can't do anything with the Capture Matrix. (I'd build the Capture Matrix manually, but there's no demonstration of what that should look like.)

I suppose you are referring to the submission page with a provision for diagrams? I have not really considered what would be needed to edit an existing submission that contains a Diagram. I suppose this would be hard, as the final product of this is the HTML code for the diagram in the Setup section. I suppose I could peel that out (in case other text was added to that section), and treat it like it was pasted in the Play-Test Applet. This would limit the piece table to the pieces in the diagram, though, so you could not add additional pieces. So it would not provide full editing capability.

Anyway, the captureMatrix is not hard to add manually. Basically you just write all rows separated by slashes. There are many shortcuts for saving on typing, (which are not used by the applet on the submission page that generates it), all explained in the Interactive Diagrams article.

Not really a problem, but in the end does it matter what order the pieces are (discounting Pawns at the beginning and Royals at the end)?

The Diagram's AI searches captures sorted by value of the victim (high to low), and then in ascending table order of the attacker. Since it is usually most best to capture with the least-valuable piece (e.g. imagine a protected Rook attacked by a Knight and a Queen), it would slow down the search if the table order differs significantly from low value to high value. But in the end it would find the same move (unless two moves really have exactly the same score).

I've been setting about making an ID for Short Sliders using the new (WIP) version of the applet, and running into some roadblocks. Alot of it, I think, is my lack of understanding, though some may be weaknesses in the system. (And some of it pertains more to information on the Interactive Diagrams page; I'm just putting everyting here.)

1. Are morph variables limited to one character? When I set (for example) the Jackal's promotion to the Bongo, the system changes the Bo to B. (replaces the o with a period). I'd really rather not have to rework all the symbols.
2. After a long period of selecting all the pieces, I saved the setup to come back and build the Capture Matrix later. It won't let me do that! I can load it, but I can't do anything with the Capture Matrix. (I'd build the Capture Matrix manually, but there's no demonstration of what that should look like.)
3. Possibly more something for Fergus: Using the Showpiece tool, some of the pieces don't recolor for black, none of the compound images render, and (oddest of all) the Hospitaller comes up as a blank.
4. Not really a problem, but in the end does it matter what order the pieces are (discounting Pawns at the beginning and Royals at the end)? I'm trying to arrange the pieces into something more intuitive to the game (Starters, then First Promotions, then Second Promotions), and so far it hasn't complained.

I'll wait for another time for things like limitations on promotions to Thaumaturge, Pawn selections between Starters and First Promotions, and complicated stuff like that.

Well, people without programming skills have been making Game Courier presets for their variants for ages. By making a preset that does not check the rules, but leave that to the players.

I suppose we could decide to make uu mean color-flipped unload in XBetza. But that would then have to be implemented in the ID, as well as in the GAME-code include file. It is unlikely this will be done any time soon.

FWIW, I support this idea in general (I've seen more than one case where this is done), though I certainly agree that there are more important priorities right now.

I suppose we could decide to make uu mean color-flipped unload in XBetza. But that would then have to be implemented in the ID, as well as in the GAME-code include file. It is unlikely this will be done any time soon.

I don't think it would be possible to implement the function performed by the additional JavaScript in the generated GAME code by post-editing the latter.

I think it's a pity that a however 'new' structure (Conquer) can't be played on Game Curier.

Of course, everything can be realized if the special programming skills exist. But they do not in my case.

Then so it shall be. Too bad.

Indeed it works fine again. Thanks!

Argh! I left in a 'die' statement that I had added for debugging, to make sure it would show the page with all the stuff I had it print when it thought it had a checkmate, rather than just terminating the game. I forgot to remove that after the problem was fixed.

I removed it now, so things should work again.

@HG:

I'm sorry. Bothering you again. In the Symmetric Sissa preset (which was edited using the Play-test applet) the software does not properly declare checkmate for either side (white or blue); instead it warns on a new page:

Please report any bugs or errors to H.G. Muller

blue wins

Use your browser's BACK button to go back to the previous page, then reload if necessary.

For general reference, here is the complete list of moves:

1. P h2-h3
1...n h8-i6
2. A g1-h2
2...n i6-h8
3. A h2-c7

If this is your settings file, you may edit it at https://www.chessvariants.com/play/pbm/play.php?game=Symmetric+Sissa&settings=9x8-enforced&submit=Edit

Apart from this problem, the preset works perfectly fine. I don't think I made any mistakes when applying the Play-test applet.

I have confirmed that the problem has been resolved. Thank you very much HG and Fergus.

Has any of the subroutines you called changed the value of k or r?

Thanks for the suggestion, printing #k and #r as wel as #hit solved it. Not that these were changed, but #r was one less than I had expected, because the loop was not supposed to go over the entire slider path, but only over the 'internal' squares (which are always empty). And it left the final step to code after it (that also has to test the occupant to determine whether the move would be valid). That it continued with Qe3-i7 was thus the fault of this other code, and not of an extra loop iteration, as i7 was the last square on the ray. This code should have tested whether #hit was set in the loop as well.

The problem of the false mate claim should be solved now; instead of testing #hit in the condition for the do-while loop, I put a

verify not #hit;

at the end of this loop. This aborts the subroutine immediately when #hit gets set in the loop, thus also suppressing the code after the loop.

I set up a simple loop similar to your own to see if I encountered the same problem:

set k 1;
set r 5;
set hit false;
do while < #k #r and not #hit:
  echo #k #r #hit;
  dec r;
  set hit true;
loop;

This looped only once. I changed what hit is set to to "e1" and got the same result. So, the problem does not seem to be with the logic of the looping condition. Has any of the subroutines you called changed the value of k or r?

The function 'Paste an existing diagram:' in your 'Play-test applet for chess variants' can't be realized via the indirect way of 'Notepad' - thanks for the tip, would have been nice if!

Well, it works for me, also when copying the ID in the Conquer article through NotePad into the Play-Test Applet. Are you sure you did not try to copy any of the enclosing HTML tags together with it?

This is a moot point, however, since the GAME code generated would not work as desired. Conquer is not a variant that is supported by the standard functionality of the Diagram. It needed custom scripting to alter the generated capture moves such that they would place a color-reversed version of the victim on the square of origin. The XBetza notation does support 'unloading' the captured piece there with the aid of the u modifier, but there is no provision for flipping its color. So additional JavaScript embedded in the page was needed for that, and this cannot be converted to GAME code by the Applet (even if it would have been pasted into it, which it is not).

I suppose we could decide to make uu mean color-flipped unload in XBetza. But that would then have to be implemented in the ID, as well as in the GAME-code include file. It is unlikely this will be done any time soon.

I don't think it would be possible to implement the function performed by the additional JavaScript in the generated GAME code by post-editing the latter.

It seems I need @Fergus for this.

The loop in the move generator of the betza.txt include file for generating slider moves looks like this:

      set k 1;
      do while < #k #r and not #hit: // for non-final (and thus empty) squares
        set to elem dec #k #tosqrs;
        if #togo:
          set newindex + 4 #legindex;     // another leg follows
          gosub NextLeg #togo #newindex #startsqr #to #locustsqr #dropsqr #k;
        else:
          gosub GotMove #startsqr #to #locustsqr #dropsqr 0 0;
        endif;
        if & << 1 23 #mode:
          push eps #to;
        endif;
        inc k;
if == 4 #task:
print . L_ #hit;
endif;
      loop;

where #tosqrs is an array of all the empty squares on the slider path. The variable #hit, initialized to false, serves for flagging if the sought move (e.g. the entered one, a legal one or capture of a royal) has been found, so that move generation should be aborted.

In the mate test (where #task equals 4) for the position given by Carlos below, the move Qe3-h6 is correctly found to be a legal one, which sets #hit, as is confirmed by the printing of L_1 by the print statement I inserted for debugging. As far as I understand this should have terminated the do-while loop, as not #hit is then no longer true. But the loop happily continues with the move Qe3-i7 (the next empty square in that direction), and subsequently generates all other pseudo-legal moves for the position. The last one being illegal because it does not evade the Sissa check, so that the verdict 'checkmate' results.

What is going on here that makes the loop continue?

Respected Mr. muller,

Question: How to express Non-crossable board positions such as D, H, WX, DX, HX, WXX, etc.?

Huge benefits with non-crossable board positions. could create thousands of fun chess variants, suitable for brain exercise mental computation.

Thank you so much!

@HG:

It seems that there is a bug in the Coherent Chess preset (which was edited using the Play-test applet), since upon reaching the position shown in the following diagram the software declares checkmate after 11... Sh7+, it being evident that White can block the check with either 12.Bh5, 12.Qh6, 12.Qg3 or 12.Qf2.

This critical position can be accessed by following these movements:

1.Gfg3    Ggg7
2.Gdc3   Qh7
3.G2h3   Qxe4
4.Gf3      Qg6
5.Gi4      Qxg1
6.Qxg1   Sc7
7.Ge4      Sxi4
8.G2d3   Bh4
9.Bc5       Bxf2+
10.Qxf2   Gfe7
11.Qe3     Sh7+

Could you please take a look at this? Thanks in advance!

The function 'Paste an existing diagram:' in your 'Play-test applet for chess variants' can't be realized via the indirect way of 'Notepad' - thanks for the tip, would have been nice if!

It's not clear what you're saying or what you're trying to do.

If I am not wrong I would be glad if you could point out the way to Game Courier. Thank you very much.

Game Courier is at this link.

@H.G.
Could you kindly help me:

I have been trying to get my variant 'Conquer' onto Game Courier for some time.

The function 'Paste an existing diagram:' in your 'Play-test applet for chess variants' can't be realized via the indirect way of 'Notepad' - thanks for the tip, would have been nice if!

I have the impression that the variant brings a slightly different speed to the already existing variants.

If I am not wrong I would be glad if you could point out the way to Game Courier. Thank you very much.

I typically get this when I try to copy-paste the Diagram definition from the Page Source of another page. Apparently copying from such a page is not 'clean', but puts a lot of invisible HTML tags on the clipboard as well, which might or might not be included depending on where you paste it. Apparently it is included when you paste it into a HTML context, (such as the Play-Test Applet's page), and the Diagram parser than chokes on it.

A solution I found for this is first copying the Diagram definition into NotePad, then select and copy it again from there, and finally paste it into the Play-Test Applet.

If I would know what kind of unwanted stuff comes with a copy from a Page Source, I could make the Diagram's parser ignore it. But it is not so easy to figure this out, as an attempt to directly display on a HTML page what was pasted would probably makes this extra stuff as invisible as it is on the Page Source. So I never got to doing that.

@H.G.:
When I want to use the 'Paste an existing diagram' function in your 'Play-test applet', I often get the error message 'Cannot make a diagram with 0 pieces on an 8x8 board!'. I have tried this with the interactive diagrams for my variants 'Conquer', 'Borderline', Bull's eye' and 'Avatar Chess' - always with the same result.
Is there a simple way to avoid this or does it require programming skills (which I don't have)?

Dear respected Mr.muller,

How to express the 4th item of a row, but non-crossable? and how about 5, 6, 7, 8, 9, items, non-crossable? Thank you very much.

I poked around for a bit on the new version of the applet a bit this morning. I think this is pretty close to ready. I'd love to have things like saving a setup as a file locally and reloading it later (so I don't necessarily have to do these large, complex ones like Short Sliders in a single sitting) or being able to reorder the pieces (so that, again referencing Short Sliders, all of the starting pieces are together, then all of the first-promotion pieces, then the second-promotion), but those things can wait for some future release.

To allow pieces to be dropped (or sometimes chosen for promotion) the number of those you have in hand should be non-zero. And if it is non-zero it will be displayed. You would only have or get pieces in hand when you need those for dropping, or as possible promotion choices, and in both cases it seems important to know how many you still have in hand.

Do the columns labeled nr serve any real purpose? If not, removing them could free up a little space.

It might have been a network glitch. After the page gets loaded it must again connect to the CVP server to fetch the listing of the piece image directory, so it can add pieces that are still missing to the list (and delete those from the list that aren't really there). If this fetch request times out, you would not get to see any error message, but the additional pieces in the directory would not be added.

Can you tell me which piece(s) you are missing, so that I can see if I have this problem too, and if so, what causes it?

Oddly, it's now the problem that seems to have vanished. I had been missing at least the plane, templar, wolf, and zebrabishop, to name just the ones that I wanted to use.

Well, e-readers do have monochrome displays, and this was originally the reason why I introduced the board markers as an alternative for back-ground-color highlighting. For the current application it seems less essential to be able to distinguish the colors, though. It would be rare that the different 'special actions' would be needed in the same variant; in fact it would already be rare that they would be used at all. And if you don't make any mistakes you would just be spreading around a special action you just selected over empty squares / table cells. And even if you did make a mistake that need overwriting you would know what you are spreading around, and where it had to go, and it would not be of interest what was there before by mistake.

As a legitimate application for overwriting I could imagine a piece that can in general not be captured, except by just one or two types, in a variant with a great many types. You could then use double-clicking to fill the entire capture row (to be used as column here) with holes, and then overwrite those for the few piece types that actually can capture by clearing the holes again.

Other than that, the only thing I'd say is that pieces on the board should have their moves on the table shaded green, just like the Absentees. If you think they should be differentiated, then perhaps cyan would do.

Yeah, this is what I was thinking too, but since placing on the board is a normal operation of the ID that is also used in playing games with piece drops (where we definitely would not want the table pieces to be marked) I didn't figure out yet how I could achieve that by code embedded in the Applet page, without modification of the general Diagram script.

And did you make any changes to the piece selection list? A couple dozen of them seem to have vanished, including several that I was relying on for Short Sliders.

I did not make any conscious changes in the table. And even if I would have deleted pieces from the table defined on the page, the initialization script there would scan the piece-image directory, and add all pieces it finds there to the table. The reason I included any piece table at all on  the page is to make sure important pieces have the appropriate move defined for them (the script would not know this for the images it adds), and to make the most commonly used pieces appear early in the table in a sensible order (rather than in the order they would have in the directory listing, which might be alphabetical).

Can you tell me which piece(s) you are missing, so that I can see if I have this problem too, and if so, what causes it?

Monochrome monitors are pretty rare these days. In fact, I don't think I've ever set my eye on one since the 1990s. So, I think your color scheme would work fine. If you're really worried about it, you could tweak the shades of the colors so monochrome displays show them in distinctive shades of grey.

Other than that, the only thing I'd say is that pieces on the board should have their moves on the table shaded green, just like the Absentees. If you think they should be differentiated, then perhaps cyan would do.

And did you make any changes to the piece selection list? A couple dozen of them seem to have vanished, including several that I was relying on for Short Sliders.

I know put in the 'Duplicate' button, and I actually think it works pretty smooth. It was important to have it always in view, though (first I had it at the top of the scrolling table, next to the 'Create holes' button). I relocated both buttons now to below the scroll window. It doesn't enforce yet that it only should be used before you placed any pieces.

I also put the row of buttons above the capture table (appearing together with it). But I still have to make those do the right thing. I still have to decide how to represent the events the buttons are for on the board and in the capture table. I could do that by coloring the squares, just as the holes colors those black. E.g. grey for vanish, yellow for explode, red for win, orange for check. Giving the buttons the the color they would distribute would make them do double duty as legend. This might not be convenient on monochrome displays, though. So perhaps I should use the highlighting markers instead.

What is not clear about the assignment? The page already mentions in three places that you have to do this by clicking on the move of the piece in the table (In the permanent help text below the table, the help text that appears when you open the morph & confine section, and the introductory text).

D'oh! Once again, I miss the painfully obvious.

A row of buttons for the win and explode options could be located above the table for setting the capture matrix.

And don't forget the "blank" button (for removing entries placed by mistake). :)

Perhaps there should be a button 'Duplicate'...

That seems a little awkward, but much better than anything I could come up with. (My best idea was allowing a space-slash-space in the move section, separating the two different moves.)

AFAICT this getting done, plus a clear way to assign a morph board and/or capture matrix to a piece, would complete the improvements.

What is not clear about the assignment? The page already mentions in three places that you have to do this by clicking on the move of the piece in the table (In the permanent help text below the table, the help text that appears when you open the morph & confine section, and the introductory text).

A row of buttons for the win and explode options could be located above the table for setting the capture matrix.

I realize that there still is a problem w.r.t. "hidden morphing". In the Interactive Diagram each piece has a fixed move, used everywhere on the board. (The exception for this is the initial moves indicated by the Betza i or ii, which are dropped as soon as the piece moves from its initial location.) So pieces with location-dependent move rules will have to be implemented as a set of different pieces, each with one of the possible moves, which then morph into the applicable type for the square they move to. I consider it a legitimate wish to represent all pieces in such a set by the same image (and possibly piece ID). E.g. represent Soldiers in Xiangqi by the same image whether they have crossed the River or not.)

The piece table of the Play-Test Applet contains each image only once, though. (And it is already very large as it is.) So setting up a position with (say) two different Knights is currently not possible. I would like to make it possible, though.

Perhaps there should be a button 'Duplicate', which would create a duplicat of the currently selected piece type in the table. It would be easiest to program if that duplicat was put that at the end of the table, but probably quite inconvenient in use. So I should probably insert it immediately behind the selected original, and then renumber all pieces on the board and in the capture matrix to correspond to the new ordering in the piece table. (This would be a royal pain in the *** to program, so perhaps I should simply require that duplicats should be created before any pieces are placed anywhere (including creation of morph boards), and disable the button after that.)

You could then change the move and possibly other properties of the duplicat. Advantage is that you could make as many versions with the same image as you like, this way.

Eventually I will need some additional buttons anyway, to indicate other things than a piece or a hole. E.g. check and win squares for the morph board, evaporate / explode for the capture matrix. 'Blank' could be another button in that group.

AFAICT this getting done, plus a clear way to assign a morph board and/or capture matrix to a piece, would complete the improvements.

For clarity: the Play-Test Applet does not allow the user to exploit every feature of the Interactive Diagram, and the automatic GAME-code generation by it does not support every feature you can use through the Play-Test Applet. This doesn't have to be a major obstacle when you want to create HTML or GAME code for use elsewhere, as these are both texts, which can be easily modified afterwards for 'filling in the blanks'.

Now the original Play-Test Applet did not have an interface for specifying morph boards, and the GAME code that would be generated by it also knew nothing about morphing. This, however, happens to be exactly what I am working on to correct, by creating a new version of the Play-Test Applet. I modified the include file used by the Applet-generated code earlier already, for performing morphing when instructions to do this are included in the Applet-generated code. And the new Applet includes an interface for defining morphing.

Defining two versions of each piece doesn't really need a special interface, as the whole point of this is that they would be considered different pieces (so they can have different moves). If you want them to have identical images this would be a problem, though, for there only is e.g. a single Knight image in the table. So to create a Diagram that has two different Knights, one for in the bulls eye, and one for outside it, you would have to pick an alternative image for in the bulls eye. But you can always correct that afterwards, by editing the piece line in the Diagram for the bulls-eye Knight, replacing the image name (say you used a Unicorn) by 'knight'. You would of course have to assign the desired bulls-eye move to the Unicorn. The Diagram would allow you to also use the same piece ID. (It is smart enough to understand that a piece should never morph into itself, so if you specify N as the result, it would take it to mean the other N.) But Game-Courier presets would not like that a bit, for those all pieces need to have a different 'label'. So if the goal is to create GAME code, you should make sure every defined piece has a unique ID.

It is possible to change the ID even after pasting an existing Diagram into the Applet. In fact, if you paste a Diagram where the duplicats use the same image that immediately solves the problem of the duplicat images, as pasting a Diagram replaces the piece table as well as the board position. The new table would then contain two images of every kind. You would only have to give them different piece IDs. You could not specify new morph boards in that case, though, as the new piece table would not specify you hold any pieces 'in hand' that you could drop on the morph board for specifying promotions.

@H.G.: I would like to be able to play my variant 'Bull's eye' on 'GAME Courier'.

With the 'Play-test applet for chess variants' ( new one) I thought I could realize this. Maybe it works and I didn't understand it correctly. Anyway, you say:

This falls within the standard capabilities of the Interactive Diagram, so that it can be implemented without any programming. Just specify two versions of each piece, one for in the bull's eye, one for everywhere else. And then specify a morph board for each of those that makes them change into the version that belongs in the zone. The morph board for the 'eye pieces' can also be used to make the bull's eye inaccessible to them.

The ability to implement two options for each character (normal/bull's eye) I can only find in your description for 'Interactive diagrams'. In the 'Play-test applet for chess variants' I did not find this option - and only there seems to exist the ability to define the 'morph board'. To get from 'Interactive diagrams' to 'Play-test applet for chess variants', I have so far used the function 'Paste an existing diagram:'. This also works, but then I fail at the definition of the 'morph board'.

I've been witching at this point for days and can't get any further.

Have I got it all wrong, or could it be advantageous to harmonize 'Interactive diagrams' and 'Play-test applet for chess variants'?

Yeah, sticking that information under Pieces on the Interactive Diagrams page would be helpful. :)

Thanks. I think I can make some better-looking diagrams for both Vanguard and Short Sliders now, and possibly others as well.

I suppose I never documented that; just announced it in a Comment.

But it is simple enough: if you replace the root name of the image with a string that contains a percent sign, it uses that string, with the % replaced by the color prefix, as the URL in the HTML img tag, without paying attention to the specified graphicsDir or even graphicsType (if the string already specifies a file extension). The only requirement is that the 'external' images use the same color prefixes.

The advantage of a checkbox per piece is that you can see at any time whether it is checked, though. But this could also be indicated by, say, changing the background color of the piece name in the table.

That would work great! (Personally I'd prefer light green.)

Eventually I will need some additional buttons anyway, to indicate other things than a piece or a hole. E.g. check and win squares for the morph board, evaporate / explode for the capture matrix. 'Blank' could be another button in that group.

Yeah, that makes more sense.

You don't have to leave the whole job to it, and it would be easy to edit the HTML code afterwards, e.g. to replace some of the graphics by images outside the alfaeriePNG35 directory. Even to images you uploaded yourself.

That would be great; I didn't know I could direct some of the graphics to another directory. Is there a tutorial or guide or anything for doing that?

Would it be possible to have a check box to the right of the piece selection for pieces to keep? The box would be automatically checked (and greyed-out to prevent from being unchecked) when the piece is on the board for setup.

The problem here is space. The new Applet page looks pretty wide, but that is because it has no add sidebars, like it would get if it would ever become an ordinary article in the database, rather than a separate html page. (Which of course would be a good reason to keep it as a separate page.) The table is already so wide that sometimes you need horizontal scroll, although that problem has been ameliorated now that the new definition of n on obliques has very much shortened the XBetza for the Falcon move.

Putting a single button 'starts off board', e.g. next to the Apply button, which you have to click after selecting a piece, wouldn't take up any space. The advantage of a checkbox per piece is that you can see at any time whether it is checked, though. But this could also be indicated by, say, changing the background color of the piece name in the table.

As for reverting a cell on the capture matrix to empty, perhaps that could be done by simply clicking on the space when the piece selected is already there? Or with a right-click? Or by putting a Hole in that spot, and then double-clicking the hole?

The problem is that left-clicking replaces whatever was there with the piece that is selected in the table, (or with a hole if the Create Holes button had been pressed last), and that there is no way to deselect that. And for the holes, just like the pieces, a double-click would fill the rank with those. A right-click would be possible, but would people ever discover that? Eventually I will need some additional buttons anyway, to indicate other things than a piece or a hole. E.g. check and win squares for the morph board, evaporate / explode for the capture matrix. 'Blank' could be another button in that group.

Tangentially, maybe the "more rules" section could also include a box to specify Royal piece(s)?

Good idea.

Another tangent: Is there any way to add graphics to this?

It uses the graphics that it finds in the alfaeriePNG35 directory. If any new image appears there, it will be automatically added to the piece table. E.g. the 'wolf' image I recently added is already in the table, without making any provision for it on the Applet page. So this isn't really an issue for the Applet, just that you want more pieces added to the Alfaerie set.

Also note that the Play-Test Applet is just an aid to creating HTML code for Interactive Diagrams. You don't have to leave the whole job to it, and it would be easy to edit the HTML code afterwards, e.g. to replace some of the graphics by images outside the alfaeriePNG35 directory. Even to images you uploaded yourself.

Would it be possible to have a check box to the right of the piece selection for pieces to keep? The box would be automatically checked (and greyed-out to prevent from being unchecked) when the piece is on the board for setup.

As for reverting a cell on the capture matrix to empty, perhaps that could be done by simply clicking on the space when the piece selected is already there? Or with a right-click? Or by putting a Hole in that spot, and then double-clicking the hole?

Tangentially, maybe the "more rules" section could also include a box to specify Royal piece(s)?

Another tangent: Is there any way to add graphics to this? Besides not seeing an antelope, bison, or buffalo, I'm surprised to see zebrabishop but not zebrarook or zebraqueen (or camelqueen, while I'm at it). There are a handful of others in Short Sliders and other games that just don't fit with any of the existing graphics.

Perhaps pieces should be considered participating automatically when they were present in a morph board or the capture matrix, in addition to being in the start position. That still leaves pieces mentioned only through the promoChoice, though.

If you have multiple pieces that morph, you must assign a morph board and/or capture-matrix row to each of those.

I am thinking of some shortcut for the ofter occurring situation where an entire rank would need the same piece. As it is now placing a piece in an already occupied square would replace the old occupant. But a double click on the leftmost square (i.e. placing the same piece as what was already there) could be made to fill the entire rank. And a double click in the b-file every even squre, and in the c-file every odd square. In the capture matrix doubly clicking could place the piece in every cell to the right of it too. (There should be a way to revert cells back to empty, though; this is now not possible other than clearing the entire thing by closing and reopening the morph section.)

Update: I figured out how to make pieces available without having them in the opening setup. I was right; my brain just wasn't processing it right.

I experimented a bit using the opening position for Short Sliders, and the capture matrix looks great. I'm only unsure about how to enter information for more than one capturing piece, but that can come as you develop it.

I also don't think I quite understand how to keep a piece available without including it in the opening setup, but that's more likely because of me (unless you haven't implemented that yet).

To get it to fit, maybe you could put the morph board information on the left; if nothing else, that'll move the capture matrix up a bit. You could also put it in its own frame or something, like the piece list is, so that any left-to-right scrolling from having a massive number of pieces only has to affect the matrix itself.

(Of course I wish there were more symbols available on the diagram... but then, I would, wouldn't I?)

I now put an interface for defining a row of the capture matrix (together with the morph board and other properties of a piece) in the new Play-Test Applet. It doesn't really create a capture matrix yet; so far it is just a test for judging if the interface is convenient, or not. It only would allow defining what happens for capture of enemy pieces; friendly capture seems to rare a feature to worry about at this stage.

I was thinking, though. Chess Variants typically have a few pieces with special properties. Defining the capture matrix per row is good for pieces that promote on capture, and allows you to diversify based on what they capture. But there are also pieces that are exhibiting their special nature when they get captured. (E.g. contageous or iron pieces.) For such pieces entry per row is quite cumbersome; you would have to indicate the special behavior in the row for every piece that captures it. Defining the capture matrix per column would be much easier for that case.

So perhaps I should put a switch there for selecting whether the promotions you entered are for a row or a column.

Currently the capture row is a bit far from the piece table, so that you might have to scroll to place pieces there. I must put it in a place where it can get very wide if there are many piece types, though. Perhaps there is too much text above it to explain how it works, but I am not sure people could figure out how to use it without that text. Of course I could put a clickable link 'hide explanation' with the text, to reduce the distance to the table?

The problems you describe with the "drop" feature are pretty close to what I suspected. That's why I said it would be "later." (And since I have yet to even think of a game that uses it, I'm in no hurry for it myself.)

If you ever do start working on it, I think some of the load can be taken by keeping a running score for each square for how useful a certain move (of one space) from that square would be for a drop. Something similar could also be done for how vulnerable the space is, and from what direction; this could evaluate how useful the space is as a block (since a drop can also be used to block a slider's or rider's move from check or capture). Those functions, which would activate only if drops are active, and could be calculated for each combination of piece and open space. That method is kind of crude and rough compared to "evaluating the future," but it's a possibility.

I suppose I could let the user enter the matrix per row, and then assign that row to a piece (the moving piece). Then there could be an Nx2 auxiliary board displayed, which on the upper rank shows all participating piece types, and pieces could be dragged to the lower rank to indicate what the moving piece should change to when it captures the piece displayed above it.

This does strike me as a very useful method. The matrix would be a separate table, I take it?

Changing the id of all absent pieces to '-' appears to have worked for on-page playing. (Flush the browser cache, as I also had to fix something in the Diagram script, to prevent the Start Position button would crash on a highlighted empty square, which can be a remnant of defining the morph board.) And it makes future editing only slightly more cumbersome, as you would have to redefine a new id. Perhaps I should reserve clearing the id to ids that have the same id as a participating piece; those would have to be redefined anyway if one wants those to appear together in the same variant.

Another matter is how to enable the user to enter a capture matrix. The problem here is that this, unlike the morph board, might not fit in the board, but would need a board that has all piece types as 'coordinates'. For games with multiple rows of pieces this is usually larger than the board. (Even for the 8x8 Team-Mate Chess it is!)

I suppose I could let the user enter the matrix per row, and then assign that row to a piece (the moving piece). Then there could be an Nx2 auxiliary board displayed, which on the upper rank shows all participating piece types, and pieces could be dragged to the lower rank to indicate what the moving piece should change to when it captures the piece displayed above it.

"Starts Off Board" would be a great addition! It'd make something like Short Sliders a lot easier to create. It'd also be a good step toward adding a "drop" feature later.

Well, it doesn't really make a lot of difference if you know how: in the old Applet all pieces would be participating when you used it for playing in the Applet itself. And for the purpose of generating HTML for a Diagram elsewhere, or GAME code, you could drag the other participating pieces from the table to empty squares on the board after you had pressed 'Start Position', before generating the HTML or GAME code.

The problem with a drop feature is mostly in the AI, that it enormously drives up the branching ratio, and that you only start to distinguish useless drops from sensible ones after two more ply of searching. (As all drops are non-captures, and in general decrease your positional score, because pieces in hand are more mobile than on the board.) With such a large branching ratio the AI would not be able to search far enough ahead to see the advantage of any drop. What would be needed is some smart method for selectively generating drops that might be useful (e.g. those that deliver check, or where a weak piece attacks a very much stronger one). This is not easy in a context where dropped pieces can have arbitrary moves. E.g. for check drops you basically need a 'reverse' move generator, which gives you all moves to a given square, rather than from one. But some moves that can be described with XBetza are very hard to generate in reverse. E.g. for a Griffon.

Would it be possible to have it so that you can switch back and forth between playtesting and editing?

That is exactly what stopped me before from culling the piece table; you would no longer be able to add new pieces once these have been deleted. But a solution for that occurred to me: the extra pieces are only troublesome if they have the same ID as participating ones. So on pressing Start Position I can simply set all IDs of the non-participating pieces to a dash. One can always assign a new, valid ID afterwards, if one selects the piece as an afterthought.

After pressing Start Position the Diagram is no longer in setup mode, though. This only affects automatic placement of color-reversed pieces, so perhaps this isn't a real problem. I suppose I could add a button to go back to setup mode.

"Starts Off Board" would be a great addition! It'd make something like Short Sliders a lot easier to create. It'd also be a good step toward adding a "drop" feature later.

That raises the problem for how to indicate participating pieces that are not present in the initial setup. Perhaps I should add a button for that, "Starts off board", so that one could select a piece type in the table, and then press that button instead of selecting a board square. These piece types would then also be left in the table when you press the "Start position" button.

Would it be possible to have it so that you can switch back and forth between playtesting and editing?

Ah OK, I think I know what you mean. You morph into different pieces than those you placed on the board, once you start playing. Problem is that I currently create the morphs by piece ID, as they would appear in the morph parameter of the Diagram that is produced upon pressing the HTML button. But the table of all available pieces contains many pieces that have the same ID. And the algorithm for interpreting the morph parameter takes the last piece in the list with the given ID (other than the promoting piece itself).

I guess this is a general problem with the Play-Test Applet, when you use it to play on the page itself: it considers the entire list as participating pieces, and this would also wreck interpretation of the promoChoice parameter: it would allow you (or the AI) to promote to non-participating piece types that happen to have the same ID in the table as the participating promotion piece.

I suppose that I should remove all pieces that are not on the board from the table, at some point. That raises the problem for how to indicate participating pieces that are not present in the initial setup. Perhaps I should add a button for that, "Starts off board", so that one could select a piece type in the table, and then press that button instead of selecting a board square. These piece types would then also be left in the table when you press the "Start position" button.

By "automatic promotions," are you referring to immediate promotion on entering a promotion zone, on the piece in question making a capture, or on another piece being captured? The Prince promotion in Vanguard Chess is an example of the latter, but I've also occasionally seen rules like, "The Pawn promotes to any piece that's been captured; if there are none, then the Pawn stays where it is until one's available, at which time the Pawn promotes immediately and automatically."

The Wizard/Sorcerer/Thaumaturge relationship in Short Sliders is also something that I'd like to see available, though if it's too complex I totally understand.

It'd also be good if certain pieces that can take a turn without actually moving (such as the Zero or the Bomb) could, when clicked, bring up a button asking if that's what the player wants to do (possibly as a spell or something similar).