You certainly know how to push the ID to its limits...

It appears unloading of locust victims was not implemented in the betza.txt GAME-code include file; if an unload was specified it would always use the piece that was in the destination square. I now added some code to replace that by the locust victim if there was any, and the destination square was empty.

This is all related to lack of a clear definition on what the XBetza u should do, and which I have been hesitant to specify. The original idea was to unload the piece taken at the destination. But since that leaves the case where the destination was empty useless, I let the ID use the locust victim as backup. Which was unambiguous at the time the ID would only allow a single locust victim. But then the newClick move entry allowed an arbitrary number of those. And I already made an exception that a u on the leg immediately following a c or d leg would prefer to unload the locust victim of that preceding leg, rather than the victim at the destination, to make the friendly/enemy-hopping kludge work. (This is already implemented at the parsing stage of the XBetza, so it would work for ID and GAME code alike, and none of the involved modifiers would be treated as a locust victim or unload at execution.)

So the currently applied rule is (1) replace all cau/dau combinations by a hypothetical p'/p" for enemy/friendly hopping only, and if a u is left, unload there (2) the victim at the destination, or if not present (3) the locust victim. There is no provision for when multiple u are left; I guess these would unload the same.

The friendly-hopping kludge is not really needed anymore in the ID, now that the captureMatrix can specify a hop ban based on the involved colored types: one can simply specify p in the XBetza, ban hopping over all types of one color, and allow it over all types of the other color. But the GAME code does not implement capture matrices yet.

For the time being it is still undefined what would happen for a true unload when there are multiple locust victims and no replacement capture. (A case that the current GAME code does not support anyway.)

@ H.G.: The Lariat's behavior in the GC preset is even worse than in the ID. It doesn't seem to work at all, and I don't read GAME code well enough to figire it out on my own.

This is the game that I'm working with, with Daniel Zacharias. I get the same error message he does, trying to use my Lariat.

That's not super surprising, as there isn't a page for Zw;

I've corrected that.

I did think that, by now, one would've been created.

No, it helps a lot to draw things to our attention. As the only one with a game starting with Zw, you were the natural one to notice this omission first.

@Fergus: This game is still not in the alphabetical index.

That's not super surprising, as there isn't a page for Zw; but I did think that, by now, one would've been created.

I published this. Since it doesn't use the usual equipment, I unchecked the two usual equipment categories it had checked.

One could, instead of the old | system, use a compound with one piece inverted (though it's actually the second piece that's affected, not the first). For example, for a charging rook.

And that turns out to be not such a great solution after all. It works fine for a piece illustration such as the above, but there's not really a way to implement that for an Interactive Diagram or anything else that appends a prefix. So, something else will have to be figured out. (Maybe an asterisk could be a wildcard for the color prefix, so _*rook becomes an inverted Rook? I have no idea whether that or anything like it would actually work; I'm just throwing out ideas.)

But like I said previously, there's no rush. My first time actually using such pieces will be for the Spears Expansion in Dealer's Chess, which won't be introduced to Game Courier until I do the 10x10 version; I'll have to finish the 8x8 version first, and that could take quite a while.

I have now unzipped Greenwade7.zip and Greenwade8.zip.

Turns out, there are some errors, so I'll be sending one more file.

Probably not today, though. Likely tomorrow.

My apologies (the errors are my own fault).

I don't think it looks so bad.

Not as good, but still not horrible.

Despite the misbehavior of the Lariat and Power Queen in the ID (which we can work on later), I think this is suitable for publication.

Addendum: I also updated the IDs for Vanguard Chess and Hundred Acre Chess.

Indeed, I just wanted to show a compound. Hawk was an improper name anyway, originally I wanted to show Lion + Bishop (Tenjiku Shogi's Lion Hawk), but it did not look so nice. I was too lazy to look up which pieces you actually had, but I figured you would have 'bird' in analogy with Alfaerie.

Thanks! :)

@Fergus: Once my two latest updates are in my SVG directory, I'll be a happy camper, and be able to stop pestering you for a while. :)

I have now unzipped Greenwade7.zip and Greenwade8.zip.

I actually had tried flushing my cache a few times while working on that; but the important thing is that it looks good now.

I do like how the combined pieces are implemented in this version better than the original. It's clearer, and one is less likely to lose details. One could, instead of the old | system, use a compound with one piece inverted (though it's actually the second piece that's affected, not the first). For example, for a charging rook.

BTW I do have a hawk icon in place , though I acknowledge that you may have used the compound to demonstrate the use of compounds or because you don't like how this hawk looks.

I was not aware of it, but I understand why it gave trouble: the | is also a character that in the eyes of the shell terminates the command. I changed the fen2.php script now to also escape that with a backslash.

This still doesn't make it usable in an ID, however, as there is no trick similar to the -- to derive the color of the second piece from the first. This could be implemented in fen2.cgi, of course. But the result of the | is often quite ugly; perhaps it wasn't such a good idea to have it at all.

Another problem for use in the ID is that a rotation specifier before a combined piece does not act on the second piece. But it seems unlikely that anyone would ever want to rotate combined pieces.

If you refer to your diagram a few comments earlier in this thread, I don't think the s=50 could have been the culprit. For one, this would be a legal request, (even though it is also default). And it did work when I added it to my Diagram below. This morning the board of your Diagram was completely empty. But after I created mine, I suddenly noticed that the pieces were also displayed in yours. So I think browser caching has been fooling us here, and that the only thing the removing of s=50 did was bypass the browser cache, which still must have contained corrupted images from before we fixed the ampersand problem.

I compared the page source from your diagram to the one from mine, and saw that mine had the s=50 argument where yours did not. I removed it and it works fine now (as you may be able to see for yourself), so that was clearly the culprit.

@Fergus: Once my two latest updates are in my SVG directory, I'll be a happy camper, and be able to stop pestering you for a while. :) (Especially if at least one or two of my "unprocessed submissions" get published. But not the Icon Clearinghouse pages, yet!)

PS: While I was experimenting last night I found that the | function doesn't work (yet) in the local fen2. Most likely you're already aware and working on it, but I thought I'd let you know just to be sure. (There's no rush, at least for me; I'm not going to need it for a little while.)

I don't know where you posted the case that did not work, but it seems to work for me:

It doesn't look fixed from here. I also tried putting it into the main article again, with the same result.

By the way, opening the piece overview shows the icons as expected. It's only on the board where everything looks like the Alaferie White King.

I fixed this. It was a matter garbage in, garbage out. Because of something to do with posting this in a comment, each ampersand was replaced with &. So, I added some code to replace amp; with an empty string before passing the data to fen2.cgi.

By the way, opening the piece overview shows the icons as expected. It's only on the board where everything looks like the Alaferie White King.

The only difference between this ID and the one in the main article is that this one replaces  http://winboard.nl/my-cgi/fen2.cgi with /cgi-bin/fen2.php (and I did capitalize "Greenwade"):

Confirmed: the Lariat in the ID definitely has more range than the intended four spaces.

The Power Queen also seems to be capable of locust capture, which is not my intent.

Those will need to be fixed, as well as the questions in the previous comment answered (or left be), before this is truly ready to go live.

OK, those newer icons are uploaded and in the article now.

I'm still considering changing the Flash Bishop to or something similar.

And I'm wondering if the icons in the article shouldn't be white instead of pink (though I kind of like them this way).

I've updated the Interactive Diagram to the one that I posted in the Comments, but I'm going to have to wait for tomorrow to update the graphics in the Pieces section.

Once I've taken care of that, I think this will finally be ready to publish.

Thank you, Fergus & H.G.! This is pretty close to how I imagined the board looking from the very start.