Comments/Ratings for a Single Item

I see that your HT subroutine has a line where it refers to origin and dest instead of to #from and #to. That may be where your bug lies.

I fixed most of the issues. Now the only problem that I can see is that the Heavenly Tetrarch's first burn is being rejected when it shouldn't be when the distance between the origin and destination of the first part of the move is at least 2. The problem is likely in the HT subroutine, since it controls the function definition for the second and third parts of the Tetrarch's move, but I could be wrong.

Here is the link for the preset's Edit form: Edit: Suzumu Shogi on the Chess Variants Game Courier

And here's the list of moves for which the error occured:

1. d 8k-8j 
1... D 9f-9g 
2. p 7l-7k 
2... P 10e-10f 
3. bg 6m-8k 
3... BG 11d-9f 
4. fd 7n-6k 
4... FD 10c-11f 
5. fd 6k-8i 
5... FD 11f-9h; pass 
6. fd 8i-5f; fd 5f-5e; fd 5e-4e 
6... FD 9h-12k; FD 12k-12l; FD 12l-13l 
7. fd 5f-7f; pass 
7... FD 12k-10k; pass 
8. fd 7f-7e; fd 7e-7f; fd 7f-8f 
8... FD 10k-10l; FD 10l-10k; FD 10k-9k 
9. bg 8k-15d; +bg-dest 
9... BG 9f-2m; +BG-dest 
10. dk 5n-5o 
10... DK 12c-12b 
11. cs 4o-14e; +cs-dest 
11... CS 13b-3l; +CS-dest 
12. +cs 14e-14d; +cs 14d-14e; +cs 14e-13d 
12... +CS 3l-3m; +CS 3m-3l; +CS 3l-4m 
13. +cs 14e-11b; +cs 11b-10a // <- ERROR: You may not move a +cs from 11b to 10a

This kind of thing is usually caused by a parsing error that is due to a simple syntax error. To find out what it could be, I added "list;" to the end of your Pre-Game code and clicked Run. At the end of the first listing, I got this:

907   remind "Enter third leg of move or press Pass;
gosub legalmoves2 KING 2;
continuemove;
elseif sub stalemated king:
endif;
;end;

So, it looks like your remind statement is missing a closing quotation mark. However, looking at your actual code, I don't see it missing.

I would recommend the general debugging technique of cutting or commenting out sections of code to determine which code is causing the problem. If you cut code, paste it back in before cutting more, so that you can later paste back in all that you cut out.

I guess I didn't make the link clear enough (Edit: Suzumu Shogi on the Chess Variants Game Courier). What I have should work. I don't see any typos in the code. But of course I'm probably overlooking something.

Edit: I found it. Turns out the remind messages in the Post-Game sections had typos in them.

Add "&submit=Edit" to the end of the URL, and this will open up the editor without running the code.

I am having problems with my new preset for Suzumu Shogi. For some reason, it just keeps echoing "Please report any bugs or errors to Adam DeWitt" over and over again instead of showing the preset like it should. Any help would be greatly appreciated.

Games are back. Thanks to who helped.

For me, it is 3 games which are stopped in the middle like yours. Hope they will be returned soon.

I am in the middle of a game of Jetan against Zacharias. I am unable to take my turn, as the screen goes to a blank yellow page when I try to get on it to send my moves. Please help.

Absolutely correct, Monsieur Cazaux. I have notified the ridiculous wrong name of 'Chatarunga' to Lady Christine Bagley-Jones, who is the strongest player of Chaturanga and Chaturaji in Game Courier. She is aware of the gross error, and has notified it to the creator of the preset, Mister Joe Joyce. Mister Joyce, however, HAS NOT RECTIFIED THE BLUNDER. I have informed the Lady that I REFUSE to play with a preset wrongly called 'Chatarunga', then I have created my own presets for Chaturaji, which I have called 'Two Players Chaturaji' and 'Two Players Chaturaji Coloured'. One preset distinguishes each of the four armies by the orientation of the soldiers, the other by the colour of the soldiers:

