Comments/Ratings for a Single Item

I have this : script src="/membergraphics/MSgame-code-generation/movepiece.js"> at the end of the preset page. Shall I simply remove this?

Yes.

To put what instead?

Nothing. It is just an alternative version of a script that Game Courier already runs.

And what will be the consequence?

Better performance, because it will not interfere with or replace any functions in the official movepiece.js script.

Will the old games still readable?

Yes.

Any impact on on-going games?

No.

The new CG feature that Fergus added implements largely the same as what before was only possible through movepiece.js, and might conflict with it. I will check whether I should simply remove that file from the server (so that presets trying to link with it won't get any code to overrule the new standard feature), or that there still is some role left for it to play. But on the tablet I have on me I don't even know how to view page source, so it will have to wait.

@HG @Fergus

For the moment, I can't edit any GC Preset file. I don't know why. I get only a blank white page whichever the GC I'm trying to edit. What's wrong?

Yes, right now when I click onto Edit Mode from a preset (mine or someone else's) I have the same trouble - even with a non-rules-enforcing Game Courier preset (naturally not generated by the Play-Test Applet).

For the moment, I can't edit any GC Preset file. I don't know why. I get only a blank white page whichever the GC I'm trying to edit. What's wrong?

It was trying to use some variables that were set only when it runs GAME Code, but in case GAME Code has an infinite loop or some other error that stops it from working, Edit mode runs without running any GAME Code. So, the problem was caused by expected variables not being set. I have now put this code in a conditional that works only when GAME Code has run and set the expected variables.

Regarding the ability to navigate through past moves, I have now gotten it to scroll up the comment for the selected move so that it will be visible once you select the move.

To make it easier to annotate a game, I have added the navbox for moving through the positions to the Annotate form.

In this game you can see that the new navigation system does not account for piece recoloring.

In this game you can see that the new navigation system does not account for piece recoloring.

I'm meaning to eventually get to that. Today I've been working on something else. I've started working on using drawdiagram.php in conjunction with the CSS method to support hexagonal boards. It's drawing an empty board on which I can overlay pieces, but I'm currently having difficulty aligning the pieces with the board.

I'm meaning to eventually get to that.

When you do, can you also add the move back/forward 1 move buttons to the page where you make a move in one of your games? It seems to be missing from that page.

Also, when I try to promote a piece in a log (such as in this log with W 13j-12k; +W-dest), when I click Preview, it redirects to a blank GC preset page.

When you do, can you also add the move back/forward 1 move buttons to the page where you make a move in one of your games? It seems to be missing from that page.

The movenum select element on the page for moving in an ongoing game was originally designed to allow players to take back moves, and since you cannot play as your opponent, it was set up to disable each move you made so that you could only select a last move by your opponent and then make a new move. However, this will still be stopped even if I enable all the past moves and provide one step buttons. So I'll consider it.

when I try to promote a piece in a log (such as in this log with W 13j-12k; +W-dest), when I click Preview, it redirects to a blank GC preset page.

That's weird. After getting the same result, I looked at the HTML code for the form, and I saw nothing amiss. It included values for game, settings, and log.

I tested Shogi to see if it happened there. It did not, though it was using ask instead of askpromote to just ask if you wanted to promote.

Since Chess now handles promotion differently than it used to, I tested Marseillais Chess, which is using an older include file that still uses askpromote. I marched up two Pawns, and it worked fine for both of them.

Turning back to the HTML of your form, I did see that positions had a value, which was unusual. This is used only for the Custom shape, but you were using the Square shape with Table rendering. I did briefly use the $positions variable for what I renamed $posdata before I noticed it was already in use. But using grep to see where I might be misusing $positions didn't turn up anything suspicious. But it did occur to me that during the brief time when I was using the $positions name for $posdata, it could have gotten recorded in your log. That did happen, making your log really huge. I deleted the line, and that fixed things. So, I expect it was such a huge line, it wasn't recorded in full, and this broke your form. I wonder if I'll have to do something to compress the $posdata value for large games like this. In my initial test, it seems to be working fine for your game. I was able to go through the moves in your game from start to finish.

Okay, it works now.

As for the Navigational panel, it's not a huge deal, but it just seemed weird to me that those buttons were missing.

In this game you can see that the new navigation system does not account for piece recoloring.

It does now, though I see I have to do something about the size of SVG images in the Captured Pieces area.

This is more behind-the-scenes stuff, but it will decrease file size. Instead of storing every single full position in the posdata JavaScript variable, it will now store only the original position in full, and it will store each subsequent position only as its differences from the previous position. I got this to work by writing a JavaScript function called getPosition, which calculates a position by starting with the original position and going through all the changes up to the specified position.

I encountered a few bugs while working on this today. At first I wrote a getPiece function, but that wasn't working out when I tried reducing the position data to only what is essential. Then getPosition would work some of the time but eventually break down. I realized that when I copied an array in JavaScript, it was making a reference to the array instead of a fresh copy. So, when I changed what was supposed to be a copy, I also changed the original array, which really messed things up. So, I wrote the function to start with a fresh array I simply populated with values from the original array. This worked, and I made other corrections to get everything working.

If captured pieces are calculated by subtracting the current pieces from the original pieces, then they will be sorted in the order of increasing frequency among the original pieces. Unlike sorting them in alphabetical order, this provides some kind of approximation of their relative value. However, it does not provide any hint of the relative value of pieces appearing in the same frequency, such as Knights, Bishops and Rooks in Chess.

Both the presets for Apothecary Chess Classic and Modern are not allowing selecting pieces with the mouse.

Both the presets for Apothecary Chess Classic and Modern are not allowing selecting pieces with the mouse.

I don't know why other games weren't affected, but I have managed to fix the problem. You should refresh your cache, since I updated movepiece.js.

It seems to not be possible to undo an illegal first move by reverting to the starting position. Could this possibly be changed?

When using the table rendering method, highlighted squares don't stay the same size as unhighlighted squares so the board ends up shifting around a lot when looking at move options. Is this fixable? At least the css rendering doesn't have this problem

When using the table rendering method, highlighted squares don't stay the same size as unhighlighted squares so the board ends up shifting around a lot when looking at move options.

This depends on the size of the individual piece, though some sets, such as Alfaerie, maximize the dimensions of the piece images, so that you may see this effect for every piece.

Is this fixable?

If you made your spaces larger than the largest pieces, you might leave enough room for a border around the piece image without expanding the size of the space. 54x54 might work better than 50x50, for example. However, the square size for the Table method is determined by the $height and $width values, which are provided in the set file, and these are usually set to 50 for the Alfaerie sets.

At least the css rendering doesn't have this problem

One of the reasons to start favoring the CSS rendering method.

Is this fixable?

It is easily fixable, and I think fixing it is long overdue, as it looks very amateurish.

The fix is to display the piece images not as content of the table cells, but as background. So instead of something like

<td style="width:50px;height:50px"><img src="xxx"/></td>

you would generate something like

<td style="width:50px;height:50px;background-repeat:no-repeat;background-position:center center;background-image=url(\"xxx\")"></td>

(where the extensive style specification can of course be achieved through a CSS class). You can then highlight through a border with negative margins. This is how I got rid of these annoying expansion/contraction effects in the Interactive Diagram. (But there I highlight by small symbol images displayed as content of the cell.)

If the cell backgrounds have transparent parts, you see either the specified cell background color there. Or, when no valid color is defined, the background of the surrounding (<table>) element. So you can still use full-board images as background.

The problem is that browsers refuse to fit 50x50 images in 50x50 cells, because they align the bottom of the image with the text line it is on, and text lines need extra space below them for the 'true descenders' on letters like j, p and q. So they always leave some space below the image, even if there is no text at all in the cell. How much depends on the font size that currently applies, but it is not possible to set that to 0.

The fix is to display the piece images not as content of the table cells, but as background.

I saw you doing that for Interactive Diagrams and applied this solution to the Square CSS format. But I did not apply it to the Square Table format, because this is supposed to be an HTML format that will continue to work with older browsers. So, to fix this, I have employed an entirely HTML solution.

The solution in place now is that it reduces the height and width values in the img tag used to display a piece that is too large for the square size. The maximum height or width a piece may now have in the Square Table format is ten pixels less than the $height and $width values. I had to work out some kinks with pieces displayed with showpiece.php. The getimgsize() function, an alternative to GD's getimagesize() function that will work with script-generated images, was not using the correct file name, and I corrected that.

The problem is that browsers refuse to fit 50x50 images in 50x50 cells, because they align the bottom of the image with the text line it is on, and text lines need extra space below them for the 'true descenders' on letters like j, p and q.

I don't think this is true. Each piece image is centered in its table cell. The problem was that when borders are used to highlight pieces, the borders sometimes extend beyond the size of the table cell, causing it to expand in size. By putting a cap on the size of the images, I have stopped this from happening.

That does look better for smaller games. For larger games (like 16x16 Bigorra) where the scale might need to be reduced to see the whole board at once, the images can look too tiny with Table, but that wouldn't matter except that with CSS they don't scale down at all. PNG does scale the pieces correctly, but with that the highlight squares don't line up with the board squares.