Comments/Ratings for a Single Item

Dear Fergus and dear authors of Chess Variant Pages,

perhaps I have not fully understood the Chess Variant Pages and do not know the possibilities that the system offers. Nevertheless, my question:

Is it conceivable - or already realized - to derive a ranking of attention or interest from the frequency of hits on a variant page? Such a possibility would be very helpful for the authors from my point of view to be able to recognize the appreciation of a variant.

I do not mean the Recognized Chess Variants in alphabetical order, nor the variants marked with 'hearts'. I have in mind a ranking in numerical ascending or descending order based on hits.

Did this already exist, so am I too late or is this an interesting approach?
 

I have made the 404 page more powerful. While I had previously set it up to give suggestions, it wasn't always doing a good job of that. It now does a better job, and if you enter just about any Chess variant name right after the domain, it should be able to direct you appropriately. Try it out and let me know if there is any way to improve on it.

Is it conceivable - or already realized - to derive a ranking of attention or interest from the frequency of hits on a variant page?

No, we have not been using hit counters, and I did not find any logs with this information. It might be possible to set something up, but I would like to have a way to ignore robot activity or frequent visitors to the same page, and I'm not sure how to do that.

We already have other measures of popularity. See Which are the Best Chess Variants?.

I have been at work making our 404 page the best in the world. The main strength of our 404 page is the ability to search the database and offer appropriate suggestions. When I was looking at examples of what are supposed to be the best 404 pages, none of them did this, and their main strengths were only in graphic design. I won't say ours has the best graphics. I did limit myself to public domain art instead of hiring an artist, and there are lots of other 404 pages with good art. But the art I chose was suitable for a 404 page and a good match for our site. So, I'm happy with it.

I found color versions of the artwork, and since the artist died over 100 years ago, I assume they are also in the public domain. But I'm having trouble deciding which I prefer. I'm wondering if maybe the color makes the images too distracting. So that others may compare them, the color images will be used if you are signed in, and the black and white images will be used if you are not.

@ Fergus

