Comments/Ratings for a Single Item

Thanks, Haru! The only ones that seem readily translatable into XBetza are the Complete Permutation Winged Cardinal, and (with some effort) the Carronade.

I think I'll go my own way with the Moose Pawn and Shield Archer.

You've been quite helpful!

Is there a maximum to the number of icons the system can handle at a time? I uploaded a few more earlier, and everything vanished from the diagram except the sample chessboard (the version that shows a piece's moves). I deleted a dozen of the new files, and it all appeared again.

I see that you have given the same ID to multiple pieces, and I'm wondering if this might be the cause of the issue you're having.

It's not inconceivable. With some of these, I'm not sure why there's an ID shown as assigned at all; nothing below the Virtuoso should have any. The only pieces with IDs explicitly assigned are the Pawns, those assigned in the original Playtest Applet (unnecessarily, I think, except for the Knight), and Centauride and Okapi (again, probably unnecessarily).

Afterthought: One of the pieces I deleted was 1rook, and it may have had a conflict with 1bishop. I'll see what happens when I upload the other deleted ones.

Status Report: It wasn't just the one. The board came back after I'd deleted four pairs of files, then disappeared again when I added one back. It seems to be currently maxed out at 512 pieces (1024 images). I'm not sure if another binary digit can be added to that, to make it 1024 pieces (2048 images).

The Interactive Diagram represents pieces by numbers internally, and the piece ID is just a property of the piece, like the name or the move. So there should not be any problem with representing pieces by the same ID. (Not even in notation; the SAN generator and parser are smart enough to disambiguate moves of pieces with the same ID to the same square, even if they are of different type. Drop moves would be a problem, though.) If he wants to select pieces which have the same ID in the table, the user can always change the ID of one of those.

The DirList function for fetching pieces not originally mentioned in the diagram definition would remove originally mentioned pieces for which the image cannot be found in the searched directory, and would then add the images that were found, but not originally mentioned (with a name identical to the name of the image file, and the first letter of that as piece ID, but no move). This adding is done by adding piece lines to the Diagram definition, before parsing the latter to make a Diagram. Since defaulting of the image name to the piece name is only done after parsing, I suppose that predefined pieces without image name can indeed get removed in this process.

There seems to be a problem caused by having multiple Diagrams on one page (in the Comments listing), where a problem in one Diagram (an undefined image name) seems to spill over to other Diagrams. The first thing to do in such a case is always to test whether a Diagram works in isolation, by clicking the View link in the comment.

In principle JavaScript errors can be traced (in FireFox) by hitting the F12 key, and looking in the console. You have to look really hard, though, as loading a CVP page typically produces dozens of errors from JavaScript in the ads. But when I scrolled back far enough I did find a complaint against JavaScript in the betza.js file, for your forelast Diagram in this topic thread.

As to a limit on the number of piece types: you will probably get in trouble for 250 or more, since holes in the board are represented by 250. Originally there could be 511 types, as the 512 bit is used to indicate the piece has moved. (So one could say there are two times 511 types, the virgin types and the 'has moved' types, and moving automatially promotes to the latter.) Later I decided that 250 would probably be enough, and the 512 and 256 bits in promotion codes now are used to indicate explosions.

The 1024 bit is used to indicate color. Higher bits in the codes in the board array are used as markers for the square, e.g. to indicate whether a destination corresponds to a castling or e.p. capture, or is under attack by an enemy (so that moves of royal pieces to it should be indicated y a gray cross). This is used by the old move-entry system; the newClick routine in betzaNew.js would not need it. (But even there move diagrams are still displayed with the aid of the old highlighting routines, as these also must indicate invalid moves, like captures to an empty square, something that newClick cannot do yet.)

There are enough bits available there, so in principle everything there could be shifted to higher bits, making more low-order bits available for representing the piece type. But that would require changing the code in many, many places. And not only that, but also all custom scripts added to individual Diagrams all over the site, which now rely on 1024 representing color and 512 representing virginity. So it seems this would only be feasible by creating a new fork of the Diagram script, incompatible with all existing Diagrams. The use of which would interfere with Diagrams on the same page using the old script, as they contain functions with the same name, which would redefine each other. So I think prospects for an expansion are pretty bleak.

The ID wasn't really designed for the purpose of implementing Play-Test Applets. If you really want to provide an unlimited choice of piece icons, I guess the easiest way to program this is similar to the way the new Play-Test Applet I am developing now handles mutiple types with identical icon (through a duplicate button): allow the user to add a number of 'very exotic' icons he needs to the Diagram's table, selecting those from some other table that you embed yourself in the page (E.g. showing white icons only, without name or move, and let a click on those add them behind the King, which then would also reveal the image name.) Perhaps all automatically added pieces should go into this table.

The problem is pretty close to what I assumed. I think I'll wait until I have an opening in the pages, and make the Icon Clearinghouse its own thing, a display page similar to the graphics pages already on the site. I'll reserve the ID here for use as a personal "notepad" of sorts, reminding me of what moves I associate with what icons. (That'll allow me to take out certain icons that I'll never use myself.)

...allow the user to add a number of 'very exotic' icons he needs to the Diagram's table, selecting those from some other table that you embed yourself in the page (E.g. showing white icons only, without name or move, and let a click on those add them behind the King, which then would also reveal the image name.) Perhaps all automatically added pieces should go into this table.

I think that this would be a good idea.

This is a rather ambitious game, but because of all the preparation it takes, I'm afraid it may not attract many players. However, I believe it is doable with Game Courier. Many years ago, I gave Game Courier the ability to use cards. See my game Magic Chess for a demonstration. If you would provide a deck of cards as separate images, I could upload it to the /play/pbm/cards directory for use with Game Courier, and then you could get started on programming the game.

That sounds awesome! I'll get started soon on the image-based cards. It'll probably be a bit of a challenge, since I created them using WordPerfect, but I'll see what I can figure out.

(I actually had planned to print out the cards and pieces, and get a 12x12 board; I described the game to a friend, and she seemed very interested.)

In your opinion, should I include the Expansion Sets? (I'm inclined to, if I can make their inclusion optional for the game initator.)

In your opinion, should I include the Expansion Sets? (I'm inclined to, if I can make their inclusion optional for the game initator.)

Yes, that's fine. You could make separate presets for each one or try to create a single preset that let's you choose from multiple options.

So far I've been able to get the three basic sets into a properly-sized (2 3/4 x 4 1/4) "one card per page" format for a PDF, but converting them to PNG (or any other graphics format) is proving to be a bit of a problem.

I can take a while at it, though, since I'd rather not post it without being able to run my SVG set through H.G.'s scalable graphics editor (even if it takes a bit of "creative piracy" to do it). There are just too many pieces here (especially in potential future Expansion Sets) that can't be properly represented with the existing art.

I just took a look at some of your cards on Thingiverse. Each one had an image of one of your 3D pieces with nothing more. For Game Courier, it may be appropriate to use cards with a 2D image matching the piece set used, include the name of the piece, and maybe a short description of how it moves, even if just in Betza code. Also, this may be doable with a script, which would avoid the need to draw each card by hand. I could even write a script that draws a card on demand from certain query parameters, which might give you more flexibility in creating decks of cards.

"Nothing more"? Each card should include the piece's name at the top, a movement diagram right below the picture, and move description at the bottom.

For the GC deck, I'll replace the 3D image with the icon I'll be using (good thought; I should've had it myself). While some of the Royals, Pawns, and Expansion Set pieces will be using composite icons, the Pieces from the main deck all have individual icons, so I'll at least be able to get a start on that.

I think I only saw your .stl files for printing the pieces, and I didn't find the PDF file you mentioned.

Click on the "Files" tab and scroll down to the bottom of the list.

Both Unipawn & Midbrother are from Three Fat Brothers Chess.

Midbrother icon also have been used for this

Thanks for the tip, Haru! Since none of the pieces can really be expressed on an Interactive Diagram as described in either game, I feel better about misusing them for my own purposes.

For Game Courier, it may be appropriate to use cards with a 2D image matching the piece set used...

I got a start on this (I got all of the Pieces done, in fact) and realized that the icon on the diagram should match the one used on the board, which I don't currently have a way to do.

Let's start by getting your SVG pieces uploaded to a subdirectory of /graphics.dir/. If you upload a zip file of them, I can transfer them to an appropriate subdirectory.

@Bob: could you also upload the zip file I sent you with my graphics?

If you do so, maybe Fergus will also be able to place the content of this zip into the graphics folder to replace my old ugly "Cazaux's graphics" in https://www.chessvariants.com/graphics.dir/index.html

Thanks

I hope you don't mind that they're in multiple ZIP files.

First
Second
Third
Fourth
Plus
Tifinagh

I likely will delete those ZIPs once the subdirectory is full.

(I also may have more to add later, based on what I find I need for these cards. I can think of at least one or two right off the top of my head.)

I'll do that after I delete the ZIPs of my SVGs, and post the link on your profile.

Thanks, your SVG files are now in /graphics.dir/svg/Greenwade/.

Awesome! Thanks, Fergus. That'll be a big step in the right direction. I'll try to get some things figured out from here (though of course I'm wide open to advice and suggestions).

I am working on an automatic set with some additional short labels. It is working with Game Courier and the Diagram Designer. I'm having some issues with displaying it in tables, but I'm having the same issue with the Automatic Alfaerie SVG set. Here's an example:

To get them to work right, I used sed to replace every instance of "fill:#ffffff" with "fill:#f9f9f9", because there needs to be a distinction between the piece color and the background color for the script to recolor the pieces, and #f9f9f9 is the piece color previous SVGs standardized on.