Comments/Ratings for a Single Item

The board is now displaying at the correct size and aspect ratio on both Android phones and iPhones. To make this work, I made sure that each cell of the table was assigned both height and width values and that these values were correct.

I adjusted the code to account for rank and file markers and borders around the board, but the board is too squat on Android Chrome. However, I will stop working on it for tonight.

It looks like a combination of two issues were causing this problem. One is that this diagram had rank and file markers around it, and I haven't done anything to adjust the height and width of the table cells with the rank and file markers in them. The other is that I was using cqi and cqb values in browsers that were apparently treating these units as zero. So, when I first got rid of the file and rank markers, the whole board disappeared on Chrome in my Android phone and on any browser on the iPhone. When I removed the cqi and cqb values from the min function, the board showed up in these browsers at an appropriate size. I still have to fix things for when a board includes rank and file markers, but for now, I have omitted them from this board, and it is displaying properly on phone displays.

I removed the onlyjs class from the diagram, and that seemed to fix the display for Firefox on my Android phone, but it had no effect on Chrome or the iPhone.

I see the same things happening on an iPhone. On my Android phone, Firefox is giving me a similar but larger board display, and Chrome is making the spaces wider than they are tall. I'll see what I can do.

And interactive diagram is still narrowed! What I mean. iPhone SE. https://www.chessvariants.com/membergraphics/who/CryInto/bugultima.png

Ideally, it should set itself to the width of the widest item that will appear in the second column.

To make it work like this, I replaced "display: none" with "visibility: hidden; height: 0px;", and I replaced "display: inherit" with "visibility: visible; height: auto;". So, while the viewport width remains the same, it will no longer jump between a one column display and a two-column display. At the viewport width where it would have been doing this, you will now just get a one column display.

But when I click 'here' to open the piece table, the table opens under the board anyway, and the word I was just clicking jumps away from under my mouse with it. And when I seek it out again, and click a second time to see the legend, it jumps back!

I got it to do that by narrowing the width of the window. The width of the second column depends upon the width of its content, and as its content varies, its width varies. So, at a certain viewport width, it will alternate between being able to fit the available space or being too wide to fit the available space. Ideally, it should set itself to the width of the widest item that will appear in the second column.

And interactive diagram is narrowed!

That should depend upon how wide your screen or window is. I have added code to betzaFlex.js to use more flexible values for the height and width of table cells in the diagram. Instead of assigning a single fixed value to height and width, it calculates the maximum value that will allow the whole board to remain visible in terms of viewport units and container units, and it uses the CSS min function to apply the minimum of these and the assigned value. So, if the viewport is wide enough, it will use the assigned value, and if it is not wide enough, it will use a smaller value that lets the whole board stay in view.

For me the Diagram looks OK. But when I click 'here' to open the piece table, the table opens under the board anyway, and the word I was just clicking jumps away from under my mouse with it. And when I seek it out again, and click a second time to see the legend, it jumps back!

And interactive diagram is narrowed!

I modified this page to use my /fergus/betzaFlex.js fork of the betzaNew.js script, and when I saw the board and the piece table side-by-side, I noticed that the piece table did not update when I switched from one Alfaerie set to another. It apparently updates only when the value of graphDir changes. As a quick fix, I wrote it differently for each Alfaerie set. Two use the full URL with the chessvariants.com and chessvariants.org domains respectively, and one uses a relative URL.

I recently changed the ID script to report non-fatal errors in the definition lines. In this case specification of key=value pairs with an unrecognized key. This should be harmless; such lines are still ignored, and the message would be overwritten as soon as you start manipulating the pieces in the Diagram anyway. It can never be a reason for the Diagram not working (i.e. not showing the pieces, which is what I see).

So it seems we are dealing with multiple causes here.

When I look at the HTML I see two lines at the botom of the Diagram definition that serve no purpose, and don't belong there, setting royal to a value it should already have, and this enableAI=2. The latter is what you would do if there is a permanent piece table somewhere on the page, instead of the one you can open below the board. (Which is convenient in games with drops, where the table is the source of the pieces to drop.) In that case the message for opening the table below the board is omitted, but since that line also contains the "Play It!" link to activate the AI this would make the AI inaccessible. (Which is OK fror drop games, as the AI cannot handle those anyway.) But sometimes you want to display a piece table for other reasons than drops, and then you can force appearence of a link to open the AI panel with this parameter.

There is no separate piece table on this page, so the enableAI=2 line would have no effect, even if it was understood. I think the reason it is not understood is that the line is prefixed with two tab characters; the Diagram parser probably considers these part of the key. Just delete these two lines, or at least the tabs. (WinSCP did not allow me to overwrite the page, when I tried it myself.)

This should make the error message disappear. It would not cure the failure to show pieces, though. For this I am in the dark, as the FireFox console did not report any JavaScript errors for this page. The pieces appear in the piece table you can open, and react to the theme buttons there.

The Interactive Diagram on this page has stopped working, and it says "unknown parameter: enableAI=2". When I looked up enableAI in the code, it was among the public parameters rather than the private variables. So, I don't understand why it should be reporting this message or what I can do to fix it.

Zillions-of-Games follows the convention of treating the color green as transparent, and it ignores any transparencies built into the image.

I don't quite understand the role of green here. In principle, when you take square shades that are not too different (e.g. light and dark brown), you could render the pieces with transparent background on the average color, and then declare that color as transparency. (Or, when you need another color to indicate transparency, use the paint bucket to flood-fill the outside with that.)

I figured out what to do about making the pieces smoother for Zillions-of-Games, which allows only a single fully transparent color instead of multiple partially transparent colors. It's similar to what I've done before in making pieces. While I might be able to automate this, I have been doing it manually following these steps in Ultimate Paint:

1. I open a PNG file.
2. With green (#00FF00) as the foreground color, I color the background green.
3. I make green the official background color and copy the image as a brush, which gives me a version of the image without the background.
4. I paste this brush to the center of a 48x48 grey (#808080) image.
5. I change anything colored #808080 to #00FF00.
6. I save it as a 256 color BMP image.

What this does is turn the partially transparent colors into shades of grey, which looks smoother than letting them turn into black, as they were doing with a simpler conversion. While the look may not be as ideal as what you can get with a PNG file on the web, it's probably the best I can do within the limitations of the graphics capabilities of Zillions-of-Games.

I tried converting three sets of Alfaerie Ultima pieces to BMP images for use with Zillions-of-Games, but I encountered a problem. Zillions-of-Games simply uses the color #00FF00 to indicate what should be transparent, and it ignores the partial transparencies that were in the PNG images. So, in Zillions-of-Games, the results don't look as smooth. Is there any solution to this? If not, I'll try using the original bitmap images and see if they look better.

OK, I created the following SVG:

• pincerpawn
• lizard
• windmill

Thanks, I have now updated the Animals set on this page and in Game Courier to use these pieces.

OK, I created the following SVG:

• pincerpawn
• lizard
• windmill
• princess
• block
• medusa
• gorgona
• crookedbishop
• reflectingbishop

I wasn't asking in general, though.

I was meaning, just in general.

But the Okapi is not one of the pieces used in the game.

But the Okapi is not.