Comments/Ratings for a Single Item

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.

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/.

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.)

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.

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.

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

... 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.

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):"?

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.

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.

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.

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

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

"pieces: {"

should be

"pieces": {

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

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.

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)..

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

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

It really should look more like:

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.

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?

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

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.

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.

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

FX5 (or whatever number you need) works