Comments/Ratings for a Single Item

Note to Fergus: although this preset is automated through the PTA, this only applies to the playing after the 'prelude'. So Aurelians question is about the GAME code for the case turn == 0 in the Post-Move sections, which is not relying on anything in the include file.

@Aurelian: I do notice you change the restrictions on what is allowed as input, and then change them back after the move gets handled. Note that the betza.txt include file normally runs under conditions (set in the Pre-Game code, where it was included):

setsystem maxmove 4;     // move + suicide + freedrop + promotion
setsystem omitmoves 1;   // in case they forgot to tick checkbox
ban commands;
allow pass 2 pass 3;     // later legs can be skipped

which is different from what you try to restore. (But of course your variant might not need all the move types that the betza.txt file supports.)

Some comments:

I am not sure whether changing the allowed input format in the Post-Move section would work. This section is only invoked after the move has already been entered, so during entry the format defined in the Pre-Game section might still apply, and cause rejection. Perhaps you should set the prelude format in white's Pre-Move section (subject to the condition turn == 0). And then restore it only at the end of the prelude section in black's Post-Move code.

Aren't you making life unnecessarily difficult for yourself, by allowing the players to place both pieces in the same turn? If you would allow two turns for the prelude (only calling HandleMove when turn > 1) you would only have to process a single move. And then you could call ParseMove true/false in the betza.txt include in order to extract the move parameters #ori and #desti, and use those to make the move.

Of course this would not give you rule enforcing in the prelude, as nothing would stop a player from moving, say, his King to the back rank. So you would have to test whether rank #ori equals 4 (or 5, for black), and whether rank #desti equals 0 (or 9 for black). And whether ther actually was a piece on #ori, and whether #desti was empty. If your rules require a specific order of placement, both prelude turns could use the same code. (If not you would need a turn-dependent test on the moved piece type, which could replace the test on the origin rank, as the piece type would only be found there anyway.)

@ Fergus,

Can you look over this : https://www.chessvariants.com/play/pbm/play.php?game=Frog+Chess+with+Gryphon+and+Falcon&settings=default&submit=Edit

preset I am attempting, and tell me what basic mistakes I am doing. I don't think my logic is very bad. But anyway I am not sure I use the proper variables.

What should happen, is that white should be allowed to move the two pieces on the back line to be gated, then black the same. It does not work as I inteneded and I don't know why. Please help1

It's important to maintain backwards compatibility, and anyone who doesn't like the name of Aanca is free to use a different name with an alias.

Indeed, it is in fairychess file. So, this is really sticking. Why can't we be disciplined just a little. On this community we all once agreed that Betza once made a mistake, he overread, when calling Aanca the wrong piece. We had a long discussion on that. So why there is still aanca for the wrong piece in this file which is rather recent? And then, it is contageous. I know that not everyone likes history and languages as I do. But once a fact is known, why keeping ignoring it? Ignorance is always stronger than culture. This is really discouraging.

It's because I failed to add the necessary aliases to get the names to display more coherently. Some pieces are defined separately for white and black because of color or direction dependent moves. Aanca is defined as such in fairychess so it will show that way unless overridden by an alias.

@ Daniel Z for Overboard:

1. I read the description of the pieces. There is no difference between White Elephant and Black Elephant, same for Hare, Courier Pawn, etc. Am I missing something? I have not understood.

2. Why do you persit in calling Aanca the W-then-B? Do this is perpetuating a regrettable mistake. Aanca is F-then-R, the Gryphon as in Grant Acedrex (our variant of the month!). Manticore, Rhinoceros (as your symbol) are names used on other variants here with no problem.

I am not sure that the word "gorgona" exists in English, does it?

As far as I can tell, only as a proper noun, as the name of two islands: Gorgona off the Italian west coast, and Gorgona Island near Colombia. (A few other things too, like a hotel in Crete, but nothing significant.)

However, pieces with these names should show a woman with snakes for hair rather than a target with lines or arrows coming from it, which seems to be based on how a particular piece moves instead of its name.

In biology 'medusa' is a stage in the life cycle of jellyfish, and I think the image attempts to depict that (the dashed lines representing the tentacles).

Anyway, the original Alfaerie GIFs used this image, and I just made an SVG copy when I needed it to equip some variant article with an Interactive Diagram. I never used the piece myself.

The Medusa may also be understood as a jellyfish by some people. In French both Medusa, the Greek monster, and jellyfish are called "méduse". Of course, the name of the animal comes from the mythological name.

For representing that piece in Musketeer Board Painter Tool I use their icon of a jellyfish.

Interesting also to note that Medusa was one of the three Gorgons in the Greek mythology. So, there is a bit of something weird in having both Medusa and Gorgona. I don't know who made those icons looking like targets.

I am not sure that the word "gorgona" exists in English, does it?

Until the CloudFlare cache gets cleared

I have now cleared it of the medusa and gorgana pieces in alfaeriePNG/.

The SVG for the Gorgona was derived from that for the Medusa, and apparently it inherited the characteristic that prevents its rendering by fen2.php.

For what it's worth, showpiece.php produced PNGs for both of these when I ran it on the SVGs a few days ago. However, pieces with these names should show a woman with snakes for hair rather than a target with lines or arrows coming from it, which seems to be based on how a particular piece moves instead of its name.

Well, on the website it is now solved. But of course you will not be looking at the website as long as CloudFlare thinks the copy of it that it has cached is still valid.

Until the CloudFlare cache gets cleared you could try to replace the "wmedusa.png" in the custom-set definition of the preset by "wmedusa.png?nocache=true".

@HG: is that problem solvable and will it be solved? In the meantime I have given the spider icon to the Medusa in my game in order to see something. I will restore the medusa if it can be solved.