https://www.chessvariants.com/play/pbm/play.php?game=Two+Players+Chaturaji&settings=chaturaji

https://www.chessvariants.com/play/pbm/play.php?game=Two+Players+Chaturaji+Coloured&settings=chaturaji_coloured

You, Monsieur Cazaux, and the other Distinguished Members of Game Courier, are invited to read what I have written there and to indicate possible corrections.

May someone correct the typo on the title of this page "A Game Courier Preset for 4-Handed Chatarunga"?

It is not Chatarunga, it is Chaturanga.

From "Chatur", meaning "four" in sanskrit.

Thanks

I found some functions for converting between the RGB and HSL color spaces, and using them got rid of the problems I was having with making the Black Motif or Magnetic pieces white. However, using them to make the Black Alfaerie pieces white would turn them grey, and trying to make White pieces grey would leave them white. To avoid these problems, I had the function choose between the old RGB recoloring method and the new RGB->HSL->RGB recoloring method based on the relative luminosity of the two colors and on whether it was converted from a true color image. If the new color has a higher luminosity, and it was not converted from true color, it will use the new method. Otherwise, it will use the old method. In my tests, this seems to be working out for the Abstract, Alfaerie, Magnetic, and Motif pieces.

In modifying the form for customizing the appearance of the board for an ongoing game, all form elements were disabled, and it took me a while to figure out what to do. That clued me in that it wasn't working in an intuitive manner. So I changed how it works. Instead of expecting you to choose the Custom theme before you can change the appearance of the game, any change to a form element for changing the appearance automatically changes the theme to Custom. As long as your theme remains set to Custom, the changes you make will be accepted. If you change your theme after starting to make custom changes, it will go with the theme and ignore the other values you set for changing the appearance. I added fields for choosing the color of Black and White pieces. However, I have not integrated these into themes.

But the anti-aliasing causes pixels on the boundary of the black outline and the colored interior to be darker versions of the interior color, by mixing in the black. So simply looking for an exact match of the original color fails to replace the boundary pixels.

I already took that into consideration.

This problem can be solved, though: you could test every pixel for the value of the brightest RGB component, and deduce from that by which factor it is darkened compared to the interior color. And then darken the replacement color by the same factor.

Here's what I'm doing. I collect all the color indexes. For each color index with a non-zero alpha value, I make a determination of whether it belongs to the outline of a piece or to its coloring. I do that with this conditional:

