Ratings & Comments

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.

Not sure if it's a bug, but for example, fairy-max should be able to play Los Alamos but can't. I've seen keywords "losalamos" and "los-alamos". Perhaps better access to the keywords?

Thanks for pointing this out.  For now, you can get it to work by editing the Los Alamos Chess include file.  Open it with a text editor and add the following line in the first section, where Invented and InventedBy are defined:

XBoardName = "los-alamos";

Thank you for answering.

This game was created in 2006, it worked from creation. Somewhere down the track, for whatever reason, it must of broken. I'll upload file again, thanks.

HG, If you are here please check my previous comments on this post!

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.

The ii modifier (or something similar meaning the same thing) is a genius idea. For the burning, there may be some merit to having something to determine certain specifics of the burning move (i.e. whether the move is passive as well as active, and if it is, which piece has priority in a conflict b/w the burning pieces) with diagram parameters. XBetza wouldn't necessarily be able to handle those specifics on its own.

It looks like this should not be over the limit. Can you send me the include file so I can give it a try?

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

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

I believe this is now ready to be published.

Is there a way to detect suicide moves in GAME code?

There are two ways of doing a suicide, and these have different effects on the $old variable. Adding an @ to a space works like a promotion, which leaves the value of $old unaffected. Moving a piece nowhere gives $old an empty value. This may give a better indication that the move included a suicide, but it would come at the expense of the information about where the piece moved to.

Since it sounds like your Fire Demon piece is making a multi-part move, you may want to break down the whole move and analyze it step-by-step. You will find examples of this in multi-move variants like Marseillais Chess and Extra Move Chess.

With that in mind, another option would be to move the Fire Demon to the piece's space, then immediately move it back.

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.

I'm trying to test a game with ChessV, and I get an error saying "Not enough Zobrist keys" when I try to start it. What does it mean?

You must be using a very large number of piece types on a large board.  There is an upper limit on #Players * #Piece Types * #Squares, although it can be increased if I add more random numbers to the list of keys.  How large is what you are trying to do?

The problem is that there is no file to download. As the author of this page, it is up to you to fix this. Please upload it with the file manager in the same way you have uploaded images. There is a link to the file manager in the Edit menu.

Hi all, thought I would say, from very soon till Christmas and the New Year I should be releasing a few games.

There is a Joy Joyce game, there is a few Charles Gilman games, and I have a game I have done myself, which probably will be the first to come out, and another game by myself that may have some new pieces, amazingly, I say amazingly because they are pretty simple pieces but I cannnot see anywhere that they have been used in any games, but I guess we shall see. I'm sure people will know if they exist elsewhere or not.

Thanks ya'll.

Hello, sorry, but I asked 2 weeks ago if someone could fix this download link, it doesn't work, is anyone able to do it.

Are you here, Greg?

One more reason for no longer supporting offline pages is that many pages now include script-generated images with the drawdiagram.php script. These will work on a website running PHP, but they will not work offline. If I wanted offline pages to support them, I would have to write a script that finds each link to a script-generated image, creates a copy of the image with a unique name, and replaces the link to the script-generated image with a link to the copy of its output. That's too much work for something no one probably needs anyway, and archive.org can already make copies of them.

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

I have been working on replacing absolute URLs with relative URLs. But I had mainly been looking for chessvariants.com URLs. I guess I'll have to look for chessvariants.org URLs too.

I did occasionally use the "info" page, previously linked to from the icon of an index entry. But I do not consider this worth keeping either. Those pages can still be reached from the "info" link in the footer of the item's actual page (except perhaps for multi-item pages?).

That's why I figured it would be okay to get rid of the link from the icon. The link in the footer had been the only link to the info page I had been aware of, and I figured it would be enough for anyone who wants to go to that page. I think most people would be unaware that the icon links to an info page or would just be interested in the link to the actual page rather than the link to a page with metadata about it. The index page really gave no indication that the icons linked to something different than the actual page, and most people who clicked on an icon would probably be surprised that it didn't go to the actual page.

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.