Comments/Ratings for a Single Item

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.