if (color_diff(array($cv["red"], $cv["green"], $cv["blue"]), $original) 
<= color_diff(array($cv["red"], $cv["green"], $cv["blue"]), "black")*2) {

The color_diff function returns the greatest difference between one color's minimum component value and the other one's maximum component value. I added the *2 to prevent some errors, and that part now seems to be working well. If it belongs to its coloring, I recolor each RGB component with this function:

function recolor_component_as ($originalvalue, $currentvalue, $newvalue) {
    if ($originalvalue == 0)
        return $newvalue;
    return min(255,round($newvalue*($currentvalue/$originalvalue)));
}

One remaining problem is that when I try to color the Black pieces white, I get an aquamarine fringe around the Black Motif pieces. In this case, $originalvalue will be 255 for the red component and 0 for the green and blue components, and $newvalue will be 255 for all three components. So, it recolors some edge pixels with positive values for green and blue but with 0 for red, resulting in aquamarine. So, I might have to factor in the value of each component when deciding how to recolor each component. But when I tried that earlier, I got some undesirable results.

But the anti-aliasing causes pixels on the boundary of the black outline and the colored interior to be darker versions of the interior color, by mixing in the black. So simply looking for an exact match of the original color fails to replace the boundary pixels.

I already took that into consideration.

This problem can be solved, though: you could test every pixel for the value of the brightest RGB component, and deduce from that by which factor it is darkened compared to the interior color. And then darken the replacement color by the same factor.

Here's what I'm doing. I collect all the color indexes. For each color index with a non-zero alpha value, I make a determination of whether it belongs to the outline of a piece or to its coloring. I do that with this conditional:

if (color_diff(array($cv["red"], $cv["green"], $cv["blue"]), $original) 
<= color_diff(array($cv["red"], $cv["green"], $cv["blue"]), "black")*2) {

The color_diff function returns the greatest difference between one color's minimum component value and the other one's maximum component value. I added the *2 to prevent some errors, and that part now seems to be working well. If it belongs to its coloring, I recolor each RGB component with this function:

function recolor_component_as ($originalvalue, $currentvalue, $newvalue) {
    if ($originalvalue == 0)
        return $newvalue;
    return min(255,round($newvalue*($currentvalue/$originalvalue)));
}

One remaining problem is that when I try to color the Black pieces white, I get an aquamarine fringe around the Black Motif pieces. In this case, $originalvalue will be 255 for the red component and 0 for the green and blue components, and $newvalue will be 255 for all three components. So, it recolors some edge pixels with positive values for green and blue but with 0 for red, resulting in aquamarine. So, I might have to factor in the value of each component when deciding how to recolor each component. But when I tried that earlier, I got some undesirable results.

The original alfaerie set should be considered obsolete now that we have alfaeriePNG, and its use should be discouraged. The anti-aliased version looks so much better. But the anti-aliasing causes pixels on the boundary of the black outline and the colored interior to be darker versions of the interior color, by mixing in the black. So simply looking for an exact match of the original color fails to replace the boundary pixels. This problem can be solved, though: you could test every pixel for the value of the briggtest RGB component, and deduce from that by which factor it is darkened compared to the interior color. And then darken the replacement color by the same factor. (This assumes the outline is pure black.) To make it resistant to multi-color originals you could even check whether the other two RGB components of the original are indeed similarly darkened (within some tolerance for rounding.)

It works with the Alfaerie set. To work, it has to know the primary color of the piece. This is stored in the variable $originalwhite or $originalblack, and the value of each variable must match a color actually used in the image. I have set their values in the main body of the code for Abstract, Alfaerie, Magnetic, and Motif pieces, and I have set their values in individual set files for some other sets. I have thought about adding code that would identify the most common foreground color in each piece image, as it already goes through each image pixel by pixel to get the color indexes, but I'm not sure if this would be appropriate for some pieces, such as pieces with textured coloring from photographs.

Does it also work for the anti-aliased piece sets?

I modified the showpiece.php script to change the color of the piece. This may later be used with the Table and CSS rendering methods to recolor the pieces, and I may modify the pc shortcode to include a color option. Here's a violet King.

I turned the code for recoloring pieces into a function, and I added the ability to recolor pieces to the circular and spherical boards and to the Diagram Designer. But I still need to do some work on the forms.

The recoloring of pieces is working very well now. Even with the Alfaerie pieces, it looks like they were originally the color they were recolored to. For some sets, there are some glitches when trying to recolor the black pieces as white, but that's usually something no one will want to do.

Today I've been working on allowing players to change piece colors when the board is displayed as an image. Recoloring is not available for boards rendered as tables or with CSS. It works best for the Abstract pieces, because they are the simplest in design. It also works for Alfaerie, Magnetic, and Motif pieces, but the greater detail of these pieces makes a perfect recoloring job more difficult. For the new Alfaerie pieces, there is one more issue. It has to convert them into 256 color palette images before recoloring them. So, they don't look quite as good as the unrecolored images. As long as you don't change the color, the pieces will not be recolored, and they will look as they normally do. I plan to work on this more tomorrow, but for now, I have copied my work to the main server to keep it from being overwritten by the backup at midnight.

This is now fixed.

Speaking of 404's, I also get those from the What's New page, specifically the two newest links (Cubic Chess and 3D Chess 4 Cubed). Though they also have the External Link icon next to the name, so perhaps that's related.