Indeed. The SVG for the Gorgona was derived from that for the Medusa, and apparently it inherited the characteristic that prevents its rendering by fen2.php. I also had these on my own PC (made with fen2.cgi on winboard.nl, before this was made available on CVP in a PP wrapper, where it was apparently not a problem), and uploaded these now to the alfaeriePNG folder.

Thank you HG. Incidently, I suspect the Gorgona image to be in the same situation.

There is nothing wrong with the preset, but the medusa images in that directory are completely blank. Something must have gone wrong while rendering those at 50x50. I will check it out later tonight.

[Edit] Strange, there must be something wrong with the SVG. When I render it with fen2.php it produces an entirely transparent PNG. The SVG exists, but when I render it directly in the browser it renders it much larger than the other SVG. Nevertheless the medusa 50x50 PNG images were on my own PC, so I must have been able to render them. Perhaps directly from my winboard.nl website.

Anyway, I uploaded these images from my PC to the alfaeriePNG directory now. That should fix the problem. (After flushing the cache; I hope the CloudFlare cache won't play you tricks; I still get the blank image if I don't append ?nocache=true to the URL.)

It's Patchanka:

https://www.chessvariants.com/play/pbm/play.php?game=Patchanka&settings=Default-PTA

I have the feeling that wmedusa.png and bmedusa.png are not recognized. In "Q": "wmedusa.png", "q": "bmedusa.png",

If I replace by wqueen.png it works. By wgorgona.png it doesn't.

I'm sure it was working when I created the GC few weeks ago.

Link?

@HG: it seems that the question is for you. I have re-created the GC using your PTA tool. I paid attention to the setgroup and the set, but, aargh, nada. The Medusa refuses to appear.

@editors: In Patchanka a Pawn may promote into a Medusa. But now when playing Patchanka with GC, the Medusa is not shown. There is a ghost space instead. I'm pretty sure I had tested it before. What has happened? Does anyone has changed something with that piece (alfaerie)? May someone look at that please?

Thank you

It is currently having a problem with Omega Chess, which uses aliases for some spaces. So, I'm going to have to build in some support for aliases.

I fixed the problem with Omega Chess by using aliases for the pieces and positions stored in JavaScript, and that introduced a new problem I also fixed. Since I was relying on the new $posdata variable to tell whether any spaces besides the origin and dest spaces were different from the previous move, it was no longer returning the correct results for the aliased corner spaces in Omega Chess. Luckily, I already had variables with the aliased values in the code, and I just used these to represent the current position in comparison with the previous position (which was already stored with aliases).

Man, I am absolutely loving the new Navigational panel on the Game Courier interface.

Thanks, and it's even better after the work I've been doing today.

Only problem I can see is that it doesn't take into account the PHP flip variable in set files, which results in the second player seeing the pieces flipped in sets where image orientation matters, such as Shogi sets.

I have been working on updating it today, and that's one of the things I fixed. I also got it to display the captured pieces for the move being shown, to display the move and inline comment above the board, and to display informative messages when it is unsupported or has insufficient data to show a move.

There are still some things to fix. It is currently having a problem with Omega Chess, which uses aliases for some spaces. So, I'm going to have to build in some support for aliases.

Man, I am absolutely loving the new Navigational panel on the Game Courier interface.

Only problem I can see is that it doesn't take into account the PHP flip variable in set files, which results in the second player seeing the pieces flipped in sets where image orientation matters, such as Shogi sets.

That worked, thanks!

I had looked for a 'Custom' group in case there was such a thing (and it could help), but somehow I had completely missed it.

I've used Alfaerie: Many (thinking it did not matter),

It does matter. Your set should be "Completely Custom Set" from the Custom group.

@ Fergus (or H.G.):

I made a rules enforcing preset for 4 Kings Quasi-Shatranj (see link below), but in spite of including custom set specifications and all other details that the Play-Test Applet generated, wrong piece types are showing up in the preset diagram, both before or after finishing editing the settings file.

I've used Alfaerie: Many (thinking it did not matter), but I also tried Auto Alfaerie PNG and Auto Alfaerie PNG35 as my piece sets for the settings file, but none of those choices worked properly after editing or before. Is there something I am missing that's not stated (or I've overlooked) on the Applet's page (a Menu: Tools item) regarding customs sets, or are the custom sets (or their implementation) no longer working properly, if they ever did?:

https://www.chessvariants.com/play/pbm/play.php?game=4+Kings+Quasi-Shatranj&settings=enforcing

I think that the settings file is fine the way you have it right now, Fergus. Thanks.

I fixed it according to how it should work with the first and last file meeting at 6:00. You should now be able to adjust your colors to how you want them.

@ Fergus:

In the settings file of mine linked to below, I had its 3 cells' colors scheme working before the introduction some time ago of automatic 'rank' labels to circular chess presets.

That is, besides shifting the position of the armies in the setup by 45 degrees, the automatic labeling seems to have unhinged the 8 orange-color cells' scheme I previously had working successfully (the majority of cells being colored either white or pink). I have recently tried many things to 'restore order' to the appearance of this preset, but no luck so far. Perhaps you can help:

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

The text that is hidden is just narrower than I thought it was. It only hides the output of runsubroutine(), and the warning I inserted was before this.

Perhaps because of the CSS for the warning class, it is showing up even though it's where messages are normally hidden.

No, it looks like any text is showing up where it should be hidden. I'll look into this after lunch.

It might be better to use one of those as the accepted value, and emit an error message if the other doesn't comply.

I have added code to display a warning if the number of ranks calculated from the FEN Code does not match the number calculated from the value of the Rank Labels field. Perhaps because of the CSS for the warning class, it is showing up even though it's where messages are normally hidden.

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.