Comments/Ratings for a Single Item

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

@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?

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.

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.

JavaScript can change the pieces on the board only if they are represented by individual images. But the PNG rendering method does not use individual piece images. It displays the whole diagram as a single image like the Diagram Designer does. In many cases, such as this one, all you have to do is change the rendering method to either Table or CSS, and then you can use JavaScript to display past moves without reloading the page for each move.

Looks like there is no much coordination between you Fergus and HG, at least something I can feel, and this is too bad for non-expert in computer people like me. HG's applet has been a real help for me. Without it, I would be unable to make a preset alone. Now, I understand that I would have to modify my presets, if this is true it is a very bad news. I have this : script src="/membergraphics/MSgame-code-generation/movepiece.js"> at the end of the preset page. Shall I simply remove this? To put what instead? And what will be the consequence? Will the old games still readable? Any impact on on-going games?

The following is a link to a game log I looked at where the arrow-buttons didn't work today (other game logs I tried, so far, didn't have the problem, now that I looked at a few more of them) - it's for a CV played on an 8x8 board with 4 armies controlled by 2 players, though I didn't check too carefully how it renders the diagram (says PNG in one place), as it's not a preset I made myself:

https://www.chessvariants.com/play/pbm/play.php?game=4-Handed+Chatarunga&log=panther-zcherryz-2022-123-934

Note that you made your preset for Bigorra with H. G. Muller's Game-Code Generator, and it includes his alternative movepiece.js file. You should remove this from your preset and from any other preset that includes it, because it was designed for his earlier and unrelated system for navigating through past moves, which is not working because of some conflicts with how Game Courier currently works, and it replaces functions from my more up-to-date movepiece.js script.

@Fergus: rectification. When reviewing the game from the first move, it works. Good. Thanks

The arrow buttons for playing forward or back the moves don't seem to be working now for me, too. It was working two days ago, if not yesterday as well.

Make sure your rendering method is either CSS or Table and that your shape is either Square or Custom Grid. It will not work for rendering methods that draw the entire diagram as a single image, as GIF, JPG, and PNG do. Also, I have not added support for hexagonal, circular, or spherical boards.

I just tested it with the only available game of Bigorra, and it works easily. Start by going to the first move with the |< button, and then go to subsequent moves with the > button or with the down arrow key.

The arrow buttons for playing forward or back the moves don't seem to be working now for me, too. It was working two days ago, if not yesterday as well.

Dear Fergus, thanks for your effort. Alas, I'm not able to operate it. It works to show the diagram for a given move, but then when I try to go ahead or back I see no change on the diagram. I'm reading your explanation but I don't understand what you have written. Your answer is so complex, I'm lost. I'm going to see if I can manage it with ID. Thank again anyway.

Yeah, I mean using the keyboard arrow keys.

This is already working without explicitly adding support for it. The trick to it was that the drop down menu required focus before you could use arrow keys to navigate it, and while clicking on a button was changing its value, it was not giving it focus. I fixed this by giving focus to the SELECT element whenever a button above it is clicked. Once you give it focus, whether by clicking on it or on one of the buttons above it, you can navigate through it with the keyboard. The left arrow, up arrow, and PgUp button all move the selected line up, which takes it back to previous moves. The right arrow, down arrow, and PgDn button all move the selected line down, which moves it ahead to later moves. Also, the Home button takes it to the first move, and the End button takes it to the last move.

That could be hard. I think there are security issues with reading the keyboard from JavaScript, and that it is therefore forbidden, unless you give focus to a HTML element that obviously allows it (i.e. a text input) with the mouse.

Yeah, I mean using the keyboard arrow keys.

I think Daniel means to be able to use the 4 arrow keys on a keyboard (rather than clicking on arrow-buttons with a mouse). I guess that could be doable, especially if exactly 4 (or less?) options to choose from with the keyboard arrow keys is all that's ever wanted for a given application. At the moment you've got six options with the arrow-buttons you've placed for GC navigation.

Isn't that what it already does? Or do you mean something other than navigating through the past moves of a game?

