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.
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 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.
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.
Yes, this allows custom sets to be supported without breaking the ability to use other sets.
I have now put that information in a tooltip for each option. I also plan to write some documenation.
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.
That is the general convention, but it's not a strict law.
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.
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
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.