Check out Makruk (Thai Chess), our featured variant for March, 2025.

Enter Your Reply

The Comment You're Replying To
H. G. Muller wrote on Sat, Jan 13, 2024 05:06 AM EST in reply to Fergus Duniho from Fri Jan 12 04:23 PM:

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


Edit Form

Comment on the page Play-test applet for chess variants

Conduct Guidelines
This is a Chess variants website, not a general forum.
Please limit your comments to Chess variants or the operation of this site.
Keep this website a safe space for Chess variant hobbyists of all stripes.
Because we want people to feel comfortable here no matter what their political or religious beliefs might be, we ask you to avoid discussing politics, religion, or other controversial subjects here. No matter how passionately you feel about any of these subjects, just take it someplace else.
Avoid Inflammatory Comments
If you are feeling anger, keep it to yourself until you calm down. Avoid insulting, blaming, or attacking someone you are angry with. Focus criticisms on ideas rather than people, and understand that criticisms of your ideas are not personal attacks and do not justify an inflammatory response.
Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

Top level header: <H1>

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: <H2>

  • Unordered list item
  • Second unordered list item
  • New unordered list
    • Nested list item

Third Level header <H3>

  1. An ordered list item.
  2. A second ordered list item with the same number.
  3. A third ordered list item.
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

Alt text for a graphic image

A definition list
A list of terms, each with one or more definitions following it.
An HTML construct using the tags <DL>, <DT> and <DD>.
A term
Its definition after a colon.
A second definition.
A third definition.
Another term following a blank line
The definition of that term.