What would make this even better is being able to use the arrow keys to navigate the game history.

This is a nice improvement to Game Courier, Fergus. A lot of chess sites have used similar buttons for viewing the playback of a recorded chess game, for a number of years now.

I was wondering if there was not something more user-friendly. On large board (e.g. 16x16), one has to scroll the screen to reach the view button and as the full board seems to be reloaded with few seconds latency, it is quite difficult to see if a piece has been taken. Going back to check is only possible by selecting the move in the list. Which is slow in long games.

I have been working on this the past couple days, and my position navigation controls are now ready for public use. Buttons appear above the drop down list of past moves, and these control navigation through the moves. There are some differences in the buttons for viewing a game and making a move in a correspondence game. The former has options for moving back to the beginning, back two moves, back one move, ahead one move, ahead two moves, and ahead to the last move. When the current move isn't the last move, it also has a button for going to that move. Since the latter has moves a player cannot go back to disabled, it has buttons for going back or ahead one turn instead of one or two moves. For the shape/render combinations of square/table, square/css, and grid/css, selecting a move with either the drop down list itself or with the buttons for navigating through it, the position will change to match the selected position. For other shape/render combinations, the buttons will facilitate navigation through the list of past moves, but they will not change the position of the pieces on the board.

You can view legal moves only for the move initially shown. While this is usually the latest move, Game Courier has long had the ability to view past moves through its usual server-side interface. When viewing a past move this way, you will be able to see the legal moves for it (assuming its preset supports them), but you will not be able to see positions past it, because to calculate the legal positions for that move, Game Courier stopped early and did not calculate the later positions. So, to view every position of a game in the new JavaScript-aided manner, you should start by viewing the latest move in the usual server-side manner.

Instead of calculating FENs based on the moves, I have had Game Courier produce an array called positions, which contains the position before and after every move, as well as information on the origin and destination of each move.

Because I had already used the name positions for the custom shape, I changed the new variable's name to posdata. Also, it only contained the position data before each move, and I added in the position data for after the last move after runsubroutine() completed. So, now the >| button works correctly.

I fixed yours yesterday to get a better idea of how it worked, but today I have been working on new code for doing the same kind of thing. I have had the new controls visible only to me so that the bugs I have to fix don't affect users. I have now made it visible to editors in general, though not others, so that you might take a look at what I have so far.

Instead of going in movepiece.js, I am writing code for individual parts of Game Courier. So far, the navbox that appears in View or Solitaire mode has controls above it. These controls affect the move shown in the box below, and for some shape/render combinations, they change the position on the board. So far, the square/table, square/css, and custom grid/css combinations support viewing past moves. Each does this with its own updatePosition() function, which is customized for how it displays the board. So, I have to do one combination at a time, and I don't think I'll be able to do it for boards rendered entirely as a single image.

Instead of calculating FENs based on the moves, I have had Game Courier produce an array called positions, which contains the position before and after every move, as well as information on the origin and destination of each move. It's able to use this to highlight not only the official origin and destination spaces but also any space that has changed from the previous move. To distinguish these from the main ones, I have made these additional borders circles. I then used it to view a game of Ultima, and it also highlighted the spaces pieces had been captured from.

Some things I still have to do are add controls to the form for moving in a correspondence game and stop legal moves from displaying for moves other than the current one.

I'm unable to use the mouse to select pieces in any of these games.

Sorry, I made a typo today. It's now corrected.

I'm unable to use the mouse to select pieces in any of these games.

https://www.chessvariants.com/play/pbm/play.php?game=Atlantean+Coffee+House+Shatranj&log=arx-cvgameroom-2023-258-846

https://www.chessvariants.com/play/pbm/play.php?game=Bigorra&log=arx-cvgameroom-2023-268-989

https://www.chessvariants.com/play/pbm/play.php?game=Enhanced+Courier+Chess&log=sissa-arx-2024-17-995

https://www.chessvariants.com/play/pbm/play.php?game=Cetran+Chess+3&log=arx-sissa-2023-334-071

