Comments/Ratings for a Single Item

Indeed. But some parts of Game Courier appear to base the number of ranks on the FEN, and other parts on the labels. This allows incompatible values to coexist internally, without warning, and not easily noticed. It might be better to use one of those as the accepted value, and emit an error message if the other doesn't comply. That would guarantee consistency, rather than making it depend on fallible users.

There seems to be some inconsistency here, though, as the 'fantom rank' does not show up in the board diagram. So some parts of the Game Courier code must have a different notion of how many ranks there are from what the rank labels imply.

The inconsistency is between the FEN code and the Rank Labels field. The FEN code has defined only 8 ranks, and the Rank Labels has named 9 ranks.

It's not correct, but the bug is not on my end. When I entered the FEN code for this game into a preset for Chess, it gave the correct value of 7. The problem is that your Rank Labels field explicitly specifies 9 ranks with the value of "1 2 3 4 5 6 7 8 9". This adds an extra element to the $ranks array, whose size is used to calculate lastrank.

OK, thanks for resolving this. The preset isn't mine, but I was using it for testing a new feature in the betza.txt include file, since it was one of the presets automated through this that I was aware of. This way of automating is not responsible for the rank labels, and purely works with the internal rank numbers. And it was not using any feature of the betza.txt incluce that was dependent on lastrank. But the new feature I was testing did. (And would actually work correctly in a context that provides the correct value of lastrank.)

There seems to be some inconsistency here, though, as the 'fantom rank' does not show up in the board diagram. So some parts of the Game Courier code must have a different notion of how many ranks there are from what the rank labels imply.

It appears the GAME-code operator lastrank returns 8 on a 9x8 board (e.g. when I add some code to print its value in this preset). That is not correct, is it?

It's not correct, but the bug is not on my end. When I entered the FEN code for this game into a preset for Chess, it gave the correct value of 7. The problem is that your Rank Labels field explicitly specifies 9 ranks with the value of "1 2 3 4 5 6 7 8 9". This adds an extra element to the $ranks array, whose size is used to calculate lastrank.

@Fergus: It appears the GAME-code operator lastrank returns 8 on a 9x8 board (e.g. when I add some code to print its value in this preset). That is not correct, is it? The GAME-code reference manual states it should return 7 on a board with 8 ranks.

Bug in Alice Chess, move not marked as legal.

I determined that the problem was only with Pawns on the side, and it was due to the functions that determine the spaces to check for legal moves in. These functions originally looked like this:

def PL array where #0 0 2 where #0 0 1 where #0 -1 1 where #0 1 1;
def pL array where #0 0 -2 where #0 0 -1 where #0 -1 -1 where #0 1 -1;

I replaced them with the more up-to-date and sophisticated versions from the fairychess include file, and they now look like this:

