Comments by FergusDuniho

I realized the role that $width and $height play in centering the borders for highlighting spaces, and with that in mind, I simplified the code in draw_grid_png.php and made adjustments to the $width and $height of Shogi pieces and to the values of $offx and $offy in image_dimensions.php. By using proper values for $width and $height, the code will always apply CSS for margins and padding to the space class rather than to each element of the space class.

I didn't immediately recognize the importance of $width and $height, because I created these variables years before I ever added the ability to display legal moves by highlighting spaces. These variables describe the width and height of spaces, and they are used when automatically generating a board to know what dimensions to give to spaces. But sometimes an image of a board is used instead, and when it is used, $width and $height should match the size of the spaces on the image.

This is what I was neglecting to do. The highlighting in Shogi was a bit off, because the value of $height did not match the height of the spaces on the images of Shogi boards.

Since Shogi divides each space by lines, there are two choices on how to specify the dimensions of a space. One is to use the inner space between the lines, and the other is to extend the size to include the lines. I tried both and chose the latter for Shogi.

For automatically-generated boards, the centering of borders for highlighting should now be done automatically. But for boards provided as pre-drawn images, it's important to match them up with the correct values for $width and $height. One way would be to size the board with spaces the same size as the dimensions given for the piece sets to be used with it. Abstract and Alfaerie sets both normally use 50x50 spaces. Another way would be to provide correct values for your board. I could add these to the image_dimensions.php script for specific boards.

Another possibility for detecting a suicide move is to store the board position before the move into a variable, then compare the new position after the move to the stored position and see what differences there are.

This could potentially solve the problems of detecting a suicide move if I knew how to do it.

Here's a preset I made to demonstrate how to do this:

https://www.chessvariants.com/play/pbm/play.php?game%3DChess%26settings%3Dspotcaptures

This records the position of every piece on the board in an array whose keys are coordinates and whose values are piece labels. It does this both before and after a move. It then goes through the current positions of pieces. For each empty space, represented with the @ piece, it compares it with the previous value to see if it was empty before. If it wasn't empty before, it records it as a capture.

Since I am already writing this, would the system used for the multi-move variants be able to handle moves with three or more parts (i.e. that of the Lion Dog in Maka Dai Dai Shogi)?

You could adapt it. For the multi-move variants, there are usually the same number of move parts each turn. So, it makes sense for these games to do the multi-part analysis globally for all pieces. But for games that include pieces with multi-part moves, you may want to reserve the multi-part analysis for specific pieces and tailor it to each piece that needs it.

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.

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

Since I can now work on code on the development server, I took the time to remove the remaining code for creating offline pages. While David used to make offline versions of the website, I have never done that. For one thing, I wasn't familiar with how he went about it. But I also didn't see the use for it. Things have changed since David wrote the code for this. Back when we got on the internet with 2400 baud modems that used the phone line, it would have been convenient to have an offline version of the site. But now that broadband and WIFI-enabled mobile devices are both common, it is easy enough to connect directly to the website. When the site is down, as it was recently, archived copies of pages can be found at archive.org. So, an offline copy is not needed for archival purposes. Additionally, the website has grown more interactive than it used to be. While it was originally a set of static HTML pages, it now includes comments, database-generated pages that may be revised on the website, and ongoing games. Finally, when I program code, I write it simply for a website, and I do not want to have to take care to build in support for generating offline pages.

Besides code that was run with the condition $foroffline or $offlineindex, I replaced every instance of echoandwrite with echo, and I removed the function definitions for echoandwrite and echoorwrite. The latter wasn't even being used anyway.

Removing some of the $foroffline code created a bug, and this happened to draw my attention to the icons that appear to the left of links. I had thought of these as slightly informative decoration, but they included links to information pages and included a bunch of ALT text telling some things about the item linked. I got rid of the links to the information pages, changed the ALT text to TITLE text, and reduced the provided information to just telling what the icon meant. With this done, I was able to remove the remaining $foroffline code in make_author_line, and I also removed the $foralttext option from it. There was really no need to include author information in the ALT text for the icon when it was already on the screen anyway. Removing the little-used links to info pages and reducing the information provided by what is now a tooltip should reduce page size and make index pages quicker to load. With that in mind, I may look into extending how many links may appear on an index page.

Thanks for reporting this. Although I'm doing most of the development over on the other server, I do copy over changes toward the end of the day after they seem to be working, and then it's Europeans who are the first to encounter any bugs I may have introduced into the code, because they start the day earlier than I do.

The bug here is preventing the Rook's legal moves from being displayed, but it does not seem to be preventing you from manually typing in the move and making it. I will now look into this and try to fix it.

I decided to rename Futashikana Shogi to Dai Shosu Shogi.

While it has apparently been done, or is in the process of being done, I would like to advise against renaming in general. When you release a game, it takes on a life of its own that may extend outside of this site. While I was working on the taginfo.php script today, I was testing it with the Ai Ai tag, and one line on the page was displaying as empty. When I tracked down what was causing this, it was the ItemID for Futashikana Shogi. Apparently, someone has programmed Futashikana Shogi for Ai Ai, where it remains known by that name and not by the name Dai Shosu Shogi.