OK. The navigation is further dependent on the presence of an array impmoves, which contains the FEN, and the number of all moves with implied side effects. In the GAME code generated by the Play-Test Applet these can only be castlings and e.p. captures. The JavaScript extracts the moves from the move list (on the page as a pulldown), and then marks all the implied moves by appending "; #" to them. When encountering such a marked move during navigation, it distinguishes castling from e.p. by the ID of the moved piece; if it is K/k it also moves the Rook, if not it removes the last moved piece.

It is imaginable, though, that some presets would have other moves with implied side effects (i.e. not written in the move list). E.g. Advancer or Withdrawer capture, burning by a Tenjiku-Shogi Fire Demon... So to meke this more generally useful it would be helpful if there was a second list of moves hidden in the page that would specify either all board mutations, or those not explicitly specified by the move list that is presented to the user. Together with a FEN of the initial position, and the list of images to use for the pieces, that would make local navigation possible as a standard feature for all presets.

I got it to work by rewriting GetPieces() like this:

function GetPieces() {
  // if(tabs.length < 2) return;
  AddButtons();
  for (let key in pieces) {
    pieceURLs[key] = dir + pieces[key];
  }
}

dir and pieces are new JavaScript copies of the PHP variables $dir and $pieces, which are normally defined in a set. They used to be in a showPiece() function, which I got rid of today, because as far as I could tell, nothing was using it, and there are other alternatives now. But I kept the lines defining these variables and gave them global scope.

I picked up this style of defining functions from Jocly; I now believe it is completely equivalent to the other method of function definition.

It was long ago that I wrote this, so I have to look it up now in the code as well. But 'tabs' is an array that holds all HTML table elements, and it is tested whether the first of these has id="board". The second apparently is expected to be a table of piece images, where the column headers are piece IDs, and the columns then contain the image. For the navigation to work, it needs to know the initial setup; this cannot be derived from the current position and the move list, as pieces could be captured before they moved. So the GAME code includes a FEN for it. Together with the move list and the knowledge of implied side effects that determines all positions in the game, in terms of piece IDs. But to display the position it needs to associate IDs with images. Some pieces in earlier positions might no longer be on the board in the current position, so it cannot get those from the board. Therefore it gets them from the table (function GetPieces).

But if the table is missing, there is nothing to get, and it cannot reconstruct earlier positions. Therefore it also doesn't create navigation buttons. If you make it create the buttons desppite the fact that it has no associations between IDs and images, the dislay function doesn't know what pieces to display. This explains why you see an empty board.

Apparently the page is no longer formatted as the code expects it to be.

@Jean-Louis: you could try to delete all spaces that separate the piece ID from the coordinates. You might have to remove the hyphen between the squares too (I am not sure about that). Of course it is essential that the Diagram would use the same piece IDs as GC; otherwise you should remove all those two. (Since GC notation always mentions the full origin coordinates, it should be redundant.)

@HG: in fact my current need is to study a game of Bigorra, which is very long with 245 moves. I need to see when and how a piece has captured another one. The game I study has been played on GC so I have its recording. Alas, on GC the captures are not recorded. This is why I need to scroll all the game along.

As you pointed out, scrolling with GC is not optimal. I wish I could transfer that game onto ID in order to scroll and replay it. Is there a way I can do that easily. When I simply paste the list of moves into ID I get an error. What should I do to get a list of moves understood by ID?

Thanks

If you changed the name of the routines called as event handlers for the mouse clicks on board squares, then you have indeed broken the presets using this code.

The functions I mentioned are only called in movePiece(), and we each have different versions of that function. So, that might not be a problem. However, I did notice that your definition of movePiece() starts like this:

