Comments/Ratings for a Single Item

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

Regarding the issue of black pieces losing their detail, I've sometimes seen (in contexts other than chess) black images with white outlines, so I wonder if it would be possible to reverse the color of the outlines, or even have something like an outlineColor variable? (Or perhaps blackOutline and whiteOutline.) It's something that probably would only work on SVG sets, but it's a thought.

Well, the XBoard set has b.svg for all pieces, and Magnetic and Motif has b.svg for the orthodox pieces.

When I made my original Magnetic and Motif pieces, I used only the white pieces from the fonts, and I colored them differently. These solid black pieces made from the solid black pieces in the font are not what I originally intended. So, the showpiece.php script should be able to avoid using them.

As it is, showpiece.php would never allow you to use the black XBoard pieces, which seems a pity.

To accommodate their use, I have added some new parameters and some new conditions on whether a b*.svg gets renamed to a w*.svg piece. The two new parameters are originalblack and originalwhite. These are variables that sometimes get assigned in a set file. They are like originalcolor, but for only one side each. When originalcolor has not been set, and one of these has, the value of the appropriate one will be assigned to originalcolor. The new conditions for changing the file name are that originalblack is an empty string, and black is not. If originalblack is not empty, then it's expected that there are black pieces available for recoloring, and if black is empty, then it's expected that there are black pieces that will appear in their original color. Also, this change only happens when image has been passed a value. If someone indicates a piece with values for set and piece, it simply uses the file named in the set file. So, this doesn't interfere with the use of sets.

I have demonstrated this by adding an Xboard set to the Interactive Diagram on the Chess page. However, there is one issue with your Xboard pieces. They have fixed height and width values, and to resize properly to the dimensions of the container, these should be set to 100% instead. I could do this with sed like I did with Bob Greenwade's pieces, or I could leave it to you.

To accommodate the use of Game Courier sets with Interactive Diagrams, I have added code to modify the value of piece if the provided value is not already a key of the $pieces array. If it begins with w or W, it loses the first letter and is set to uppercase. If it begins with b or B, it loses the first letter and is set to lowercase. In each case, it gets the extension chopped off.

Here's an example of a Chess Interactive Diagram using Game Courier sets to identify piece images.

When JavaScript is running, this static image will be replaced with an Interactive Diagram

I've sometimes seen (in contexts other than chess) black images with white outlines, so I wonder if it would be possible to reverse the color of the outlines, or even have something like an outlineColor variable?

I see no useful purpose behind this. Black pieces with white outlines are ugly.

Regarding the issue of black pieces losing their detail, I've sometimes seen (in contexts other than chess) black images with white outlines, so I wonder if it would be possible to reverse the color of the outlines, or even have something like an outlineColor variable? (Or perhaps blackOutline and whiteOutline.) It's something that probably would only work on SVG sets, but it's a thought.

I agree with Fergus that this is ugly, and should not be supported. The XBoard black pieces are designed with white details inside tof them, however. If you would want to recolor those, it is the black part that should be recolored, not the white. Usually any color that can be distinguished from black gives much better looking pieces if you ise the outline pieces.

I have some new set files for the Seireigi presets available for Game Courier. You can find them here.

I have added a new parameter to listcomments.php called for. This parameter takes a PersonID, and it returns comments for the person identified. These include the following:

• Comments posted on any page for which the person is listed as an author, an inventor, or an editor.
• Any comment posted to his profile page.
• Any comment where the person is tagged by his PersonID or UserID with an @ sign in front of it or referred to by his full name.
• Any comment that is a reply to one of his.

To make the last one possible, I added a new column to the Comment table, called ParentName, which includes the Name or PersonID of the person being replied to. This is to keep the script from needing to do some kind of complicated query to get this information. However, I have not updated the Comment table with values for past comments. So, until I do that, it will only work with new comments.

When you are logged in, you will find a new menu item in the menu headed by your name. It is called "Comments for You" and will use this new parameter for listcomments.php with your PersonID. The main purpose behind this new feature is to make communication with contributors easier. If you haven't been by in a while, you will now have one place to go to catch up on comments requiring your attention.

I have modified the Categories in the Item table to include a new UsualEquipment category and I changed all the Usual- categories to Diff- categories, making appropriate changes in scripts dealing with categories. If I have missed anything, let me know.

While most of the former Usual- categories have application to other Chess variants, some do not. Diff-Setup is mainly suitable for Usual Equipment variants with different setups, though it may also be applicable to games with unusual ways of setting up the game, such as Capablanca Random Chess. I think it would be stretching it too far to use it for any game on a different board with a different setup than Chess. Diff-Modest may apply just to usual equipment games, since the Modest category was created with those in mind. Since this category has fuzzy boundaries, I'm wondering if we might get rid of it. I'm thinking of merging Diff-Other with the Other category.

Some searches that were previously to Usual- categories have been converted to searches for UsualEquipment AND the corresponding Diff- category, and that seems to be working out.