Additionally, the name has been changed without updating the RelocatedPages table. This table should have a row added to it for each page whose URL and ItemID both change. It may be done by editing the table in PHPMyAdmin, which the main editors have the URL, userid and password for.

When the page gets rewritten, it should mention the original name and why the name was changed.

I fixed the problem by no longer enclosing each section in SECTION tags.

It might be. It looks like Safari's Reader mode makes inappropriate decisions about what to exclude. In another page I looked at, it showed the Pieces section but skipped the Rules section. My advice would be to not use its Reader mode on this site. It should be unnecessary anyway, since mobile pages here leave out sidebar ads.

On my iPad, Safari's Reader mode is skipping the whole Pieces section. Without Reader mode, things look fine in both Safari and Chrome. I also tried Firefox's Reader mode on my Likebook Mars. It did not skip the Pieces section, though it did mess up your ASCII diagram.

Try using only alphanumeric and punctuation characters found in ASCII in your file names. Korean letters may not be recognized by all software.

There appears to be some kind of corruption from the MariaDB 10 installation that is preventing a reinstallation of MariaDB 5.5 from working. When I check its status after reinstalling version 5.5, it says "Failed to start MariaDB 10.6.4 database server." I expect I will have to reinstall CentOS, but I don't want to get it started right now, because it is late. Unfortunately, the new VPS also seems to be having issues with MariaDB 10. It frequently loses connection with the MySQL server, and I have to refresh a page a few times before it connects.

Since I haven't gotten MariaDB to work on the original server, I switched the domains of the servers. However, there are still things to fix, and I still have to deal with the original server.

My attempt to update chessvariants.com to MariaDB 10 has not been successful, and I have been unable to revert to MariaDB 5.5 without errors. So, chessvariants.com is currently without a working database. At least I made a backup and copied it to chessvariants.org. If the problem on chessvariants.com continues, I might not continue with HostSlayer. As long as I have things backed up on RackNerd, I may try reinstalling the OS on HostSlayer. But for now, I have floaters in my eyes, and I need to have lunch.

The new server is running PHP 8. So, I have updated some scripts over there to work with PHP 8, and I have copied the updated versions to the main server. These include the following:

• 404.php
• footer.php
• ads/adlocale.php
• index/commentsinc.php
• index/database-funcs.php
• index/displayusersubmission.php
• index/fpd-indexing-funcs.php
• login/header.php
• play/pbm/play.php

One change is that {curly brackets} may no longer be used to specify characters within a string. [Square brackets] must be used instead, as they are already used for array elements. The other is that parentheses must now be used to specify the order of evaluation for nested ?: statements.

I will check more pages later to see if any more scripts need updating.

I can't access my game that was interrupted. I hope that timed-out games (due to the site being down) will be playable soon.

It appears that the problem with your game affects only Chu Shogi, and it has nothing to do with the game being interrupted, as I encountered the same problem when I tried to simply move pieces in Chu Shogi. What happens is that the page stops displaying partway through the menu, and it doesn't give me any clear indication of what is wrong. It looks like this is going to be a problem for Adam DeWitt to solve, as it stems from his chu settings file.

Please back it up ASAP!

I copied a backup of the files and the database to the backup server. When I extracted the tar file, it overwrote the .htaccess file, which caused chessvariants.org to go to chessvariants.com. I will have to rewrite the .htaccess file so that the same file can work properly on both servers. Then I'll be able to test that the database and pages are working correctly over there.

The server never crashed. I was simply unable to boot it back up after attempting a reboot. For those who don't know, this is because the host's website was down, which left me without the ability to access the control panel for the VPS. The host is now back online, and I now have a second VPS with a different company, which has been assigned to the chessvariants.org domain. I will now work on backing up my websites to the other server.

The labels w and W are using paths that do not exist. The value for $dir should be an absolute relative path, not one whose value depends on another path value already being set. The value "/graphics.dir/alfaerie/" specifies a specific directory, but "../graphics.dir/alfaerie/" does not, or it specifies the wrong one, such as "/play/graphics.dir/alfaerie/". While "../" should not be used in $dir, it may be used in the location of a specific piece, because this will be relative to the absolute value in $dir. For example, w may be "../alfaeriemisc/compounds/%zebrawazir.gif".

I don't understand what means "the available includes files" ?

An include file is a file containing programming code that is available for including in larger programs. The purpose behind this is to avoid rewriting code for different programs. Instead of writing each program from scratch, you can include include files to handle things that someone has already written code for. When writing GAME Code, you can use the include command to include the code in a particular include file. These are written as text files and have the .txt extension, which is the default extension for text files. But they are normally included without including the extension in the file name. The include files I have written are all in the /play/pbm/includes/ directory. To include one with the include command, just give its base name, which is the part before the .txt extension. H. G. Muller has written some include files in a different location, and these, I believe, are included by giving its full path and file name.