movePiece = function(c) {

Is that just an alternate way of defining a function, or does it make a difference?

I think the new functions I wrote were for the purpose of handling multi-part moves with a common first move. In games like Fusion Chess, it can pop up a requester asking which full move a player wishes to make.

That doesn't explain the non-appearence of the button bar, though, as this is done by the initialisation code, and is not triggered by mouse clicks.

Through testing with a copy that I can add alerts to, I found this line to be the problem:

  if(tabs.length < 2) return;

This appears just before AddButtons(); in GetPieces(). An alert works before this line but not after. Using an alert to report the value of tabs.length, it is 1.

By commenting out this line, the buttonBar shows up, but when I try to navigate through a game, it does nothing but clear the board.

The statuss element is something I use while debugging; by having its object available in a variable it is easy to put error messages in the innerHTML there. After I had debugged the code the statuss element was removed (it would only be in the text part of the preset I used for debugging), and all displaying of error messages was removed, so it doesn't hurt that statuss is now undefined. I could have removed this line too, but leaving it in makes it easier to resume debugging in case of trouble.

If you changed the name of the routines called as event handlers for the mouse clicks on board squares, then you have indeed broken the presets using this code. Proper operation depends on the functions being called. That doesn't explain the non-appearence of the button bar, though, as this is done by the initialisation code, and is not triggered by mouse clicks.

I think most of the functions is the same as your originals; the reason I overruled thos was not because I wanted different behavior w.r.t. the mouse clicks. But l changed the HTML representation of the board on initialization, with the routine FixBoard: this makes the piece images background. I did that to get rid of the annoying expansion and contraction of board ranks when the rank became empty, or a piece on it got highlighted. But this means that the event handlers also have to modify the board squares in a different way in response to the clicks.

Perhaps something changed in the layout of preset pages that broke things.

I'm currently looking at your movePiece.js code. I see that GetMoves has this line:

  statuss = document.getElementById('statuss');

However, there is nothing on the page called statuss, and your code doesn't create anything with that ID.

I also think your code may be based on an old version of movePiece.js. While yours has the functions showLegalFrom() and showLegalTo(), mine uses the functions showAllLegal() and showNextLegal(). I do recall using the other function names at one time. Since I did not describe them with comments, it's just the function names and the code itself that might tell us the difference between these.

Perhaps something changed in the layout of preset pages that broke things. The script tries to insert them into a HTML element with tagname 'kbd'. (The function AddButtons, which is called from GetPieces, which is called after a 500ms delay from GetMoves, does that. This is conditional on an array 'impmoves' being defined on the page, though. Which the betza.txt include would do, to relay which moves had implied side effects.)

The idea was indeed that the functions in movepiece.js would overrule those defined on the page (of which they are modified versions) earlier.

Presets automated with GAME code generated with the Play-Test Applet have such buttons to navigate through a game locally. At least if they include the JavaScript it suggests in the HTML rules section.

My Experiment preset has included the JavaScript you suggest, but it's not providing any navigation buttons. I added type="text/javascript" in case that would help, but it didn't. I also checked that JavaScript functions can overwrite other JavaScript functions with the same name, which is also how functions and subroutines work in GAME Code. So, trying to redefine functions is not the problem. Your MovePiece.js script comes after mine on the page and should overwrite any functions with the same name. So, I imagine something is broken in your script.

I understand the design choice of letting the navigation be handled by the server rather than locally through JavaScript was made for the benefit of users with JavaScript switched off.

Not quite. It is mainly that Game Courier is a server-side project with some client-side enhancements, which is in contrast to the Interactive Diagrams, which is a client-side project with some server-side enhancements. So, each does some things better than the other. Also, I don't have the same experience you have in client-side programming, and I more frequently approach things from the server-side. But I am interested in adding this as a further client-side enchancement to Game Courier.

Presets automated with GAME code generated with the Play-Test Applet have such buttons to navigate through a game locally. At least if they include the JavaScript it suggests in the HTML rules section.

The problem is that this JavaScript cannot be used for other automated presets, because it is unaware of automatic side effects (i.e. board modifications not explicitly indicated in the move notation). Such as e.p. capture and castling. The GAME code from the Applet solves this by including a list of such moves as JavaScript array hidden in the preset page, which the navigation code then uses to see where it should apply side effects to the moves in the official move list that the user can see.

I understand the design choice of letting the navigation be handled by the server rather than locally through JavaScript was made for the benefit of users with JavaScript switched off. But it is a pity that the interests of such mostly hypothetical users goes at the expense of actually existing users like Jean-Louis and me, for which the server-side implementation is so woefully inadequate that it is totally useless, and I have long since accepted that in practice Game Courier just doesn't support navigation through existing games. (For me the problem existed even in small games, where no scrolling is needed, because long delays occurred in page loading due to adds present on the preset page, and even on a good day when such delays were seconds rather than minutes the board image would jump to different locations on the display from move to move. I doubt, btw, that users with JavaScript off would think the existing system satisfies their needs.

I used to see something like that on presets made with H.G. Muller's GAME-Code Generator, but when I went looking to see how it worked, I couldn't find any that did that anymore.

I see. I was wondering if there was not something more user-friendly. On large board (e.g. 16x16), one has to scroll the screen to reach the view button and as the full board seems to be reloaded with few seconds latency, it is quite difficult to see if a piece has been taken. Going back to check is only possible by selecting the move in the list. Which is slow in long games.

Ideally, one would need a control zone with arrows to go back and forth. Thanks anyway, I will see if I can manage my study like this.

View mode lets you view successive moves 1 by 1. To view a move, you should select it and click the View button, which will load a new page with a different position. If you start from the beginning, it will automatically select the next move for you, so that you can go through a game just clicking on the View button.

@Fergus: I need to study some past games played on GC. How to "scroll" in a given game in order to see the successive moves 1 by 1?

I know how to visualize a given position, but I can't find how to scroll in the list of moves.

I don't know if this feature exists.

Thank you

This and other changes I tried making to the code didn't help. So, I undid them all to avoid introducing new bugs with code that didn't solve the problem anyway, and I deleted every variable assignment in your settings file that was to an empty string.

Games with a rank label of 0 don't display correctly, as can be seen in Apothecary Chess Modern. It looks right if the rank label 0 is replaced with something else

Another game with this problem is Rococo

Now that Daniel brought this problem up, I should also note that presets with a Max Columns value of 0 don't display, only showing the following text.

When cols is zero, you don't have a board. Exiting before it tries to divide by zero.

An example is my old Hook Shogi preset and other old presets, for which I did because I was younger and less experienced.

Thankfully, this is very easy to fix. Throw in a clause in the script that forces the Max Columns value to be 1 if the field is evaluated to be 0.

Pseudocode, assumes val("Max Columns") has been pre-validated to let only integers through.

if (val("Max Columns") == 0) { cols = 1; } // Set Max Columns to 1 to prevent dividing by 0 or a negative number

else cols = Math.abs(val("Max Columns")); // Valid value (take absolute value to ensure proper division)

How would I go about programming the King to be able to swap places when capturing its own pieces? Like I could swap a pawn next to the King and still have all of the check detection. What I have now is letting me capture my own piece, but I can't drop it back down to where the King was to imitate a swap. The code successfully says that it swapped but the piece remains taken.

sub k from to:
  verify fn km #from #to;  // legal king move
  verify sub hw #from #to; // dont mind this
  if not #ktest:           // whether or not to just test legality
    if and $lastcaptured (isupper $lastcaptured):
      say Swap King {#from} with {#to};
      drop $lastcaptured all #from;
      set k #to;
    endif;
  endif;
  return true;
endsub;

edit: entirely my fault, i didn't have any code in my Post Move section so it didn't actually run the k subroutine. i made it so it drops the piece where it moved from

Games with a rank label of 0 don't display correctly, as can be seen in Apothecary Chess Modern. It looks right if the rank label 0 is replaced with something else

Another game with this problem is Rococo

The problems with Hexagonal Chess and Napoleonic Chess are now fixed.

Now the default presets for Glinksi's and McCooey's Hexagonal Chesses are broken. Neither one shows any legal moves.

Separately, this preset just shows the board but the rest of the game interface is missing.

Here are a few things to keep in mind about reassigning the value of $pieces.

1. This does not give players the option of choosing different sets unless you explicitly build this in.
2. When you use the pc shortcode to display piece images in the description, they may not always be accurate. However, if you are providing only one set, you can get away with direct links to the piece images.
3. When you go to the Related menu and select Diagram Designer, it will usually display your diagram with the wrong images.

It appears to be fixed now

Okay, there was another section of code to update. How does it look now?

Now the images are reverted still, but all the pieces also have black backgrounds

I have now added some new parameters to showpiece.php. The image parameter is for the relative path to a file, and the originalcolor parameter is for the original color of a piece. With these, a piece can be specified and recolored without providing the set and piece label, and I have modified draw_square_table.php to use these new parameters when using showpiece.php.

Here is what was going on. I recently added the feature to recolor pieces across all rendering methods. For tables, it recolors pieces by linking the IMG tag to the showpiece.php script instead of directly to the image file, and it identifies a piece by its set and label. Although you were not recoloring your pieces, the color name began with a # sign for one variable but not for a variable it was being compared with. So, even though the colors were the same, the == comparison indicated that they were different, and it linked to the showpiece.php script instead of to the image. For the sake of more accurate color comparisons, I wrote a new function called samecolor, which puts each color string into a uniform format before comparing them. Using this function, the color of your pieces matched the original color, and the link used the image instead of the showpiece.php script.

I'm not sure what is going on. However, switching to the use of aliases should fix this.

Yeah, I can do that. I just wish it weren't necessary since it means modifying every preset that uses this method, which was working perfectly until just recently. It seems to only happen with HTML Table rendering, so it could be circumvented by settings affected presets to use a different method by default. That still means modifying a lot of broken presets to fix this.

It's happening with A, S, G, and D. These are the four that are assigned to images that originally had different piece labels. Curiously, when I have it display a list of the pieces, it shows this, which I believe is correct, yet it still shows the wrong pieces.

Array
(
    [k] => bking.png
    [K] => wking.png
    [q] => bqueen.png
    [Q] => wqueen.png
    [r] => brook.png
    [R] => wrook.png
    [b] => bbishop.png
    [B] => wbishop.png
    [n] => bknight.png
    [N] => wknight.png
    [p] => bpawn.png
    [P] => wpawn.png
    [A] => wmage.png
    [a] => bmage.png
    [G] => wpegasus.png
    [g] => bpegasus.png
    [T] => wtiger.png
    [t] => btiger.png
    [S] => wslidinggeneral.png
    [s] => bslidinggeneral.png
    [U] => wunicorn.png
    [u] => bunicorn.png
    [D] => wdragon.png
    [d] => bdragon.png
)

But when I assign pieceset to a variable and have it say it, it gives me an empty string. However, it appears that the value of pieceset is not the problem. Despite having the correct images in $pieces, it is displaying the original images from the set.

I'm not sure what is going on. However, switching to the use of aliases should fix this. Using aliases will not change the labels used to display pieces. With aliases, there is a strict separation between your labels and your notation, and you should always see the correct images. The main catch is that you have to make sure all your functions, subroutines and other code properly handle aliases. The fairychess include file, which this preset is using, does properly handle aliases, and you just have to make sure that any additional code also handles aliases. Check the tutorial for this include file for more information.

It doesn't happen when I use the Play button, but when I use Move and try to move pieces the images change. Also, in this ongoing game I see it after each move, but before I move it all looks ok.

Okay, pieceset is a function, not a variable. So, ignore my advice to use $pieceset.

I have not been able to reproduce the problem in this game. Can you set up an example for me to look at?

This same problem is also in this preset, using this code:

set mypieces ();
set mypieces.k $pieces.k;
set mypieces.K $pieces.K;
set mypieces.q $pieces.q;
set mypieces.Q $pieces.Q;
set mypieces.r $pieces.r;
set mypieces.R $pieces.R;
set mypieces.b $pieces.b;
set mypieces.B $pieces.B;
set mypieces.n $pieces.n;
set mypieces.N $pieces.N;
set mypieces.p $pieces.p;
set mypieces.P $pieces.P;
if == pieceset alfaerie-allsvg:
  set mypieces.A pieceimg .W;
  set mypieces.a pieceimg .w;
  set mypieces.G pieceimg .P;
  set mypieces.g pieceimg .p;
  set mypieces.T $pieces.T;
  set mypieces.t $pieces.t;
  set mypieces.S $pieces.GG;
  set mypieces.s $pieces.gg;
  set mypieces.U $pieces.U;
  set mypieces.u $pieces.u;
  set mypieces.D pieceimg .D;
  set mypieces.d pieceimg .d;
endif;
setsystem pieces #mypieces;

I tried changing pieceset to $pieceset, but that just caused the pieces defined in the if condition to be replaced with black circles.

One thing I will note is that I no longer recommend editing the $pieces array. This is a bad practice, and I regret coming up with the idea. I now recommend the use of aliases as best practice.

IIRC the possibility of the $pieces array was created because users wanted to combine piece images from different 'sets' (perhaps even standard sets supplemented by images uploaded by themselves to the /membergraphics/ sub-tree). Aliases don't do that for you; they just allow you to rename the pieces in a given set.

It is indeed inconvenient that expanding a set is done by execution of Pre-Game code. But the alternative, asking an editor to create a new set including the desired extension graphics was even more inconvenient.

It would be good if there was a way to assign arbitrary images (i.e. anywhere in the public_html subtree) to to piece labels without invoking GAME code. Just like you can specify a FEN for a preset, and the corresponding position will already be displayed on the preset's page even before you start running the preset.

I've mainly seen this in generated presets, but it doesn't look like it's doing anything very obscure so I thought it was worth asking anyway. Now I have a question about the use of aliases. Does aliasing only allow using images from the currently selected piece set?

This is another example of reverting to the piece image originally assigned in the set file.

I do not see what could be causing the problem this time, and since this is an automatically-generated preset, it is beyond my usual expertise.

One thing I will note is that I no longer recommend editing the $pieces array. This is a bad practice, and I regret coming up with the idea. I now recommend the use of aliases as best practice.

The same problem is happening in presets that don't check the value of pieceset. The Skica preset I mentioned at first has this

set mypieces assoc
  P "wpawn.png" p "bpawn.png"
  N "wknight.png" n "bknight.png"
  B "wbishop.png" b "bbishop.png"
  R "wrook.png" r "brook.png"
  Q "wqueen.png" q "bqueen.png"
  K "wking.png" k "bking.png"
  C "wcamel.png" c "bcamel.png"
  W "wwildebeest.png" w "bwildebeest.png"
  I "wbishopinv.png" i "bbishopinv.png"
  U "wqueeninv.png" u "bqueeninv.png"
  S "wrookinv.png" s "brookinv.png";
setsystem dir "/graphics.dir/alfaeriePNG/";
setsystem pieces #mypieces;

When you made your last bug report, I did see a huge problem that I immediately fixed, and that problem is indeed gone now. But I now see that you were describing a different problem. Pieces identified as s/S change from the Chinese Pawn image to the Promoted Rook image. Checking the set, I see that s/S is assigned to the Promoted Rook image, though judging by the number of them, they should not be Promoted Rooks in this game. In the code, these lines are used to assign the Chinese Pawn image to s/S:

if == pieceset alfaerie-metamachy:
  set mypieces.s pieceimg cp;
  set mypieces.S pieceimg CP;
endif;

When I use the PNG or CSS rendering methods, the s/S pieces continue to use the Chinese Pawn image. But when I use the Table rendering method, they change to the Promoted Rook image. The problem may be that pieceset does not return the value of the variable, making the behavior of the conditional iffy. This should work instead:

if == $pieceset alfaerie-metamachy:
  set mypieces.s pieceimg cp;
  set mypieces.S pieceimg CP;
endif;

[Edit: pieceset is a function, not a variable. So, $pieceset should not be used.]

Okay, I fixed that. There was a namespace conflict with a new feature I added just a moment before you posted your bug report. I've now changed it to not conflict.

That didn't fix it. It looks like the image shown in the confirmation page is ignoring the changes made to piece labels and images in the pre-game code. I'm seeing the same problem in some other games too, such as this one.

https://www.chessvariants.com/play/pbm/play.php?game=Maasai+Chess&log=arx-cvgameroom-2022-323-205

Okay, I fixed that. There was a namespace conflict with a new feature I added just a moment before you posted your bug report. I've now changed it to not conflict.

https://www.chessvariants.com/play/pbm/play.php?game=Skica&log=sissa-arx-2022-289-168

In this game I'm seeing the piece images change after I make a move and before I confirm the move. That makes it awkward verifying that the move I made is what I really want to do.

This is a small sample, if I did everything I'd be spending all day:

https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=dax00-cvgameroom-2020-304-184 https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=per31-cvgameroom-2019-145-205 https://www.chessvariants.com/play/pbm/play.php?game=Shogi&log=niccar-krinid-2004-167-366

https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=hambledon-sdc.stats-2008-361-709 https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=tamandua-cvgameroom-2015-24-775 https://www.chessvariants.com/play/pbm/play.php?game=Ultima&log=sissa-tamandua-2013-90-201

Please give me links to specific logs.

A lot of the logs of some games return error messages:

For Ultima it says that a certain line contains a syntax error, e.g. Syntax Error on line 585

For shogi it says that a given move was done illegally, e.g.:

ILLEGAL: g 4i-5h on turn 6:

The move MOVE: g 4i-5h ain't well-formed. g is a coordinate. So 4i should be a hyphen.

There may be others I haven't noticed.

For games using a Rank label of 0, the 0 rank is not displayed and any pieces starting there are shown as captured.

That's now fixed.

For games using a Rank label of 0, the 0 rank is not displayed and any pieces starting there are shown as captured.

I tried starting a game with the following time settings

Spare Time 1 week
Grace Time 24 hours
Min Time 2 days
Bonus Time 12 hours
Max Time 2 weeks

It wouldn't work, saying that I shouldn't set Min time above Max time

Does the Alfaerie-Many set affect the time it takes to process a move? I've been working on a large preset and whenever I tried it using alfaerie-many it never even finished running the pre-game code.

I don't think that would work. White could use his first turn to advance  its entire army 2 ranks, which would give him a significant space advantage.

I'm not great with Game Code, so I might not have the best advice. I don't think there's any way to have real-time movement. Maybe you could approximate it by letting players take turns making any number of moves until a capture occurs.

Hey all, new user here. Question, I'm trying to program Senterej, the Ethiopian Chess variant into Game Courier. Would anyone have a recommendation for coding the mobilization phase? (where pieces can be moved freely until the initial capture)

I searched game courier to see if it was coded for play already and did not see it

Thank you very much

Okay, I fixed the error, and the King can capture the piece on b2 now.

Hello Fergus, it's in this game: lunaris-cvgameroom-2022-24-568 when i now try to capture with my king (a1-b2) this happens. Maybe there's something else wrong in the rules enforcement, but it shows this error message. I created this file based on shogi, meaning i edited the shogi preset.

Can you give me a link or a series of moves in which this error comes up?

Hello, for some reason i get the following error message in a game of judkin shogi:

Syntax Error on line 587

The cond operator requires at least three arguments.

Since that line is from the shogi include file, which i suppose was well checked, i don't know how i could possibly correct that. Who can tell me, what's the problem? I copy and paste the relevant part (from the pawndropcheckmate subroutine - even though i didn't use a pawn in my move) the relevant line is the one with an arrow.

sub pawndropcheckmate pawn spot:
    my allies;
    local king kingmoves black test to;
    verify empty #spot and onboard #spot;
    if == #pawn P:
        set king where #spot 0 -1;
        set black true;
    else:
        set king where #spot 0 1;
        set black false;
    endif;
    verify == space #king cond #black k K;
    set kingmoves merge leaps #king 1 0 leaps # 1 1;
    for to #kingmoves:
------>     if not cond #black islower isupper space #to or empty #to and onboard #to:
            move #king #to;
            set checked fn cond #black ATTACKEDBYW ATTACKEDBYB #to;
            restore;
            verify #checked;
        endif;

Thank you, Armin