Fergus, such a change should really be done after some time to discuss all the ramifications, and making all the code changes at once.

Diff-setup, diff-move, diff-capture all only really make sense in the context of usual-ish equipment, I think, along the lines of what you mentioned for setup.

I think Usual-Other should just become Usual; it's not necessarily "other" in the (vague) way the Other category is, it's just playable with the usual equipment without having fallen into one or more of the other Usual* categories.

Modest should be its own category. They will be a subset of Usual, at least until someone gives a convincing argument about a variant that should violate that pattern. I don't think it should be removed: it has useful signal, even if fuzzy, and many of the other categories are similarly fuzzy anyway (such is just the nature of categorizing [chess variants]).

Diff-setup, diff-move, diff-capture all only really make sense in the context of usual-ish equipment, I think, along the lines of what you mentioned for setup.

To check on which Usual- categories have been used by games that do not use the Usual Equipment, I added the ability to search for rows that do not have a specified category. This involves preceding the category name with !, which is used for negation is some programming languages. Here are links that search for the category without including anything in the UsualEquipment category. I have removed the heading from each link so that it will display the SQL code instead.

• Capturing in a Different Way
• Different Opening Setups
• Rules About the Board
• Differently Moving Pieces
• Moving Your Opponent's Pieces
• Multiple Move Variants
• Winning in a Different Way
• Other Variants
• Modest Variants

Every one of these search links produced results, though I think there are some that should be listed as UsualEquipment. I will look into whether some have the wrong categories set or if I made an error in selecting which ones to add the UsualEquipment category to.

[UPDATE: The reason some Items were missed was because several had not checked the 2d category. So, I modified my selection to exclude the 1d and 3d categories and added the 2d and UsualEquipment categories to any that turned up. Also, before doing the update, I scanned for the 4d category and didn't see it turn up. Even with this update made, though, every search link still has results.]

'Different Opening Setup' is not a category that would make any sense other than in combination with 'Usual Equipment'. OTOH 'Rules About the Board' is a bit unspecific if it can also apply to a non-standard 8x8 board. Boards can use different regular tilings (e.g. hex variants), have strangely shaped edges (e.g. Balbo's Chess), or a different global topology (e.g. Cylinder Chess), irregular tilings, multiple layers (e.g. Alice Chess), different dimensionality (e.g. Raumschach), or be simply large or small compared to 8x8.

Another category that seems to be missing is variants with Neutral Pieces.

Another category that seems to be missing is variants with Neutral Pieces.

Yes, I want to talk about categories that are still missing. Games with pieces that can merge or split apart, as in Fusion Chess, is another missing category. One option would be to have a category for different rules concerning pieces, such as Diff-PieceRules, which could parallel Diff-BoardRules without being anymore specific. However, this might already overlap with Diff-Moving or Diff-Capturing.

We should be careful not to explode the list of categories, and keep tags in mind. (It would be nice to be able to sort the tag listing by count.)

The Topic Index has links to usual-equipment listings that need to be updated.

Another category that seems to be missing is variants with Neutral Pieces.

...which is something I wish the Interactive Diagrams could handle (though I mostly understand why that can't).

Yes, I want to talk about categories that are still missing. Games with pieces that can merge or split apart, as in Fusion Chess, is another missing category. One option would be to have a category for different rules concerning pieces, such as Diff-PieceRules, which could parallel Diff-BoardRules without being anymore specific. However, this might already overlap with Diff-Moving or Diff-Capturing.

Amidst all this, could there be a category for Different Promotion Rules? (Like in Short Sliders.)

Amidst all this, could there be a category for Different Promotion Rules? (Like in Short Sliders.)

What are those? What would qualify as a different promotion rule?

What would qualify as a different promotion rule?

Normal chess promotion morphs the Pawns when they reach the furthest row (8th on a standard board); anything else is "different." Some games, like Mecklenbeck Chess (origin point of the Mecklenbeck Pawn) and most if not all forms of Shogi, let the pawns promote early, on the 6th or 7th rank if not earlier. In Short Sliders (and the Leapers Who Love Them) (and probably a few others), many pieces promote by capturing enemy pieces; Short Sliders also lets pieces promote more than once.Shogi and Short Sliders are also games in which pieces other than Pawns can promote.

This category would fit Metamorph Chess and Assimilation Chess, but there is a question of how finetuned our categories should get. On the one-hand, Diff-Promotion would fit in with Diff-Moving and Diff-Capturing. But then we still have games where there is demotion, or pieces change without involving promotion or demotion, such as when a player's own pieces merge or split apart. Should these be in a separate category, or should we have a category that includes promotion, demotion, and other ways of changing pieces? Maybe something like ProteanPieces.

I think you already were putting merging/splitting into its own category, and changing in other ways (besides promotion and merging) couild be is own thing as well. At least, that's my mind; you make the decisions.