def PL filter lambda (onboard #1) mergeall where #ori -1 1 where #ori 1 1 values lambda (where #ori 0 #1) range 1 var fps =ori;
def pL filter lambda (onboard #1) mergeall where #ori -1 -1 where #ori 1 -1 values lambda (where #ori 0 neg #1) range 1 var fps =ori;

Apparently, the earlier version would break out prematurely if one of the spaces was not on the board, which would be the case for a Pawn on the side of the board. But the one using lambda functions does not do this.

Bug in Alice Chess, move not marked as legal.

1. P d2-d3 
1... n g8-f6 
2. N b1-c3 
2... p e7-e6 
3. N C3-D5 
3... q d8-e7 
4. P e2-e3 
4... n b8-c6 
5. Q d1-d2 
5... p a7-a5 
6. N g1-f3 
6... b f8-c5 
7. B f1-e2 
7... n F6-E4 
8. K e1-g1 
8... r h8-g8 // - Check! -
9. P g2-g3 
9... p b7-b6 
10. B c1-h6 
10... b c8-a6 
11. R a1-c1 
11... n C6-B4 
12. N d5-b4 
12... p A5-B4 [not marked as legal, had to force it]

Also, the Preview of Comment doesn't seem to work.

To prevent the recoloring of pieces not meant to be recolored, such as Shogi pieces, I stopped assigning values to $originalwhite and $originalblack if the set doesn't already have known colors.

Game Courier now supports the use of recolored SVG pieces with all of its rendering methods. The available set I've tested this with is "alfaerie-svg", which is listed as "Alfaerie SVG". The "Alfaerie: All SVG" set actually uses PNG images, not SVG images. It should be renamed, or its pieces should be modified to use SVG pieces.

I got it to work by changing the content-type to image/svg+xml.

When I included the line header('Content-Type: image/svg');, it still did not work in an IMG tag, and it would not even work in a separate tab. Instead, it would download the SVG file.

Does the showpiece.php say in the header that the Content-Type is image/svg, rather than image/png?

I am currently working on supporting recolored SVG pieces in Game Courier for the CSS and Table formats. This involves the display of individual piece images. It works fine for GIF or PNG pieces, but not for SVG pieces. Although it will work if loaded into a separate tab, it will not display the piece through an IMG tag. The first piece below is from the alfaerie-svg set, and the second is from the alfaerie set. Only the latter is displaying through the IMG tag. Any ideas why?

Here's my code for recoloring and displaying the SVG image:

if (preg_match("/\.svg$/i", $url)) {
    $blob = file_get_contents($url);
    if (array_key_exists($color, $colorcode))
        $color = $colorcode[$color];
    if ($color[0] != "#")
        $color = "#" . $color;
    if (strtolower($color) != "#f9f9f9")
        $blob = str_replace("#f9f9f9", $color, $blob);
    echo $blob;
}

It seems I had an extra parameter in the israngecapture subroutine from when I was trying to use a subroutine to determine whether a range capturing piece had any legal moves left mid-move. It is fixed now. The responsibility of determining whether a piece has any moves left mid-move has been moved to the Post-Game sections, making use of the legalmoves2 subroutine's return value. I also fixed Mitsugumi Shogi's GC preset, which had the same problem.

Edit: I also got rid of the from parameter in the israngecapture subroutine and the statements that call it. Since it wasn't being used within the subroutine itself, there was no need to include it in the parameter list.

Adam,

I was recently getting lines like this in the PHP error log:

[18-Dec-2022 15:05:06 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 45
[18-Dec-2022 15:05:06 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 45
[18-Dec-2022 15:05:06 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 45
[18-Dec-2022 15:05:06 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 45
[18-Dec-2022 15:05:06 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 45
[18-Dec-2022 15:05:06 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 45

Not sure what was going on, I added some code to log the value of $move, and now it looks like this:

[19-Dec-2022 00:27:03 UTC] move: sub israngecapture from to kingpos
[19-Dec-2022 00:27:03 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 47
[19-Dec-2022 00:27:03 UTC] move: sub israngecapture from to kingpos
[19-Dec-2022 00:27:03 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 47
[19-Dec-2022 00:27:03 UTC] move: sub israngecapture from to kingpos
[19-Dec-2022 00:27:03 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 47
[19-Dec-2022 00:27:03 UTC] move: sub israngecapture from to kingpos
[19-Dec-2022 00:27:03 UTC] PHP Warning:  Undefined array key 2 in /home/chessvariants/public_html/play/pbm/gamecode.php on line 47

The culprit seems to be your israngecapture subroutine. When I looked at your code, it was defined with the three parameters shown above, but you were calling it without a value for the last parameter. Now that I understand what the problem is, I have replaced the error log with an error message for the user.

If all your pieces are from the same set, I am going to recommend using aliases instead of the newer method of rewriting $pieces.

Note that I added several 'Automatic' sets, each of which contains all available pieces of the corresponding style. E.g. alfaeriePNG, alfaeriePNG35, Utrecht/Small, XBoard, XBoard33.) That makes it easier to satisfy the 'same set' condition.

These all use the (fully capitalized or lower-cased) image names as internal piece labels. If I understand everything correctly that would not be a problem, and can be hidden from the user by defining an alias for those to be used in notation.

Fair enough.

Note that your code also runs on the server side. What you meant was that the issue was with the language rather than with your code.

Thanks for fixing checkahop.

As for the rest of the RANGECAPTURE code, the not so compact cx and cy assignments were me trying to fix the bug before realizing it was a server-side issue. I can just use cmp there since the jumping Generals can only jump along the eight cardinal directions. Since they use #ori and #dst (the variables that store origin and dest), and the jumping Generals cannot change direction mid-move, there is no need to compare directions, as using cx and cy with checkaride and checkhop returns the same direction as that of the first part of the move. The if statement with the checkaride clause is there to enforce the two jump limit for these pieces. If that checkaride clause fails but the ismultimove subroutine succeeds, the moving pieces has jumped over a piece (and another piece which it just captured) already, and thus cannot jump any more pieces.

It looks like I already fixed the same problem for checkaride. So, I just copied the relevant code to checkahop, and it appears to be fixed now.

I got your moves to work by deleting the whitespace at the end of each line. However, your code is fairly complicated. I think the relevant code is in the RANGECAPTURE subroutine. Since the subroutine's parameters are #from and #to, I presume that #ori and #dst are set outside the subroutine, and these refer to the origin and dest of the previous move.

I would replace the first part with this. It should give the same values but is more compact.

set cx sign - file #dst file #ori;
set cy sign - rank #dst rank #ori;

In this section, I don't think checkaride is going to do what you want.

  if checkaride #ori #dst #cx #cy and == 1 var phase;
    return checkaride #from #to #cx #cy or checkahop #from #to #cx #cy and cond empty #from capture (not empty #to);
  else;
    return checkaride #from #to #cx #cy and cond empty #from capture (not empty #to);
  endif;

If the previous move was a hopping capture, then checkaride should fail, because of the piece lying between the two positions. Also, it's not comparing the direction of the current move to the direction of the former move. It's just comparing the direction of the former move with itself, and since these should be the same already, it is just checking whether the space is clear between #cx and #cy. If you mean to compare the direction of the current move with that of the former move, this would work better:

if == sign - file #to #from #cx and == sign - rank #to #rank #from #cy and == 1 var phase:

To test whether there is a problem with checkahop, I think I will have to work with a simpler piece function.

If all your pieces are from the same set, I am going to recommend using aliases instead of the newer method of rewriting $pieces. This method works only when you are running the script. Consequently, some images will not show up in your description when the script is not running, such as in Edit mode. When you use aliases, you just use the original piece labels in your description, and it displays all images every time. You just have to be careful to always translate the original labels into aliases whenever you use them.

I followed your link and pasted in the moves you listed, but it gave me an error on the very first move.

The amazing thing is that I cannot read the comments on Game Courier when not logged on, because it says the article has not been published yet!

There seems to be a bug with the checkahop operator, in that it seems to allow both the hop in the intended direction and the hop in the opposite direction, at least on the second part of a multi-move. This can be demonstrated in this game of Suzumu Shogi (the experimental version w/ triple capturing versions of the jumping Generals)

1. rg 7m-7d; +rg-dest 
1... RG 10d-10m; +RG-dest 
2. wb 11n-12o // begin setup for bug demo
2... WB 6c-5b 
3. +rg 7d-6c 
3... +RG 10m-11n 
4. fe 8m-10m 
4... FE 9d-7d 
5. lh 9m-8k 
5... LH 8d-9f 
6. d 12k-12j 
6... D 5f-5g 
7. d 12j-11k 
7... D 5g-6f 
8. p 14l-14k 
8... P 3e-3f // end setup for bug demo
// in this position, when +rg 7c is clicked after 9. +rg 6c-7c, it shows the two intended hops plus another (unintended) hop on 4c which jumps over the first piece in the opposite direction, which is incorrectly accepted by the rule enforcement code.

I'm pretty sure this is a server-side bug and not a bug involving my code. Any help would be much appreciated.

That was what I was thinking as well, and given that the rest of the code is fine, we are probably right. Unfortunately, simply getting rid of that clause won't really solve the issue. The Heavenly Tetrarch has a unique mechanic that causes it to jump over the first square it travels over, so the preset needs to take that into account. It might be possible to get rid of it with clever use of the cond statemenet though.

Edit: Turns out I was using the wrong variables to account for the distance of the first part of the move. The values of origin and dest were updated before the move was evaluated, so the distance would always be 1 and the move would thus get rejected. I fixed this by using ori and dst instead, which stay the same for all parts of the move.

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.

I speak of the link with the name of the game which is written just below the diagram in the GC page.

Okay, I changed that to use the $rulesurl variable calculated in the header, which can be different than the value stored in $rules. So, it should work now.

Yangsi, Xiangqi, Glinski's, Gross Chess…

Everything I try doesn't work.

I tried Fantastic XIII, and also Shako and Expanded Chess and the link doesn't work, it always goes to 404. Maybe we don't speak of the same thing.

I speak of the link with the name of the game which is written just below the diagram in the GC page.

It seems like the Rules URL is broken for every game.

I tried multiple presets, including Shako and Expanded Chess, and the Rules URL worked fine every time. Instead of saying every game, which obviously you can't confirm without exhaustive work, tell me which particular presets you are seeing this problem in.

Same observation than Daniel from my side

It seems like the Rules URL is broken for every game. The / at the beginning is removed. I tried fixing it for one of my games and nothing changed.

I managed to solve the King's move display issue by using sub checked cond == #from #king #to #king in the relevant places in the stalemated subroutine. Afterwards it gave a weird error where the King was in check after moving both Kings, but after adding a few lines to force update the k and K variables in the Post-Move sections, the preset is now working perfectly. Thank you for your help.

The problem appears to be that you are not updating the value of k or K when the King moves. This gives inaccurate data to both the checked and stalemated subroutines, which results in inaccurate return values. So, it is an instance of garbage in, garbage out.

In my tests of how intersection works, it will return an associative array when the first array is associative and the second is sequential. It will also treat a variable name as a constant name if there is no variable by that name and there is a constant by that name. So, what I thought were problems with the code might not be.

If the purpose of these intersections is to weed out empty spaces, the same thing can be accomplished more easily with diff noupper @ or diff nolower @.

I notice that your calls to stalemated include two arguments, but only one parameter is defined for the subroutine.

Also, Daniel Zacharias found that if you enter King moves manually, it works fine.

The King's legal moves were highlighted for the first player, but they were not for the second player. After I moved the King manually, it declared check. Considering how your pieces move, this seems inaccurate. All I did was move each King forward to file 6.

He thinks the problem may be in the stalemated subroutine. When I coded this preset, I removed the checkmated subroutine used in my other presets to simplify the code a bit. so that would make sense.

After the two King moves I mentioned, the only highlighted legal moves are to 5j, the space vacated by the King. After each one of these moves, it declared "Checkmate! Black has won!" When I tried other moves I expected to be legal, I could make them, but then it would declare Checkmate again.

Looking at your Post-Game code, I see lines for enforcing the rule against checkmating with a Pawn drop. Code for this should be handled by the stalemated subroutine, because it has to apply to potential moves, not just to actual moves. However, I don't think that code is responsible for the inaccurate estimates of check and stalemate.

Since it declares checkmate only when checked and stalemated both return true, there may be bugs in both, or there may be a bug in a function called by both, such as the definition of a piece move, or there may be a bug in checked, which is also called by stalemated.

Since the checked subroutine shows problems by itself, and it is also called by the stalemated subroutine, it could well be the problem. It works differently than the checked subroutine I have in the fairychess include file. It sets enemies to an intersection between noupper and #bpieces or nolower and #wpieces. However, there are no variables called bpieces or wpieces. There are only constants by these names, and these two constants are sequential arrays. However, noupper and nolower return associative arrays. So, an intersection would not give you the desired result.

I see the same error in your stalemated subroutine. You are trying to find an intersection between an associative array and a variable that does not exist, and the constant with its name is a sequential array anyway.

Sorry about that. Here it is.

Cannon Shosu Shogi on the Chess Variants Game Courier

Also, Daniel Zacharias found that if you enter King moves manually, it works fine. He thinks the problem may be in the stalemated subroutine. When I coded this preset, I removed the checkmated subroutine used in my other presets to simplify the code a bit. so that would make sense.

Posting a link would help.

I am making an experimental GC Preset for Cannon Shosu Shogi. Everything seems to be working properly, except for the fact that the Kings are unable to move. The Black King is only able to move on the first turn. Any help would be greatly appreciated.

Thankfully, I managed to fix this by excluding forced promotions from the move string.

The problem occurs when I make a triple move with a piece with Lion Dog powers where all three parts move the piece to different squares and the third square is empty. The preset will exit with an error message stating that the promotion is illegal when it should be legal.

After a triple move, you would need a fourth move for the promotion, but your allow statement does not include any allowances for fourth moves.

@Adam: thank you, I had copied what was done for SAC chess, i thought that 4 parameters were necessary indicating both K and R moves. But you're right, it is not the case. I don't know if it may induce an error as it is, I don't find any case.

@Greg: according to the point above, the presets to be corrected are SAC chess, Heavy Chess and Very Heavy Chess. Thank you.

I'm talking about your Very Heavy Chess preset. The f2/f9 and h2/h9 values in the wcastle/bcastle variables are unnecessary.

@Adam:I don't catch which game you are talking about. I was talking about Hannibal Chess for which I've made a preset. The castling there is correct according to the rules. (Castling is as in standard chess, except a king goes three squares sideways during the process (instead of two squares). )

I believe you are talking about something else. What is it? Thx

@Jean-Louis Cazaux The wcastle and bcastle variables in your preset aren't set properly. If castling works exactly like it does in chess, wcastle/bcastle should be set to e2 i2/e9 i9, respectively. Other than that, I don't see any bugs.

@Bn Em

Thank you for the answer.

@Max

Game Courier doesn't (currently?) support games for more than two players. Idk how those four‐player variants were done, though it wouldn't surprise me if it's in teams where each player is suppoesd to control both armies in each team. (presumably these are not rule‐enforcing)

I feel like multiplayer games may technically be on Fergus' list of things to Maybe Eventually Add to GC (istr him mentioning it though I wouldn't hold him to that) but there's no support now and iirc probably requires a fairlyfundamental refactor at the very least

Is it technically possible to make a playable preset for any three-player chess variant? I've already built a GC preset for ThreeHex chess, but I'm not sure if it will work since I used a set group for four-player chess (I didn't find any three-player variant here).

Max.

@Adam: thank you for the explanation.

I have then submitted the GC Preset for Hannibal Chess with moves displayed and enforced rules.

I was forced to mention this is the title because a short "Hannibal Chess" exists already, it is a preset with no rules enforced. I hope this doesn't cause any problem.

For what concerns Very Heavy Chess, any answer ? Again the available preset is bugged. Shall I update also a corrected version? If I do that someone will remove the bugged one?

@Jean-Louis Cazaux You can't get a preset to show up in the Games to Play section just by creating it (Good thing too, otherwise it would have way too much stuff in it).

Go to the tab with your name and click Post Your Own Game in the drop-down menu. This will bring you to the prompt for creating your game's index information. You should prompt up top that asks "Is this the type of page you want to submit?" Click the link that says "Create Game Courier Preset." And the rest is just making the page and waiting for it to be approved.

I am having a problem with the promotions in my Taishin Shogi preset. The problem occurs when I make a triple move with a piece with Lion Dog powers where all three parts move the piece to different squares and the third square is empty. The preset will exit with an error message stating that the promotion is illegal when it should be legal. Any help would be greatly appreciated.

The problem is happening in the bpromote and wpromote subroutines. The relevant errors have also been numbered to aid debugging. Also, the setup has been rearranged to allow quick access to moves that generate the error.

Hello.I fear nobody will answer my last posts here, so I renew in case I'll have more success:

• There is a bug in the GC preset of Very Heavy Chess available from the Alphabetical index. I have given the reason in my earlier message and suggest what has to be modified. Can someone make the correction?

• I have made a GC preset for Hannibal Chess. It is available under my own GC Setting Files. How to place it in the list of "Games to play" and/or the Alphabetical index?

Of course I will do that myself if someone explains me how to do.

Thank you

I have written a preset to play Hannibal Chess, enforcing the rules, which is therefore better than the one available. We are playing it with Kevin P.

My preset is here:

https://www.chessvariants.com/play/pbm/play.php?game=Hannibal+Chess&settings=default-v2

I don't know how to made it available for the Games menu. Maybe an editor can do it?

Thank you

@Greg or another editor.

I think I know where the bug comes from in the Very Heavy Chess preset.

The "Pre-Game" block doesn't have the right squares, it has been cut-and-paste from Heavy Chess.

Instead of

setflag b2 b9 i2 i9 f2 f9; set k f9; set K f2; set ep false; set bpr 8; set wpr 3; set wcastle d2 e2 g2 h2; set bcastle d9 e9 g9 h9;

it should be:

setflag c2 c9 j2 j9 g2 g9; set k g9; set K g2; set ep false; set bpr 8; set wpr 3; set wcastle e2 f2 h2 i2; set bcastle e9 f9 h9 i9;

Could you make the correction?

Also the "Rules URL" is wrong, pointing to Heavy Chess instead of Very Heavy Chess.

I could do the correction myself but I don't think it will be saved for everyone.

Thank you

Here's the game log for Very Heavy Chess in question, that seems to have a bug.

@ Greg: If you have time these days, please try to fix the preset, and/or the log (Black may need to take back his last move).

https://www.chessvariants.com/play/pbm/play.php?game=Very+Heavy+Chess&log=panther-timurthelenk-2021-339-162

The preset for Very Heavy Chess seems corrupted. It is not the one I designed, it is another one made by Greg Strong. I have a game going on with Kevin P. and I'm getting an absurd check, which is removed by another absurd move.

Would it be possible to put my preset instead?

Thanks

I think mobile devices are suffering from a similar misalignment problem to the one I pointed out earlier. Whenever I load a GC preset that uses an image format on a mobile device, the hitboxes are misaligned, and the image is much smaller than normal. However, whenever I clear my browser cache everything looks fine the first time I load the preset page.

I've been working on this more today. Thanks to having a development server, I've been able to make extensive changes without regularly introducing bugs into the scripts people were using to play games. I realized that I could use margins to position the highlighting, and I moved as much of the CSS as I could from each IMG's STYLE element to some STYLE tags. This reduced the HTML code and the filesize of the page. I also added some code that is more adaptive to grids with unusual geometries, though I didn't test it on anything more unusual than Shogi. I made the highlighting of the last move made always the same color as the other highlighting, and I increased the border size for the piece that last moved to 5px, which fits the space better. As mentioned before, I'm now using circular borders to highlight hexagonal spaces. I slightly reduced the size of borders highlighting empty spaces from the size I made them yesterday, because it looks better that way, though I kept them larger than they used to be.

What I meant to say was the the highlights for empty squares are slightly off center.

I've been working on that today, and I just copied over the changes I made. The highlight area is now larger. It had been small to fit on hexagonal spaces. Instead of using the same CSS for square and hexagonal spaces, I made the highlight area for hexagonal spaces round and increased its size. I'll see if anything more needs to be done tomorrow.

I guess I worded that wrong. What I meant to say was the the highlights for empty squares are slightly off center.

Pieces are normally centered, but if you have odd-sized pieces on an even-sized space, or vice versa, 100% alignment may not be possible. Also, centering works best for pieces with nothing beyond the image of the piece itself. Some piece sets, such as Alfaerie, make all piece images a fixed size by adding extra space around most images. If the image of the piece is not properly centered in an image with extra space on the sides, it will not look properly centered on the board.

The hitbox positioning is much better. The images may be slightly off center, but that isn't much of a problem.

I added max-length: 100% !important to the STYLE field for the board image, and this fixed the problem. The squares for highlighting pieces and legal moves now align correctly.

Checking a screenshot of a Rook's legal moves in Chess in a graphics program, the squares for legal moves were at the right pixel locations, but the board was smaller than it should be. The image was 427x431. For comparison, I loaded the image by itself, took another screenshot, and checked its size. This time, it was 436x440. So, the browser is shrinking the image to fit the space, and after the browser has shrunk it, the precalculated positions for the empty images do not align with it. Therefore, I have to prevent the browser from shrinking the image.

While the right-shifting was more readily apparent, I also checked for vertical shifting by creating a position where a Rook covered a whole file. What I found is that there is also downward-shifting. No matter whether the board is rotated for Black, the empty gifs in the lower right are closer to the lower right corner than empty gifs in spaces more to the left or top. This is consistent with right and down being the two directions that increase as the x or y position of the image increases, since 0,0 is in the top left corner.

So far, I can't tell what the problem is. It affects both Square and Grid boards. I have been testing Chess, and the numbers look right when I examine the generated source code. Each square is 50x50, and after file a, each empty image for displaying a legal move has a left position that is 50 pixels greater than that for the file to its left. The a file starts at 16 pixels left, and each empty image for an empty space on that file starts at 23 pixels left. The h file starts at 366, and each empty image for an empty space on that file starts at 373. In each case, the difference is 7. Also, 373-23 and 366-16 are both 350, which is the expected value when each square is 50x50. With all these values being correct and equivalent, it remains a mystery why the empty image shifts slightly to the right with each file from left to right.

As I've been editing code to not show warnings in the PHP error log, I have made lots of edits to draw_grid_png.php. I'll have to take a look at it and see what's causing this.

It does not appear to be caused by any recent edits to draw_grid_png.php. I temporarily reverted to an earlier version, and the problem remained.

I noticed that in one of your games yesterday, and when you mentioned it, I thought perhaps it was because there were no adjustments for your boards in the image_dimensions.php script. But I just tested Shogi and Xiangqi, and I am seeing the same thing. As I've been editing code to not show warnings in the PHP error log, I have made lots of edits to draw_grid_png.php. I'll have to take a look at it and see what's causing this.

I noticed that for the PNG, JPG, and GIF image rendering options that the hitboxes for the squares were off center compared to where the image was, with the effect being least at the upper left corner and increasing as you go towards the lower right corner.

The author of the preset had accidentally reversed the alias with the actual piece label in his alias definition. I corrected that, and now when you click on that piece, it will use the Y alias for it and accept your move.

When trying to move the war machine in Atlantean Coffee House Shatranj I get this error:

ILLEGAL: .DW f3-e3 on turn 1:

The move MOVE: .DW f3-e3 is not well-formed.

It seems that on custom boards, pieces are now displayed farther down and to the right than they are supposed to.

This has now been fixed. Now that it's using relative URLs for pieces, I had to change how the path to the image file is calculated.

It seems that on custom boards, pieces are now displayed farther down and to the right than they are supposed to. I have seen this issue appear in both Crazy 38's and Detective's Rhombic Chess, where it did not previously. Here is what I see in Crazy 38's:

And here is what I see in Detective's Rhombic Chess:

This problem seems to be with the custom board rendering, as all other board shapes work normally.

Why are there no pieces displayed? Even when I try customizing the preset.

Can you provide more information about what you are doing? All I can tell you right now is that there is no system-wide problem.

Why are there no pieces displayed? Even when I try customizing the preset.