Comments/Ratings for a Single Item

Yes, this is explained in the User's Guide.

https://www.chessvariants.com/play/pbm/userguide.html#takeback

Thank you. Done.

The link for the rules in the page of the preset for Chess 9x9 does not send to the rules of this game but to the rules of Cardinal Chess instead. Maybe this should be corrected

That preset is owned by Vitya Makov. He would need to edit it.

I would like to request that the presets default2 and promotest for Suzumu Shogi be deleted, as they are excess presets and no known games for Suzumu Shogi have been found. (promotest was made to try and work around an internal bug in Game Courier, and default2 was made when I thought I would need to update the default preset for the game, only to find that it was safe to change the original).

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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'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.

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.