Where can I find this include file?

It's in the includes directory. So, you just include it by name.

BTW, I did stumble on the method for defining a piece set through assigning to $pieces. Perhaps this is the best method to convert Interactive Diagrams to GAME code, as these Diagrams do specify the filenames of the piece images, the directory where these images are to be found, and the piece IDs (which can be used as labels). So it would just be a matter of dumping this internally held info in the form of a GAME-code associative array, in the code generated for the Pre-Game section.

Yes, that could work, though there is one caveat. When Game Courier is in Edit mode, it does not run any code unless someone clicks Run. This is a safety precaution to allow someone to edit buggy code that would otherwise disable the preset. Consequently, the board may not look right in Edit mode until someone clicks Run. If you use a set file in conjunction with the update-piece-set subroutine, though, it will avoid that problem. However, there could be a discrepancy between the labels used for the FEN code and the notation used in the preset.

To avoid that discrepancy, I was thinking of letting custom piece sets be stored as constants. However, constants are stored in logs, not in settings files. So, I'm not sure I have a good solution for this yet.

I think the unexpected result is due to a space missing between * and 2 in the .dog definition.

Yes, when I corrected that, .dog gave me the correct result.

If I understood the 'new method' correctly, it would require help of an editor to define a new piece set in a PHP file.

No, the new method was provided to eliminate the need to make new set files. I have now written a subroutine that will do the job once you feed it the data. It is in the include file update-piece-set, and the subroutine is called update-piece-set. Just feed it the notation you will use. To make preparation of data easier, you may feed it all the data it needs in a single array. Each array element should be a single piece label or an array including the piece label first and the new notation second. Where a piece label is by itself, it will reuse the same label for the same piece. Where it comes paired with new notation, it will use the new notation for the piece and discard the old piece label.

This method allows the designer to write the FEN code using the original labels, but within the code, it will change the piece labels to the desired notation, and it will strip the $pieces array of all pieces not being used.

You may get data on what notation to use from the user. For each piece, just include an extra field on what notation to use for the piece. When it's left empty, use the original piece label.

@Fergus: can there be a problem with functions that have a name starting with a period?

It would appear so. I ran this code to test this:

def cat * 2 #0;
def .dog *2 #0;
set p fn cat 8;
set q fn .dog 8;
dump;

And the result I got was this:

array(1) {
  [0]=>
  array(1) {
    ["main"]=>
    array(2) {
      ["p"]=>
      int(16)
      ["q"]=>
      array(2) {
        [0]=>
        string(1) "8"
        [1]=>
        string(2) "*2"
      }
    }
  }
}

This may be because GAME Code uses the period to separate array elements from arrays. I would recommend using aliases (old way) or rewriting the $piece array (new way) to avoid the need for writing functions with names that start with a period.

I added a photograph, edited some text, and approved this page. Although my magnetic set folds the wrong way for this game, I put the board on its side, placed the pieces on in reverse along the side files, and reversed the image, so that everything looks correct for this game. I'm not sure this game truly counts as a 3D game, because it does not have a third dimension of movement. Instead, it is a flat surface wrapped around a 3D object, such that there are connections between spaces on the edges that don't normally exist in Chess.

Since what you sent me was not an HTML page with images embedded into it, I mixed what you had written in with what Hans had written, and I included selected photographs. I broke up the image of pieces into individual pieces so that it would flow better. I commented out most of what Hans wrote but left it on the page so that I can later check whether any of it should be included.

I don't see it, and I may not have that address anymore. Please go to my profile and use the address provided there.

would it be possible to have GAME code support operators nolower and noupper, as analogs to isupper and islower?

No, those are already in use for returning arrays of spaces. Also, PHP doesn't have a ctype function for what you want.

E.g. nolower would return true if its string argument would not contain any lower case characters, i.e. if it is all upper case, digits or punctuation.

With #0 standing in for the space with the piece in question, try using match #0 nolower. This will check whether it's among the spaces whose pieces have no lowercase letters in them. Or with #0 as the piece label, you could try not fnmatch "*[a-z]*" space #0. This checks it against a wildcard pattern for containing any lowercase ASCII characters, then negates the result.

Perhaps Fergus can tell if there are alternatives to islower and isupper that ignore non-alphabetic characters, (or judge only the first letter in the string), and thus can be used to reliably recognize color in an environment of names that contain digits / punctuation. My first thought would of course be to outlaw such piece names in the fist place: it seems totally silly to allow such names. There doesn't seem any need for it.

My recommendation is to change the piece labels, which I have previously documented how to do. This would require extra programming, though, which could defeat the purpose of having all the code generated for you. Perhaps code for changing piece labels could be automatically generated with the other code. This would require you to enter both the original piece label and the notation you want to use for the piece. See recent comments to the Developer's Guide for details on what kind of code is needed to do this.

I am not familiar with how these automatically generated presets work. It looks like it might be trying to emulate logical directions without using the built-in support for logical directions. I cannot tell what piece the Mortar is or how it moves from this code.