Something may be wrong with the 'game review' page (linked to from 'What's New' page). No reviews show at all, but rather some sort of coding(s).

I decided to go with color.

Something may be wrong with the 'game review' page (linked to from 'What's New' page). No reviews show at all, but rather some sort of coding(s).

Okay, I've corrected the link to use the supported parameter instead of sortbydate.

The home page still needs a lot of work to become presentable:

• It is not clear that the photographs or program logos can be clicket to navigate somewhere; the fact that the page is full of recognizable links creates the impression that navigation should occur through those.
• The photograph for Shatranj / Chaturanga is awful. The pieces are so small and shown at unfavorable angle that it require a microscope to notice these are not just an ordinary stounton set, and the board looks like it has disintegrated into individual squares for no obvious reason.
• The alignment of the images is messy: the images are not of equal size, so that upper-left alignment of the smaller xiangqi images is all wrong.
• Although there now is a photograph for the 'featured variant', it is not obvious at all what its significance is. The word 'featured' (or better:  'variant of the month') does not appear with it. There is also no link in the accompanying text (like there is for Shatranj/Chaturanga and Xiangqi/Janggi/Shogi), nor a suggestion that the image can be clicked.
• The program logos are all of different size; again there is no suggestion that clicking those would do anything.
• Depending on the display/window width, the four topics with an image either display as 4x1, 2x2 or 3+1. In the first two cases the program logos are tiled to approximately the sam size as one of the other images (which is OK), but in the latter case they are displayed side by side, and because that doesn't fit, displayed as rows of 6 + 2 (messy).

It is not clear that the photographs or program logos can be clicket to navigate somewhere; the fact that the page is full of recognizable links creates the impression that navigation should occur through those.

I created new buttonized images of each logo.

The photograph for Shatranj / Chaturanga is awful.

I replaced it with a Chess photo.

and the board looks like it has disintegrated into individual squares for no obvious reason.

Since I don't have a Chaturanga board, I made it by laying out individual board tiles. Since these were hand-made, they did not all align up evenly.

The alignment of the images is messy: the images are not of equal size, so that upper-left alignment of the smaller xiangqi images is all wrong.

I took the width and height values off the Xiangqi image, then replaced it with a Janggi image, because its more square shape is less portrait, and that fits better with the other images being more landscape than portrait.

Although there now is a photograph for the 'featured variant', it is not obvious at all what its significance is. The word 'featured' (or better: 'variant of the month') does not appear with it. There is also no link in the accompanying text (like there is for Shatranj/Chaturanga and Xiangqi/Janggi/Shogi), nor a suggestion that the image can be clicked.

I added a line about that with a link in it below the image.

The program logos are all of different size;

I made new ones that are all the same size today, but the uniformity made none of them stand out as much. By being different sizes, they all stood out better. So, I reverted to the ones with different sizes.

• Later on, I used a mix of resized logos and old ones to make each line the same length when there are four lines, but without making each logo the same width. This gave them a staggered but justified look.
• After increasing the width of your idiagram logo, I recolored the white part to better show the beveled edges.

Depending on the display/window width, the four topics with an image either display as 4x1, 2x2 or 3+1. In the first two cases the program logos are tiled to approximately the sam size as one of the other images (which is OK), but in the latter case they are displayed side by side, and because that doesn't fit, displayed as rows of 6 + 2 (messy).

I tried using flexboxes to get the one alternative I would consider better, but I couldn't get it to work. I wanted to evenly split them on two lines with the logos spread out across the width of the page, but all I could do is split them into 4+4 all on the left side. So, I reverted it back. For now, the logos are grouped into pairs that must be on the same line. That's why you'll get 6+2 instead of 7+1.

• However, I did adjust the flex-basis of the DIVs and got some screen sizes where all eight logos appear on a single line.
• I later added some synchronized media queries to keep the logos on a single line for the 3+1 pattern by allowing them to resize. On both Firefox and Edge, this seems to work correctly without the logos stacking into a block when three images are above them.

I have picture of my Shatranj board and pieces that may interest you. Just to see how to upload. Or I send by PM.

We don't have a PM system in place. To upload it, you can go to your personal information page, then select "Upload or Manage Files" from the Edit menu. I believe you're familiar with how that works from uploading images for your pages.

I have now managed to use @container queries to get the logos for game software and web servers to increase in size to fill available space when there is some. This should put the space they take up on par with the preceding images. However, @container queries are a new web technology, and it may not be available on older mobile devices whose OS can no longer be updated. For desktops, though, you should be able to run a browser capable of handling them. For example, @container queries do not work on my iPad 2, and in landscape mode, the logos show up in a 3/3/2 pattern instead of 2/2/2/2.

I have picture of my Shatranj board and pieces that may interest you.

I got them from you by email. I uploaded smaller versions and tried them out on a test page, but I don't think I'll use them.

I didn't know I could upload on that page. Good. 

(I remove the photo having got a very bad private comment about this by an editor. I just wanted to help, forget it)

Does anyone recognize the Chess set used for the Chess photo on this page? Since my mother picked it up at a yard sale for me, I don't have any information on it. It is a medieval fantasy themed set with Wizards for Bishops and Dragons for Knights. I borrowed the board from another set.

The randgame.php script will now send you to a page's canonical URL instead of to a semantic URL with /page/ as the directory. When you do enter an URL with the /page/ directory, it will also send you to the canonical URL for the page, and when there is none, it will run the 404.php script. Note that these are two separate changes, as the randgame.php script will send you straight to the canonical URL without sending you to the /page/ URL first.

I also changed the ItemID for the home page from HomepageofTheChe to Homepage, and I made the appropriate corrections in the database and files where the old ItemID appeared.

I added a special media query to this page to recognize the browser available on the Kindle. Recent Kindles have a 300ppi screen, which results in displaying 300 pixels as an inch. Since most screens would display 300 pixels in a larger physical size, this can lead to images and text being too small in the Kindle browser. While it's Article mode can make a page more readable, it's best to not make readers need to rely on it. The query checks whether there are lots of pixels on a small screen. The idea is to check that the width is at least the width in pixels of the 6 inch Paperwhite and no more than the width of the 10.2 inch Scribe in inches. With some margin for error, the query looks like this:

@media (min-width: 1060px) and (max-width: 7in) {
}

Besides the size issue, the Kindle browser has hardly been updated in years, and it does not support many features that have become commonly supported in other browsers. For example, this page uses a flex display, but since the Kindle browers do not support this, I have provided some fallback CSS for putting some sections in columns.

The whole site should now appear at a more normal size in the Kindle browser, because I used the @media query described earlier to zoom the contents by a factor of 2 in Kindles.

It seems that the script for editing a page's index information is a bit broken. For example, I am trying to check the fields 2d and Shogi-based for MSshuka and MPshuka because I forgot to do so when initially creating them, but every time I try to do so, it doesn't work. This is the case even if I delete them and restore them afterwards. Any help would be greatly appreciated.

Edit: I thought I'd create a page for Honno Shuka (Shuka + 1 Chu Shogi Queen, placed halfway b/w the Bishop and Rook at setup), which bridges the gap between Shuka and Shosu Shogi, before deciding that the game should be kept under Shuka's lore section. However, now that I am trying to delete MShonnoshuka, I am having the same problem that I encountered when I accidentally made MSshoka instead of MSshuka. Namely, MShonnoshuka is still in the database, but the database has been tricked into thinking MShonnoshuka has been deleted.

Since editors use some scripts that other members do not, this might be a script I do not use frequently. What is the URL of the script that is not working right for you?

It is the "Edit Index Information" script in the Edit tab in the top menu.

Edit: I've decided to change the name of Shuka to Seireigi.

The Edit Index Information script is working now.

It seems MShonnoshuka has not been fully deleted. When I changed Seireigi's name from Shuka, I tried to delete MShonnoshuka, but it seems that the page hasn't been fully deleted (probably because I clicked "Delete This Submission" too quickly). The record of it is still in the database, but the database thinks it has been deleted, as shown below. I would like this record to be fully deleted so it doesn't cause problems in the future.

404 Error from https://www.chessvariants.com/rules/honnoshuka

Now that you mention CSS: it seems that old HTML pages are somehow missing a link to a standard style file. Pages like this one do not display the text box with the featured variant on a black background, and also use different header styles.

Now that you mention CSS: it seems that old HTML pages are somehow missing a link to a standard style file. Pages like this one do not display the text box with the featured variant on a black background, and also use different header styles.

I fix them as I notice them. While most just have the link to the CSS script missing, this one had it with LINK spelled as LINN.

Ah, so I was very unlucky to pick this page for cloning, to make the new Play-Test Applet.

Since I am systematically editing many of these pages for putting Interactive Diagrams in them, and know which CSS is responsible, I will also keep an open eye for these kind of problems.

I noticed a bug with the matedbypawn subroutine in the fairyshogi include file.

Specifically, if the King is unable to move anywhere (due to moving into check or otherwise), the subroutine thinks that a Pawn cannot be dropped to check the King, even if this does not actually result in mate.

Here's an example of the bug from Shogi:

1. p 5g-5f
1... P 5c-5d
2. g 4i-4h
2... G 6a-6b
3. g 4h-5g
3... G 6b-5c
4. g 5g-4f
4... G 5c-6d
5. g 4f-4e
5... G 6d-6e
6. g 4e-5d
6... G 6e-5f
7. g 5d-5c
7... G 5f-5g
8. s 3i-3h
8... S 7a-7b
9. s 3h-4i
9... S 7b-6a // After this move, Pawn drop checks are not marked as legal, even though 3 pieces can capture the checking Pawn afterward.

Okay, that's fixed. One part was using the wrong variable name for the position the Pawn was on.

Would like to enter a variant in the system. Note: If there are more than 6 entries, other entries must be deleted. Deletion does not work - empty pages cannot be saved.

The matter is not very user friendly, what can be done?

Thanks. I also saw that the fairyshogi Dragon_Horse-Desc function/variable was missing.

@Fergus
It seems that I can only accumulate 6 unpublished variants. Then the message comes that for more variants unpublished variants must be deleted first.

When I try, the message appears that only variants without content can be deleted. If I delete the content (including images), then the variants cannot be saved due to lack of content.

This is quite frustrating.

Can you please tell me how to delete unpublished (or published) variants. Thank you very much.
 

It seems that I can only accumulate 6 unpublished variants. Then the message comes that for more variants unpublished variants must be deleted first.

I'm facing a similar difficulty, except that I haven't tried deleting any of my variants (the frustration of which I can understand). In my case I'm just waiting for the editors to get around to approving existing pages before I finish the remaining 3 pages of the Icon Clearinghouse (plus the additional SVG edition), the Vanguard Chess GC page, and other CVs I have rattling around in my skull (or, in one case, on my hard drive). Said approval can take a while, so I'm just gonna be patient.

I may have overlooked some things. But in the explanations I did not find any indications for the deletion of an (unpublished) variant.

If I delete the content (including images), then the variants cannot be saved due to lack of content.

I have now changed that. It will now allow you to save a page without any content, and in case this was by accident, it will tell you how to restore the previous version.

Thanks for the response.

But perhaps for clarification: I would like to delete an unpublished variant.

When I try to do that I get the following error message: 'As a safety precaution, you may not use this script to delete a submission unless it is empty. Delete its content first if you mean to delete it'.

The page is without content and deleting it does not work. Unfortunately, nothing has changed here yet.
 

In the test I ran, I created an unpublished page, added some content, removed the content, restored the previous revision, removed the content again, and deleted the page. So, things should be working. Have you made sure that your page contains no whitespace? What page is it you're trying to delete?

I have identified the page you are trying to delete. What I'll try is copying your encoded password from the database, changing your password so that I can log in as you, see what's going on, fix any problem, and then copy your encoded password back into the database so that your password is the same as before. If that doesn't work, you can contact me by email to give you a new password.

As I surmised, the problem was some extra whitespace on your page. I dealt with this by changing the code to trim off whitespace before testing whether each section was empty. With that change, I deleted the page while signed in as you. I then copied your original encoded password back to the database.

Brilliant, thank you Fergus.
 

@Fergus
I have the following problem:

When a page is created under 'Post Your Own Game' and a name is assigned to the variant in the 'Index Information', it seems that the name cannot be changed - at least I haven't found a solution for this.

What I mean is that if there is a working title, a new name in the 'Index Information' in the 'Item Name' field is not taken over. This means that the outdated working title appears unchanged in the 'Your Unpublished Submissions' and in the list of published variants.

Is there a solution for this that can be done not only by the editors?

Is there a solution for this that can be done not only by the editors?

Not at present, as it involves a search and replace through multiple tables of the database.

Too bad. This means that authors need to think carefully about what to name their variant.

Should perhaps be communicated somewhere.

In my case it means that a variant cannot be published because of a name similarity.

Kind of dumb.

This means that authors need to think carefully about what to name their variant.

Also type carefully. I deleted Opaki Chess, and will replace it later with Okapi Chess.

The deletion and reinstallation of a variant cannot be the solution for this - or can it?

I think it's the only one currently available to users. (In most cases, I'd copy-and-paste the old one before deleting it, though.)

Okay, looks like this.
But it should reveal an optimization point of the system. That's what we're here for.
Isn't it?

Printing the time a comment was posted is a very good idea. Also printing the time of the comment it was a reply to less so. Having to identify the comment by comparing time strings is cumbersome. It would be better to have a link to the comment (e.g. displaying it in 'View' mode) that people could simply click; this will then show its own time of posting anyway.

You must not have noticed that the time of the comment a comment is replying to is in fact linked to that comment. I am using the time to identify it in the link text, because when you're already looking at both comments, you can tell that you are by seeing that the time of the earlier comment matches the time of the one the later one is a reply to.

I must admit I had not tried that. But the main thing that annoys me is that the header becomes so long by displaying two time/date strings in it that extends over two lines at the screen width I am using:

Isn't it possible to use another text for that link than the time/date? Like "reply to a comment of Fergus Duniho"

What I've done is leave out date text that can be inferred if left out. If the reply was posted on the current day, the day is left out. Otherwise, if the reply was posted in the current year, the year is left out. If the replied-to comment was posted the same day as the reply, its day is left out. Otherwise, if it was posted the same year, its year is left out. Finally, the timezone gets left off the time for the replied-to comment unless it is different. Since the timezone is based on the location of the member who is signed in or set to UTC if no one is signed in, these will be different only for shifts between regular time and daylight savings time. Since we just shifted to regular time in the US on Sunday, I am seeing EST on the most recent comments and EDT on comments from last week.

To the editors: I would like to present further variants. Unfortunately I can't, as only a limited number of suggestions are possible.

It would therefore be nice if a few of my suggestions could be published - or rejected.

On this occasion: Why is the number of unpublished suggestions limited?

I'm pretty sure the reason for the limitation is to keep someone (like me) from posting more variants and other articles at a time that they could handle.

(That said, I'd really like to see at least one more of my variants -- ideally, Zwangkrieg -- approved so I can continue my work here....)

Sorry Bob, I can't follow your argument.

When the editors decide to publish variants is beyond our control. That could be tomorrow or in three months' time.

They (the editors) can feel comfortable to take action. But why should I be prevented from continuing to be creative?

I did not invent this, but it seems a good way of distributing the editor's reviewing efforts more equally between various contributors. If one person could create an unlimited number of submissions in a short time, submissions by others made after that mighthave to wait unreasonably long to get reviewed.

Dear H.G. This is only true if the authors are very unevenly creative, because only then can you level out an issue. But who publishes a countless number of variants?

All in all, the matter is not evenly distributed; the editors are the tug on the scales.

O.K., if you say that these are the general conditions, then any discussion is superfluous. But you don't seriously want to take such a one-sided view.

I'm pretty sure the reason for the limitation is to keep someone (like me) from posting more variants and other articles at a time that they could handle.

Do you mean "than they could handle"?

Well, I would call submitting 5 contributions where others only submit one reasonably uneven.

They (the editors) can feel comfortable to take action. But why should I be prevented from continuing to be creative?

The limits are in place to keep people from submitting more than we can handle. However, the limits do grow when more of your submissions have been accepted. This is because new contributors need a training time for learning how to write a rules article properly. Also, we want to encourage authors to do each page well before continuing onto the next.

That was mainly what I was trying to get at (and communicated rather poorly, surprisingly so for a lifelong writer).

Your argument is - with respect - illogical. Whether authors submit more or less has no effect on the capacity of the editors. The editors work off what they can . If authors submit more, then they just have to wait longer. But at least they can continue working.

While I do somewhat defend the policy, Gerd's argument isn't without merit. It'd be very nice if we could have "under construction" pages that only the creator could see, for experimenting, spitballing, long-term construction, storing up extra submissions, and such. (I would've preferred to attempt the Icon Clearinghouse that way; it'd be done by now, and waiting in the wings, if that had been the case.)

I suggest that the number of proposals be increased to 10 or 15.

Gerd, The limitation is increased once more articles are accepted!

The information does not help: no indication of quantity and time. It can't just be a matter of waiting. A little too much randomness.

Surely a pragmatic solution must be possible?
 

At one point the limit on submitted as yet unpublished items was set at 9, I recall. Now it is apparently down to 6.

Over a long time I saved up 25 CV ideas (besides not yet writing down 9 rules pages I hoped to make sometime, to match with 9 preset launch pages of mine that had no rules page). What I did was have diagrams for each of the 25, found in comment threads - knowing the dates of the comments I then listed them all in the Notes section of a page for one of my less good CVs (I thought), squirrelling them away for if I ever got around to submitting them as full-blown rules pages.

Incidentally, I also found submissions have taken a long while to get accepted for quite a while now it seems, maybe because editors have less spare time or there are less active ones(?); also, I vaguely recall some changes to the way rules pages are submitted were made several years back, which I thought might make things harder for me, as I'm not so good with modern computers and, e.g., HTML, still.

Where are we now? Will everything stay the same? Or are there partial improvements for authors?

I'm wondering if we should relax our standards, let in anything that looks Chess variant related even if it might be flawed, and focus our efforts more on gatekeeping and curation than on working closely with authors to make better pages. We have only a few editors, and I know I don't have the time or inclination to carefully go over every submission. I'm really much more interested in working on my own content than I am in editing that of others. But what do other people think?

I think I made my thoughts reasonably clear earlier when I asked for "notebook"/"under construction" pages. If you make no other changes, that much would be very welcome to me.

If you do throw the floodgates open, I think it'd be a good idea to have some sort of perk (something small, like a star on the Index) for pages that have gone through an editorial review, or at least a reminder that such review is available for those who want it. I know that editors (and others) have caught many flaws in games I've submitted, and those games are better for it.

EDIT: I should also point out that many older pages, looking quite useful otherwise, are in desperate need of updates to become more legible.

If limiting the number of variants to be submitted were really a measure to improve quality, then it would make more sense to reduce the number. But that would have a demotivating effect.

But I think Kevin's suggestion - if I understood him correctly - is a very good one, namely to set up a kind of test page where interactive diagrams can be stored under 'Notes' in order to save them for later. There you can test your variants and compare your ideas. In my opinion a good solution.

I understand Fergus's interrogation. It is a large burden put on the editors to check out all the contributions. Of course, another way of doing it that could be faster and save time for the editors would be good.

That being said I am grateful to the editors who reviewed my published pages in the past, because they have detected errors, or they have simply helped me to improve my text.

There is also the need to stop publications that would not be suitable at all.

I don't know, maybe if a submitted page (so, when an author declares the page is ready) could be first sent to a kind of "reserve" space (a kind of "buffer"), visible by anyone. Then, if no negative comments is sent by anyone within 1 or 2 months, the page is automatically sent to the "normal" space, otherwise the editors are alerted and they only have to watch those pages only before releasing them. Would it be going in the right direction?

This is the well-known problem of claim and reality not matching. Structuring a page according to 'Introduction', 'Setup', 'Pieces', 'Rules' etc. does not seem to solve the problem.

The problem of a small number of editors and a large number of authors is inherent in the system and can hardly be solved either. Whether a kind of 'purgatory' could be the solution here, dear Jean-Louis, is again a question of internal organization.

In my view, interactive diagrams and their moving diagrams could contribute to solving the problem. On such a basis, it should be much easier for editors to revise proposals.

I think it could be communicated that proposals based on interactive diagrams are preferred for review. And editors could use the time saved in this way more for proposals without such diagrams.

Could make the problem easier.

In my view, interactive diagrams and their moving diagrams could contribute to solving the problem. On such a basis, it should be much easier for editors to revise proposals.

On this topic, I do think that a section dedicated to an "Interactive Diagram" (and forced into HTML mode, if possible) would solve a few problems that I've had with editing games that already have them.

Interesting but I wouldn't support this. First, not everyone is able to code an ID. Even me who has done some of them and who is not unfamiliar with several programs, it requires me a special effort to write down one because I'm not doing it every day. Second, I think that not every CV can me rendered by an ID: a CV can be multiplayer (>2), multi-turns, 3D and more, having unusual board patterning, etc.

A submission form with a diagram section already exists. You would have to typeits URL inthe addressbar to get there, though. I will see if I can still find what that was.

Dang it, these things need to be easier to find. I still have to go through the alphabetical index to get to the Betza page, the Play-Test Applet, and the Diagram Editor; I'd love to be able to mark those and other pages the same way I can mark Favorite pages on my personalized menu. (That, or have a "Tools" submenu in the Explore or Help items.)

I think it would be good to have a 'Tools' item on the main menu bar, where you could select the pages you mention, plus the Checkmating Applets.

The link for the submission forms that includes an aid for including a diagram is

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

The first form is the same as always, but it brings you to the enhanced form if you press 'Step 2'. The aid writes the HTML for the diagram in the Setup text section, where you could further edit it, if so desired.

I think it would be good to have a 'Tools' item on the main menu bar, where you could select the pages you mention, plus the Checkmating Applets.

To be clear, I was referring to the Diagram Editor with scalable graphics, whereas most people here are more familiar with the Diagram Designer.

The link for the submission forms that includes an aid for including a diagram is

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

Thanks. That'll be handy if I can still find it once I'm able to submit new variants again. (Still waiting for some approvals....)

I have made the Tools menu, but I have not added the Diagram Editor with Scalable Graphics, because its image links are broken. Like it does in Firefox, the Tools menu appears to the left of the Help menu.

So that we can more easily look up the submissions of individual authors, I have added an Unpublished Submissions link to the person information page. It should show up only for authors with unpublished submissions.

Gerd Degens wrote:

I think it could be communicated that proposals based on interactive diagrams are preferred for review. And editors could use the time saved in this way more for proposals without such diagrams.

Jean-Louis Cazaux replied:

Interesting but I wouldn't support this. First, not everyone is able to code an ID. Even me who has done some of them and who is not unfamiliar with several programs, it requires me a special effort to write down one because I'm not doing it every day. Second, I think that not every CV can me rendered by an ID: a CV can be multiplayer (>2), multi-turns, 3D and more, having unusual board patterning, etc.

For these reasons, I wouldn't make it a requirement. However, we could communicate that programming a game, whether by Interactive Diagram, Game Courier, Zillions-of-Games, etc, can speed up the review process, because doing this requires the author to think through the rules more clearly and thoroughly, and this in turn can help the author explain the game more clearly and thoroughly. And in the event that it does not, we can at least turn to the programmed version to answer remaining questions about the rules.

Nice! Thanks, Fergus!

Hopefully H.G. will be able to figure out something to fix the DESG for us before too long. (Or, I'll figure out some way to put an easy-to-find link somewhere....)

However, we could communicate that programming a game, whether by Interactive Diagram, Game Courier, Zillions-of-Games, etc, can speed up the review process, because... .

That was exactly my intention. 

I would like to go a step further and suggest adding a marker to the submissions that have an interactive diagram. This could be done in the index information by including an additional selection field. It would be conceivable to mark the title of the submission with an '*' ('ID' would be nice, but..).

The counter-argument is easy to imagine, namely that submissions without a marker would be moved to the back. On the other hand, the existence of interactive diagrams is intended to speed up the review process. This would then also benefit the other suggestions.

While I am not against encouraging the inclusion of Interactive Diagrams, and providing better support for making this easier for non-technical users, we should keep in mind that there exist variants that the ID just cannot handle. Such as those with alternative board topologies, multiple moves per turn, pieces that can split up. It seems unfair to discriminate against such variants by delaying their publication.

It seems unfair to discriminate against such variants by delaying their publication.

It makes no sense to 'deny' the existence of Interactive Diagrams just because there is a very vague assumption that the publication of others will be delayed.

It would just be another item that is asked for in the Index Informtion. And I don't think that has anything to do with discrimination and unfairness.

It seems unfair to discriminate against such variants by delaying their publication.

It's not about deliberately delaying the publication of variants without Interactive Diagrams. It's simply that one that has been programmed in some way, which doesn't have to be an Interactive Diagram, has advantages that can speed up the review process. One advantage is that the author has thought through the rules well enough to represent them as a program, which should make it easier for him to explain the rules and for us to figure out any details he left unexplained. Another is that it demonstrates the playability of the game. However, as an editor yourself, you are free to give more attention to submissions that are disadvantaged by not being programmed.

One follow-up question:

Will there be an indicator for existing Interactive Diagrams (Game Courier, Zillion of Games etc.) - or are there other reasons against it?

I think it will be easy for an experienced programmer to add a feature to the index information that is queried when a new variant is created. Wouldn't that make sense?

I think the time is ripe for this.

- - - - - - - - - - CRITICAL BUG NOTICE - - - - - - - - - -

Game Courier is having serious server-side issues when loading presets with fairychess.txt-like code.

When I went to move in my Dai Seireigi game with Bob Greenwade, It gave the following error, despite the fact that I haven't changed anything in the code (which was working properly before).

The piece p is undefined.

Since this is not a preview, something may have gone wrong with the code. For diagnostic purposes, the last move played was

1. p 8k-8j

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

// Test of new rule-enforcing Dai Seireigi preset
1. p 8k-8j 
1... P 8e-8f 
2. i 9l-9j 
2... I 7d-7f 
3. p 13k-13j

Furthermore, some presets that use fairychess.txt or fairyshogi,txt are struggling to even show up on-screen, despite the fact that they were not changed in any way before the bug occured. For example:

• Chess
• Shogi
• Seireigi

I have a similar bug interrupting a Game I'm playing on Devingt Chess:

https://www.chessvariants.com/play/pbm/play.php?game=Devingt+Chess&log=nanil618-timurthelenk-2023-314-626&userid=timurthelenk

I don't know what to do.

PLEASE HELP

This is the message:

The piece P is undefined.

Since this is not a preview, something may have gone wrong with the code. For diagnostic purposes, the last move played was

1. P f2-f5

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

1. P f2-f5 1... s g10-h7
2. P h2-h3 2... p e9-e6
3. P g2-g4 3... p d9-d7
4. S g1-f4 4... p g9-g6
5. P e2-e4 5... p a9-a6
6. S d1-c4 6... p c9-c8
7. S f4-g7 7... q f10-g9
8. S g7-h10 8... q g9-h10

I have a similar bug interrupting a Game I'm playing on Devingt Chess:

It looks like this was caused by a bug fix I made earlier today. It's temporarily back to how it was, but I will have to find a way to fix both bugs.

Maybe my earlier bugfix had a typo, because I inserted the same bugfix after writing some diagnostic code, and your Devingt Chess game still worked.

A few days ago, Amazon updated the browser on the Kindle Scribe and maybe other Kindle browsers. It has much better support for HTML5 and CSS3 than it previously had. So, I tested it here. Game Courier and Interactive Diagrams work, but Jocly would not. Even though the Scribe is a mobile device, Game Courier is not increasing the size of the board to fit the screen. The informational emojis that appear before some names in comments do not show up properly. Signing in works, but it does not retain the cookie storing my userid. So, instead of being able to sign in with the menu, I have to go to the login page each time. Fonts appear to be loading correctly. I checked the serif text for the distinctive Q used by Literata, the sans-serif text for the open g used by Noto Sans, and in general how well the text on my Scribe matched the same text on my desktop, and by all indications, it is using the correct fonts. I cannot change the font size in the Kindle browser, but at least it is large enough for me to read. I'm trying to use Article mode on the Game Courier Developer's Guide, but it's taking its time or not working. I then tried Hectochess, but it wasn't working quickly enough. Then I tried Xiangqi, which is shorter than the Developer's Guide and has no interactive diagram, and it worked. The text is in Helvetica at about the same size it was before with wide margins. In the past, Article mode used Caecilia at a larger size. Images and Chinese characters are showing up, but no images are side-by-side. For some unknown reason, it is displaying the contents of the page twice in Article mode. Looking at Xiangqi in regular mode, the embedded video displays the message "Your browser can't play this video." This is to be expected, since an e-ink device is not well-suited for video, and Kindles are not very high powered devices.

The problem is solved for my game. Thank you Fergus.

Sadly, red is showing up as white on my Kindle Scribe's browser. So, I'm going to have to recolor some pieces.

I have found a solution to the red pieces showing up as white on my Kindle without recoloring any image files. I first got it to work with Game Courier and the Diagram Designer, and now it also works with Interactive Diagrams. However, Interactive Diagrams will have to be edited individually to apply the solution.

The general solution tests whether the User Agent string matches a brand name of some of the most popular ereading devices. In my case, I have confirmed that my Kindle has "Kindle" in the User Agent string, and my Likebook Mars has "Likebook" in it, and tests with Game Courier show that it is correctly recognizing these devices. When it displays a piece whose file name begins with "b" or "B" on a recognized eink device, it changes the piece color to #808080. This is a medium grey that works about equally well on the Kindle, which displays #FF0000 as white, and my Likebook Mars, which displays #FF0000 as black.

On the Ultima page, I have changed the value of graphDir for the Abstract set to '/play/pbm/showpiece.php?originalcolor=ff0000&image=/graphics.dir/abstract/new/'. The originalcolor value is required for recoloring a piece, but this value is true only for the black pieces. With the wrong value for the white pieces, they simply won't be recolored. The image value is the actual directory where the images are found. It comes at the end, because this will be concatenated with the prefix and the rest of the file name to form the complete file name.

Incidentally, my fitness tracking watch told me that I had completed 10,000 steps today while sitting here typing. Maybe it interpreted typing action as walking.

Well, this problem seems specific to the Abstract set, as I am not aware of any other set that uses bright red for piece coloring. And I don't recall having ever used Abstract in an Interactive Diagram. When I am transforming the main diagram in an article to an interactive one I tend to skip those articles that use Abstract, because there are no anti-aliased images available for that yet. So it seems more efficient to postpone these until there are.

The Ultima Diagram initially is not in Abstract either, and it is only due to the theme buttons that it can be switched to using Abstract. So I don't think there is any problem there, or at worst that the problem is very minor: there might be one or two IDs that I overlooked somewhere on this website, and people viewing those with a new model Kindle would not be able to distinguish the black pieces from the white. This seems unlikely to happen ever, but if it does, they could complain, and we know how to fix it.

this problem seems specific to the Abstract set

It also extends to the Magnetic and Motif sets. Magnetic uses a different shade of red, but it would still appear as white on my Scribe. Today I made the solution more general. I programmed showpiece.php to know the original color for images in certain known sets. So, originalcolor is no longer needed in the query string, and the showpiece.php script can be used with most any set in an Interactive Diagram by appending '/play/pbm/showpiece.php?image=' at the front of a graphDir value. As a demonstration, and to test things until they worked, I did this for every set for Chess.

Additionally, I added the parameters of black and white, which are used to specify a particular color to use for black or white pieces respectively. This allows a single graphDir value to separately define the color to be used for each side. To enable different colored SVG pieces to be used, it also converts an SVG filename beginning with b to one beginning with w. This lets it tell that the piece should be black while enabling it to use the w*.svg file that actually exists. This eliminates the need to create PNG copies of SVG files, because they can now be used directly in Interactive Diagrams for both sides, so long as the showpiece.php script is being used to display and color them. As a demonstration of this, the Chess page has the Alfaerie SVG set. You should notice this is subtly different from the Alfaerie set, which uses PNG files.

This script starts to evolve into nearly the same thing as the fen2.cgi piece renderer on my website, which we never managed to port to CVP. Can it also render the SVG in different sizes? Perhaps I could make the 'Diagram Editor with Scalable Graphics' use that script, to make it independent of my website.

Beware that some of the SVG sets have different images for white and black pieces. These would be needed if you want truly black pieces; filling the white (outline) pieces with black would not work, because the inside details would become invisble. For any other color the outline pieces look better.

This script starts to evolve into nearly the same thing as the fen2.cgi piece renderer on my website,

I created showpiece.php to support Game Courier, and I recently added some new parameters to support Interactive Diagrams. I think fen2.cgi still has many features it does not have.

which we never managed to port to CVP.

I could try to compile it here if you give me the source code.

Can it also render the SVG in different sizes?

No, is there a use for that? I know you used to make PNG versions of SVG images at smaller sizes, but showpiece.php will output an SVG if that is what the original image was, and SVG images can resize to fit the container. So, they don't have to be resized ahead of time. Since Game Courier will resize boards, there might be a use for resizing GIF or PNG images, but that might interfere with the transparent part, and HTML or CSS can already resize the display of the image.

Perhaps I could make the 'Diagram Editor with Scalable Graphics' use that script, to make it independent of my website.

Maybe, but it will depend on what that needs it to do.

Beware that some of the SVG sets have different images for white and black pieces.

Game Courier handles this by assigning different images in a set file, and showpiece.php can make use of set files. I could modify it to use set files even with Interactive Diagrams. Do Interactive Diagrams have any way of their own to indicate different images for black and white pieces besides a different prefix?

These would be needed if you want truly black pieces; filling the white (outline) pieces with black would not work, because the inside details would become invisble.

I normally color black pieces with a lighter color than actual black. As far as I know, the SVG pieces on this site are all white (outline) pieces. So, showpiece.php just loads a w*.svg file when given a b*.svg file name for the image parameter. When using a set, it would just load whatever file was named.

I could try to compile it here if you give me the source code.

Well, we already tried that, and after an uphill battle even succeeded, and the resulting binary is even on the CVP server, as public_html/index/fen2.cgi . But it appears we ran into a problem with the server refusing to execute the resulting CGI file when accessed from the web; see the discussion here.

Do Interactive Diagrams have any way of their own to indicate different images for black and white pieces besides a different prefix?

No, they use the files that start with the blackPrefix for black. It is up to the set designer what image these contain.

As far as I know, the SVG pieces on this site are all white (outline) pieces. So, showpiece.php just loads a w*.svg file when given a b*.svg file name for the image parameter.

Well, the XBoard set has b*.svg for all pieces, and Magnetic and Motif has b*.svg for the orthodox pieces. The unorthodox pieces in the latter two are basically just cut & paste jobs on pairs of orthodox pieces, but I never got to do those jobs on the black pieces. In theory these could be easily done, though, if there would be any use for those.

As it is, showpiece.php would never allow you to use the black XBoard pieces, which seems a pity. Perhaps it could be made to use b*.svg instead of a*.svg, when it is present, and the requested color is very dark (e.g. all colors < 0x10)?